ALDLDroid Android App

[Jayme]

ok so I started with 11P v104. no go... it doesnt seem to ID properly.

Code: Select all

[INFO] (Real time tuning Moates) 05/01/16 10:46:52.574 Got response from real time tuning hardware: 
[INFO] (Real time tuning Moates) 05/01/16 10:46:52.576 
[INFO] (Real time tuning NVRAM) 05/01/16 10:46:52.584 Reading signature for MPR_IGNITION_MODULE_SIGNATURE
[INFO] (Real time tuning NVRAM) 05/01/16 10:46:52.587 Reading ECU memory at offset 65408 with a length of 16
[INFO] (Real time tuning NVRAM) 05/01/16 10:46:52.594 Writing command to ALDL: e3 58 02 ff 80 44                                                                                                       .X...D

[DEBUG] (ECU) 05/01/16 10:46:52.635 Got response from ECU: F4 57 01 00 B4 F4 8E 01 00 00 00 00 FF 00 FF 06 01 00 F3 02 D0 00 66 00 08 00 00 80 80 14 86 00 76 00 80 02 00 00 96 00 00 00 64 DF 00 6F 00 00 C0 00 00 00 20 40 02 00 20 00 00 FF 00 01 78 00 B1 (�W������f���v��d�o� @ �x�)
[DEBUG] (ECU) 05/01/16 10:46:52.637 Data is at offset 8 and 57 bytes long
[DEBUG] (ECU) 05/01/16 10:46:52.644 Sending command "Tx Mode1 Message0" (F4 57 01 00 B4) and now listening for packet (65 bytes)
[INFO] (Real time tuning NVRAM) 05/01/16 10:46:52.679 Got ECU response: e3 58 02 ff 80 44                                                                                                       .X...D

[ERROR] (Real time tuning NVRAM) 05/01/16 10:46:52.682 Got no response
[INFO] (Real time tuning NVRAM) 05/01/16 10:46:52.687 Writing command to ALDL: e3 58 02 ff 80 44                                                                                                       .X...D

[INFO] (Real time tuning NVRAM) 05/01/16 10:46:52.709 Got ECU response: e3 58 02 ff 80 44                                                                                                       .X...D

[ERROR] (Real time tuning NVRAM) 05/01/16 10:46:52.711 Got no response
[INFO] (Real time tuning NVRAM) 05/01/16 10:46:52.715 Writing command to ALDL: e3 58 02 ff 80 44                                                                                                       .X...D

[INFO] (Real time tuning NVRAM) 05/01/16 10:46:52.739 Got ECU response: e3 58 02 ff 80 44                                                                                                       .X...D

