According to sources of the dll that was communicated to me by the author.
My work explained in a mail:
Hi,
I finally found a solution to the fenix case.
The header FF 00 followed by 33 04 (for ex.) which are program number and calibration number, does not make any issue.
But, a raw frame can include a suite of parameters as "FF FF 00", and that can make an issue.
Specially if that suite of parameters is emitted first in the buffer by the ECU, a thing which happens casually.
Your comment in the dll: We found "FF 00" indicating start of frame, and it wasn't the first two bytes (which may be wrong, as it could have been FF FF 00).
That´s it exactly !
Anyway, do not change the .dll code, it works well.
My solution is simple and I fixed the issue in my own ADX, I explain the maner:
A raw frame from Fenix 3 a or b, includes 36 octets (Offset 0 to 36).
The whole data stream can be 42 octets (less or more), depends on double octets FF FF (Barometric Pressure, RPM, Injection Time, iddle RCO, etc.).
Instead of calling a single Static packet Size in the Macro command, I call a first one to synchronise, then a second one to read data.
First Static packet Size with Body Size = 1, Payload Size = 1, Payload Offset = 0 (no header), Timeout = 400 ms.
Second Static packet Size with Body Size = 42, Payload Size = 42, Payload Offset = 0 (no header), Timeout = 0 ms.
This trick works !
L'expérience est plus riche de la compréhension des échecs que de la satisfaction des succès inexpliqués - EDISON