Also, made a quick homepage for anyone who is actually keeping up with this... I've always had it but was too lazy to finish but decided to whip one up again....

http://www.geocities.com/pasky13

I'll be posting updates on the board and on the site for now on. Its a bit graphic intense, so beware if your on dial-up.

 

Heyy Pasky I have a good connection now but none of the function tabs work and there is no a data to report.

 

What do you mean by good connection? Did you get the message, "Successfully recieved correct data from the ECM. Test Complete"? If so, then i'll use this method for the handshake and will implement the tabs immediatley for data translation, thanks for the tests.

 

Yes that is the message I am getting and no problem on the testing. I have 2-3 here at most times. Just let me know when you get the tabs going and I will follow with more testing.

 

Woo hoo! Awesome news, before I begin to work on it more, did you actually get anything in the recieved data box?

If so and if possible but it is not neccessary. Take a screen shot of the window after you get the message so I can see if the data looks correct.

You can do this by putting focus on the program (in other words having it be the active window by clicking on it) and holding ALT and press Print Screen on the keyboard.

Then open MS paint (Start --> Programs --> Accessories --> Paint)

and go to edit ---> Paste, Select yes to enlarge the bitmap image save it and send it my way at pasky1382@netscape.net

Really appreciate the help, if the data is correct the hard part is over and I can begin the translation process.

 

I will try it tonight.

 

Alrighty, thanks for all the help, im about to head off to work.

 

Well I cant seem to get a screen shot but here is what it says.

Sent Data
F0 56 01 B9

Received Data
F0 55 BB
F0 56 1 B9 F0 95 1 19 F1 0 80 60 C

Here is the thing though. It will never connect on the first try nor will it give the same received data twice.

 

That would seem correct, the reason it may connect the second time is the handshake waits until the ECM throws a chatter packet (F0 55 BB.

Which it does when it communicates with something at the baud rate of 8192), once it recieves it, it immediately throws a request packet (F0 56 01 B9) to the ECM.

Then the ECM throws its data back. THe first 4 bytes in the received data box are the echo of the send request (F0 56 01 B9 ) and the next three bytes is the header for the data packet the ecm sent (F0 95 01).

The data will always change beyond F0 95 01, so all this is normal and tells me a handshake is taking place. Sorry it takes two times to connect, im not sure how often the ecm spits out a chatter packet, so its a hit or miss thing but the chance of missing isn't high.

Hope that explains it and thanks much for the info, now I can continue with the next part.

 

New version up at http://www.geocities.com/pasky13, it may be buggy so don't get discouraged if it doesn't work I took about 2 hours to fiddle with it and wrote a routine to get packets and display the rpm of the vehicle. If it doesn't work, please let me know what happened to the best of your knowledge

You won't get a pop up message if you got a good data packet, but the status bar at the bottom left will change to "connected" The text box next to the connect button is temporary and will be used to display the rpm of the vehicle.

Basically this is a test for me on translating the data to see if its being done correctly, let me know how it goes. Remember it might be buggy as im tired and have to hit the hay, I will overlook it some more tomorrow but the input will be greatly appreciated, thanks.

 

Sorry man no response and it gives a bad reply. The reply is totally off. I got BB most of the time and that was it.

 

Alrighty, thanks again, I havn't had time to overlook it, im working from 6-11 tonight and probably really won't get out until 1:00am =/ but i'll see if I can find some time to overlook it, I think I know whats going wrong.

 

Uploaded a new one at the website, im gonna start putting version numbers on these to make it a bit easier next time im in a hurry at the moment but I made a quick overview, took out a lot of the meat to save it for the last part so this one should display the rpm correctly, give it a shot and tell me how it goes, thanks.

 

Sorry man no luck again. The Closest it gets now is a "Runtime error 13-Type Mismatch". The received data is F0 55 BB F0 56 1 B9 F0 95 1 19 F1 0 80 60 0 8 when it does receive anything. Good luck.

 

Ahhh crap, ok its trying to use a wrong variable, thats good that it is getting data though, that means most of it is working.

 

Fixed it, download the new one and give that a shot, just gave it a ver number also to make it easier on ya.

 

Ok took a few hours today and implemented a few new things, tabs are now all working however only settings and Sensor data have anything in them at the moment.

I fixed the problem, I was trying to throw a string data into a integer array without using ASC() first, that should get rid of the type mis-match.

The other good news is I got more sensor data translated, RPM, Coolant temperature, Coolant Temperature (startup), TPS voltage, IAC Steps, Battery voltage, I was going to do them all but will wait ti'll I find out if it works correctly, im pretty sure this is going to be "the one" that will work.

 

OK we have no errors this time but a different problem all together. The received data is a mile long and the readings that i get from the sensor data is incorrect and not active. The readings are static and dont change at all. After a few minutes it gave me a runtime error 5 also.

 

Ok what time did you try it? I fixed a few things about 2 minutes ago. Also what were the static values?

EDIT:

