forum.fenixecu.com

DSL pour le dérangement

DSL pour le dérangement

DSL pour le dérangement

Bonjour,

Je suis étonné que personne ne m’ait remonté ce type de dysfonctionnement auparavant. Cela fait quand même 5 ans que ces fichiers définitions sont disponibles et utilisé. Je ne rencontre moi même pas ce comportement, et crois moi j'ai utilisé et testé ces mêmes fichiers longtemps avant de les mettre en ligne et après évidement.
De plus les fichiers definitions pour Fenix 3 sont les mêmes que sur Fenix 1 et tu dis ne pas rencontrer le "bug" sur les Fenix 3...

Pour info, on ne fabrique pas les fichiers de la même façon :
On pourrait penser à un problème de vitesse de trame.

Sportivement,
Manu

Je vais vérifier le fonctionnement du fichier ADX et le corriger si nécessaire.

Sportivement,
Manu

DSL pour le dérangement

DSL pour le dérangement

DocBrown a écrit :La trame brute commence par FF 00, et suivent le numéro de programme, et les autres octets.
Rien de nouveau, c'est commun à tout les ECU fenix.
Si un octet de valeur dans la trame est à FF, il est doublé, on obtient FF FF.
La dll traite tout cela, pas de soucis.

Tout va bien si un couple d'octets FF FF, est réduit à FF et est suivi d'un octet de valeur non nulle (Ex: 01).

Par contre, si cet octet qui suit est de valeur nulle, soit 00.
On aura un soucis, car cet ensemble d'octets seront vu comme entête de trame, soit FF 00.

Vu qu'elle n'est pas programmée pour filtrer l'anomalie citée plus haut, on a un bug.

Je ne vais pas rentrer dans les détails de la DLL, mais cette affirmation est fausse. A aucun moment un FF FF 00 ne peut la bloquer ou la faire attendre. Crois moi.

Manu a écrit : Je ne vais pas rentrer dans les détails de la DLL, mais cette affirmation est fausse. A aucun moment un FF FF 00 ne peut la bloquer ou la faire attendre. Crois moi.

Attention , ceci pourrait être interprété par un 2nd bottage en touche

Ah non, le premier n'avait pas lieu d'être....

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 !