Yes, it should work just fine under Boot Camp, Parallels, or VMWare.
If insanity overcomes me I may at some point port it to Qt for multiplatform support, but I have a bunch of functionality I want to add first.
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
Yes, it should work just fine under Boot Camp, Parallels, or VMWare.
If insanity overcomes me I may at some point port it to Qt for multiplatform support, but I have a bunch of functionality I want to add first.
S-2000 Roadster
#1244
You're absolutely right! Even if someone were willing to share their Win32 source with me, I'd end up throwing out 80% of it anyway. I totally agree that documentation is more useful than source code, with the possible exception that someone could write a standard C parser for the Tesla files and maybe share that without any GUI code.
I've been through your documentation, Tom, and it's excellent! My only hesitation is that Scott seems to have already deciphered extensions to the format, so I'm wary that I'd be missing something if I start developing a new app.
What would be great is if someone were to revise the documentation and share a 2.0 specification. I wouldn't expect Tom to do this, necessarily, since he's already contributed a great deal just by making the documentation that exists so far. Who knows, if I find a lull in my work, I might have time to look into this. I'll certainly share my OSX app if I ever make one.
tomsax
Member
The basic format of the log file hasn't changed except in the ways I have documented.
Some new records were added with the 2.0 Roadsters, and a few fields in existing records changed. Even apart from that, our collective understanding of the data fields is a moving target as we continue to decode more data fields.
Over the last few days, I've been working on fixing a data field that changed between 1.5 and 2.0, a field that was added in 2.0 and also trying to crack four fields that have long been flagged as interesting candidates but not yet reversed.
Even if you started with everything we know perfectly combined and documented, it would still change. I'm sure if you started looking at the data, you'd find new stuff as well.
If you can implement a graphical parser that supports just the stuff in my document, you'll have a lot of cool stuff to show. If/when I get done with the stuff I've been working on recently, I'll update the document and try to do a good job of documenting the changes.
SByer
'08 #383
Hah! Fair enough. But I do know exactly how much is required to write a full GUI, which is why I don't create GUIs using any of the platform native tools any more if it can at all be avoided (just too darned painful!). It sounds like what's really needed is to try and come up with some database schemas to keep flexibility for the future. It's pretty easy to go from there to a reasonable web UI (there are a couple of good JS+Canvas charting packages out there, but then: open source, gift horse, mouth...). I can see where creeping feature-itis would permanently extend that, and it's also just me flapping about what I would do in my copious free time. Heck, I'm still trying to finish fixing up a raw Perforce -> Git converter (open source, gift horse, mouth...) so I can re-start working on the other things in the stack of programming to do at home...
S-2000 Roadster
#1244
I hope that questions about the VehicleLogs file format are acceptable on this forum, and that this is the appropriate thread.
Tom's .doc mentions that the 2nd section is 8 MB, but I can't find anything documenting how to determine the size of the 1st section (other than that it is 'small'). Anyone know?
Tom's .doc mentions that the 2nd section is 8 MB, but I can't find anything documenting how to determine the size of the 1st section (other than that it is 'small'). Anyone know?
tomsax
Member
This is certainly the active log thread, but it might be better to have the more technical discussion on the format in the original log parser thread just so we keep this one focused on the apps.
Hmm. I totally skipped explaining that.
The key is the vehicle info record, record type 1. The log seems to use them as markers for subsections, especially in the transient section. In those records, the top bit in the byte I call t3 in the document is set in the permanent section and clear in the transient section. The transient section begins with the first vehicle info record that has the most significant bit of t3 cleared.
I'll add that info to my document.
The Roadster 1.x uses a 32MB NOR flash. There were two flash partitions used for the logs. The permlog was 4MB and the tmplog was 8MB. vms_log was created by concatenating both logs and saving them in the 2011xxxxxxx.tar file. The log_offset file in the tarball tells you where each of the logs ends. This is important because the logs will wrap. If you ignore it, you can read records in the file that are older than the ones in the beginning. You should also verify the Xsum of each record.
The Roadster 2.x uses a much larger NAND flash. There are no dedicated partitions for the temp and perm log files. The log files can be as large or small as needed, but they seem to still wrap at the 4MB and 8MB size and use the log_offset file. It's possible that the permlog can now grow with out limit as I have not seen a 4MB wrapped perm log from a Roadster 2.x. As Tom said, there is a header or ident record (type 1) at the beginning of each section. I didn't notice the bit Tom found to distinguish between the perm and temp sections. It appears that all the record type numbers are unique, so it doesn't really matter which section (i.e. log) they are stored in.
Last edited:
My approach was to simply read all the valid records then sort them by date/time. That way I don't care if it wraps.
Yeah, I still have some Heathkit electronics test equipment in boxes in my basement; some of them even still work. The oscilloscope gave up the ghost years ago and has been discarded, but I still have a working frequency generator and frequency counter, which have even seen use on rare occasions. I also have a VTVM and capacitance/inductance bridge that might still work, although they've got tubes and I've not turned them on in a dog's age.
benji4
Roadster 2.5 #0476
I deleted logs I had saved on the USB as I assumed the car would output a full log rather than just the last piece if there were no files on the USB. After deleting the files, however, I still only get the portion of the log since the last download when I insert the USD. Is the portion I deleted now permanently gone? Is there anyway to make the car output a complete log rather than just data since the previous download?
It's not the data since the last download. It's the data that fits in the memory store. It's a rotating buffer, with oldest data being overwritten by the newest. Depending on your driving you might get the last month or two worth.
In other words, never delete the data. Copy it to your hard drive. It doesn't take much space.
In other words, never delete the data. Copy it to your hard drive. It doesn't take much space.
benji4
Roadster 2.5 #0476
Got it, that makes sense! That leads to this question: Can the graphical log analyzer use multiple files? Also, one other thing that might be nice: the graphs should probably scale better instead of being 0 to max value. Many thanks!
Right now it can't read multiple files. I suggest that you download periodically, so that the successive logs overlap.
I can autoscale the graphs, but that often has undesirable side-effects unless you do it carefully. I'll look into it.
It's been a while since I've posted an update, and I have a bunch of things I want to add to the parser. I should have a bit more time available in the next few weeks, so I'll try to get a new update out.
Similar threads
- Article
- Article
