ALDLdroid

[3400tZ]

PROGESS!!

Finally got the 1227747 working on the bench (Thanks to Chris for helping me figure out a little wiring issue I had with the harness adapter)!

I took this picture, and I feel like such a geek :) On this pic (from left to right):

- MegaSquirt 1 CPU
- MegaSquirt 2 CPU
- ELM327 ODB2 to Bluetooth adapter
- Bluetooth to RS232 configured at 9600bps (MS1)
- Bluetooth to RS232 configured at 115200bps (MS2, MS3)
- WiFi to RS232 (this might be useful for ALDLdroid as well as some Android head units seems to support nothing else then WiFi, but it's a pain in the ass to configure, slower data rate and more expensive (around 100$ for the adapter) so its a last resort option)
- MegaSquirt 1 v3.0 (I just install my MS2 CPU to make it an MS2 for testing)
- MegaSquirt 3 v3.57 with MS3X board and RTC module (same thing as I have in my car, backup ECU, currently used for testing as well.)
- MegaStim on the MS3
- TinyIOx (CAN board for MS2-MS3)
- The 1227747 ECM with adapter harness and the JimStim
- ALDL to USB connected to the harness
- The 1227730 ECM with adapter harness
- ALDL to Bluetooth adapter on top of the 1227730

And yes I'm using weather pack connector as a quick connect/disconnect for the ALDL connector (as I only have one). I used weather pack as this is all I had laying around, also I bought that kit that I never used (about 150$ kit with 200$ worth of crimping tools :O)

Tomorrow I will try to test ALDLdroid with the 160baud ECM :)

[mikew]

Man you've got it bad, that's a lot of stuff..... we might need to find you a 12-step program!!!!

Until then, keep up the good work!

[buddrow]

Looks like I'll have to aquire an Android device since my iphone will be useless lol keep up te good work!

[GaryDoug]

I took this picture, and I feel like such a geek :)

If you are a geek, I afraid to ask about me ;-) This are my setups for developing "Scan9495".

http://i1105.photobucket.com/albums/...psf1798d34.jpg

http://i1105.photobucket.com/albums/...ps48ca38d9.jpg

[3400tZ]

Nice setup Gary :) Maybe I could add support for those ECM at some point :)

So tonight I tried ALDLdroid with that 160 baud ECM and as expected, it didn't work. I spent like 2 hours fixing a millions thing, I feel like I'm getting somewhere but now I'm a bit stuck.

What I'm getting from the ECM is non sense:
fe 00 fe fe fe fe fe fe fe fe 00 00 00 00 fe fe fe fe 00 fe
fe fe fe fe fe fe 00 00 00 fe 00 fe fe 00 fe 00 fe fe fe fe
fe fe fe fe fe fe fe fe fe fe 00 00 00 00 00 00 00 00 00 00
fe fe fe fe fe fe fe fe fe fe fe fe fe 00 00 fe fe fe fe 00
fe fe 00 fe fe 00 00 fe 00 fe fe 00 fe fe fe 00 fe 00 00 fe
00 00 00 00 fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe

This is an example of 6 reads for 20 bytes of data (that should be the pay load size for $42). For some reason, I'm only getting "00" and "FE", nothing else. They are always in different order and there is never anything else. Does I'm missing something ? This ECM is unidirectional AFAIK so I cannot send it anything to tell it to send me something else then this horse s**t :D On both Bluetooth and USB, it's the same thing.

I'm never sending it anything, just reading the RX buffer and seeing that. Anyone ever wrote a 160 baud ALDL software that worked ? :) Or anyone familiar with the 160 baud ECM to help me with this ? :)

Thanks!

[antus]

Theres some 160 baud info here. I believe from memory that he reads the port at a higher speed and treats a frame error as 0 and no error as 1 or vice versa to work around not having an interface that will do 160 baud. If the ftdi can run that slow, maybe this approach is no longer needed.

http://www.techedge.com.au/vehicle/aldl160/aldl160b.htm

[3400tZ]

Well, I'm using 4800 baud right now because its what the ADX file is defining. Maybe I should try 160 baud and see what happen...

I will read that page as well.

[mikew]

