User avatar
TickTock
Posts: 1701
Joined: Sat Jun 04, 2011 10:30 pm
Delivery Date: 31 May 2011
Leaf Number: 3626
Location: Queen Creek, Arizona
Contact: Website

Re: The CANary project

Fri Nov 08, 2013 9:19 am

Rev 157 is now published. Three main new features:

1) expanded configuration screen into two screens to accommodate configuration of the new features (tap Next/Prev to switch screens)
2) added a mute/un-mute toggle in the upper right corner of all screens (except the config) which will silence all audible indicators.
3) added a heater monitor that alerts you when the heater turns on

That last feature is less useful to 2013 models but in AZ with the single setpoint climate control, it is common to need AC driving home but then have the heater turn on the next morning if you forget to turn off the CC. I've sometimes gone 20 miles or more before I realized I was burning an extra 2kW. Very annoying. So now, if enabled, the CANary will emit a 0.5 second tone when it detects the heater turning on. It does not sound for the AC - just heat.

robot256
Posts: 21
Joined: Wed Nov 13, 2013 2:47 pm
Delivery Date: 02 Mar 2013

Re: The CANary project

Thu Nov 14, 2013 11:14 am

Hi everyone! I just finished reading all 62 pages of this thread, and I am extremely impressed by what you guys have accomplished this year. I am looking forward to building a CANary of my own (for my 2013 Leaf) and helping out as time allows.

Full disclosure, I am an electrical engineer with a lot of programming and circuit experience, so I saw a lot of familiar lessons in your development history. I also fall into the category of "never got a bleeping ARM toolchain to install properly", so I was thrilled to learn about the mBed platform through your project.

You guys have already figured out my biggest concern with the circuit: zener regulators are terrible for sensitive circuits. Then again, so are DC-DC converters from the Chinese factory reject bin (e.g., what you usually find on eBay), so for future builds take a look at one of my favorite Texas Instruments modules: http://www.mouser.com/Search/Refine.asp ... =pth08080w. Use one of these to go from 14V down to 5V, and use an LD1117 to regulate the 5V down to 3.3V. Much less power, heat, and headache. Just be sure to follow all the module datasheet's filter capacitor specs and you will have no noise issues at all. :D

It looks like the link to the Eagle files on the mbed.org CANary page is broken. I would like to get my hands on those (and maybe expand the board so that the DC-DC and battery fit). Also, do you have the 3D model source file for the enclosure posted anywhere?

Leafman's discovery with the CAN bus filters chokes was very educational. I guess Phil's advice was spot-on after all.

And not that it matters now, but the reason your zeners got so hot is because your leads were too long. The best heatsink in your project is the PCB itself, and long leads prevent the heat from conducting into the PCB. The surface area of they leads is so small that they "sink" almost no heat at all.

Thank you everyone, especially TickTock and Gary, for posting your work for all to read and share. I can't wait to dive into the code, but alas, grad school exams take precedence. I'll be watching for updates!

User avatar
TickTock
Posts: 1701
Joined: Sat Jun 04, 2011 10:30 pm
Delivery Date: 31 May 2011
Leaf Number: 3626
Location: Queen Creek, Arizona
Contact: Website

Re: The CANary project

Thu Nov 14, 2013 1:14 pm

Welcome! Looking forward to seeing your enhancements to both the board design and software. Also, thanks for the heads up about the broken link. It should be fixed now.

If you are going to spin a new board, there is one improvement that Gary suggested which I wish I had implemented. Wiring up the LCDs is a very tedious task. Adding a small board to connect to the displays such that a 0.1" pitch header or similar can be used to automatically hook up would be a big improvement. If you do decide to explore this, take care, though, that it fits in the enclosure. The footprint is limited by the space behind the center console so it is a bit cramped in there.

robot256
Posts: 21
Joined: Wed Nov 13, 2013 2:47 pm
Delivery Date: 02 Mar 2013

Re: The CANary project

Fri Nov 15, 2013 9:21 am

Thanks for fixing the download link, I have a copy of the Eagle files now. Might I suggest also adding a link from that page to this forum thread?

I like the idea of making a little connector board for the LCDs. I might even go a step farther and make them use FFC jumpers to the main board.

