Brammo Owners Forum
Brammo Empulse Discussion => Brammo Empulse Mods => Topic started by: Ain on December 31, 2012, 01:27:38 AM
-
The Empulse R has an 8GB USB flash drive for logging your riding and charging. When I picked up the bike, I was told I wouldn't be able to make sense of the files, but I figured it might be worth looking anyway while I had the seat off. There are .DRV files and .CHG files (I'm guessing the obvious - "driving" and "charging").
Logger cable under the seat:
(http://i45.tinypic.com/2u9lgtt.jpg)
(http://i50.tinypic.com/2w4cpvt.jpg)
Closeup of the SanDisk 8GB drive:
(http://i48.tinypic.com/zsnz44.jpg)
Here's what the top-level directory looks like on the drive:
(http://i50.tinypic.com/24qjyow.jpg)
Here's what the LOGS directory looks like:
(http://i45.tinypic.com/2jd4dux.jpg)
Just in case anyone is motivated to try and figure out what's in the files, I've attached both a .DRV and .CHG file from my data logger (I picked a couple smaller ones). It's unclear if they're encrypted using any of the SanDisk "Secure Access" stuff, or if they're just in a format designed for whatever program Brammo uses for logging. There's obviously a structure to them, but it's not in plain text.
It would be fun to figure out what's in the files for any future "do it yourself" diagnostics.
- Ain
-
Awesome. I'll see if I can update my log decoder (http://brammoforum.com/index.php?topic=361.msg1970#msg1970).
-
im currently trying to analyze the distribution of the bytes.
idea: uniform distribution of bytes would be aequivalent* to encryptioned data
im "a bit" slowed down by the decision to use haskell to write the analyzer, but I want to work on my haskellskills :D
@ protomech: could you consider showing the sourcecode to your old analyzer? I would try to implement it myself (in haskell) for the first reason, and cant use your .exe as second reason (using linux here).
---
* not in hard binarian logic of course, which is sadly impossible to use in real life.
-
Yep, it's a couple of posts down in that thread. C# code.
Quick glance through the .DRV file shows a much less regular structure than the Enertia logs.
-
well, my 5h-oneliner is now ready :D
[florian@frankenstein haskell]$ ./brammoLogAnalyzer < ~/Downloads/41875A2F.CHG
[47159,2061,2024,661,795,2051,1666,2436,770,1958,1005,2013,1955,328,6605,181,530,2065,4241,168,64,34,210,695,695,640,0,177,8,2,93,143,172,341,240,46,37,87,319,330,36,52,0,0,0,181,18,0,1175,412,216,208,210,214,247,315,2206,33,175,0,1928,12,1929,0,495,34,384,386,209,385,208,33,33,125,89,0,0,1382,18,0,38,33,36,33,33,23,373,24,203,972,368,1278,83,242,185,483,695,717,159,0,175,24,0,0,0,0,0,0,27,0,0,0,0,0,319,0,175,0,0,0,0,79,0,0,0,525,0,175,1412,0,0,0,1,524,7,175,0,0,0,0,0,1,0,0,0,0,0,171,0,0,0,0,0,0,32,0,0,0,0,0,101,0,0,0,0,0,0,15,0,0,0,0,0,5,0,0,2,0,0,93,434,2,0,0,0,0,7,0,0,0,0,0,175,76,0,0,0,0,0,39,0,0,0,0,0,0,63,0,0,0,0,22,85,94,433,74,27,115,69,2,0,0,0,2,119,94,0,349,0,0,0,0,57,172,0,0,0,261,57,0,0,0,0,43,46,154,45,1225,0,0,8,37,36,35,35,847]
thats the number of occurences of a byte with the intvalue of the index in this list. I think we are looking at unencrypted and uncomprehended data.
<edit> But why are there the encryptiontools on the stick? </edit>
most important part: haskellskillz +1 :D
<edit>@ protomech: thanks, didnt read your previous posts any farther. whupps :D </edit>
-
I realized afterward that my bike's VIN number was visible in the clear at the top of the .DRV file, so it might be looking like binary data and not encrypted data.
- Ain
-
Yes. Here's a snippet from the charging file:
3c1212071117003e49ff2807000000000000000000000000003c2020202020203e56353152554235353658444130303030323500
3c1212071117003e4330322e30312e373130312e30322e303430312e30312e323138372e30302e343530312e30312e32312d2d2e2d2d2e2d2d30312e30312e323130312e30302e313630352e30302e3232
3c1212071117003e440000000000000000000000000000000159
3c1212071117003e423a38383838383800160100000000000064008000000000002d740000007f00004e4a00000f0e010e87004500004272610e060e070e070e040e060e0a0e080e050e010e040e080e050e040e090e080e050e050e080e090e050e080e0a0e0a0e070e0c0e0f0e0d0e090e060e060e060e06ffe3ffe30000ffe3ffed0000ffe30000595b595a5d5e5f006060606061616200
3c1212071117003e4600000000000000c0858585b4b4b47d7d7d5e5e5e010d0d010101050505010102585858
3c1212071117003e4500000100000040ff0303000000e8030110120100d60b43561000001bd60b4356
3c1212071117003e4d3130a0000000000537f500040bd5220000000000005b00f700000000000000000000090c06020002800000000000
3c1212071117003e4d3231300000000005382700020be1260000000000005b00f700000000000000000000090c06020002800000000000
3c1212071117003e4d3330ee0000000005384000040bd3260000000000005b00f700000000000000000000090c06020002800000000000
3c1212071117003e4d3430930000000005385900020bda210000000000005b00f700000000000000000000090c06020002800000000000
3c1212071117003e4d3530c70000000005385900020bf6210000000000005b00f700000000000000000000090c06020002800000000000
3c1212071117003e4d3630790000000005380e00020bff200000000000005b00f700000000000000000000090c06020002800000000000
3c1212071117003e4d3730720000000005382700020c0a1e0000000000005b00f700000000000000000000090c06020002800000000000
3c1212071117013e440000000000000000000000000000000159
3c1212071117013e423a38383838383800160100000000000064008000000000002d740000007f00004e4a00000f0e010e87004500004272610e060e070e070e040e060e0a0e080e050e010e040e080e050e040e090e080e050e050e080e090e050e080e0a0e0a0e070e0c0e0f0e0d0e090e060e060e060e06ffe3ffe30000ffe3ffed0000ffe30000595b595a5d5e5f006060606061616200
3c1212071117013e4600000000000000c0858585b4b3b47d7d7d5e5e5e030202010101050505010101585858
3c1212071117013e4500000100000040ff0303000000e8030110120100d60b43561000001bd60b4356
3c1212071117013e4d313093000000000537f500040bd5220000000000005b00f700000000000000000000090c06020002800000000000
3c1212071117013e4d3231300000000005382700020be1260000000000005b00f700000000000000000000090c06020002800000000000
3c1212071117013e4d3330ee0000000005380e00040bd3280000000000005b00f700000000000000000000090c06020002800000000000
3c1212071117013e4d34309a0000000005385900020bda210000000000005b00f700000000000000000000090c06020002800000000000
3c1212071117013e4d3530c10000000005384000020bf6220000000000005b00f700000000000000000000090c06020002800000000000
3c1212071117013e4d363065000000000537f500020bff1f0000000000005b00f700000000000000000000090c06020002800000000000
3c1212071117013e4d37306c000000000537f500020c0a1e0000000000005b00f700000000000000000000090c06020002800000000000
3c1212071117023e440000000000000000000000000000000159
3c1212071117023e423a38383838383800160100000000000064008000000000002d740000007f00004e4a00000f0e010e87004500004272610e060e070e080e040e070e0b0e080e060e010e040e080e050e040e090e080e050e050e090e090e060e080e0a0e0a0e070e0c0e0f0e0d0e090e060e060e060e0600000000ffedffe30000000000000000595b595a5d5e5f006060606061616200
3c1212071117023e4600000000000000c0858585b4b4b47d7d7d5e5e5e010107010101050506020202585858
3c1212071117023e4500000100000040ff0303000000e9030110120100d60b43561000001bd60b4356
3c1212071117023e4d313093000000000537f500040bd5220000000000005b00f700000000000000000000090c06020002800000000000
3c1212071117023e4d3231360000000005382700020be1260000000000005b00f700000000000000000000090c06020002800000000000
3c1212071117023e4d3331020000000005384000040bd3260000000000005b00f700000000000000000000090c06020002800000000000
3c1212071117023e4d3430930000000005384000020bda210000000000005b00f700000000000000000000090c06020002800000000000
3c1212071117023e4d3530c70000000005384000020bf6210000000000005b00f700000000000000000000090c06020002800000000000
3c1212071117023e4d3630580000000005380e00020bff200000000000005b00f700000000000000000000090c06020002800000000000
3c1212071117023e4d3730790000000005382700020c0a1e0000000000005b00f700000000000000000000090c06020002800000000000
3c1212071117033e440000000000000000000000000000000159
3c1212071117033e423a38383838383800160100000000000064008000000000002d740000007f00004e4a00000f0e010e87004500004272610e060e070e080e040e070e0b0e080e060e010e040e080e050e040e090e080e050e050e090e090e060e080e0a0e0a0e070e0c0e0f0e0d0e090e060e060e060e0600000000ffedffe30000000000000000595b595a5d5e5f006060606061616200
3c1212071117033e4600000000000000c0858585b4b4b37d7d7d5e5e5e080104010101050505010101585858
3c1212071117033e4500000100000040ff0303000000e9030110120100d60b43561000001bd60b4356
3c1212071117033e4d3130a0000000000537f500040bd5220000000000005b00f700000000000000000000090c06020002800000000000
3c1212071117033e4d3231290000000005382700040be1260000000000005b00f700000000000000000000090c06020002800000000000
3c1212071117033e4d3330e80000000005384000040bd3260000000000005b00f700000000000000000000090c06020002800000000000
3c1212071117033e4d3430c10000000005384000020bda210000000000005b00f700000000000000000000090c06020002800000000000
3c1212071117033e4d3530c10000000005384000040bf6210000000000005b00f700000000000000000000090c06020002800000000000
3c1212071117033e4d363058000000000537f500020bff1f0000000000005b00f700000000000000000000090c06020002800000000000
3c1212071117033e4d3730790000000005380e00020c0a1e0000000000005b00f700000000000000000000090c06020002800000000000
Line returns added by me to show structure.
Probably the 3c121207 bit is a datetime structure, as in the Enertia log files. So perhaps not as irregular as I supposed.
Edit: I'm assuming the grouping of 7 records there are the 7 battery modules.
-
ain: could you provide us with a charging log with a external measured date?
like charging it for 5 minutes giving us the new log file :)
bwt, I think those 7-blocks are every 10 seconds.
> 3c1212071117-003-e4d3...
> 3c1212071117-013-e4d3...
etc
-
The header looks the same as the Enertia log file.
3c 3e bracket the datetime group.
3c 12 12 07 11 17 00 3e
=
2012 Dec 07 11:17:00
You can see this btw where it skips from
3c1212071117593e
to
3c1212071118003e
One group of log samples every second, which explains the large file sizes.
-
Ain,
Can you verify that 41875A2F.CHG has a creation/modification date in the filesystem around Dec 7 11:17?
-
One group of log samples every second, which explains the large file sizes.
With ~10 lines per group that would mean 100 seconds charging in that file. Thats not much.
Given a consumption of 1kb / s it also would mean it would run out of memory after just 90 days of consecutive charging :D
"Insert new device to charge" :D
-
Edit: Whoops, forgot I was looking at hex characters and not bytes.
Approximately 650 bytes/second of charging. A full 3.5 hour charge would write around 8 MB of logs, or about 2.3 MB/hour, which seems to be more or less consistent with his directory screencapture above.
His CHG file sizes are 3.1 MB, 2 KB, 1.4 MB, 1.4 MB, 10.8 MB.
I'm assuming the 10.8 MB log file is very close to a full charge + balance.
Probably if the device approaches a full state then it will erase older log files. It probably writes at a much reduced rate once it enters a sustain mode - look at the 1.4 MB charge file, which I assume was generated from a ~44 hour charge.
-
Hackers Unite....
It's fun to see you two having such a good time with freaking numerical gibberish :)
And while I assume Brammo looks at some of that info as proprietary, well once the bikes are in the wild, the geeks are gonna play...
Me? I killed way too many brain cells in college...I was hacking mainframes on campus at 12...by 19 the only numbers I was crunching were phone numbers of all the pretty ladies**
Gavin
-
Ain,
Can you verify that 41875A2F.CHG has a creation/modification date in the filesystem around Dec 7 11:17?
Correct - thats the 12/7 11:17am file! It was only plugged into for a few minutes on that charge.
The forum only lets me attached small files (<500 bytes) which is why I picked a couple smaller ones.
A "full" charge can generate a 30MB file, so it's obviously logging pretty frequently while charging.
Edit: I'm assuming the grouping of 7 records there are the 7 battery modules.
It also looks like there are some repeating numbers in the 7-line groupings, so I wouldn't be surprised if there's a serial number in there for each battery module. There are stickers on the top of each module, so I'll see if I can grab a photo of one next time I have the seat off. That might unravel one more field.
- Ain
-
Source/binary distribution attached.
I haven't been able to pull much useful yet out of the log files, but it does appear to log bank voltages (1..28) and pack voltage. I would assume there would be some throttle positions, speeds, ambient temperatures, module temperature, regen mode, sport mode switch, etc logged in there as well.
Here's an example data record with my interpretation:
Hex string representing a single log record:
3c1212071117013e423a38383838383800160100000000000064008000000000
002d740000007f00004e4a00000f0e010e87004500004272610e060e070e070e
040e060e0a0e080e050e010e040e080e050e040e090e080e050e050e080e090e
050e080e0a0e0a0e070e0c0e0f0e0d0e090e060e060e060e06ffe3ffe30000ff
e3ffed0000ffe30000595b595a5d5e5f006060606061616200
Broken down into parts:
3c1212071117013e
'<', YYMMDDHHMMSS, '>' date time tag
42
block id
3a383838383838001601000000000000
unknown data, often invariant
64
pack voltage? (seems to vary as the sum of cell voltages)
008000000000002d740000007f00004e4a00000f0e010e8700450000427261
unknown data, often invariant
0e060e070e070e040e060e0a0e080e050e010e040e080e050e040e090e080e05
0e050e080e090e050e080e0a0e0a0e070e0c0e0f0e0d0e090e060e060e060e06
32 16bit values, seems to represent 28 bank voltages in millivolts + bank 1 repeated 4 times
ffe3ffe30000ffe3ffed0000ffe30000595b595a5d5e5f006060606061616200
unknown data, often invariant
You can edit the Log Settings.xml to add new values if you identify them. The XML file contains a series of "blocks" with an associated id tag. Each block type seems to have a consistent record structure.
The charge and discharge logs share block ids, or at least both logs contain the bank voltage records.
-
There does seem to be some Hex String labels in there in between raw data blocks. These appear to be buffered by zeros to offset the data blocks to specific offsets. Right after the date there are "4d31", "4d32", etc on consecutive lines. This is "M2", "M3", etc in ASCII. It looks like M2 through M7 repeat every time increment.
Then there are other large data blocks that start with "423a383838383838" after the date sentinel, which is "B:888888" in ASCII. Later in this data block there is a "42726" in the exact same place in each of these large data blocks. This converts to "Bra" in ASCII which I would guess stands for Brammo.
It definitely is an interesting log format, with mixtures of different ASCII, numeric, and date formats all in the same file. A single conversion pass won't decode it. Different hex pairs have to be converted in different ways depending on their position in each line.
-
4d31 through 4d37 are M1 through M7. I'm not sure why you thought it started at M2?
I'm guessing it is data about each module in a separate entry - aren't there 7 battery modules?
-
You people are feakin' scary. :D
I can just see someone at brammo reading this, and going. "no, no, Nooo." While someone else is tearing up a keyboard writing a software patch while muttering something like. "Oh, those Brammoforum guys think they hack my code. Yeah, well hack this!" But I always picture the Brammo folks having more fun then they probably are. :D
-
This ain't hacking. When I started using computers you had to load your hexcodes in by hand just to balance your checkbook, if any of you kids know what that is...
-
A checkbook? Those belong in a museum..
-
A checkbook? Those belong in a museum..
I completely agree. I have never had one and don't plan on changing that
-
Any more work on this?
-
I've written a "slightly better than a hex dump" viewer, but all it does so far is recognize the date fields, express them as dates and then print the rest of the entry out as hex codes except for the V (VIN) and C (Comment? Charge?) sections which appear to be in ASCII.
I've written it in JavaFX because it's what I know and there is a nice charting package built in which I'm sure will come in handy once I get to that point. The question is how to share and collaborate on it? For now I have a few things I'd like to get going on it before it is really useful so I'm going to keep hacking on it, but I've attached a snapshot of what it looks like.
-
A little bit more work - I think I can calculate SoC from the logs (and graph it).
-
If any body is interested is helping us figure out what wondrous secrets are hidden in the Empulse log files, now is your chance!
I've uploaded a modification of Flar's fantastic Enspector java program.
https://bitbucket.org/freepz/enspector/downloads (https://bitbucket.org/freepz/enspector/downloads)
The big change here is that you can edit what data is displayed on the graph.
So far, Flar and I have figured out the Odometer, and I think that I have the air and motor temperatures.
Here's what it looks like:
(http://freepz.files.wordpress.com/2013/03/enspectorv2.jpg)
Once you've figured out some of those data values, just post your settings.json file somewhere and we can all import it and find out what you've discovered.
-
To facilitate sharing, I've created an editable spreadsheet that has a definition of the various values that can be found in the logs.
Here's a link to that spreadsheet:
https://docs.google.com/spreadsheet/ccc?key=0AhH9n2kvW1yEdDJfNjkzakFPcmxZRlI3Q2RNanRVNWc&usp=sharing
If anybody has figured out what some of the other bits mean, please update the spreadsheet.
-
I've uploaded a new version of the Enspector.
https://bitbucket.org/freepz/enspector/downloads
Changes for 1.03:
- The Edit Graph window is now a table that can be scrolled and sorted. This makes it work a lot better when there are many entries in the table (the old version got pretty wonky with more than about 6 rows).
- The Log Data now shows the data values that are known: Speed, RPM, Odometer, Motor and Air temp, and Throttle Position
-
Any more work on this?
-
My log drive stopped working a few months ago so I haven't had much incentive, but I'm looking to get that fixed soon...