It's taken me long enough but I finally got around to fixing Jason Weir's original perl coded Aldltobin.pl script. I basically edited it so that it works ;-) and compiled it to run as an exe so people without perl on their computers can still use it. If you want the source code e-mail me at prevost.3@osu.edu The program can be found in the incoming directory. ftp://ftp.diy-efi.org/incoming/ under ALDLtoBIN.zip Maybe I should explain what the program does. The program takes a bin file and logged BLM data from WinAldl and spits out a new_bin file ready to get burned. The new bin not only has the corrected fuel tables but it also has the checksum automatically updated. If you've got one of Craig Moate's adaptors you'll need to change your mask id (D004) to AA so your ecm doesn't hickup when you switch with the ecm still powered up. I'm working on a C++ version of this software but this is a big step in the right direction for those of us with slow laptops that don't like waiting 5 minutes for excel to refresh only to be completely frustrated when data doesn't import correctly or paste like it should!!! The features of this program are very simple. Input comes from you (options) and 2 files. Output is a new binary image. Run the program from the command prompt (windows users either start-run-cmd-enter or start-run-command-enter) Usage= drive:\directory>aldltobin <filename.bin> <winaldlblmdata.txt> <ecm> <what data to use> example= c:\winaldl>aldltobin anlu.bin 20030114_154207_BLM.txt 8746 N The <ecm> can be either the 8746 or 7747 (common ecm's used with winaldl) but all similar ecm's are supported if you know the starting location of the main VE table. Just type in the binary location (ex. 4C2). The <what data to use> is either the Narrow average 10 or Wide average 10. N or W. It's up to you which you want to use. If you've got lots of Narrow data then use that obviously, else use the Wide. That's it. Oh yeah, and the files should be in the same directory or the complete path names must be typed out. If you've got suggestions through them my way. co-author, Jon Prevost copyright, this is FREEWARE but if you use it you have to let me know how you like it. The software can not be used for commercial use without the written concent of either myself or Jason Weir.

So this is basically an automatic of the "VEfixer" spreadsheet? Cool!!!

yup, but I would highly recommend you change all of your 400-3200rpm 2nd VE table cells to 0. I could right a program that changed those as well but it's so much easier just setting them all to 0 and working only with the main VE table.

You say it makes a bin file by looking at a readout from the cable? SO then after like 10 times through shouldent it be pretty close to right on, without any real work by the person?

Now, are suggesting that it would be best to set the 2nd VE table to zeros and just leave it that way permanently? or just zero it out until you get the main VE table dialed in and then go back and play with the 2nd? Please elaborate a little. Thanks...

The 2nd VE table is from 0 to 6400rpm. Do NOT put a zero in the 0 cell of that table, just zero from 400 to 3200. I could modify the program easily to do this for you or simply modify both tables with the correction values but honestly I don't think it's needed. You shouldn't make it harder for yourself with 2 tables to think about. The adder table's 0rpm cell should be just slightly below the main VE tables 400rpm value! It's all the same but correcting one table without the other is not going to be enough since they are added together.

Ok, let's see if I got my feeble little mind wrapped around this correctly. The 2nd VE table is just an array really and is expressed as % of main VE table. So I should zero out the array from 400 to 3200 rpm. This will force all VE calculations to be made with the main VE table and the 2nd VE will then essentially be ignored as if it was never there. Is that about right? Sorry, I'm a little slow on this one. And if this is the case, why in the hell did they ever put the array in there in the first place?

Yeah, that's correct for the most part. There are 2 tables, main VE and adder VE. The values in these tables gets added together and that's used to map out your fuel curve. By zeroing out the adder table all the corrections can be made in the main table. Don't zero out the whole table because of the reasons I already posted but also because most if not all of our engines have a peak torque/VE above 3200rpm.

Ok, Im still trying to grasp this. sorry.
OK I start with logging some data with winaldl. Now with the .csv excel file what do I do? I tryed to open the ALDLtobin.exe and a MS-dos screen poped up and then closed itself. I know im missing alot, could someone break this down alittle bit more?

You've got to goto a command prompt first. In windows, click the start button, then goto "Run". Type "cmd", or "command". A command prompt will pop up. You'll then need to change your directory to the directory that the program is in, i.e.

cd c:
cd FolderName\ALDLToBIN

Then use the format Jon listed.

Ok now with the win aldl file mine isnt a .txt its a .csv will it work like this? And he said 7747 and 8746's work by just puting in that. I have a 7730 I think the start address is 6EE but I am not sure. so if all that works then theoretically I press enter with all that and i get a new .bin ?
sorry, Im a slow learner with some things.

Don't use winaldl for the 7730 and I don't even think it works. You need Craig's software (also free) and just use his VEphd software (also free). You've got a faster data stream, no sence in limiting it. Also the VE tables in the p4 (your ecm) isn't like that in the c3's.

