|
Title: m box XDF error? Post by: spen on November 05, 2010, 11:00:23 AM A curious anomoly has arisen when comparing my output with Nyets m box data: I'll use KFZW2 - ignition map. address x axis y axis Spen 0x811d32 0x8100ff 0x8100c2 Nye 0x11D32 0x100FF 0x12B04 As you can see we disagree on the Y axis. Y axis in the xdf is RPM. I offer up the following as evidence of why I am right: (http://i272.photobucket.com/albums/jj172/spen0007/rpmscaleiswrongonkfzw2.jpg) Looking at the larger window at the back. r12 is loaded with 0x11d32. The scanning routine called by calls 0, unk_78B8 just looks in address range 0x81 + r12. This is the map itself being loaded. Just under the map being loaded r13 is loaded with 0xfe. The routine at unk_78B8 treats r13 as a scale for the map. Again it looks at 0x81+r13 as before. This scale is the % load. The scale contains it's own length as the first byte, so the actual scale starts at 0x8100ff. Now I differ on the remaining scale, the RPM scale. You can see the unk_78B8 routine being primed with the RPM by loading it in to r14. The ram address is 0x380f46. Searching for writes to 0x380f46 reveals only one write. This is shown in the other window. Following the same logic as above we can see r12 loaded with 0xc1 before the scanning routine at unk_75d2 is called. This corresponds to a search at 0x8100c1 (and taking care of the byte for length gives 0x8100c2) Therefore I assert that the remaining scale is at 0x8100c2 and is in bytes. In some other roms this scale is in words and has a different scanning routine. There is a nice scale at 0x8100c1, of length 0x10. This scale is in bytes. It all seems to fit to me, but it would mean the M xdf is incorrectly scaled in some ignition maps. What do you think? Have I missed something? Title: Re: m box XDF error? Post by: iznogoud on November 06, 2010, 05:51:54 PM (Why do you and he have an offset of 0x800000 ?)
Title: Re: m box XDF error? Post by: Tony@NefMoto on November 07, 2010, 12:32:31 PM Here is what I have from my definition:
address: 0x811D32 X axis: 0x8100FF Y axis: 0x8100C2 Spen is right, Nyet is wrong. Title: Re: m box XDF error? Post by: spen on November 07, 2010, 01:42:20 PM Cheers Tony. That was driving me mad. It also means that everyone is using the wrong RPM scales on a number of maps :o
I'll be able to output a number of XDF files soon enough and they'll be right in this department. Iznogoud, My 'offsets' are not offsets, they are memory addresses as written / read by the ecu. Just take away 0x800000 to arrive at the file offset. Tunerpro works in file offsets, but I work in IDA. Title: Re: m box XDF error? Post by: iznogoud on November 07, 2010, 05:45:25 PM OK I see.
Tony, can you point us to your Mbox XDF file? Also, is your bin the same or different than Nye's? (We have already established that Audi put out 2 different Mbox bins.) I will email him. Title: Re: m box XDF error? Post by: Tony@NefMoto on November 07, 2010, 10:22:07 PM I don't have a file per se. All of my map definitions are in code inside my ECU editing software. I will see if I can put something together to release in the near future.
My maps definitions were found by reverse engineering the ECU code. Nyet's defintions were done by cross referencing other defintion files against the S4 mbox data. Title: Re: m box XDF error? Post by: nyet on November 08, 2010, 03:19:53 PM For the record, do not trust ANY of my XDFs to be canonical. spen is obviously on the right track.. as he (and others) have said, my locations are from crossreferencing map data from other sources.
At the end of all this, can somebody summarize the errors in my xdf so I can update it? :) Title: Re: m box XDF error? Post by: spen on November 09, 2010, 02:36:56 AM Hiya. It's the RPM axis in the timing maps. Some maps use 8bit axis and some use 16 bit rpm axis.
I'll put together a matrix of ME7 timing map name and the axis locations for the M box. For starters, in the M ecu, KFZW and KFZW2 have axis at file offsets: X axis: 0x100FF Y axis: 0x100C2 Title: Re: m box XDF error? Post by: iznogoud on November 09, 2010, 08:56:39 AM Well... I am having much less luck with Nye's files.
I started pulling out the axes maps from his Mbox file using his Mbox XDF. I wrote a little code that parses the XDF, reads the BIN and does the work. I verified that what my code picks up is correct -- but I am known to be stupid at times. Here is an example of a discrepancy I found. In the MAF voltage linearization I see a lot of bad data by just looking at the raw hex data, not even plotting them. Let's see if I can paste it here: Code: --> "Linearization of MAF voltage" <-- Too many FFFF in there. What am I doing wrong. (I have not even started with the disassembly of the assembly stuff.) Title: Re: m box XDF error? Post by: iznogoud on November 09, 2010, 09:05:46 AM Hmmmm... I see what is going on. I am setting defaults to ZERO for addresses of XAddress and YAddress of the XDF file. For that particular map there is no XAddress or YAddress, so I am point up to the top of the file by default.
Something I am not understanding about the XDF format maybe...? But I see garbage for data on other maps that do not suffer from my bad assumptions. An example is the "Minimum Ingition Angle" 2D map. Even within TunerPro it looks like the axes have garbage for data, as do the data of the map itself. Ideas? Title: Re: m box XDF error? Post by: iznogoud on November 09, 2010, 09:35:50 PM Oh, this phaquing thing... I am so sick of running into this problem.
Just tried it again on my 32bit linux box. There is a difference... So, there is some issue with the addressing, and it manifests itself in two different ways. When I read the same binary on the 32bit and 64bit machines I see different results on the X and Y map addresses that I am reading. That's one problem that I should be able to trace. But here is another. I was seeing garbage on the data itself, as I noted above, for various maps. It turns out I was running TunerPro on the 64bit machine over "Wine" the windows compatibility API for linux. Whether it was the 64bit-ness or the fact that I am running it over Wine, I do not know. But I know I have an issue that is not related to the files I am using, but rather to the environment I am using. At least now I know and you know too. Sorry for the threadjack. Title: Re: m box XDF error? Post by: spen on November 10, 2010, 01:51:15 AM I have the same problem with hex turning in to garbage if I have too much wine :D [/topic] Title: Re: m box XDF error? Post by: Tony@NefMoto on November 10, 2010, 12:25:32 PM I find my code runs best when I run with beer on the couch.
Title: Re: m box XDF error? Post by: iznogoud on November 10, 2010, 02:37:05 PM I find my code runs best when I run with beer on the couch. I cannot work with beer or vodka -- it is one or the other. I can do math fine, if not better, with vodka/beer in hand but not code. Women tend to distract me and it is a non-linear function of their amount of clothing and apparel. I did some map searching with my hacked up codes and tried to match Nye's bin to the Abox bin that I got from this site (both for the B5 S4 ECU). Attached is an HTML tabulation of addresses for Abox matched to Mbox in terms of axes addresses (not the data). I find multiple matches for some of the axes. I have not looked into it, but I am guessing that there are duplicate axes maps for multiple tables. This makes sense since you could have the most generality by allowing all tables to have their own axes maps, but at the end some of them have exactly the same data (say RPM values, or load values, etc). How do I separate apples from oranges here without looking at the assembly parts? attached are the HTML file and the code I used. Title: Re: m box XDF error? Post by: Tony@NefMoto on November 10, 2010, 02:53:58 PM Some maps do share the same axis data.
Title: Re: m box XDF error? Post by: iznogoud on November 10, 2010, 05:08:45 PM Some maps do share the same axis data. Yes, that I can understand. But there is a difference between sharing a unique map, or have two different axes-maps that are identical in terms of their contents but are found in different locations. With my brute-force naive searching there is no way to distinguish between the two. I can write a piece of code that takes maps that have the same axis-map data and see if the incidences are the same (in terms of how many those map pairs or triplets, etc, are). But there is no way of associating any axis-map with any particular map that uses it from the definitions. I think that is where the assembly should be helpful. Anyway, I will take this as far as I can with this conventional thinking and we'll go from there. Title: Re: m box XDF error? Post by: torch on November 11, 2010, 07:16:13 AM I ran into this same thing in my Mitsubishi days. There are multiple maps with the same data (AFR in that case) and no indication as to which was being used. With our quick flashing tools from Tony, we can find them the same way I used to. Just zero the map out. If it was being used you can tell pretty rapidly. This obviously won't work for accumulated data maps, but I think you get my point. Granted, in the Mitsubishi there were only like 5 AFR and a few timing maps to hack with, but what's the fun of a simple system?
Matt Title: Re: m box XDF error? Post by: iznogoud on November 11, 2010, 03:28:42 PM I will modify tp.c to uniquely identify the axes-maps. We can make changes systematically and have somebody with a simulator run the bin file. It can get tedious but it is a input-output way of reverse engineering this.
Title: Re: m box XDF error? Post by: iznogoud on November 12, 2010, 09:22:17 AM I do not know how helpful this is, but it shows that several maps share axes-maps.
Title: Re: m box XDF error? Post by: nyet on November 14, 2010, 07:56:26 PM my mesim project parses bins with my xdf/map locations fine.
For example, it can read a bin file and extract min/max from every table... whatever you are doing to parse the bin, your code is probably doing it wrong. pointer arithmetic, or lack of proper ntohl/htonl/ntohs/htons Title: Re: m box XDF error? Post by: iznogoud on November 14, 2010, 09:39:24 PM The code is posted above. It does not look at the data (no conversion or casting) so it only does addressing. I double-checked the data it extracts for each of the tables and looked at that address location in the bin with a hexeditor and those match fine.
I am saying that the XDF I am using, which is yours, has some minor issues here and there. Like for example the last map is pointing to a blank spot of FF FF FF... I am not claiming that I know what is going on. I am basing all of this off your work! There has got to be an error in that tp.c code. I will find it. Title: Re: m box XDF error? Post by: iznogoud on November 14, 2010, 09:58:03 PM Double-checked a few maps of my output with what hex values TunerPro shows. Attached is a screen grab showing the first table and the last map that I think is problematic. You can see on the title bar which files are loaded. I may just have bad files. Something is up nonetheless.
Title: Re: m box XDF error? Post by: nyet on November 15, 2010, 05:26:10 PM Code: --> "Linearization of MAF voltage" <-- Title: Re: m box XDF error? Post by: nyet on November 15, 2010, 05:27:13 PM Double-checked a few maps of my output with what hex values TunerPro shows. Attached is a screen grab showing the first table and the last map that I think is problematic. You can see on the title bar which files are loaded. I may just have bad files. Something is up nonetheless. That last table is unused in M-Box Title: Re: m box XDF error? Post by: nyet on November 15, 2010, 05:28:57 PM The code is posted above. It does not look at the data (no conversion or casting) for 16 and 32 bit values, you will have to (at least) be endian aware. Title: Re: m box XDF error? Post by: iznogoud on November 15, 2010, 06:09:15 PM The code is posted above. It does not look at the data (no conversion or casting) for 16 and 32 bit values, you will have to (at least) be endian aware. Correct. This file seems to be LSB (little endian) by looking at what I am picking up and what TunerPro shows on the HEX mode of the tables (what I have in the image above). This is for the actual maps, so I am certain I am getting those axes read correctly. I will look at mesim again. (I did not know about that unused map.) Title: Re: m box XDF error? Post by: iznogoud on November 15, 2010, 06:13:09 PM Code: --> "Linearization of MAF voltage" <-- That doesn't look like 14254 at all That is a special map that does not have Axes data. Get the latest tp.c and re-run it. I think that section of the printout is not relevant anyway. The HTML files that are generated are the important ones. I re-run it again. The tp.c I am using recognizes that there is something special about that map and just treats it as a 1D array for the 256 values. Here is my printout: Code: --------------------------------------- The one you were running uses the "default value" for XAddress which is 0x0 and so it reads crap from the top of the file. I fixed that sometime ago; it fooled me once. Title: Re: m box XDF error? Post by: nyet on November 16, 2010, 04:43:12 PM The one you were running uses the "default value" for XAddress which is 0x0 and so it reads crap from the top of the file. I fixed that sometime ago; it fooled me once. Aha! Good find! Ok that makes sense. How should one encode "no axis data" in an xdf record? I can fix up my xdf to do that as well. No wonder this xdf crashes tuner pro when you open this table... Title: Re: m box XDF error? Post by: nyet on November 16, 2010, 04:48:47 PM oh, never mind.
my .xdf actually is correct (that i can tell), it uses hard coded xaxis lables (512 of them) and XLabelType = 2 Title: Re: m box XDF error? Post by: iznogoud on November 16, 2010, 09:59:43 PM Will dig into it again. TunerPro consistently crashed on that map for me.
(Edit) I noticed in the past that when the labels are there TunerPro is happy reading it, but still crashes. (Had zero seconds to breathe today and now I am spent and ready for bed.) Title: Re: m box XDF error? Post by: nyet on January 21, 2011, 12:32:01 PM Will dig into it again. TunerPro consistently crashed on that map for me. (Edit) I noticed in the past that when the labels are there TunerPro is happy reading it, but still crashes. (Had zero seconds to breathe today and now I am spent and ready for bed.) Its a known problem with tuner pro switch it from 512x1 to 1x512 and it won't crash Title: Re: m box XDF error? Post by: nyet on January 21, 2011, 12:34:59 PM Hiya. It's the RPM axis in the timing maps. Some maps use 8bit axis and some use 16 bit rpm axis. I'll put together a matrix of ME7 timing map name and the axis locations for the M box. For starters, in the M ecu, KFZW and KFZW2 have axis at file offsets: X axis: 0x100FF Y axis: 0x100C2 Spen have you found any other discrepancies. For example, KFZOP/OP2, KFZWMS (all were using 12b04) these are adjacent to the map, so i assume they are ok: DZWTIN (was using 15222) KFZWMN (was using 16b0c) KFZWMNST (was using 16bf4) KFSZT (was using 1a417) I assume scale/offset is 40/0 Title: Re: m box XDF error? Post by: nyet on January 22, 2011, 06:43:54 PM Updated my xdf.
Spen, i would appreciate your feedback! http://www.nefariousmotorsports.com/forum/index.php?topic=200.msg2224#msg2224 Title: Re: m box XDF error? Post by: FR Wilk on February 11, 2011, 11:19:33 PM possible error? :o
KFZWWLNM X and Y address are the same? XAddress =0x10122 YAddress =0x10122 Title: Re: m box XDF error? Post by: nyet on February 12, 2011, 04:13:47 PM possible error? :o KFZWWLNM X and Y address are the same? XAddress =0x10122 YAddress =0x10122 Thank you! That definitely looks suspect. Does anbody have any idea what those should be? My guess would be Y = 10097 Title: Re: m box XDF error? Post by: FR Wilk on February 12, 2011, 06:11:15 PM Also, there are 4 maps "KFDLUR" at
10333 10373 103B3 103F3 There are another 4 that appear to have the same axis as the above. 1022A 1026A 102AA 102EA Any ideas what they do? Names? Title: Re: m box XDF error? Post by: nyet on February 12, 2011, 08:41:38 PM Sort of pointless do go about it that way. There are thousands of maps. Deciphering what an unknown map does is silly compared to trying to locate a map that you know does something you want to change.
Title: Re: m box XDF error? Post by: iznogoud on February 12, 2011, 08:53:35 PM (Glad to know this thread is not dormant.)
Nyet, I tried getting mesim. I think I emailed you about it. Now sure how to get this running or which of the files bundles to get. Help! Title: Re: m box XDF error? Post by: spen on March 04, 2011, 07:25:29 AM Nyet
I'll check those axes for you. I had to take a break from the internet for a while hence the slow response. Spen Title: Re: m box XDF error? Post by: spen on March 04, 2011, 08:03:39 AM For example, KFZOP/OP2, KFZWMS (all were using 12b04)
KFZWOP rpm axis = SNM16OPUW, 16 words stating at 812B04 (axis length at 0x812B02 {program counter 0x805EF8} KFZWOP2 is the same these are adjacent to the map, so i assume they are ok: DZWTIN (was using 15222) - 1d table scale at 0x815222 {program counter 0x8631A6} KFZWMN (was using 16b0c) - Internal scales adjacent to the data -0x816B0C, 0x816B1C {program counter 0x88AACC} KFZWMNST (was using 16bf4) - Internal scales adjacent to the data -0x816BF4, 0x816C04 {program counter 0x88AB76} KFSZT (was using 1a417) - haven't found this one yet. Title: Re: m box XDF error? Post by: nyet on March 04, 2011, 02:10:07 PM KFZWOP rpm axis = SNM16OPUW, 16 words stating at 812B04 (axis length at 0x812B02 {program counter 0x805EF8} KFZWOP2 is the same spen, thank you so much. I have changed my map pack. I don't know if i'll release an update just yet; i'll probably wait for a few more corrections first. OH and please look for KFZWMS :) thanks in advance. Title: Re: m box XDF error? Post by: Rick on March 22, 2011, 02:32:51 PM Nyet,
rpm axis data for timing map in the last xdf you posted look like garbage? Rick Title: Re: m box XDF error? Post by: nyet on March 22, 2011, 05:21:31 PM Nyet, rpm axis data for timing map in the last xdf you posted look like garbage? Rick 12b04 (SNM16OPUW)? Looks fine in winols, but the xdf is autogeneratead, perhaps there was a translation error. Title: Re: m box XDF error? Post by: Rick on March 23, 2011, 06:52:42 AM Probably, not looked at the .kp.
How much of a difference is there between the old incorrect axis values and incorrect? Old one went from 400 to 6500rpm I think? Rick Title: Re: m box XDF error? Post by: spen on March 28, 2011, 07:25:09 AM Here is KFZWMS in xdf format for the M rom: %%TABLE%% 000002 UniqueID =0x0 000100 Cat0ID =0x8 040005 Title ="Map with permanent latest possible ignition angle (KFZWMS)" 040011 DescSize =0x32 040010 Desc ="Map with permanent latest possible ignition angle" 040100 Address =0x11bb0 040150 Flags =0x301 040200 ZEq =0.750000 * X,TH|0|0|0|0| 040230 RangeLow =0.0000 040240 RangeHigh =255.0000 040300 Rows =0x10 040305 Cols =0xc 040320 XUnits ="%" 040325 YUnits ="Upm" 040330 ZUnits ="grad KW" 040350 XLabels =0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00 040352 XLabelType =0x1 040354 XEq =0.750000 * X,TH|0|0|0|0| 040360 YLabels =0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00 040362 YLabelType =0x1 040364 YEq =40.000000 * X,TH|0|0|0|0| 040505 XLabelSource =0x1 040515 YLabelSource =0x1 040600 XAddress =0x100ff 040610 XDataSize =0x1 040620 XAddrStep =1 040650 XOutputDig =0x0 040660 XAxisMin =1000.000000 040670 XAxisMax =1000.000000 040700 YAddress =0x100c2 040710 YDataSize =0x1 040720 YAddrStep =1 040750 YOutputDig =0x0 040760 YAxisMin =1000.000000 040770 YAxisMax =1000.000000 %%END%% The other axis which Rick says is garbage, isn't. The data is wide, and I suspect the full xdf has it as bytes. Spen Title: Re: m box XDF error? Post by: nyet on March 28, 2011, 11:06:46 AM Spen, as usual, you rock.
Thank you. Title: Re: m box XDF error? Post by: nyet on March 28, 2011, 11:09:42 AM The other axis which Rick says is garbage, isn't. The data is wide, and I suspect the full xdf has it as bytes. Spen Here is what i have for 12b04 040325 YUnits ="U/min" 040362 YLabelType =0x1 040364 YEq =0.250000 * X,TH|0|0|0|0| 040515 YLabelSource =0x1 040700 YAddress =0x12B04 040710 YDataSize =2 040720 YAddrStep =2 040750 YOutputDig =0x4 040150 Flags =0x302 Title: Re: m box XDF error? Post by: spen on March 28, 2011, 02:32:17 PM Change to "Flags = 0x301" ;) (http://i272.photobucket.com/albums/jj172/spen0007/fixedkfzwopfornyet.jpg) Title: Re: m box XDF error? Post by: nyet on March 28, 2011, 02:39:30 PM Change to "Flags = 0x301" ;) Err, im confused. 0x301 is signed, BIG endian 0x02 is unsigned LITTLE endian... i.e. if length is >1, flags should be 0x302 or 0x303, but never 0x301 what am i missing Title: Re: m box XDF error? Post by: nyet on March 28, 2011, 02:47:11 PM Here is what I have for flags
0x001 - value signed 0x002 - value le 0x040 - xaxis signed 0x100 - xaxis le 0x080 - yaxis signed 0x200 - yaxis le so 0x302 is value, xaxis and yaxis LE KFMIOP has SizeInBits = 0x10 = 2 bytes XDataSize = 2 YDataSize = 2 Which is right Code: %%TABLE%% Title: Re: m box XDF error? Post by: nyet on March 28, 2011, 03:02:41 PM Oh, and my KFZWOP is still using the old rpm axis in my last released map pack...
I have not posted the latest one yet. Title: Re: m box XDF error? Post by: spen on March 28, 2011, 03:37:42 PM my xdf output routine produced:
%%TABLE%% 000002 UniqueID =0x0 000100 Cat0ID =0x8 040005 Title ="Optimal ignition angle (KFZWOP)" 040011 DescSize =0x17 040010 Desc ="Optimal ignition angle" 040100 Address =0x1140e 040150 Flags =0x301 040200 ZEq =0.750000 * X,TH|0|0|0|0| 040230 RangeLow =0.0000 040240 RangeHigh =255.0000 040300 Rows =0x10 040305 Cols =0xb 040320 XUnits ="%" 040325 YUnits ="U/min" 040330 ZUnits ="grad KW" 040350 XLabels =0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00 040352 XLabelType =0x1 040354 XEq =0.023438 * X,TH|0|0|0|0| 040360 YLabels =0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00 040362 YLabelType =0x1 040364 YEq =0.250000 * X,TH|0|0|0|0| 040505 XLabelSource =0x1 040515 YLabelSource =0x1 040600 XAddress =0x162e8 040620 XAddrStep =2 040650 XOutputDig =0x0 040660 XAxisMin =1000.000000 040670 XAxisMax =1000.000000 040700 YAddress =0x12b04 040720 YAddrStep =2 040750 YOutputDig =0x0 040760 YAxisMin =1000.000000 040770 YAxisMax =1000.000000 %%END%% Back in a minute.. Title: Re: m box XDF error? Post by: spen on March 28, 2011, 03:45:56 PM mm, on version 4.14 tuner pro using flags = 0x301 or flags = 0x302 made no difference to the presentation.
I'll have to find the code and see if I can work out if I misinterpretted the flag bits, as I'm assuming your flag definitions are correct. What does make a difference is that we're using different map addresses, which means something is wrong. I'm going to double check the map I've identified as kfzwop. Title: Re: m box XDF error? Post by: nyet on March 28, 2011, 03:58:55 PM I'm assuming your flag definitions are correct. Bad idea! Check independently! :) Quote What does make a difference is that we're using different map addresses, which means something is wrong. I'm going to double check the map I've identified as kfzwop. I didn't post my kfzwop because my latest released mappack has the wrong rpm axis (it still uses the 8bit 100c2)... here it is anyway for reference Code: %%TABLE%% Title: Re: m box XDF error? Post by: spen on March 28, 2011, 04:12:14 PM Ahh, that's why the addresses are different!
Sorry didn't see you were giving me KFMIOP. I think KFMIOP has axes at 0x8100dc and 0x812b04; I think your x axis is out. I don't have time to write more I'm out of battery. I'll do an export of KFMIOP as a XDFobject for the M box when I can. Title: Re: m box XDF error? Post by: nyet on March 28, 2011, 04:19:23 PM Spen, thanks!
At some point we need to find a decent way of auditing my entire map pack in one fell swoop :/ And then there is the problem of getting a .kp out of an .xdf, and not the other way around, since i use .kp as canonical ... Title: Re: m box XDF error? Post by: nyet on March 28, 2011, 10:41:26 PM Nyet, rpm axis data for timing map in the last xdf you posted look like garbage? Its a problem with "significant figures" handling in tunerpro. My maps are marked for 4, which is xxxx.xxxx for rpm, which gets truncated to xx.xxxx since the display is limited. Working on setting the right sigfigs now Title: Re: m box XDF error? Post by: nyet on March 28, 2011, 11:06:52 PM I found a bug in my map conversion program.
It wasn't handling precision correctly. Title: Re: m box XDF error? Post by: nyet on March 28, 2011, 11:28:02 PM updated xdf, kp, and csv here
http://nyet.org/cars/files/8D0907551M-20110328.zip |