The CANary project

OT also, what new A/CAN...?

I'm having a heck of a time getting the latest revisions to build. If I goto revision ~142, i get errors complaining about ff_convert not being defined, if i get latest, then its powercontrol.h is missing.

Any ideas what I'm doing wrong. I've deleted and re-imported from the repository several times.

Or can you just post a bin?

Yes! I had that happen to me, too. With no change to the code. They changed something in the compiler and I spent hours trying to get anything to compile (even switching back to older revs wouldn't work). Anyway, the fix (included in the latest - rev145) is to go into CHAN_FS/option and rename the file ccsbcs.c to ccsbcs.cpp. Apparently that code uses cpp nomenclature and they started to crack down on cpp code disguised as c code. Why? I have no clue but it was rather frustrating. Anyway, the latest rev should take care of this but if you want to stick with rev142 (or any other rev other than 145), that should fix the compile error.

That worked I used revision 144 as it seems 145 is missing a bunch of files when i switch to it. Thanks for the tip, and I agree that's a stupid 'feature'.

I'll let you know how the metric numbering works out on the DTE, havnt driven the car since last week due to distance requirements.

Thanks for the heads up - I just published rev147 that should fix the missing files. I am a bull in a china store when it comes to this mercurial interface. I also changed how the CONFIG.TXT is backed up on the thumbdrive. Now, it backs up when the "save config" option is selected (used to back up whenever you updated the firmware). I also changed the name on the thumbdrive copy to CONFIG.BAK so it wouldn't get recopied back into the device on the next update by accident. If you want to edit it and update it:

• 1) rename the CONFIG.BAK on the thumbdrive to CONFIG.TXT
  2) edit it
  3) insert into CANary, press reset
  4) select update firmware

If the update firmware routine sees a CONFIG.TXT on the thumbdrive it will copy it over before looking for a firmware.bin update.

You folks are doing great work.
I am pleased that the "active" community is expanding.
My sincere thanks and encouragement, Gary.

Thanks Gary!
Nananaleafman, let me know what you think of the brake monitor. I ended up increasing the brkMonThr to 4000.

Wish I could contribute more, but my real life has been upside down these last few months. We get our new house in sept so things should settle down after that.

Anyways, I just updated firmware at lunch, so I'll get to play with it on my hour drive home.

TickTock is doing some fine work on the firmware!

OK. Just publish a new rev. New features include:

• 
  1) Per-charge trip meter. Now there is a per-trip, per-charge, and user resettable trip meter displaying total miles, total kWh, and efficiency
  2) Added time (all MY) and date (MY2011-2012) auto-sync option on car turn-on to keep the CANary internal clock synchronized with the GPS time from the nav unit. MY2013 will have to update the CONFIG.TXT to indicate the model year. Can be disabled in the config.
  3) Added an audible battery power reversal indicator. When enabled, emits a short tone whenever the current flow reverses direction. Is enabled when the brake monitor is enabled so the Brake Monitor Mode can really be thought of as a Hyper-Helper mode. Chirps (800Hz) geiger-counter style proportional to the amount of applied friction braking as before, but also lets you know when you enter (400Hz) and exit (1600Hz) regen (or, more accurately, enter/exit battery charge/discharge) so you can optimize coasting without taking your eyes off the road or taking the car out of Drive.
  4) Added a test screen with up to eight user-programmable watchpoints (MSGID & Byte) for analysis.
  5) Added ambient temperature to main screen (doesn't exhibit the delayed response you get on the eyebrow display)
  6) Added the battery series resistance to the trip log

TickTock said:

Take a look at https://docs.google.com/spreadsheet/ccc?key=0An7gtcYL2Oy0dGRaSWl6VTV2eXBQMy1ON2xZSzlMUXc#gid=5 (be sure to note the different tabs at the bottom). It contains everything I could find that has been unearthed on the various canbus messages. The content came from the contributions of Turbo2ltr, garygid, and many others. If you discover anything useful (or not ) please let us know!

Click to expand...

Do you mind if we include this specific link in the Leaf OVMS development forum in order to help the Leaf OVMS become a reality.

arsharpe said:

TickTock said:

Take a look at https://docs.google.com/spreadsheet/ccc?key=0An7gtcYL2Oy0dGRaSWl6VTV2eXBQMy1ON2xZSzlMUXc#gid=5 (be sure to note the different tabs at the bottom). It contains everything I could find that has been unearthed on the various canbus messages. The content came from the contributions of Turbo2ltr, garygid, and many others. If you discover anything useful (or not ) please let us know!

Click to expand...

Do you mind if we include this specific link in the Leaf OVMS development forum in order to help the Leaf OVMS become a reality.

Click to expand...

Not at all. My entire motivation was to help enable as many after-market devices as possible. All I request is you share anything further you discover so I can add it to the dBase.

Accessing the spreadsheet link from my Android Tablet,
I get what appears to be an endless loop (not tested
to the end).

TickTock said:

OK. Just publish a new rev. New features include:

• 
  1) Per-charge trip meter. Now there is a per-trip, per-charge, and user resettable trip meter displaying total miles, total kWh, and efficiency
  2) Added time (all MY) and date (MY2011-2012) auto-sync option on car turn-on to keep the CANary internal clock synchronized with the GPS time from the nav unit. MY2013 will have to update the CONFIG.TXT to indicate the model year. Can be disabled in the config.
  3) Added an audible battery power reversal indicator. When enabled, emits a short tone whenever the current flow reverses direction. Is enabled when the brake monitor is enabled so the Brake Monitor Mode can really be thought of as a Hyper-Helper mode. Chirps (800Hz) geiger-counter style proportional to the amount of applied friction braking as before, but also lets you know when you enter (400Hz) and exit (1600Hz) regen (or, more accurately, enter/exit battery charge/discharge) so you can optimize coasting without taking your eyes off the road or taking the car out of Drive.
  4) Added a test screen with up to eight user-programmable watchpoints (MSGID & Byte) for analysis.
  5) Added ambient temperature to main screen (doesn't exhibit the delayed response you get on the eyebrow display)
  6) Added the battery series resistance to the trip log

Click to expand...

Probably going to publish a new rev soon with a easy-access mute button (for my wife ). It's already there but buried in the config screen.

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.

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.aspx?Keyword=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.

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!

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.

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.

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

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.

TickTock said:

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.

Click to expand...

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 said:

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.

Click to expand...

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 said:

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.

Click to expand...

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 said:

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.

Click to expand...

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

TickTock said:

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.

Click to expand...

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 said:

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.

Click to expand...

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 said:

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.

Click to expand...

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.