ALDLDroid Android App

[3400tZ]

Lot of smart people on this forum!

VK_3800, I'm trying to think how I can apply your idea without breaking XDL logging for everybody else now Right now, at the positions you modified, I have the packet size which is 57 from your ADX file in both positions. How I can calculate these positions dynamically from the ADX file so that it works for everyone ? I currently have packet size for both positions and I have a feeling it's wrong as I don't see why it would make sense to have twice the same thing... I'm not sure if I understand what 6 extra bytes you're talking about... I'm also trying to understand why only your ADX file is triggering this issue, that would probably be useful for the fix.

Hopefully we can get to the bottom of this and have a proper XDL logging for everyone

[antus]

Read it from the message description in the ADX, eg for reference the macro may say Mode1Message0 then Mode1Message0R, eg

Send:

Code: Select all

  <ADXCSENDCOMMAND id="Mode1Message0" idhash="0x55C678F5" title="Engine Data">
    <desc>Get Mode 1 Message 0 Frame</desc>
    <SNDCMDCHECKSUM type="2" />
    <bytestring size="0x4">F5570100</bytestring>
  </ADXCSENDCOMMAND>

Then receive:

Code: Select all

  <ADXCLISTENPACKET id="Mode1Message0R" idhash="0xB8CF04CA" title="Listen for Engine Data" flags="0x00000005">
    <listentimeout>400</listentimeout>
    <packetbodylength>67</packetbodylength>
    <packetoffsetinbody>0</packetoffsetinbody>
    <packetsize>66</packetsize>
    <headerstring size="3">F55701</headerstring>
  </ADXCLISTENPACKET>

So im not sure if its packet body length or packet size also if its hex or decimal but you might be able to reverse engineer it from the example above and the 12P adx file. My example is not 12P its a different file I had on hand.

[VK_3800]

I am using the standard OSE12P Petrol 1 bar ADX now, I just had to change the echo setting to make it work (duh, not so smart now am I). Can't imagine that has anything to do with it, or could it?

As far as I can see only the 57 bytes corresponds to actual data as per the ADX, so reading it from there won't give you the longer length. I was kinda hoping you would know what the extra 6 was? (I guess the fact you don't means it must be coming from the ECU). Might have to keep digging and see if something jumps out at me as to what this stuff is - as I mentioned, sometimes Tunerpro logs include it and sometimes they don't.

I also had success simply chopping off the 6 bytes and rewriting the addresses and total file size before I noticed the other lengths in the header. Maybe its OK to simply truncate the data to the length specified in the ADX?

[VK_3800]

Wait a minute... I might be sending you guys on a wild goose chase, sorry!

The Autoprom has three additional inputs, each with a 16 bit value:
http://www.gearhead-efi.com/Fuel-Inject ... n-TunerPro!

So what I need to do is try modifying the ADX to include this extra data (and the correct length). If this is the case then obviously Tunerpro handles the extra data automatically when logging, perhaps the difference between logs including and excluding the data is whether its in Autoprom or pass-through mode...?

Will report back.

[Jayme]

depends how tunerpro vs aldldroid was coded. tunerpro is better at handling extra bytes that arent in the message length definition when logging. you may find that you need to open the adx editor, and click on "Rx Mode1 Message0". increase body size from 60 to 66 and increase payload size from 57 to 63. then save and load the adx into aldldroid and see if it fixed it.

[VK_3800]

^ Seems to be exactly it. Just tried increasing the message size (which changes the numbers shown by antus above) to 66 total/63 payload, ALDLDroid doesn't like it and just gives me a checksum error when I try to connect now. Doesn't seem to be any checksum defined in the ADX? Will try with Tunerpro later, out of time for now.

I'm also not sure in the link above that the message size was altered at all, seems like they just added the extra values and relied on Tunerpro logging to include the extra data?

[Jayme]

from memory, the last byte of an aldl packet is the checksum, but tacking on those extra 6 bytes means the last packet is no longer a checksum (and also no longer correct) and hence you get an error. when I was logging vpw with my avt 852 cable on aldldroid I had the same thing... have to disable checksum checking in aldldroid as the vpw packets dont have the aldl checksum in the last byte either.

one theory that explains it is that aldldroid throws all the incoming packet into the xdl, but then drops in the packet size directly from the ADX into the header. so it wont play when you have those 6 extra bytes in each frame. tunerpro must do something else like calculating the actual packet size and using that in the header, or stripping off the extra data from the frames before it even logs them...

[VK_3800]

That makes sense. Disabled checksum in ALDLDroid, attached is a short log. I see it has the 63 byte length in the header, but the first additional byte (0x41 from the first Autoprom input) is repeated 7 times (6 copies too many), maybe some sort of padding to length gone wrong?

Sounds like the most foolproof mechanism would be if ALDLDroid could calculate the actual size of the first packet and use that in the header, then the checksum could remain since everything else about the log with the standard ADX is just fine. At present it wouldn't bother me personally if the extra data was stripped (truncate message to size in ADX) but seems like it would be nice to support the additional Autoprom inputs especially since it supports it for emulation etc.

ALDLDroid doesn't seem to connect with the Autoprom in pass-through mode so can't compare that, I don't really want to use it that way anyway as I lose all the other features which ALDLDroid does an excellent job with!

[Jayme]

try grabbing a serial port monitor (I normally use accessport.) and grab a log of your serial port then log some data with tunerpro. that will give a big hint about what is really happening with the message length and what the correct settings should be.

[3400tZ]

HA! You're using the AutoProm! Yeah, actually you guys are right on the money. Those 6 bytes are the 3 extra input channels with 2 bytes each of the AutoProm. Those get written into the XDL file on each read but aren't taken into consideration in the row size in the header of the log file. Now it all makes sense, that would explain why you were the only one seeing this. Most people are using an ALDL cable, I know I did all my testing using that. I never realized the AutoProm could make a difference.

I'm thinking what I can do is just to add 6 bytes to the packet size in the header of the log if the connection is made through an AutoProm... Does anybody sees an issue with this ? I would change:

buffer.putInt(listenPacket.getPacketSize());
buffer.putInt(listenPacket.getPacketSize());

to this:

int dataLength = listenPacket.getPacketSize();
if (ecuConnection.isAutoProm()) {
dataLength += 6; // AutoProm has 3 channels of 2 bytes appended to the ECU data stream that need to be taken into consideration here
}
buffer.putInt(dataLength);
buffer.putInt(dataLength);

AutoProm in passthrough should definitely work, it's the same as a regular ALDL cable for the app, it's not even possible for the app to know if it's an AutoProm or just an ALDL cable using that mode.