The CANary project

[TickTock]

Hi, this is a very interesting project. I was wondering how exactly you are calculating the Battery's state of health, any extra sensors for that purpose or just the regular voltage versus time calculation. I actually needed to measure that since I've been having alternator issues recently. Also, if you're having buffer issues, instead of shifting the buffer dump back on the ISR, just use a software interrupt that clears it before a certain limit is reached. It'll reset the buffer every time but I guess buffer values are not that critical for a real-time system. I apologize if you've already tried this approach and I missed that in some post.

Alternator? Anyway, the mbed had an onchip analog to digital converter which I feed the 12V to (through a resistor divider) for monitoring. So, yes, an extra sensor. Not sure I understand the voltage vs. time calculation comment.

 

[garygid]

The buffer is used to hold all of the received messages
from both of the CAN buses, along with their time stamps,
and we want to write all of them to a log file.

Sometimes, especially writing to a flash drive, there are
"long" delays, perhaps for clearing more memory, that
take up to 700 ms or so, and the buffer gets too full.

Perhaps writing directly to a mini SDHC card will not
have these long delays?

When the buffer will overflow, one can clear the buffer,
losing N messages, or just toss out the new message,
overlay the previous message with an "Error" pseudo-message,
count the losses, and insert the Lost-Message-Count
into the error pseudo-message.

I do the latter, TickTock prefers the former.

 

[TickTock]

Actually, I prefer no overflows at all!

 

[garygid]

Oh, yes indeed, my friend!!!!

 

[TickTock]

It is my next focus area on CANary to fix (however, I haven't had a lot of time to spend on it lately). I just remembered that I replaced the thumbdrive recently (old one got into a write protected mode that I cannot figure out how to undo). This happened the same time as my edits (I was trying out nananaleafman's thumbdrive USB update feature). That could be why suddenly I am getting buffer over-runs - not the code edits (maybe the new thumb drive write speed is limited). I'll try some different brands to see if that helps (there is quite a range of speeds - http://usbspeed.nirsoft.net/). I'll probably still try the software interrupt for dumping, though, to help make it more robust/tolerant of slow devices.

 

[garygid]

About the biggest buffer that I was able to create in the Mbed
for the CSM Messages was 2048 messsges.

With around 2000 messages per second arriving on each bus,
any delay over about 500 ms would cause an overflow.

In testing the Mbed writing to USB flash drives, I found frequent
small (a few ms) delays, occasional longer (50 to 100 ms, as I recall),
and occasionally a long delay of about 700 ms, typically resulting in
a buffer overflow. Using a fast micro SDHC card (in a small USB
adapter) seemed to greatly reduce the delays. I do not remember
(remembred what? ) if the test data write, read, buffer, and transfer
became fully reliable or not.

The test code is in my original Mbed source.

 

[nananaLeafman]

Wow, seem to have lost my subscription to the thread. Glad the usb firmware thing is working well for everyone. I've been busy with a flooded basement and havnt really touched this since that update. I have had no problems with my zener since i used a digikey one instead of one from mouser.

