Sorry for long post, but necessary to explain. Have been working on this for some time now and believe there is a bug in the Mode 3 logic if, in a Mode 3 ADX, a request is made for more than one, 2-byte variable in the 0x3000-0x6fff range. Here's why.
Have a simple Mode 3 ADX that requests only 2 items: Spark-TDC (0x3128/29) and Spark-REF(0x30BD/BE). Weirdly, only the first item in the xmit string is reported back correctly. The second is not converted according to the conversion formula but is reported raw. Swap the items in the xmit string, reorder their offsets and same thing. This would be easier to understand if I could send ADX files and logs to an email address.
Example:
Send Request for Spark-TDC(0x3128/29) and Spark-REF(0x30BD/BE)
0xF4 0x5E 0x03 0x31 0x28 0x31 0x29 0x30 0xBD 0x30 0xBE 0x1D
Reply:
timeout: 400
payload offset: 3
payload size: 4
body size: 7 (Also used 8, no difference)
Results:
looking at one sample
Code: Select all
Spark- TDC (1st item) Spark-REF (2nd item)
Returned 22.15 5670.01
Conversion divide by 0.351563 divide by 0.351563
Result Dec 63.00 16128.00
Result Hex 3F 3F00
And thus the MSB of the 2nd item Spark-REF (3F) is same as the LSB of 1st item Spark-TDC (3F). Every sample this way.
Additionally, if insert a 1-byte value between the 2 Sparks (eg RPM) the 2nd spark is reported incorrectly as above.
I'm fixated on this because I need to have both Sparks in the same Mode 3 ADX., but as long as both are in there, regardless of what else is in the xmit string, the 2nd transmitted spark reports errantly as above.
again, it appears the problem lies in having more than one 16 bit item in the transmit string.
=====================================================
EDIT -- And the conversion is the same for both Sparks in the ADX: X * 0.351563
=====================================================
Help please & thanks in advance!