I'm going to list a few of the PCB changes I'm thinking about so you can comment on them before I start making changes:

On the two breakout boards:
* My interpretation of the OBDII spec is that "signal ground" is intended to be the return path for the single-ended K- and L-line serial connections. Since all we use ground for is shield and power return, we should connect both to "chassis ground" at this board, and have them fan out separately from there.
* Nice job with the shield pins between the signal pairs on the FFC connector. It is also good that you have them not connected to anything at the CANary board--this directs any noise the shield picks up back into the chassis, not into your board.
* Since I would like to use CAT6 the whole way, I am thinking about putting a row of holes on the OBD breakout, or possibly an RJ45 jack. That way I can still use the filter chokes on the board. Thoughts?

On the power distribution at the main board:
* In my new scheme, unswitched 12V will go straight to the PTH08080W, which will produce 5.0V, eliminating the zener and the LD1117.
* The 5V rail will go to the mbed Vin pin, so there will be as little heat as possible generated on the CPU card itself regulating it to 3.3V.
* The same 5V rail will power the LCD backlights.
* The 3.3V rail will stay the same, coming out of the mbed to power the CAN transceivers and LCD drivers.
* The VU pin of the mbed says "5.0V USB OUT" in the documentation. This page says the Vcc on the host USB connector should be connected to VIN (i.e., external 5V supply), and not connected to VU.

Other things:
* I believe this was hinted at somewhere in the thread, but the operation of the 65HVD230 CAN transceiver is undefined when RS is unconnected. There should be a pull-up resistor to 3.3V at the pin so that it is held high (standby) when the TX jumper is removed.
* More imporantly, though, have you had any trouble receiving the 500kpbs CAN bus while leaving the transceiver in "low speed standby" mode? If so, then there should probably be a separate jumper on the TD line to properly disable TX while leaving RX active.
* I might suggest switching to the Microchip MCP2561 transceiver. They are a little cheaper, I have had good results with them and they include slew-rate limiting without any extra resistors. Thoughts?
* ADC inputs have the best accuracy in the middle of the range. For the input voltage sense, we know it will always be in the 11-15V range. If we change R2 to 5.1k, 13V input gives us 1.5V at the ADC, right in the middle of the 3.3V range.
* Your backlight circuit is clever, but I'm pondering whether switching to a 2N7000 MOSFET and removing the filter capacitor (and moving it closer to the PWM pin) will give better efficiency. Does Q1 get hot when operating at half brightness? How much current do the backlights draw at your typical high and low brightness settings?
* Just curious, where did you get the speaker circuit? What is R5 for (does it make the sound different)? We'll have to hook the speaker to the 5V rail with my new regulator design, but that works just fine in my experience.
* And finally: decoupling capacitors! We need to add 0.1uF ceramic capacitors near the VCC pins on the two CAN transceivers. This is important :)

EDIT: I think I will also add a PTC fuse on the 12V inputs at the OBD breakout board. That should keep a short circuit from either hosing the car or melting your wires.

GoneSilent
Posts: 33
Joined: Tue Oct 22, 2013 12:01 am
Delivery Date: 22 Apr 2013
Location: Oakland, CA

Re: The CANary project

Fri Nov 15, 2013 12:38 pm

robot256, if you make a run of pcb's I'd like to buy one to build up.

User avatar
TickTock
Posts: 1701
Joined: Sat Jun 04, 2011 10:30 pm
Delivery Date: 31 May 2011
Leaf Number: 3626
Location: Queen Creek, Arizona
Contact: Website

Re: The CANary project

Fri Nov 15, 2013 12:45 pm

Lots of great stuff! I was going to build another that I could loan out but now I think I may wait until your CANary2000 is ready. ;)

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 agree, eliminating all the linear regulators except the 5V-->3.3V is a good improvement. The PCB still gets quite warm even with the Zener replaced with a DC-DC due to the LM1117.

