Page 1 of 1
FRD logfile?
Posted: Sat May 23, 2009 7:25 am
by LeoK
I was reading about the new raw log format.... are there any applications that use it yet, or is it just being discussed?
L.
Re: FRD logfile?
Posted: Sat May 23, 2009 7:42 am
by LT401Vette
TunerStudio will log in it by changing the extension to .frd instead of msl, but that is really just for a reference...
There are a couple of people working on prototype hardware to log to it, which is the real intention. But nothing readily available.
Check the discussion in the MegaLogViewer forum.
Re: FRD logfile?
Posted: Sat May 23, 2009 8:16 am
by LeoK
I just ran a log, and when I opened the file, it looks like the same tab delimited text.
I have been working on a logging program for a portable device, so I was hoping to get a raw data file, that I could use as a test input data stream.
Re: FRD logfile?
Posted: Sat May 23, 2009 9:33 am
by LT401Vette
You removed the .msl and replaced it with .frd, and it still captured in ASCII?
Re: FRD logfile?
Posted: Sat May 23, 2009 10:07 am
by LeoK
Oh! <slaps forehead> When I turn on logging and it prompts me for the file name, thats when I change the extension right? I will try it again.
Re: FRD logfile?
Posted: Sat May 23, 2009 12:03 pm
by LeoK
That worked. I renamed the file with a .frd extension when I started logging, and it did log to a binary datafile.
Thanks!
Re: FRD logfile?
Posted: Sat May 23, 2009 1:57 pm
by LT401Vette
Have you seen the instructions on how. To turn on transformtion on, so it appears on the menu?
Look in the TunerStudio.properties file
Re: FRD logfile?
Posted: Sat May 23, 2009 9:14 pm
by LeoK
No I haven't seen those instructions... I will check it out. Thanks for the tip!
So I am playing with the info in the data file.... and this is what I could pull from the header of the file:
2009-05-23 23:00:28.990 xxx[5825:20b] File Format: FRD
2009-05-23 23:00:29.024 xxx[5825:20b] Format Version: 256.000000
2009-05-23 23:00:29.030 xxx[5825:20b] Date / Time: 121378890
2009-05-23 23:00:29.031 xxx[5825:20b] Firmware Signature: MSII Rev 2.88600
2009-05-23 23:00:29.031 xxx[5825:20b] FDS Start Offset: 5308416
2009-05-23 23:00:29.032 xxx[5825:20b] OCH Length: 42352
Most of that is pretty straight forward, but I don't know if the start offset is right... and I am pretty sure the OCH Length is wrong.
I tried to convert the numbers from binary using the NSNumber numberWithUnsignedLong method, and got numbers like:
2009-05-23 23:11:46.823 xxx[5897:20b] FDS Header
2009-05-23 23:11:46.824 xxx[5897:20b] File Format: FRD
2009-05-23 23:11:46.824 xxx[5897:20b] Format Version: 256.000000
2009-05-23 23:11:46.825 xxx[5897:20b] Date / Time: 13719136
2009-05-23 23:11:46.825 xxx[5897:20b] Firmware Signature: MSII Rev 2.88600
2009-05-23 23:11:46.826 xxx[5897:20b] FDS Start Offset: 13719152
2009-05-23 23:11:46.826 xxx[5897:20b] OCH Length: 13710608
Anyone got any tips on getting the proper Version, Time, Offset, and Length?
Re: FRD logfile?
Posted: Sun May 24, 2009 5:32 am
by LT401Vette
I think this is what you are looking for:
http://www.efianalytics.com/TunerStudio ... talog.html
No need to reverse engineer it
TunerStudio only generates those as a reference file right now.
TunerStudio will then convert it from the binary frd format to a standard ASCII file if you enable it in the TunerStudio.properties file. Find this section:
Code: Select all
#uncomment for FRD to show on the menu
#showFrdMenu=true
Change it to:
Code: Select all
#uncomment for FRD to show on the menu
showFrdMenu=true
Then there will be a new option on the DataLog menu called "Import / Conversion" The FRD format is the Quicky Logger.
Re: FRD logfile?
Posted: Wed May 27, 2009 6:56 am
by LeoK
Thanks for the info!
Is the id/type (1 byte) defined? From what I can see, it is set to the char "p" in my log (from a MSII). I would have thought it would be an "a", the RTU Char.
Re: FRD logfile?
Posted: Wed May 27, 2009 8:18 am
by LT401Vette
The 1 byte in the data section? The valid. Values for that are 1 or 2. Normally it would just be a 1 indicating a normal outpc pull. The only other option currently is a 2 that indicates MARK timestamp fills the next 4 bytes.