Storm td5: pour nous les zommes
Modérateur : phil13
- beurk
- Quatre-Quatreux
- Messages : 17004
- Date d’inscription : octobre 2007
- Contact :
- Statut : Hors ligne
thunder td5: pour nous les zommes
Outre les possibilités de remap offertes par les ECU "NNN" de 2002 à 2006, il y a une possibilité de dialoguer avec ces derniers puisque le Nanocom le fait.
Donc j'attaque ce fils pour vous faire partager mon expérience et vous proposer à terme un circuit et un soft à monter soit-même et en open source (sous licence GPL) pour faire des enregistrements des données directement depuis ce boitier, avec répétiteur sur une tablette Android, mesures d’accélération et géolocalisation.
En ce qui me concerne, les données d'accélération sont utiles pour la détermination de la puissance (roaddyno), la géolocalisation pour enregistrer l'ensemble du parcours - pour enregistrer une balade par exemple.
Ce travail de rétro-ingénierie est bordé par notre code de la propriété intellectuelle dont l'article L. 331-5 (et ses successeurs):
Les mesures techniques ne doivent pas avoir pour effet d'empêcher la mise en œuvre effective de l'interopérabilité, dans le respect du droit d'auteur. Les fournisseurs de mesures techniques donnent l'accès aux informations essentielles à l'interopérabilité dans les conditions définies aux articles L. 331-6 et L. 331-7.
- beurk
- Quatre-Quatreux
- Messages : 17004
- Date d’inscription : octobre 2007
- Contact :
- Statut : Hors ligne
La communication avec storm
Ce que la norme fourni La documentation LR (manuel d'atelier) Land Rover précise que la prise OBD est conforme au standard SAE J1962.
Donc la communication avec l'ECU passe par 2 bornes:
- 7 -> K line of ISO 9141-2 et ISO 14230-4 (vers ECU moteur)
- 8 -> à la discrétion du fabriquant (vers BCU alarme)
ISO 9141-2 & ISO 14230-4 sont des normes de communication numérique avec des ECU moteurs - dont acte
Sans trop rentré dans le détail tout de suite, ISO 14230-4 / KWP2000 fonctionne de cette façon:
- tension du signal 12V/14V bit0=+/-0 | bit1=+/-12V
- liaison série asynchrone (URAT) sur 1 ou 2 fils (pin7= K; pin15=L avec 2 possibilités: soit signal symétrique sur K et L; dans ce cas la communication est bi-directionnelle sur les 2 pins, soit K est utilisé en Tx et L en Rx)
*format 8bits *Une trame UART est constituée de la façon suivante :
*>un bit de start toujours à 0 : servant à la synchronisation du récepteur
*>les données : la taille peut varier (généralement entre 5 et 9 bits)
*>éventuellement un bit de parité paire ou impaire
*>un bit de stop toujours à 1 (la durée peut varier entre 1, 1,5 et 2 temps bit)
*Le niveau logique de repos est le 1.
- 2 ou plusieurs appareils communiques; le tester est le premier à "parler"; l'ECU, les ECU répondent.
- 3 modes d'initialisation de la communication:
ISO 9141-2 init: envoi du bytes (0x33) à 5 bauds, puis transmission à fréquence fixe
ISO 14230-4 slow init: 19 bytes différents peuvent être utilisé en fonction du service demandé, avec un envoi simple (1 byte) ou groupé (2 bytes) à 5 bauds - un peut comme ISO 9141-2 init
ISO 14230-4 fast init: la communication commence par un créneau de 2x 25ms , puis initialisation de la communication par envoi des bytes à 10.4kb. Le premier byte : 0x..1 (0xC1 chez Vw, 0x81 chez volvo,....)
Quelques spécifications sur la communication typé UART (Universal Asynchronous Receiver Transmitter):
Principe échanges entre Tester et ECU:
Principes de timing pour détection d'erreur:
Format des données REQ et REP:
- beurk
- Quatre-Quatreux
- Messages : 17004
- Date d’inscription : octobre 2007
- Contact :
- Statut : Hors ligne
Sniffer les échanges sur le K-line 1/3
Pour 12€ j'ai acheté ça:
- un cable Y femelle/femelle/male pour capter les échanges entre le Nano et l'ECU - au bout d'une des prises femelle, un clone d'un tester logic Saleae avec prise du signal dans un pont de résistances 7K afin d'abaisser la tension (/2) et de ne pas charger les ports (Tester et ECU). Le clone peut sampler jusqu'à 24Mhz sur 8 canaux différents simultanément. - pour in-fine pouvoir capter les signaux et les interpréter avec le logiciel Saleae: https://www.saleae.com/downloads L'interface du logiciel avec un capture de signal.
- beurk
- Quatre-Quatreux
- Messages : 17004
- Date d’inscription : octobre 2007
- Contact :
- Statut : Hors ligne
Sniffer les échanges sur le K-line 2/3
Pour rappel, le nano peut faire les choses suivantes:
- mode instrument pour le suivi des capteurs en temps réel
- mode diagnostique des différents capteurs et configuration ECU
- mode diagnostique des différents périphériques (Alarme, abs, .....)
- mode reprogrammation ECU
Nano en mode instrument Au cours des mois précédents, j'ai fait beaucoup de logg avec le nano pour savoir que la période d'enregistrement des datas fuelling est de l'ordre de 932ms
Le logic logger saleae est configuré à 12Mhz pour avoir le plus de précision possible sur une durée de 10s
Dans un premier temps pour valider le principe, j'ai tout scotcher sur une plaque de bois pour éviter faux contacts et cours juxxx....pas de photo
Que ce soit à l'arrêt, en roulant, moteur arrêté ou tournant, le principe est le même:
- brancher le nano, puis sur le portable lancer l'enregistrement.
La bidouille commence a être intéressante, les premiers créneaux apparaissent...
Et voilà ce que j’obtiens après une quinzaine de tests concluants:
Wakeup pattern [table="width: 500, class: grid, align: left"]
[tr]
[td][/td]
[td]1[/td]
[td]0[/td]
[td]1 avant Tester frame[/td]
[/tr]
[tr]
[td]ISO 14230[/td]
[td]>300ms [/td]
[td]25 +/-1[/td]
[td]25 +/-1 total 50ms[/td]
[/tr]
[tr]
[td]mesures[/td]
[td]>300ms[/td]
[td]26.55ms[/td]
[td]118.9ms total 145.5ms[/td]
[/tr]
[/table]
Chaine 1er et 2eme échange.... 1er échange 2eme échange et ainsi de suite.....
Les bits sont convertis en bytes (hexadécimal au dessus en bleu)
A partir des enregistrements, le logiciel Saleae étant assez intuitif, il est possible de mesurer n’importes quelle durée comprise entre 2 marqueurs repositionnables (comparaison base ISO 14230-4:
[table="width: 800, class: grid, align: left"]
[tr]
[td][/td]
[td]ISO 14230-4[/td]
[td]Mesures[/td]
[/tr]
[tr]
[td]Fréquence transmission[/td]
[td]10400 bauds +/-5% min 9880 baud; max 10920 baud[/td]
[td]Tester (p=94.08µs) F= 10629 bauds / ECU (p=98.83µs) F=10118 bauds [/td]
[/tr]
[tr]
[td]P1 normal[/td]
[td]0<P1<20ms[/td]
[td]+/- 71µs[/td]
[/tr]
[tr]
[td]P2 normal[/td]
[td]25ms<P2<50ms[/td]
[td]700µs à 11ms[/td]
[/tr]
[tr]
[td]P3 normal[/td]
[td]55ms<P3<5000ms[/td]
[td]100ms à 235ms[/td]
[/tr]
[tr]
[td]P4 normal[/td]
[td]5ms<P4<20ms[/td]
[td]31µs[/td]
[/tr]
[/table]
- beurk
- Quatre-Quatreux
- Messages : 17004
- Date d’inscription : octobre 2007
- Contact :
- Statut : Hors ligne
Sniffer les échanges sur le K-line 3/3
A- Arduino nano
Pour arriver à mes fins j'ai pris l'option du programmable et non du paramétrable (ELM327/323).
Les cartes Arduino proviennent d'un projet libre (c'est mon objectif et un choix de vie). Le langage de programmation c'est le C/C++. Elles arrivent toutes assemblées
Site Arduino:https://www.arduino.cc/
Wikipedia:https://fr.wikipedia.org/wiki/Arduino
J'ai jeté mon dévolue sur une arduino nano:
- un port usb pour téléverser la programmation et communiquer vers l'extérieur via une interface série sur le PC
- tension logique 5V (TTL)
- alimentation 6-20V (parfait pour être alimenté par la prise ODB)
- 14 broches Entrées/sorties numériques: 4 pour carteSD, 2 pour USB, 2 pour port E/S OBD à (voir plus bas), reste 6 broches libres
- 8 broches Entrées/sorties analogiques (0/5v)
- un peu de mémoire Flash/SRAM/EEPROM
- vitesse 16MHz
- aussi grosse que mon pouce (carte du bas)
B- Interface 12V-TTL (Kline vs 5V) L9637D
La carte arduino ne tolère en entrée que des tensions de 5V. Il y a lieu de fabriquer une interface entre le signal 12V délivré par le pin7 (KLine) et l'arduino. Le meilleurs compromis, c'est le circuit L9637D. Sauf qu'il n'existe qu'en boitier SO8.....c'est du CMS (Composant Monté en Surfaces) donc très petit. De plus j'utilise un carte de prototypage rapide au pas de 2,54 mm. Donc j'ai procédé à un montage amovible.
le data sheet: http://www.st.com/content/ccc/resource/ ... 000234.pdf
le schéma de montage/interfaçage - conversion de la seule entrée/sortie K-Line en 2 entrées/sorties TX et RX
Le CMS monté sur support bricolé - la taille, le résultat à atteindre (merci les lunettes loupes)
Un support amavible standardisé SO8 to DIP8 (que j'utiliserai par la suite)
C- Montage général pour développement ultérieur
Pour faire mes premiers pas dans le projet, j'ai d'abord conçu l'ensemble sur plaque de montage rapide filaire.
Pour m'aider dans cette tache et parc que j'aime le travail bien fait (sic) j'ai utilisé le logiciel fritzing:http://fritzing.org/home/
Il permet de concevoir ce type de montage, mais aussi d'avoir une représentation schématique, puis de concevoir le(s) PCB des circuits à faire faire chez un chinois du coin. Le tout est lié, donc chaque liaison, chaque modification se répercute dans les 3 espace de représentation....super pratique. J'utilise des soft similaire dans mon job.
Vue Schématique:
Vue de la plaque de montage: Vue du mien. Il tient dans le vide poche du cubby box, bien callé.
J'ai à ma disposition une liaison BT pour contrôler avec le PC et la carte SD pour enregistrer ce que je souhaite. 2- PREMIERS SKETCHES ARDUINO
A- balayer les bytes et trouver les bons seuils de découpes
Premier sketch, simple, efficace. Je récupère les données sur la console série du logiciel de programmation arduino.
Le formatage en sortie est assez basic, mais suffisant pour trier les datas et inscrire les durées entre byte.
Le formatage de sortie est du type:
B1
TP (temps interbytes mesuré par la carte)
B2
TP
B3
.....
Code : Tout sélectionner
// UART------------------------
// Tx - Pin 9 - D6
// Rx - pin 10 - D7
// USB------------------------
// Tx - pin 1 - D1
// Rx - pin 2 - D0
// BIBLIOTHEQUES EXTERNES-----
#include <SoftwareSerial.h>
//formatage de sortie pour mesure de temps entre bytes:
//b1
//#TP
//b2
//#TP
//b3
//.....
// VARIABLES--------------
byte InByte; // variable de stockage temporaire pour bytes
SoftwareSerial UART(7, 6); // Porte série K-Line (RX,TX)
long Time = 0; // stockage temporaire de temps
long TP = 0; // stockage valeur temps inter-bytes
void setup()
{
Serial.begin(115200); // initialisation port usb à 115200 bauds
while (!Serial) {
; // Attente pour connection port serie usb
}
Serial.println("Carte ok"); // Texte de confirmation carte prête
UART.begin(10375); // initialisation port UART à 10375 bauds
Time = micros();
}
void loop()
{
if (UART.available())
{
TP = micros() - Time;
InByte = UART.read();
Serial.print(InByte, HEX);
Serial.print(";");
Serial.print("#");
Serial.println(TP);
Time = micros();
}
}
Je récupère sur la console série les infos formatée, je les copie colle dans un fichier .txt, je renomme en .csv, puis je l'ouvre sur excel et voilà:
colonne de droite les bytes (octet en fr dans le texte, représentation d'un unsigned int (entier non signé - de 0 à 255 sur 8bits) en hexadécimal) / colonne de gauche les durées, temps entre chaque bytes donnés en µs (attention cette valeur est indicative et non réelle du fait de la tolérance du quartz / variations suivant température) Un byte en hexa c'est 2 caractères. Quand il n'y en a qu'un, c'est qu'il manque le préfixe 0 (ex: 1, devrait s’écrire 01....en c++: 0x01)
B- thésauriser les trames + tris dans excel
Le but de ce travail est de pouvoir découper les échanges suivant des seuils de temps.
Le premiers sketch m'a fourni ces seuils sauf qu'il a fallut manipuler les statistiques dans tous les sens pour arriver au bon découpage.
Sans compter que même si l'arduino nano tourne en 16Mhtz, le mode de découpage que j'ai adopté génère des erreurs (2.5%).
courbe de découpe 1 le seuil de 40 000µs est bien visible courbe découpe 2 amplifié au ² min-max en découpe frame/subframe Tout ça pour arriver à mettre ua point un sketch final qui permet de découper proprement les bytes et les sub-frames échanges TESTER-ECU
Code : Tout sélectionner
// UART------------------------
// Tx - Pin 9 - D6
// Rx - pin 10 - D7
// USB------------------------
// Tx - pin 1 - D1
// Rx - pin 2 - D0
//formatage de sortie:découpe des frames/subframes (echanges TESTER->ECU)
//subframe1.1;#TP;subframe1.2
//subframe2.1;#TP;subframe2.2
//subframe3.1;#TP;subframe3.2
//.....
// BIBLIOTHEQUES EXTERNES-----
#include <SoftwareSerial.h>
// VARIABLES--------------
byte InByte; // variable de stockage temporaire pour bytes
SoftwareSerial UART(7, 6); // Porte série K-Line (RX,TX)
long Time = 0; // stockage temporaire de temps
long TP = 0; // stockage valeur temps inter-bytes
void setup()
{
Serial.begin(115200); // initialisation port usb à 115200 bauds
while (!Serial)
{
; // Attente pour connection port serie usb
}
Serial.println("Carte ok"); // Texte de confirmation carte prête
UART.begin(10375); // initialisation port UART à 10375 bauds
Time = micros();
}
void loop()
{
if (UART.available())
{
TP = micros() - Time;
InByte = UART.read();
if ( TP < 1800) //2800=1erreur
{
Serial.print(InByte, HEX);
Serial.print("|");
}
if ( TP > 1800 && TP < 15000)
{
Serial.print(";");
Serial.print("#");
Serial.print(TP);
Serial.print(";");
Serial.print(InByte, HEX);
Serial.print("|");
}
if (TP > 35000 )
{
Serial.println(";");
Serial.print(InByte, HEX);
Serial.print("|");
}
Time = micros();
}
}
J'obtiens ce tableau qu'il me suffira de trier pour localiser les bytes qui changes et qui sont porteurs de l'information que je cherche.
A gauche la requête TESTER, au milieu le temps de réponse de l'ECU, à droite la réponse de l'ECU. Chaque Byte est séparé par un |. Après plusieurs essais en condition moteur arrêté et moteur tournant et en roulant..............et des tris successifs dans excel, voilà ce que j'obtiens:
Les échanges NANO-ECU avec balayage des 5 fenêtres du mode instruments: synthèses des échanges / apparitions chronologiques Les échanges NANO-ECU avec balayage des 5 fenêtres du mode instruments: loop suivant les fenêtres du Nano-com F1/F2/F3/F4/F5 les XX sont les bytes porteurs des données. CS, c'est le checksum de la trame (idem coté TESTER). Le CS sert a vérifier l'intégrité de la transmission
Les échanges NANO-ECU in-loop lors d'un enregistrement fichier CSV mode instruments
Arrivé à ce stade, je sens qu'il va y avoir du sport pour identifier les données!!!!
Alors un jeu de sudoku se met en place et avec un peut de bon sens, j'ai trouvé 2 premières trames: Engine speed et véhicule speed
Ce sont tout bonnement les 2 premières trames de la fenêtre de lancement du Nano en mode instrument. Pourquoi? 1-c'est logique du point de vue des successions des trames dans les différents modes, mais surtout le nano fait un test pour voir si le moteur tourne car entre moteur arrêté et moteur tournant les trames ne sont pas les mêmes. Et surtout leur cyclicité change.
TESTER: 2|21|9|2C|
ECU:4|61|9|2|ED|5D|
La donnée se cache dans les octets 2 et ED.
La vitesse de rotation variant de 0 à 5000 rpm elle ne peut pas être codé sur un octet (0 à 255), mais sur un word (16-bit unsigned number) de 2 octets: 2ED.
Converti d'Hexadécimal en décimal, ça donne 749.....en RPM!....la vitesse moteur au moment de l'enregistrement
- mimouss
- Modérateur
- Messages : 13488
- Date d’inscription : mars 2005
- Localisation : essonne
- Statut : Hors ligne
re: Storm td5: pour nous les zommes
C'est intéressant! Mais complexe mais intéressantbeurk a écrit : vous en avez assez.........ou vous en voulez encore?
Et subaru forester 2.5L bva
et subaru forester 2.0l turbo bva en rénovation ( comprendre entrain de pourrir )
- Rem's
- Quatre-Quatreux
- Messages : 5117
- Date d’inscription : juillet 2012
- Localisation : Lyon
- Statut : Hors ligne
re: Storm td5: pour nous les zommes
- valJeep
- Modérateur
- Messages : 12789
- Date d’inscription : novembre 2010
- Localisation : entre sauvignon et chardonnay :D pays d'Ancenis ;)
- Statut : Hors ligne
re: Storm td5: pour nous les zommes
t'es pas arrivé pour décoder les trames hexa
- beurk
- Quatre-Quatreux
- Messages : 17004
- Date d’inscription : octobre 2007
- Contact :
- Statut : Hors ligne
re: Storm td5: pour nous les zommes
A- les trames et leurs significations
B- les 2 modes de fonctionnement du nano-com et les raisons de faire autrement
- valJeep
- Modérateur
- Messages : 12789
- Date d’inscription : novembre 2010
- Localisation : entre sauvignon et chardonnay :D pays d'Ancenis ;)
- Statut : Hors ligne
re: Storm td5: pour nous les zommes
Je dis que tu as pas fini de décoder les données hexadécimale de façon empiriquebeurk a écrit : TESTER: 2|21|9|2C|
ECU:4|61|9|2|ED|5D|
La donnée se cache dans les octets 2 et ED.
La vitesse de rotation variant de 0 à 5000 rpm elle ne peut pas être codé sur un octet (0 à 255), mais sur un word (16-bit unsigned number) de 2 octets: 2ED.
Converti d'Hexadécimal en décimal, ça donne 749.....en RPM!....la vitesse moteur au moment de l'enregistrement