Now, won't this be a hoot with my DIY EPROM emulator that I'm coming out with?

I can't think of anything better. All side projects are on hold until this summer. If a diy eprom emulator comes out then I'll try and develop some program along with winaldl or winbin to auto update for a self learn. The only issues are the cells that don't get data. I'm still working on an excel alogorithm that works well to get you into the ballpark but I can't figure out how to have the equations work from in to out bounds. Basically I need to run a do while loop that finds the cells with no data and edits them according to they're positional vector in comparison to peak torque and then continue on to the cells outside of those cells. Really not hard but it's time I don't have.
Believe it or not, I've only take 1 programming class EVER. It was only for a couple months, fortran and maple 7. I picked up so fast that the teacher offered me a job as a TA for the next quarters class. Perl is great. I had no idea it was so simple and as powerful as it is. It's now my adopted "quick file editing" language of choice. Anyhow, please e-mail me with the updates and if you need any help. I've got a EE grad student that loves this stuff. He's doing our little in-steering wheel display/shift light for our formula car. It's already done and looks badass, definatly a talented individual.

I've got a VB program that I wrote that does this, but only for the 1227747. It also has all the values and tables for the IAC (the next thing I plan to tackle) that you can modify and update.

It reads your bin file, reads the BLM file saved from WINALDL, and lets you update the table and save it. You can also turn off EGR and turn on closed loop idle. It's not quite ready for primetime yet, but after some testing I would be happy to upload it.

Sounds good, just make sure it doesn't require any special .dll's or what not. Most of the computers are old and VB might be a little too much, we'll see. Oh yeah, and don't forget to include the 8746 ecm. It's only an address change.

JPrevost, yellow73bb,

In your programs, do you just multiply the WinALDL 'Correction' table with the old VE map or do you do it cell by cell and analyze the '#Samples' and 'Std. Dev.' tables do decide if the correction should be used or not?

A cell with only a few samples might not have enough data to validate a correction based on it.

Even if a cell has enough samples in it the sampled values might vary too much to validate a correction. This can be seen in the 'Std. Dev.' table.

It uses either that Narrow correction 10 or Wide correction 10. That way it's the last 10 good cells of data.

The Correction will hold the last 10 samples IF you have received 10 samples or more in that cell. That is why you could use the #samples table to verify that you have at least 10 samples.

Even if you have 10 samples some of them could be odd values that should not be used for tuning. By looking at the Std. Dev. table you can see the spread of data in that cell.

The standard deviation measures the spread of the data about the mean value. It is useful in comparing sets of data which may have the same mean but a different range. For example, the mean of the following two is the same: 15, 15, 15, 14, 16 and 2, 7, 14, 22, 30. However, the second is clearly more spread out. If a set has a low standard deviation, the values are not spread out too much.

15, 15, 15, 14, 16 will have a standard deviation of 0.6
2, 7, 14, 22, 30 will have a standard deviation of 10
Both cells would show an average of 15.

If one cell has a high standard deviation then that is a warning flag.

This automated tuning help is a great thing but it is a risk if you dont validate the data used for tuning.

It's a tool, not an answer, just a tool!

Sorry, Don't take it personally.

Yes, it is probably a great tool as it is. I was just trying to point out possible improvements.

I'm not considering what I have to work with is YOUR software .
I can think of MANY improvements that need to be done but I don't have the time to do it. Besides, with the way people on this board crap on TBI I'm suprised there was even a reply thanking me for this.

Jon-
I just used your program for the first time, and I have to say it is a real time saver. Thanks. It sure beats copy and paste from Excel. BTW, I also like the ability to use the "wide" option. Your 8746 .ecu file is also appreciated.

Ral

Thanks for the kind words. It really does cut down on the time and that's all I wanted to do. Honestly I'd rather use excel because I have a auto-update chart to compare and contrast the changes logged but.... when you've got things to do and maybe a slow computer, this is worth it.
BTW, that ECU file still needs some work. There are some 8 bit constants that should be arrays (16-bit). I just haven't gotten around to fixing it. I figured I'd just release and update. Maybe somebody else wants to do it .

ttt

how long should i run data logging, and is there any special ways i should drive to get better results from it.

Steady, smooth throttle transistions so as not to screw things up too much with the pump shots. Also holding a gear helps get more data at higher rpms and go up to 3200rpm and lift off the throttle slow to dig down into the high vacuum (~20kpa) range. You'll see that the most accurate data will be changed where you've gotten the most datapoints. I also highly recommend you use excel or something to chart out the new tables and do some smoothing so it doesn't look WAY out of wack. Remember better rich than lean.
I'm working on some really cool iterations that'll smooth data and give you a great baseline for tuning your VEs. I'm also going to try and make the script add the VE #2 array to the #1 table before making changes, then doing a bunch of other cool stuff. Right now I'm working with excel to get the interpolation equations figured out. The idea is basic. Vol eff increases as MAP increases. At least this is what it should do. Then it should also increase all the way to your peak torque and then from there decrease. Getting solid results in an area can help interpolate a guestimated curve good enough to be a baseline before using a wideband o2.
All of this is taking a back seat to some more important things in my life but it will get done. If anybody wants to help please PM me.