I don't see any issue adding the holes to the OBD breakout. However, I *really* like the flex cable. It has very good signal integrity (as shown by the scope captures with and without earlier in this thread) but best of all slips under the trim without any danger of flex or wear. Others have shown that CAT5 can squish pretty flat and doesn't distort the dash much but, OK, so I'm a little OCD. Also, if you are going to use CAT6, you can omit the breakout all-together (only really need chokes on the main board since all the electronics in the LEAF have their own) and make a low profile connector.

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. That said, there have been some issues with the VP230 so it is worthwhile to look into alternatives. You read about the bad device that interfered with nanaleafman's car. I also have a batch that behaves like VP231 (Rs would disable the RX, too) although they are marked VP230. 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. 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. There are a number of features that rely on the ability to TX to query for information. Probably the most notable is the individual cellpair voltages. If you disconnect the TX by pulling the existing sleep/txen jumper or the proposed TD jumper, you will not be able to get that data. So I question the value of another jumper except for diagnostic purposes.

Not much feedback comes to mind on the other suggestions - all seems like good stuff. You can make a lot of room for extra components and connectors if you remove the battery holder. I had to remove it anyway to clear the display so it is just wasted PCB area. Good spot to add the display connectors and breakout boards.

robot256
Posts: 21
Joined: Wed Nov 13, 2013 2:47 pm
Delivery Date: 02 Mar 2013

Re: The CANary project

Fri Nov 15, 2013 2:55 pm

TickTock wrote:Lots of great stuff! I was going to build another that I could loan out but now I think I may wait until your CANary2000 is ready. ;)
High expectations! Let's hope I can live up to them...

Thanks for the feedback. I don't think I'll have time to finish redoing the board until December, but I'll post updates as I make progress on the schematic. Comments below.
TickTock wrote: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.
TickTock wrote: I don't see any issue adding the holes to the OBD breakout. However, I *really* like the flex cable. It has very good signal integrity (as shown by the scope captures with and without earlier in this thread) but best of all slips under the trim without any danger of flex or wear. Others have shown that CAT5 can squish pretty flat and doesn't distort the dash much but, OK, so I'm a little OCD. Also, if you are going to use CAT6, you can omit the breakout all-together (only really need chokes on the main board since all the electronics in the LEAF have their own) and make a low profile connector.
Hmm, I think I will use the flex cable after all then. I remember your scope traces with it being pretty good. I should probably test it with my ham radio transmitter before driving, though.
TickTock wrote: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.
TickTock wrote:That said, there have been some issues with the VP230 so it is worthwhile to look into alternatives. You read about the bad device that interfered with nanaleafman's car. I also have a batch that behaves like VP231 (Rs would disable the RX, too) although they are marked VP230.
I'm curious where you got those parts. There are a lot of problems with counterfeit/incorrectly marked parts, and places like Mouser and Digikey aren't immune but better than most at keeping their supply chain clean. They will even replace parts if you get defective ones, and if you're lucky, the replacements will be from a different reel...
TickTock wrote: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.
TickTock wrote: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.

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.

User avatar
TickTock
Posts: 1701
Joined: Sat Jun 04, 2011 10:30 pm
Delivery Date: 31 May 2011
Leaf Number: 3626
Location: Queen Creek, Arizona
Contact: Website

Re: The CANary project

Fri Nov 15, 2013 3:47 pm

robot256 wrote:
TickTock wrote: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.

User avatar
garygid
Gold Member
Posts: 12469
Joined: Wed Apr 21, 2010 8:10 am
Delivery Date: 29 Mar 2011
Leaf Number: 000855
Location: Laguna Hills, Orange Co, CA

Re: The CANary project

Fri Nov 15, 2013 5:28 pm

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
See SOC/GID-Meter and CAN-Do Info
2010 Prius
2011 LEAF, 2014 Tesla S85
2018 & 2019 Tesla Model 3
PU: SDG&E
Solar PV: 33 x 225W -> 7 kW max AC
Craigslist: Xm5000Li Electric Motorcycle

User avatar
TickTock
Posts: 1701
Joined: Sat Jun 04, 2011 10:30 pm
Delivery Date: 31 May 2011
Leaf Number: 3626
Location: Queen Creek, Arizona
Contact: Website

Re: The CANary project

Fri Nov 15, 2013 9:12 pm

robot256 wrote:
TickTock wrote: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.
robot256 wrote:
TickTock wrote: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.
robot256 wrote:
TickTock wrote: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.
robot256 wrote:
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." :-)

Return to “LEAF CANBus”