The CANary project

[TickTock]

I think how you connect the USB Vbus depends on the use model. Since CANary is the Host, it needs to provide 5V to the device (thumbdrive) so I connected the VU (5V out) to the USB connector. If we were using CANaray as a device (and it was drawing it's power from the host on the other end), I think we would connect the USB power to the VIN. If you are planning on feeding 5V into the Vin, then I think you can do what you say.

I found the schematic of the mbed LPC1768 module and it shows pretty clearly that the VU pin is not really good for anything but getting 5V specifically from the built-in USB port, when it is plugged in to a computer. Back-feeding it with 5V only makes you consume another 5mA through that 1kohm R15, and lets 5V get to the onboard LM1117's through two diodes instead of one. So, I will disconnect it and feed my 5V separately to VIN and the USB host port.

Since you are generating 5V, I agree with your plan, but I think you are misunderstanding the use of that USB port. There are actually two USB ports and the only one you will ever connect to a PC (and back feed 5V) is the one already on the mbed at the top. The one we added to the CANary board is only to attach a USB thumbdrive (device) so you will never back feed 5V in that path. However, if you are generating 5V with your own DC-DC, I agree you can connect the USB VBUS to that +5V supply (which you also plan to connect to Vin) instead of VU. Gotta run now - will digest the rest a little later.

 

[garygid]

Wonderful development, I am watching with interest.

I have not had the time to keep my "roadkill" (flat)
version of CANary up to date, but I am watching.

I am working on the Arduino Due based controller
for charging batteries, to become a mini-QC controller.
I am trying to write some crude simulator software,
to better test communication and logging.

But, excellent work, guys!
Cheers, Gary

 

[TickTock]

Does the MCP2561 operate with 3.3V? I chose the VP230 simply because it was the first I found that operated at the native 3.3V levels of the mbed.

Yes, the MCP2561 can accept any voltage from 1.8 to 5.5.

I scanned the datasheet and this does look like a nice option. Pin compatible with the VP230 so I may give it a shot. I like the "permanent dominance protection feature." The only thing that may be a problem is the slow wake time (up to 4us) whereas the VP230 indicates only 1.5us max wakeup time. So the MCP2561 may miss some data while in standby. Maybe this was what was wrong with the "bad batch" I had that I thought behaved like VP231s. It may just be that my first batch was a good one with a faster wake (0.55us min) and was able to wake fast enough to get the message that awoke it. Now I understand your comment about the TD jumper. You were suggesting never putting the device into standby and blocking TX that way.

I don't think I need a pullup on the Rs since I actually *drive* it to 3.3V when disabled (it is a digital output) so it already has a very strong pullup.

Then what is JP-ETX for? I thought that was the jumper you pulled during bench testing to make it not transmit. When you pull that jumper, you need a resistor (pull-up or pull-down) on the RS pin to keep it from floating.

I see - maybe you are right, but my reasoning was the pin may be used to set the slewrate. Higher R to ground means slower slewrate so inf. R to ground should mean zero slewrate. Seemed to work that way.

I am curious why you thought disconnecting TD would be necessary to ensure RX operation, though. My understanding is Rs high should be sufficient to disable TX and should not interfere with RX.

In the '230 part, pulling RS high disables the TX and switches the RX into a low-speed/low-power mode, enough to detect activity but with a time delay on the output. I wasn't sure if the Leaf's bus as fast enough for this to garble any packets, but if did, then you would want to leave the RX in high-speed mode (RS low) but still disable the TX. It sounds like this isn't really an issue since you guys are running with TX enabled pretty much all the time.

Yup - Before we learned how to query for cellpairs and Ahr, etc, we used to keep it in standby only and that seemed to work. In fact, Gary's original SOCmeter was hard-wired permanently in standby mode. Maybe we were dropping a frame or two on wake but all the useful information was repeated often enough that it worked. If you want to make sure you get every frame then you are probably right - it is best to just leave it in active mode.

I had another crazy idea last week, before I found your page: to modify the VSP sounds by putting a relay in the speaker harness so I can switch between the stock sounds and user-generated sounds of my own choosing. I was looking at using something like the MP3 Trigger board, but now I might tie it into the CANary and use the mbed's analog output to play sounds from the flash. That way I would not have to hang another snooper off the bus to get the shifter position and speed, and would only require a couple more headers on the board.

Sounds cool. It would be a little more useful and intuitive to have voice messages rather than cryptic beeps. Thing like "Heater On" or "You just lost a capacity bar." You could have a lot of fun with your SO. I am pretty sure I could write an algorithm to detect my wife's driving and give helpful comments like "Really?" and "Don't mind that curb - I've been meaning to get new tires anyway."

 

[JeremyW]

I had another crazy idea last week, before I found your page: to modify the VSP sounds by putting a relay in the speaker harness so I can switch between the stock sounds and user-generated sounds of my own choosing. I was looking at using something like the MP3 Trigger board, but now I might tie it into the CANary and use the mbed's analog output to play sounds from the flash. That way I would not have to hang another snooper off the bus to get the shifter position and speed, and would only require a couple more headers on the board.

Sounds cool. It would be a little more useful and intuitive to have voice messages rather than cryptic beeps. Thing like "Heater On" or "You just lost a capacity bar." You could have a lot of fun with your SO. I am pretty sure I could write an algorithm to detect my wife's driving and give helpful comments like "Really?" and "Don't mind that curb - I've been meaning to get new tires anyway."

The ability to make my leaf sound like a Jetsons' car and have a custom annunciator? YES PLEASE!

Found a link for some Jetsons car sounds: http://www.findsounds.com/ISAPI/search.dll?keywords=Jetsons

 

[robot256]

(Not quoting text because it's too hard to edit on my phone, but this is in response to TT on more of the schematic.)

In the '230 datasheet, table 6 shows the Rs pin functions. Stantdby is when the pin is held >0.75Vcc (2.4v). Non-slew rate controlled mode is when Rs is pulled below 1V (i.e. zero ohms to ground.). Slew rate limiting is active when a resistor with 10k<R<100k is connected to ground, presumably because there is an internal voltage divider that raises the pin to the 1 to 2.4V range. But nowhere does the datasheet actually say what the pin does when left disconnected--you just got lucky that it floats low. This is liable to change in future revisions of the part or at different temperatures, so a pulldown is in order.

I think the issues you had with that batch of '230s might be related to this. Also could be related to the fact that while if you stay in active or standby you get a clean signal, but if you change mode during a packet you will get garbled data unless you get really lucky with timing and part selection. You could try waiting until the end of the packet that wakes you before switching to active mode.

I found the schematic for the mbed dev board and realized the true purpose of the VU pin. When you power the board only from the mbed programming port, you connect VU throught a diode to the slave device port, so it will get 5v also. I will add diodes so it looks like the dev board circuit, then you can test the usb drive stuff on the bench without a power supply.

 

[TickTock]

Thanks robot256. I think I finally understand the point you are making. I can eliminate the LM1117 if I just set the DC-DC to 5V and provide that directly to the slave USB port. Adding the diodes as you say will give you the same bench functionality as the existing design but save the 5mA leakage in R15 and reduce the power used by the mbed. The elimination of the LM1117 is nice, too, since it frees up board space.

 

[robot256]

I found the datasheet for the LCD module used on the TFT Proto: http://www.mikroe.com/downloads/get/1009/tft_320_240_touch_spec.pdf. It says the backlight LEDs use 60mA total with a drop of 2.9-3.4V. It is clearly designed to be PWM-controlled directly from a 3.3V rail, but I'm a little wary of drawing that much power from the mbed's regulator (and USB port), and also loading the supply to the CAN transceivers. So we can instead use the 5V DC-DC output, and put them in parallel, each with their own 30 ohm series resistor.

The displays, I think, draw too much power to supply from the USB input, but we can safely hook up the flash drive port so you can test it without a power supply. Or should this be an option, to allow everything to be powered from the USB port?

EDIT: How much current do you usually end up using in your backlights? If you always run them at half power, we could maybe hook them to the USB input after all.

 

[TickTock]

Yeah, I powered them off the 7V DC-DC/Zener output for the reasons you stated. 5V should work fine, too. 30 Ohms each or 15 Ohms total - either works. I can't recall actually measuring the current but I have my PWM set at 80%. Unfortunately, my filter circuit results in a non-linear relationship so it's not a straight scalar. The PWM outputs aren't strong enough to sink that much so you will need the transistor. I chose to filter the PWM output at the base of the transistor to avoid flicker (figured the non-linear response wouldn't be a bad thing either). Was afraid the flicker would be annoying in your peripheral vision (where you are most sensitive to flicker) if I just let the pwm drive it unfiltered.

 

[robot256]

Flicker shouldn't be a problem if we use somethimg like a 1khz clock. Removing the filter and replacing the BJT with a MOSFET should reduce the overall current draw.

It occurred to me this morning that we could have two transistors and control each backlight separately. Then you could do things like flash one or the other when its data updated or an event occurred.

 

[TickTock]

The higher efficiency switching approach should work, too. More than one way to skin a cat as they say. One nuance of the mbed you should keep in mind is there is only one PWM counter. Although there are multiple semi-independent PWM outputs, they all share common hardware. I didn't know this and was wondering why the display blinked after emitting a beep. Not HF flickering, it would just turn off whenever I ended the tone (but turn back on on the next per-second "tick" update). Similarly, if you change the frequency of the PWM counter (like when you wish to emit a specific tone), the display PWM frequency will also be changed. I do restore the PWM to 1kHz at the end of each speaker beep now and most tones are >1KHz so the frequency change is almost imperceptible even when you are looking for it. If you implement the audio speaker idea, then this issue goes away since you will no longer use the PWM to drive the speaker.

 

[robot256]

Reading a bit on using the DAC output to play sound files, it may take a lot of CPU power. In that case, it might be better to use an external MP3 chip. Would streaming a wave file from the USB drive use too much bandwidth? I'm not too sold on the idea of anything but beeps in the cabin, so I would plan to keep the speaker on the PWM output since you have it working pretty well now. I'm planning to order the Application Board so I can play with various sound-making methods. I'll have more time to look at it later.

EDIT: I also just noticed that you forgot to put the 15k pull-downs on the USB host port data lines, the application board has. Wonder if that explains any of the USB detection anomalies you have seen.

 

[TickTock]

Reading a bit on using the DAC output to play sound files, it may take a lot of CPU power. In that case, it might be better to use an external MP3 chip. Would streaming a wave file from the USB drive use too much bandwidth? I'm not too sold on the idea of anything but beeps in the cabin, so I would plan to keep the speaker on the PWM output since you have it working pretty well now. I'm planning to order the Application Board so I can play with various sound-making methods. I'll have more time to look at it later.

EDIT: I also just noticed that you forgot to put the 15k pull-downs on the USB host port data lines, the application board has. Wonder if that explains any of the USB detection anomalies you have seen.

Yes! Although my s/w work-around (polling) seems to work it would be nice if the hot plug detection mechanism worked on an interrupt.

Wrt sound, there is plenty of CPU power to spare... if you don't mind missing a frame time to time (only really an issue if you are logging). Worse-case, the display may take a second to update. To keep components down, maybe we can just disable the audio when logging. Speaking of dropping frames.. the only thumbdrives I've found that never drop a frame are the microSD readers with a class10 microSD card. Even the ones that advertise high write speeds started dropping frames (write buffer overrun) after a few weeks of use.

 

[garygid]

I thought that somebody said that the 15k resistors
were not needed on the Mbed USB port because
that was already handled internally (in the chip?).

-----
My experience writing streams of data to a USB Flash
Drive and a USB adapter for an SD card (with the Mbed)...
Typically the write (of 14 binary bytes of data) would
return quickly, but some took some ms, others took
longer (tenth of a second), and infrequently the delay
was as much as 750 ms (almost a second).
The Flash Drive was worse than the SD adapter.
One needed a substantial buffer to hold about
one second's worth of the logging data stream.
At 2000 messages per second, 28k bytes of buffer.

----
Of course, one might reduce the data rate by only logging
the first and last of any string of identical messages.
Then, if the data is not noisy, and just changing
occasionally, one skip logging the redundant messages,
typically logging two whenever the data changes.

One could analyze some logs to determine how beneficial
the skip internal-redundant messages might be.

-----
I include a pseudo-messages in the log whenever a
message, or sequence of messages, cannot be stored
in the ring buffer. Others prefer to just discard the
excess data. I prefer to know if any were lost, and
how many were lost.

Cheers, Gary

 

[robot256]

I just ordered the mbed and Application Board that Sparkfun sells. I'll be able to test various audio playback and USB connections with it. I'm basing my circuit updates largely on the Application Board's schematic, which includes the 15k resistors.

I made a first pass at the schematic. I tidied things up and found the right capacitors for everything. I also threw in a few extra audio circuits, including an LM386 amplifier, which you could use to play back voice announcements on an internal speaker.

 

[TickTock]

In-line images work great for simple schematics. Otherwise, maybe a dropbox with the eagle files. Do you plan to use the enclosure or design a new one? It would be great if you could keep the holes and USB connector in the same locations so it could be retro-fitted into existing enclosures.

 

[robot256]

In-line images work great for simple schematics. Otherwise, maybe a dropbox with the eagle files. Do you plan to use the enclosure or design a new one? It would be great if you could keep the holes and USB connector in the same locations so it could be retro-fitted into existing enclosures.

I found my imgur login and updated my previous post with the schematic image. I am hoping to use the same enclosure design, maybe with a few tweaks. Making it physically compatible should not be too difficult.

 

[TickTock]

What kind of diodes do you plan to use for the supply isolation? The USB voltage spec is 4.75-5.25V. Have you located a good diode with <250mV turnon voltage? Or will you set the 5V to be higher (although that only works for D1 - VU really wants to be directly connected to the slave)?

 

[robot256]

I found the same diodes that the application board uses in the same place, i think BA60A. Forgot to put the part number on the schematic.

 

[TickTock]

I found the same diodes that the application board uses in the same place, i think BA60A. Forgot to put the part number on the schematic.

But those won't work how you have them connected (will result in 4.3V to the slave device). [Edit]One option is to remove D2 and set your 5V output to 5.7V. However, if your DC-DC can tolerate 5V getting back-fed in from the Host connection when there is no 12V supply, you can eliminate both and leave the DC-DC at 5V.[/Edit]

 

[TickTock]

Picking up a few more CANary owners. Kudos to robot256 for reading all 62 pages but I figured it probably isn't reasonable to expect everyone to do so. So I started a user guide page on the wiki. Pretty crude right now but will embellish along and along.

http://mbed.org/users/TickTock/code/CANary/wiki/guide