Hey man, tried to pm ya but it was full and your email was bouncing.

Im tryin to hammer out the fuel table and when I run the program it just changes all the values to zero (its reading in the data from the original bin ok though, those numbers are showing up right). Should I exclude something from my logging (right now Im just logging everything), or is this an ID 10 T error?

oh yea, Im running it from the c:\car dir with the log, bin, and exe all in that dir. My command was

c:\car>aldltobin antt.bin 041803_4.txt 8746 W

Oh yea, if you're still working on putting it in C++ let me know. Acutally today i was thinking it'd be even cooler to code it in java for mac/linux users.

how are u guys getting a txt file. i data logged and it just says xxxxxxx_xxxx_LOG

That could be dangerous... But its cool.

Something like that for $8D would be neat.

-- Joe

Can this be used for the 7060 ECM? The reason I ask is that a fellow club member (454SS club) has written a new Prom with a different VE resolution. The new chip uses a 17 x 17 table vs the 12 x 13 stock table. This changes the rpm range to 0 - 6400.

MAP scaling is from 20 kpa to 100 kpa in 5 kpa increments. He has also written a new TDF file for Tunercat.

My truck is a 90 and uses the 7747 ECM. I am considering changing over to the 7060 ECM so I can use his set up.

Thanks

Bill

i tried to use the program but a window would just pop up and then close.

my promt i ran was C:\WINDOWS\Desktop\PROM\aldltobinalt ANLU5369 61.bin 20030307_155940_LOG 8746 N

everyone seems to have a txt file, but mine did not have that at the end. am i using the wrong data file.

also how long should i data log, i drive 20 mins in the morning to get to school, is that enough?

I can make the program work for anything that's supported by winaldl.
You guys can't use the LOG files, you need to save the BLM or INT tables (BLM is better idea) and use THOSE files.

oh so i copy and paste from my log file to a excel file, and use that

No.

oh so do i wait till it is full, then click save

It doesn't need to be full but you'll want as many cells in narrow filled. If your BLMs are in the 126 to 130 range I would only use the narrow, not the wide, it'll give you more accuracy. The more data avail the better. It's best to wait until operating temp, clear table, look at the number of samples and fill them up with smooth transient throttle movement.

What do you mean by "filing them up with smooth transient throttle movement"? Do you actually type in BLM values at the MAP/RPM values that did not get data during the data logging run?

Scott

no he means, whatch the table fill in, and while you are driving, smoothly (read, don't mash the gas) accelorate to get to the desired RPM range to fill the cells.

oh ok, i get it now, if the numbers aren't in the125-130 range then do i use the promt with a W at the end.

when i click save table, does it only save the table im looking at, if so which table should i save. i think theres like 8

It saves all of the BLM tables but don't worry about that. All of them are in the file ___BLM.txt , use W if you just need to get into the ballpark figure but if you've got a lot of narrow cells filled in with data then go ahead and use N

oh ok, i get it now, thanks

I realize this is old news, but does anyone have a copy of the source laying around ? I've searched any place referenced and Jon doesn't have it anymore....

I've got a copy: here, just remove the .txt extension from the executable file and follow the readme.

Thanks, thats what I have already. That's the actual perl code with the perl parser wraped around it... (compiled into an exe)

I have that, and it works great. But I was looking for the actual perl source code.

Thanks for the help though..

ahh ok, my bad, sorry that's all I've got.

Ok, so I had a stupid pill yesterday and didn't notice the date. Anyway I downloaded it from the link that BronYrAur posted, but I can't get it to open. I removed the .tst extension, and tried to run it from the command line. A DOS window quickly opens the recloses. How in the workd do I get this thing to run? TIA

I've followed the above instructions as best as I could, but I've forgotten my DOS. I have managed to get as far as the following:

ALDLtoBin - by Jason Weir 2002
Compiled and modified by Jon Prevost

Compiled and modified by Jon Prevost

USAGE: aldltobin binfile winaldlfile ecm N or W
Example: aldltobin anlu.bin BLM.txt 8746 N

All files must be in the same directory or you must specify the entire path

E:\ALDLtoBIN>

So what do I do now?

Assuming you have your BIN file and saved BLM file from WinALDL copied into the ALDLtoBin directory, you type (into your DOS window)

aldlbin the_name_of_your_bin_file.bin the_name_of_your_BLM_file.txt 7747 N

or if you have an 8746, you put 8746 instead of 7747.

Teeleton