I will be using my Chinese adjustable switchmode supply when i get a chance, the other one with all the issues seems too hard to connect (maybe i'm just lazy), since I dont have the proper connectors on hand.

I'm hoping to do some digging on the charge timers and see if i can rig up a solultion for that when i have more time.

 

[Turbo3]

Just used CANary to take some long logs and noticed that out of 11 million samples 5 million are MsgID=000 with all zero data. Where are these all zero frames coming from and can we drop them and not save them to the USB drive? Using Rev 105 firmware.

 

[TickTock]

Just used CANary to take some long logs and noticed that out of 11 million samples 5 million are MsgID=000 with all zero data. Where are these all zero frames coming from and can we drop them and not save them to the USB drive? Using Rev 105 firmware.

This is a bug - those should not get written. I just tested the fix and published it.

 

[Turbo3]

Tried to change the default for logging to be true (logEn=true line 66 in main.cpp) but both screens come up blank after reset.

 

[TickTock]

Yep. Was the USB drive. Put in a different brand and I have not had a dropped message since. To help verify the root cause, I downloaded a freeware app (Check Flash) and, sure enough, the new drive was only sustaining a write speed of 0.9MB/s while my old thumb drives were in the 6-7MB/s range.

It is my next focus area on CANary to fix (however, I haven't had a lot of time to spend on it lately). I just remembered that I replaced the thumbdrive recently (old one got into a write protected mode that I cannot figure out how to undo). This happened the same time as my edits (I was trying out nananaleafman's thumbdrive USB update feature). That could be why suddenly I am getting buffer over-runs - not the code edits (maybe the new thumb drive write speed is limited). I'll try some different brands to see if that helps (there is quite a range of speeds - http://usbspeed.nirsoft.net/). I'll probably still try the software interrupt for dumping, though, to help make it more robust/tolerant of slow devices.

 

[Turbo3]

The is a little OT but Gary can you change CAN-DO (using 210 right now) to append HH:MM to front of the SS.MMM time field when saving a long CANary trace in csv format. It would make it easier to use the csv file if the time did not wrap every 60 seconds. Actually I would like to see this added to the view field in the program too but csv is most important to me now. Still don't know how to look at large traces in your program.

The HH:MM would of course start at 00:00.

 

[garygid]

The logging software should insert a Date-Time pseudo message
at the start of each minute, and you can enable displaying those
date-Time messages (MsgID = FFF) along with any other data.

I thought that CANary inserts those messages into the buffer
to write to the log file.

If MsgID = 000 messages are getting into the buffer,
there is something wrong with the message-reading
code.

 

[aminorjourney]

Out of interest, has anyone switched the CANary enclosure around so that it would work with RHD cars?

 

[TickTock]

Out of interest, has anyone switched the CANary enclosure around so that it would work with RHD cars?

No, but it wouldn't be too hard to do. The trick is ensuring the board fits with the new mirror'd shell such that the programming USB port is accessible. Will probably have to install the PCB rotated 180 degrees and this could create new, unexpected clearance issues. Also, do you know if the dash footprint is a mirror image of LHD cars? If you are seriously interested in taking on this project, I would be willing to render a RHD version but keep in mind you may encounter unanticipated problems - possibly requiring a rev2 of the enclosure which can be painful at >$100 ea!

[Edit:removed comment about USB being upside-right. It will, infact, be upside down if the enclosure mirrored and the PCB rotated.]

 

[TickTock]

Just an FYI: I am working on a major overhaul of the USB file access to use a different library that supports timestamps and more robust error handling. So any of you co-developers that are working on any file related features may want to hold off until I publish my next rev (all the file access procedures are changing).

 

[TickTock]

OK. I just published a new revision (rev 113) of CANary. This has a LOT of edits:
1) Added a logging indicator on the main screen (blinking red light in upper right corner). It mimicks LED4 - toggles each time the write buffer wraps.
2) Added a trip meter (see image below). Top is auto reset each time the car is turned on the other two are user resettable
3) Added a lookup table with GregH's latest ADC<->temperature data
4) Changed the USB filesystem (this was the largest change). log files will now have proper timestamps
5) Added a USB detect function to look for USB drive insertion
6) Enabled logging by default (will start logging as soon as a USB drive is inserted - no other action required)
7) Added a trip log. Similar to T3's battery log (in fact 99% identical) - just writes to a separate file once on powerup and once on powerdown.
8) Corrected bug causing the regen display to falsely indicate regen when the car has been put into Neutral (if you touch the brakes while in Neutral it's all friction)

 

[TickTock]

Probably worth noting that the kWh displayed in the trip meter is different than the kWh displayed on the main screen for total battery available energy. The latter is just gids*.075 while the kWh displayed on the trip meter are actually generated by counting Coulombs. They track fairly well except when charging (I don't add energy when charging to the trip accumulator for obvious reasons).

 

[TickTock]

Quick bug fix in battery log files. New rev 114.

OK. I just published a new revision (rev 113) of CANary. This has a LOT of edits:
1) Added a logging indicator on the main screen (blinking red light in upper right corner). It mimicks LED4 - toggles each time the write buffer wraps.
2) Added a trip meter (see image below). Top is auto reset each time the car is turned on the other two are user resettable
3) Added a lookup table with GregH's latest ADC<->temperature data
4) Changed the USB filesystem (this was the largest change). log files will now have proper timestamps
5) Added a USB detect function to look for USB drive insertion
6) Enabled logging by default (will start logging as soon as a USB drive is inserted - no other action required)
7) Added a trip log. Similar to T3's battery log (in fact 99% identical) - just writes to a separate file once on powerup and once on powerdown.
8) Corrected bug causing the regen display to falsely indicate regen when the car has been put into Neutral (if you touch the brakes while in Neutral it's all friction)

 

[TickTock]

To help keep the CAnary secure during spirited driving, I have found that these work very well:

3M damage-free picture hanging strips

Also, I was nervous about it becoming a projectile in the event of an accident so I added the "safety cable" seen in the pic below. When the panel is snapped into place it is secured around the center attachment post.