Just found out why the recieved data got extremely large, sorry I didn't notice this and you have to be a ginea pig but it I had it truncating on itself, I wasn't clearing it after getting a new packet. But that does tell me one thing, your getting more than one data packet which is definatley good, so basically it was doing this:

Lets say data was (12345)

it would take '1' * 26 for one sensor data

getting 26

and the buffer was just adding to itself

(12345)(54321)(98765)(12358)
So it stayed static because of that, it just kept seeing the '1' that was already there since it goes by position.

I think the error was caused because the text length got too long for the item data box, so it overflowed the buffer.

Either way it was fixed now and thanks so much for doing the testing, this one should do the trick.

 

Used an API to add a scroll bar to the received list box so you can see all the data.

 

My pleasure on being the guinea pig. I have a couple customers that really need this stuff. I will try it again when I get home.

 

just kinda curious....why do your customers need this stuff? do we have some more v6 hotrods out there?

 

No luck man. Will not even connect this time. Received data is too short most of the time and either times out or gives me the same error again. And yes we are working on a turbo application and a BIG n2o application. These guys need something cost effective to scan their cars. A snap on or matco scanner just wont be in their budget. Good luck Pasky.

 

tell us a little about our v6 buddies. or tell them to get on this board and share what they've got.

pasky, when i "received" data, i get "AD DD FF 55 BB" continuously. i tried swapping the connection pins around on my cable and that was the best i got. with one of the other pins hooked up, i got the "connection timed out" error. also, does this not work on windows XP? i tried it on my brother's laptop but couldn't get the program to even open. keep up the great work though! we appreciate your work.

 

Both are going to have sheet metal intakes that we have designed for higher rpm/power range. Both will also have 3000 stall converters, ported heads and custom camshafts. Both will be using stock rotating assemblies until something goes boom. Thanks for all the effort Pasky.

 

what's goin on with the aldl program? no updates for a while!

 

Sorry been quite busy working at least 55+ hours weekly. I have not forgotten about the project and I do have my car running so I can do my own testing in the garage to get things faster, I just need to find time. Sorry for not keeping you posted.

 

that's alright, i was just wonderin where you had gone.

 

I don't have a V6, but if you need help with debugging the code itself shoot me a PM. Done enough VB programming (starting with V3) in my time to at least be able to help that much, if you have patience. For your post, I work about as much as you, with irregular hours (gotta love NYCT), so if you get something you can't figure out and can wait, I'll take a look.

Also, if you're interested, I'm working on a PocketPC ALDL program (Using VB.Net). If we can get together on a common log file format, we can come up with something like VEMaster that can use input from either of our apps... or at least a CSV file exporter that works with both. One less format floating around that's only used by one application.

 

Cool idea! I thought about that a while ago, but buying a serial port CF card is just too damn much money. I should see if they dropped in price (cheapest I could find back then was $150).

I wonder... if something could be rigged up with bluetooth? A wireless proximity connection to the ALDL... could leave it plugged into the ALDL 24-7-365! I mean, they've got those bluetooth wireless headsets for cell phones, and I doubt a headset is all that complicated. In fact... if the headset's digital... could always hook the mic up to the ALDL's serial line thru an opto-coupler! Hm. I might have to start looking at some specs...

Count me in, too, if you guys need help programming. I'm doing all my new stuff in .NET now (although i haven't touched my Dell Axim X5 yet), but I can still swing VB6 no problem.

Actually... I just realized (thru a search, since this post is over a year old!!) that Pasky swapped an LT1 into his V6 car. I doubt he's still working on a V6 computer hookup

 

Oh, damnnn... check this out: http://www.circuitcellar.com/PSOC2002/winners/h9.htm That PSoC chip is slick... damned if I know how to program it (or what to program it with), though. The chip only sells for about $10 from what I could find. And looks like the PSoC Designer is the programming tool, free from http://www.cypress.com ...

So I guess this would be really hot, but it'd need a lot more time than I could give it!

 

i think pasky is still working on this a little in his spare time. i could be wrong though.

however, tuner pro r/t now has a datalogging file for the SD V6 guys!! not trying to say anything about anyone else's attempts at making this type program, just throwing this out incase pasky's program is not being worked on anymore.

 

I recently saw one for $65. If I can't get the cable to work, I may try that. However $65 + the cable I already have is kind of expensive.

Ok, I don't know if Sony-Ericsson or Jabra just screwed up or whatever, but every time my earpiece leaves the Bluetooth range, a partnership has to be re-established with the device. I don't know fi this is typical and the phone is the only Bluetooth device I have.

I'm working with an X5. I'm actually hacking a serial cable until I can get it to work, I know it can be done, I just have to do it (and need the patience).

That'll teach me not to look at dates!

http://pocketdl.goumba.net/

 

Pasky is still working on it, and is using VB.NET now.

See this thread:
https://www.thirdgen.org/techbb2/sho...hreadid=264438

 

Thanx LinuxGuy, that's the thread I was looking for in the first place, I thought there was one more recent. When I couldn't find it, I just put it here.