Antusprom - tunerpro realtime via ALDL

[delcowizzid]

well got my FTDI usb>serial from hongkong this week quite cheap at around $30 NZ delivered.works great been connected and playing round changing some settings wworked a treat.fast as download of the bin to the pc when useing the FTDI compared to my pc serial port that i had issues with.

[UCMatt]

Fantastic work!
A few years ago, I put a dallas chip into my '808 with the same intention, but ran out of time (and talent ) to get the software side of things going.
I can’t wait to get hold of a standard BIN with the additional ALDL commands to have a play with this.

Let me know if you want any help with beta testing.

Cheers

Matt

[delcowizzid]

the bins are done for vn-vp auto and manual and for VR manual https://pcmhacking.net/forums/viewtopic.php?f=27&t=100 but you need to have a serial connection board and an sram fitted R/T board as found on here to make them work

[Jayme]

used this lastnight on my newly constructed realtime board. im using the built in real com port on my laptop. the bin seems to take about 2 mins to download upon initial startup, what kind of speeds are everyone else getting?
Im also having troubles with both efilive and scannerpro only getting intermittent packets of data from antusprom, which I suspect may be a vista incompatibility. ill boot into windows xp tonight and see how it goes in there.

[antus]

Antusprom adds a 'fake' echo to emulate the traditional 1 wire aldl interface. This is because in tunerpro RT4 you can not turn echo off. This means in scannerpro or efilive you'll need to pick the echo option which might be the opposite of what you expect.

Comms can be a bit flakey on some hardware. I'd like to improve this but im no expert windows programming (I am a linux developer by trade). I know the timings built in to antusprom work well with the FTDI usb serial interface, but I cant see why it wouldnt work for a hardware com port.

Echo settings are the most likely problem.

[Jayme]

Ah, I have echo turned off as thats how it works when efilive connects directly to the com port. I should have realised this, as I rememebr now, it wasnt actually a lost packets when the gauges were going nuts, it was just an echo back of what it sent. I thought, "thats odd" but it still didnt click to turn on cable echo lol.
how long does it take to download the bin on your ftdi? I might be going to ebay to buy one now would also save me having to use my old junker of a laptop.

thanks for the great program

[delcowizzid]

i got an FTDI cable from hongkong $30 to my door off ebay was faster than my serial on my PC and my PC serial was corrupting data suck the bin out with antusprom and open a spark graph in tunerpro and see what it looks like

[antus]

I'll have to get back to you on the download time as my car/ecu is in the workshop at the moment. Delco wizzid might be able to time it at let you know? VL400 has suggested that I should add support for the 128 byte read command in the OSE binary, so I shall do that and faster initial download speeds should be obtainable where supported.

[VL400]

For me using the 808 comms board and a FTDI USB-Serial adapter it takes 60 seconds.

Using the FlashTool it also takes around 60 seconds to get a 32k bin using the normal 64byte read but using the 128byte read in OSE releases it cuts the time to 48 seconds. But its the write time thats the big improver going to 128byte packets, writing a 7kb calibration file takes 35 seconds using 8byte write and 10 seconds with the 128byte write.

[Jayme]

I did some more testing lastnight. it takes me 2m 6sec to download a 32k bin into antusprom. once I got tunerpro up and running, I did a diff against the original bin I had on file and it came back exactly the same, so looks like im not getting any corruption.
I thought id test to make sure realtime was still happening so I changed the idle rpm only to find the car didnt react. I thought "thats odd" so I closed and reopened tunerpro and sucked the file out of antusprom again only to find the change I made to the idle was still present. so I looked over at antusprom and the messages suggested it at least thought it was writing to the ram and it thought it was working, at this point I looked down at the board and realised I had write protect enabled on the board still LOL. needless to say it all worked once I turned wtire protect off.

antus was right, it was the max232 echo that I had turned off, once I turned it on efilive started working correctly, but it is also showign signs of being slow, in efilive I normally get 1093 frames per 2 mins, through antusprom I only get 621 frames per 2 mins, so things are definitely slower than usual. mind you I have only actually tried this newly assembled serial board though antusprom so ill try it direct tonight to rule out the new serial board. looks like ill be buying one of those FTDI cables now. then ill be able to use my new laptop with the bigger screen