Support officiel Megasquirt, Tech Edge WBO2, Tuner Pro, AutoSport Labs et Fenixecu 

  • DSL pour le dérangement ;)

  • Des questions sur la création de fichier définition ou bien des problèmes pour les utiliser, c'est ici
Des questions sur la création de fichier définition ou bien des problèmes pour les utiliser, c'est ici
 #3501  par DocBrown
 03 févr. 2015 21:15
DSL pour le dérangement ;)
Modifié en dernier par DocBrown le 04 avr. 2015 12:18, modifié 3 fois.
 #3505  par DocBrown
 05 févr. 2015 11:32
DSL pour le dérangement ;)
Modifié en dernier par DocBrown le 04 avr. 2015 12:17, modifié 1 fois.
 #3506  par DocBrown
 05 févr. 2015 18:09
DSL pour le dérangement ;)
Modifié en dernier par DocBrown le 04 avr. 2015 12:17, modifié 1 fois.
 #3507  par Manu
 05 févr. 2015 19:36
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 :
Image
On pourrait penser à un problème de vitesse de trame.

Sportivement,
Manu
 #3514  par Manu
 06 févr. 2015 21:47
Je vais vérifier le fonctionnement du fichier ADX et le corriger si nécessaire.

Sportivement,
Manu
 #3515  par DocBrown
 06 févr. 2015 22:46
DSL pour le dérangement ;)
Modifié en dernier par DocBrown le 04 avr. 2015 12:16, modifié 1 fois.
 #3543  par DocBrown
 13 févr. 2015 15:25
DSL pour le dérangement ;)
Modifié en dernier par DocBrown le 04 avr. 2015 12:16, modifié 1 fois.
 #3545  par Manu
 14 févr. 2015 15:17
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.
 #3547  par Sylvain_L
 15 févr. 2015 11:45
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 :roll:

Ah non, le premier n'avait pas lieu d'être.... :mrgreen:
 #5344  par DocBrown
 07 mai 2016 00:05
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 !