Go Down

Topic: Building a CAN API for Arduino DUE (Read 184156 times) previous topic - next topic

yoh-there

Thank you Paliser!

A "real", as in , official matrix, well, I don't see it happening to be honest. But I hope some people will chime and and find more fields.


As far as I know, the original CLIP tools only work with the Zoe when they can "phone home". However, I have already planned to do what you suggest, but only slightly different. Next Saturday I will visit a guy who has bought a Carsoft i907, it is a diagnostic tool with specific firmware for the Zoe and Fluence (another EV of Renault).

And since I build the Due with a CAN T-cable I can indeed sniff what is going on on the bus(ses) when we interrogate i.e. the individual cell voltage. So yes, great advice. More next week!

Collin80

Well, if you want to create a database of the signals you are finding then a program I'm writing will soon be of use to you. I have some programs at my github repos (https://github.com/collin80) that could be useful. GVRET is an Arduino sketch that uses due_can and is *much* more advanced than the bundled example sketches that come with the due_can library. I have tested GVRET up to around 4000 frames per second without any dropped frames. The PC side complement to that is SavvyCAN which is a QT program you can compile on Windows, Linux, or OSX. That program is soon to support full DBC file creation so that you can create a database of signals in an industry standard format and then use that database to automatically interpret the incoming frames (or frames you loaded from a file). So, if any of that is useful to you then have at it - the source is all open. I'd love to see people making DBC files of their work since that way lots of people can collaborate and make use of the work.

yoh-there

OY! I should have spotted that earlier Collin! I already did a logger and formatter and a kinda-sorta database myself. :-/

I will dive into what you made, THANK YOU!

And how the DBC format works, as I already (mostly nicked from Alexandre BTW) have about 60 parameters. Learning every day :-)

yoh-there

#498
Jul 08, 2015, 07:46 pm Last Edit: Jul 08, 2015, 08:02 pm by yoh-there
@Colin80, I am really sorry to sidetrack a bit here, but the SavvyCAN.... it is my first delve into QT and I have some problems building it. It complains about seriaport. Can you please tell me what version of QT you are using? I installed 5.0.2 and that might be the culprit, as I read somewhere it is only included starting 5.1. But before I mess up my system further...... Thank you so much!

Edit: Ehm, with 5.5 (yes I did) the qmake is ok but on the make I get issues on #include <QtGui/QAction>.

Collin80

I build it with QT 5.4. But, as luck would have it, I routinely publish binaries of it too:

www.kk-ev.com/SavvyCAN.zip         (Windows 64 bit)

www.kk-ev.com/SavvyCAN.tar.gz     (Linux - Does not include any QT libraries so you'd have to install them from your linux repo)

www.kk-ev.com/SavvyCAN.dmg        (OSX - I believe version 10.7 or newer)

yoh-there

Thank you! Still fighting with that, but I'll get there! I will let you know.

yoh-there

#501
Jul 10, 2015, 03:37 pm Last Edit: Jul 10, 2015, 04:50 pm by yoh-there
Dear @Collin80,

I got it working, and that surely looks good. Very impressed with what you did. And I had a quick start with your item on evtv. Can I ask a few questions here?

GVRET: I added the SD card to the DUE. GVRET now stops complaining abot not being able to log. Is it supposed to create a log when run without anything hooked up to the USB? If so, how does it deal with closing the file? I mean, at one moment or the other I have to pull the plug!

My own logger/display/database (a faint blip compared with what you did) I rewrote slightly to use the same packet format as GVRET both for logging as well as displaying. Mine, though simply terminal based, might draw the eye a tad more to any bit somewhere changing. If I still think that's true after fiddling a bit, I will try to add some code at your discretion of course. But let me learn SavvyCan more first before I pound my chest :-)

As for defining fields, what do you recommend while DBC editing is not available yet? The tool that Victor distributes? Notepad-style? In the latter, do you have maybe a link to a quick-start guide? In essence I already have ID, bitx-to-bity (from 0-64), divisor, multiplier and value offset for roughly 60 fields. Which node is sending I don't know, but I can throw that in the "catch all" bin.


Collin80

GVRET: I added the SD card to the DUE. GVRET now stops complaining abot not being able to log. Is it supposed to create a log when run without anything hooked up to the USB? If so, how does it deal with closing the file? I mean, at one moment or the other I have to pull the plug!
It periodically flushes the file so when you're done logging you can just power off. At the worse your file will be missing the end few frames.

Quote
As for defining fields, what do you recommend while DBC editing is not available yet? The tool that Victor distributes? Notepad-style? In the latter, do you have maybe a link to a quick-start guide? In essence I already have ID, bitx-to-bity (from 0-64), divisor, multiplier and value offset for roughly 60 fields. Which node is sending I don't know, but I can throw that in the "catch all" bin.
Well, you can use Vector's DBC editor. It should be essentially free to use - you just have to download a trial of one of their products. The trial will expire but the DBC editor never should.

yoh-there

Thank you Collin. I noticed no file at all, but it might have to do with some defaults. I am a bit lost on how to update the EEPROM settings. I will be rude and for the moment just update the defaults in my source copy.

DBC editor: Got, will give that a spin.

yoh-there

More success. The T-cable proved invaluable and we sniffed what was going on between the Zoƫ and an iCarsoft 907. As expected, some data was being actively queried by the tool. With partly my own software and partly SavvyCan we were able to see what was going on and map what the tool was reporting on some raw data. I can now query the LBC for it's 12 temperature sensors in the battery compartment, and the EVC for i.e. current drawn/fed and the maximum charging power it will accept given the SOC and temperature of the battery pack.

Some data span multiple packets and thatwas, erm, interesting!

Go Up