The CANary project

My Nissan Leaf Forum

Help Support My Nissan Leaf Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Just a teaser:
5yfu7ell.jpg

Metric is a toggle in the config page, and is saved in the config file, which has been incremented a version level.

I also have successfully tested the update from usb, not as clean as the one that's in main.cpp, but its way more convenient for sure. The way I implemented it was a button on the config page, which then removes any bin file on the local drive, then copies over firmware.bin off the /usb device.

I'm going to test the metric stuff tomorrow and I should be able to get TickTock the branch over the weekend if it works. :)
 
I've published the metric & usb update code over at http://mbed.org/users/leafman/code/CANary/

Take a look, and if you need me to change anything just let me know. I can also create a pull request if you want.

Seems to work well for me so far, although I'd make sure you have sufficient voltage on your usb connector before attempting it. I've tried down to 13V (car voltage) and havnt had issues, but you've noted much lower voltages than my car.
 
I loaded your version and it looks great! Going to be a little painful merging, though, since some of the edits are in common areas (auto-merge only works well if each author's edits are isolated from each other). I'll combine them this weekend.

I'm getting a really bad glare these days in the morning - I think I will try some anti-glare screens...
 
Yeah, I kinda trampled over all the files of code... Sorry about that, couldnt think of a way to not touch pretty much everything and have it work.

Let me know if you find a solution, the glare is pretty bad on mine...

I just (within 5 minutes) received the first dc/dc converter (liek the one you had ordered), however the quality is alarming to say the least. I've identified multiple solder shorts, so I'll have to see if I can fix it.

MoD2ux5l.jpg

Pings 1&2 on the LM2596 are shorted... more on the backside.
 
OK. Merge done. Wasn't really so bad afterall - you kept your edits pretty well contained. Nice work-around for the timestamp issue. Was able to update the last couple firmware updates using the thumbdrive so now I can remove the USB cable I have draped down my dash (too much trouble to connect so I left it connected all the time :)).

http://mbed.org/users/TickTock/code/CANary/
 
I was putting together a partial kit with my left-over parts and noticed my implementation doesn't match the documentation. I will update the wiki, but I wanted to mention here that:
1) instead of 100Ohm current limiter to the LCD, I am using 49 Ohms
2) instead of 1K and 3.9K for the 12V divider, I am using 10K and 39K. The original should work fine - I just decided to go with 10K/39K since I was running low on 1Ks.
3) I haven't done this, yet, but plan to replace the 6V Zener with a 5.1V to ensure the 5V supply doesn't droop.
 
How does the firmware update via the Flash drive work?

Just put a "xxx.bin" file on the root of the flash drive, plug into
the CANary, and power on?

Then, the files on the Flash are examined for the latest ".bin" by time code,
and, if later than the latest on the USB internal flash, the newer file is copied
across (with what time code?), and the Mbed reboots itself?

What other new features are included, please?
Thanks for the parts. :D :D
 
It must be called firmware.bin and you force the update from the config screen. NOTE! Any previous .bin files stored on the mbed will be deleted (this is a necessary work-around due to the timestamp still not being supported by the filesystem library).

In addition to this nananaleafman added a metric option for display. In my local area, I have added Ah, state-of-health, and more accurate temperature (using the ADC values and the table GregH compiled). I am still fiddling with the formatting (I think I will move the Ah and health to a dedicated splashscreen since they don't change during driving). Let me know if you are going to start modifying and I will publish so you can start from the most recent (to make the merge go better).

Here is the list of enhancements I plan (eventually :))
Code:
//To Do:
// * USB device detect
// * Enable file timestamps
// * Audible friction brake feedback
// * User-configurable watchpoint
// * Add 50% charge option
// * Tire Pressure Sensor display
// * Fix bug in playback while connected to canbus (hangs)
// * Force regen display to zero when in neutral
// * Add coasting regen to regen/braking display
// * Change semilog efficiancy graph to linear with 10 minute values
// * Add Trip meter (kWh and efficiency for current trip)
// * Make unique sound when log file write fails and logging disabled
// * Make display updates interruptable for log writes
// * Add additional 79b bank readouts
// * Ignore the missing 4th pemperature sensor on 2013 models
// * Add ability to transfer settings config file to/from USB
// * Add once-on-powerup/powerdown log
 
My first experiment with anti-glare screens is disappointing. I tried the Fosman (cut to size). While it did reduce the glare by spreading it out, it also reduced the contrast so I don't think it really improved visibility much. I *do* like the matte, finger-print free finish, though. I will try a different brand (any suggestions?).

Left screen below has the screen applied, right screen doesn't.
 

Attachments

  • glare_small.jpg
    glare_small.jpg
    136.2 KB · Views: 45
Ok, makes sense, and for now, the manual is better than
an automatic firmware update.

The 2013 is missing good data for the third temperature,
and FF FF FF is returned for the 3rd value.

I am trying to get feeling better, and help a bit
with the mini-DC charger project, but I hope to
revisit the CANary code again, sometime.

For me, the logging of all the CAN Messages was never successful.

When you want to add the "Shunts-On" data to the cell-voltage
barchart, I think using the bits in the 4812 order is correct,
but one other disagrees.

Cheers, Gary
 
garygid said:
Ok, makes sense, and for now, the manual is better than
an automatic firmware update.

The 2013 is missing good data for the third temperature,
and FF FF FF is returned for the 3rd value.

I am trying to get feeling better, and help a bit
with the mini-DC charger project, but I hope to
revisit the CANary code again, sometime.

For me, the logging of all the CAN Messages was never successful.

When you want to add the "Shunts-On" data to the cell-voltage
barchart, I think using the bits in the 4812 order is correct,
but one other disagrees.

Cheers, Gary

Do you have a link to the mini-DC thread. I am also very interested in this since my 12kW solar has a peak power voltage of 384V and open circuit voltage of 536V. Seems almost optimal for direct charging (with a simple linear regulator - of course nothing is really simple at 12kW...).

I've been waiting for the shunt theory to settle out before implementing since this still seems a bit sketchy (why are they turned on for cells having low voltages?) but will add that to the Todo list.

Did you follow nananaleafman's experiences? He ended up having a bad VP230 - maybe yours is marginal? If you have a scope, that might shed some light on it.
 
I just published my edits to date which includes display of %SOH (state of health) and Ah (full capacity) on the main screen. Main screen is getting a bit busy so I anticipate moving the SOH and Ah to a separate battery health screen in the future.
 
garygid said:
I suspect that the "bin" file that one gets, assuming that the
source code is the same, could be zipped and emailed to me.

Let's try that with your latest version?
sent. Although, lately I've been getting more frequent write buffer overruns. Didn't think I changed the code that much but now I hear the beep several times during the 30 minute drive to work. I think I will try putting the buffer dump back on an ISR so it can interrupt the more time consuming display updates (but make sure the CANbus receive is higher priority). I found a way to generate a software interrupt so the CANbus RX can trigger the write buffer dump if the high water mark is reached.
 
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.
 
Back
Top