ALDLDroid Android App

[3400tZ]

Cool, I will try with my OBD1 ECMs if I can reproduce using two listen packets (probably just copy paste it or something). I will let you know if that replicate the issue, I could figure out what the real issue is for sure that way.

Thanks for your time and patience!

[3400tZ]

Just pushed 0.63 to Play. It should show up for update in a few hours, give it a go and maybe it will work ? There was definitely an issue with multiple listen packets like you said, hopefully it's the last issue...

[Jayme]

hasnt appeared yet.... time to start fiddling with my F5 key

[Jayme]

ok so mixed results! it doesnt crash now so yaaaaaaaay !!!

only catch now is the xdl log wont open in tunerpro.... It opens but goes stupid and doesnt display properly. ive only logged on my bench computer but I should still see .440v on the o2 sensors.

ALDL_LS1_1_1_0.adx

(39.14 KiB) Downloaded 367 times

2015-01-21_16.48.51.csv

(11.31 KiB) Downloaded 338 times

2015-01-21_16.48.51.xdl

(3.05 KiB) Downloaded 346 times

[Jayme]

2015-01-21_16.48.51-tp5.xdl

(2.25 KiB) Downloaded 358 times

so here is a log taken by tunerpro using the same ADX. I have identified at least one issue in the way the relative offset to the next record is handled by aldldroid. I suspect this stems from multiple listen packets.

aldldroidlog.JPG (62.16 KiB) Viewed 6126 times

you can see in the above picture, the column the highlighted byte is in. this is supposed to be the relative offset to the next packet. in this log, instead the same offset is copied for 3 records (the number of listen packets) before moving to the next offset. in the below picture I have edited the hex to show how it should look.

aldldroid-fixed.JPG (57.87 KiB) Viewed 6126 times

[3400tZ]

Well, we're making progress for sure now! Good catch, that's indeed a problem. I've written the fix, I will include it in the next version. While we're on the XDL issue subject, I think it's possible there is another issue. The format for the header of each listen packet is:

- 4 bytes for next frame address
- 4 bytes for the timestamp
- 4 bytes for message ID

For the message ID, I've just hardcoded 0x00 0x00 0x01 0x00, it works fine with only one listen packet but I'm not sure about many. Do you happen to know where that message ID come from and what it should be ?

On another note, I got my NVRAM ECU from antus today so I guess I will be testing that in a near future (I hope!)

Thanks

[Jayme]

reading up on the docs I have from helping VL400 with the XDL format, I believe it is the array index of the description array from the header. so the first described packet DPID_FE_RX will be 00, second described packet DPID_FD_RX will be 01, Third described packet DPID_FC_RX will be 02. in the tunepro log, that byte is in sequence, 00, 01, 02, 00, 01, 02 etc.

[Jayme]

just checked up on it.... the tunepro headers go like this:

00 00 4F 00
01 00 4F 00
02 00 4F 00

yours go like this:
00 00 01 00

[3400tZ]

Ok so possibly first two bytes is the index of the listen packet (0 based), what about that 4F 00, any idea ?

[Jayme]

no idea, but I have hand edited the aldldroid log with the fixed packet offset bytes and the 00 00 4F 00 message descriptors, and it opens and shows in tunerpro fine now

edit: so I looked up another multi message log from a completely different ADX. this one has this message format:
00 00 4E 00
01 00 4E 00

so it means something..... perhaps some relationship to the position of the listen packet array?