First off.... have you tested the ECU with a known working 160 baud software package and a "real" PC serial port to verify that some jack-wagon didn't send you a busted ECU (that works as far as he remembers but hasn't been used in years)?

If it passes that test, will it work with the same software and your USB to serial cable?

It's been a long time but I recall that the 160 baud software had some timing parameters that had to be tweaked to get it to work reliably and the serial port isn't actually set to 160 baud, it was something like 1600. I don't believe the 160 stream is a true serial protocol, it's just 160 bits per second.

[RobertISaar]

open as .txt, but this outlines every comm protocal that GM used for OBD1 applications.

[GaryDoug]

I have never worked with 160 "baud" but from reading the material at the link on the prior page, it seems obvious that 1) the bits are sent in the opposite order from the 8192 system (msb first, instead of lsb first), 2) each bit has its own start and stop bit, and 3) the baud rate might be simulated by using a higher rate (1600) and testing each bit as a full 8-bit byte received. Note the reference to the result of "FE" just like your results. See the section titled: RS232 1600 baud Serial and ALDL 160 baud data.
Are you using 1600 baud?

[EagleMark]

If you are a geek, I afraid to ask about me ;-) This are my setups for developing "Scan9495".

http://i1105.photobucket.com/albums/...psf1798d34.jpg

http://i1105.photobucket.com/albums/...ps48ca38d9.jpg

Nice work Gary!

If you'd like to make a post somewhere here announcing the software I' will copy it to out LT1 Info thread so everyone can find it in future!

[mikew]

I've been thinking about 160 baud.....

I assume that the bluetooth ALDL adapter you have is the one from Red Devil River and it says it supports 160 baud, so should work with your Android software as-is.

In order for theRed Devil River adapter to transmit the 160 baud data stream via bluetooth, the adapter has to convert the non-standard 160 baud stream to a standard UART style stream at whatever baud rate the bluetooth transmitter is running at.

So, if all the above is true, you only have an issue with your serial to USB adapter. The folks at Red Devil River have already figured out how to do this conversion inside their adapter (it has to have some sort of micro-controler inside it), maybe they can give you some insight as to what is needed to read the 160 baud data stream directly. I think you're gonna have to write your own library.

[3400tZ]

Mike, I did test the ECM with TunerPro, it works great. Looks like that jack-wagon sent me a good one :P

Robert, this is VERY useful! The annoying part is that java byte are obviously 8 bits. The FTDI drivers for USB only allow me to read a byte array. So, I'm thinking of doing something like this:

- Convert the byte array to binary
- Find the sync element
- Read all bits in chunk of 9 bits after the sync element
- Make sure the first bit of each chunk of 9 bits is 0.
- Extract the 8 bits (starting from second bits of each chunk) and build a new data array with all those 8 bits byte.
- Then I got my data array that I can forward to the other stuff just like I'm doing with the 8192 baud ECM

Gary, I'm curious where do you see the reference to FE ? I don't see it... I'm using 4800 baud, which is what is defined in the ADX. I think its fine... maybe ?!

Mike, yes, it's in the Red Devil River's instructions that 160 baud is supported. Currently I just need to move a jumper to make it work. I'm pretty sure I'm going to have to write my own thing, this app is over 10k lines of code of my own thing really :) I will start with what I mentioned above and I will email Timm (Red Devil River) if I'm really stuck. Timm really seems to be a nice guy from what I've seen so far but I don't want to be too annoying just yet. I will try a few things on my side.

You guys are awesome, we will figure this out :)

[3400tZ]

Hummm but thinking about this, I'm only getting "FE" or "0" back. 0 is obviously 00000000 and FE is 11111110 so with this in mind, it mean I'm somehow never getting the sync character (9 consecutive "1").

I'm stuck :/

[GaryDoug]

Gary, I'm curious where do you see the reference to FE ? I don't see it... I'm using 4800 baud, which is what is defined in the ADX. I think its fine... maybe ?!

Sorry, that was found in a link within the posted link document: Further, and more recently written, 160 baud information can be be found here.

I wouldn't assume that the interface adapter does anything fancy with any decoding. It's probably just a Serial-to-Bluetooth type. I would be very surprised to find anything more sophisticated inside, like anything along the line of an ELM327 (OBD2 multi-protocol decoder) or something.