[ERROR] (Real time tuning NVRAM) 05/01/16 10:46:52.741 Got no response
[ERROR] (Real time tuning NVRAM) 05/01/16 10:46:52.742 Maximum number of try reached to read ECU memory
[INFO] (Real time tuning NVRAM) 05/01/16 10:46:52.744 Reading signature for OSE_SIGNATURE
[INFO] (Real time tuning NVRAM) 05/01/16 10:46:52.746 Reading ECU memory at offset 65408 with a length of 16
[INFO] (Real time tuning NVRAM) 05/01/16 10:46:52.752 Writing command to ALDL: f4 58 0d ff 80 28                                                                                                       .X...(

[INFO] (Real time tuning NVRAM) 05/01/16 10:46:52.770 Got ECU response: f4 58 0d ff 80 28                                                                                                       .X...(

[ERROR] (Real time tuning NVRAM) 05/01/16 10:46:52.771 Got no response
[INFO] (Real time tuning NVRAM) 05/01/16 10:46:52.774 Writing command to ALDL: f4 58 0d ff 80 28                                                                                                       .X...(

[INFO] (Real time tuning NVRAM) 05/01/16 10:46:52.789 Got ECU response: 0d 4f 53 45 31 31 50 72 6f 20 50 50 0d                                                                                  .OSE11Pro PP.

[ERROR] (Real time tuning NVRAM) 05/01/16 10:46:52.793 Got invalid response length, expected -3 but got 13. Response was 0d 4f 53 45 31 31 50 72 6f 20 50 50 0d                                                                                  .OSE11Pro PP.

[INFO] (Real time tuning NVRAM) 05/01/16 10:46:52.795 Writing command to ALDL: f4 58 0d ff 80 28                                                                                                       .X...(

[INFO] (Real time tuning NVRAM) 05/01/16 10:46:52.806 Got ECU response: 67 00 00 04 00 00 00 00 00 00 00 00 00 00                                                                               g.............

[ERROR] (Real time tuning NVRAM) 05/01/16 10:46:52.811 Got invalid response length, expected -82 but got 14. Response was 67 00 00 04 00 00 00 00 00 00 00 00 00 00                                                                               g.............

[ERROR] (Real time tuning NVRAM) 05/01/16 10:46:52.813 Maximum number of try reached to read ECU memory
[INFO] (Real time tuning NVRAM) 05/01/16 10:46:52.814 Reading ECU memory at offset 32512 with a length of 32
[INFO] (Real time tuning NVRAM) 05/01/16 10:46:52.818 Writing command to ALDL: f5 58 02 7f 00 32                                                                                                       .X..2

[INFO] (Real time tuning NVRAM) 05/01/16 10:46:52.828 Got ECU response: 00 00 00 00 00 00 00                                                                                                    .......

[ERROR] (Real time tuning NVRAM) 05/01/16 10:46:52.832 Got invalid response length, expected -82 but got 7. Response was 00 00 00 00 00 00 00                                                                                                    .......

[INFO] (Real time tuning NVRAM) 05/01/16 10:46:52.834 Writing command to ALDL: f5 58 02 7f 00 32                                                                                                       .X..2

[INFO] (Real time tuning NVRAM) 05/01/16 10:46:52.948 Got ECU response: 40 98 57 21 7e d0 31 00 02 54 40 01 fc 00 12 ec 80 d8 00 90 00 90 00 90 00 90 00 90 00 90 00 90 00 90 00 90 00 1a ac 86 @.W!~.1..T@.............................
 21 86 21 86 21 86 21 8b aa a8 2a 97 1d 97 1a a7 13 b0 ad b2 7a 90 00 86 21 86 21 86 21 86 

so it seems to not catch the 11P ID properly and then moving on? also seeing some weird responses to F5 ID request? there is no F5 device on the bus. I also suspect the logging packets that are active when I try to start the tuning section are mixing in there somewhere.

also, id like to see it able to ID the nvram without an active ADX. it doesnt seem to send any packets at all out to try to ID if I dont have an active ADX logging at the time of going into the tuning section ?

ps. love the dropbox integration.

[Jayme]

quick addition to the above. I can see the problem now. the length of the response to f4 58 0d ff 80 28 is really, really really long for 11P.
you seem to pull a fixed length, then the rest of the data backs up in the memory and keeps coming in over the next couple of serial data reads. if you look carefully, you can see my packet I sniffed from the OSEplugin ID request that I have pasted below is spread over the next few data requests as the data is all backing up in the read buffer and it not actually a response to the requests that are sent.

Code: Select all

F4 D6 0D 4F 53 45 31 31 50 72 6F 20 50 72 6F 67 1 0 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 7E 56  7E 57 21 7E D0 31 0 2 7E D0 25 7E 56 6D 90 0 90 0 90 0 90 0 90 0 90 0 90 0 90 0 90 0 90 0 90 0 1A AC 86 21 86 21 86 21 86 21 8B AA A8 2A 97 1D 97 1A A7 13 B0 AD B2  0 86 21 86 21 86 21 86 2C 86 2E 86 30 86  86 32 B5

In windows, I latch onto the serial port data available event and it reads every packet available on the serial port rather than requesting a fixed number of bytes - to avoid extra unexpected data backing up in the read buffer and causing this issue. im not sure if you can do something like that in android?

[antus]

Hes going through the same search logic as oseplugin does (hes got access to and has based the logic on the source). So I think its looking for everything oseplugin does (including PCMs, VL400's ignition module etc) so after it fails to find it keeps trying and you see it looking for device F5 etc.

[j_ds_au]

Can new prolifics even do 8192 baud?

Yes, the newer types can, but you need to add a registry entry specifying the divisor for the MS-Windoze driver to work at such "odd" baud rates. Not sure what happens for Android.

Joe.

[3400tZ]

Jayme: I wonder what happened with the beginning of the ECU response for that 11P reply... The app uses the second byte of the response to calculate the expected response length but now it seems like it's missing something at the beginning of the response for some reason

[Jayme]

could be something to do with echo handling? my interface has echo and the one you used for testing does not (I think?)

Edit: just a theory but is it possible the echo eating code is eating a little bit more than just the echo?

[3400tZ]

I was thinking that too, I looked at the way echo is handled and it *should* be ok... The idea is just that if its there, it's getting removed and that's it. Also, the log of the ECU response is before any processing so I'm wondering why the echo wouldn't be there at all like it is in the preview response you got

[Jayme]

Its definitely got echo. Its a one wire aldl interface. Maybe android has some auto echo handling at driver level? If it helps i can send u my entire debuglog?

[3400tZ]

If you can take a similar comms debug log of TP and OSEplugin and 11P, that could help, hopefully we could figure it out with that.

[3400tZ]

Oh wait, I think I know what's going on. I'm looking for the second byte of the response for the expected response length, but all that is happening before stripping the echo off, that will screw things up for sure when there is echo as the second byte will be the second byte of the command, not of the response. I guess I will have to rework that part a little. That will be fun