TEP 96 ou autre pour diagnostic

Citro · Message par **Citro** » mar. 29 09 , 2009 8:30

claudegu a écrit :Je récupère le TEP demain, j'ai fabriqué un adaptateur avec pont diviseur et résistance série au cas où, le tout muni d'un jack pour aller sur le PC, j'ai le soft Audacity (gratuit) qui permet d'échantillonner à la vitesse voulue.

L'idée d'utiliser Audacity, alors là tu me "scotches"... GENIAL.

claudegu · Message par **claudegu** » mar. 29 09 , 2009 18:31

Bon, première tentative "d'enregistrement" du dialogue TEP Scootelec.
Tout d'abord, le premier envoi du TEP pour réveiller l'UCE n'est pas à 5hz comme dans la norme OBD, on serait plutôt à 40 bauds..??
Ensuite, tant que l'on a pas mis le contact, le TEP affiche le message pour mettre la clé et, une fois par seconde il y a une interrogation, cette fois-ci, on semble proche des 10400bauds de l'OBD. (image interrogation.jpg)
Enfin, si on met le contact, c'est une communication continuelle.

Je vous ai fait des copies d'écran dans Audacity, évidemment, ce n'est pas un oscillo à mémoire, et comme c'est fait pour le son, on ne voit pas les 1 et 0 mais juste les changements d'états.

Bon courage!!!!

Citro · Message par **Citro** » mar. 29 09 , 2009 20:07

claudegu a écrit :Bon, première tentative "d'enregistrement" du dialogue TEP Scootelec.
Tout d'abord, le premier envoi du TEP pour réveiller l'UCE n'est pas à 5hz comme dans la norme OBD, on serait plutôt à 40 bauds..??
Ensuite, tant que l'on a pas mis le contact, le TEP affiche le message pour mettre la clé et, une fois par seconde il y a une interrogation, cette fois-ci, on semble proche des 10400bauds de l'OBD.
Enfin, si on met le contact, c'est une communication continuelle.

Je vous ai fait des copies d'écran dans Audacity, évidemment, ce n'est pas un oscillo à mémoire, et comme c'est fait pour le son, on ne voit pas les 1 et 0 mais juste les changements d'états.
Bon courage!!!!

En effet.
Sacré boulot en perspective...

claudegu · Message par **claudegu** » mar. 29 09 , 2009 20:30

Voila le résultat de mon analyse des trames :

Première séquence à faible vitesse :
0 état de la ligne au début
1 pendant 70ms
0 pendant 30ms
1 pendant 80ms
0 pendant 60ms
1 pendant 100ms

Séquence d'interrogation toutes les secondes, j'ai supposé une transmission avec 1 bit de start, 8 bits de données et Un stop

la séquence fait 4 octets : 83h, EEh, 00h, 9Ch

Une fois le contact mis, l'interrogation reste la même, mais il y a une réponse de 10 octets:

C9h, EEh, 00h, 42h, 18h 92h, 42h, 00h, 41h, D5h

Voila, voila. j'en ai terminé avec ce que je sais faire, la patate chaude au suivant!!!!!

pdelagrange · Message par **pdelagrange** » mar. 29 09 , 2009 23:53

Quelques petites remarques:

- la graduation en temps ne semble pas cohérente avec la bande passante de ta carte son... ça ne devrait pas retomber si vite. C'est peut-être l'impédance de ton pont diviseur + résistance série qui est trop forte.
- c'est bizarre que ça commence par un pic vers le haut... puisque l'état de repos est un état haut (tu peux vérifier?)
- 40 baud c'est inconnu au bataillon. C'est devrait être 5. Cependant en "fast init", on a un pulse de 25ms pour réveille l'UCE. Ca peut ressembler à ça.
A mon avis tu observes des rebonds de l'insertion du câble.

En "fast init", la demande "startCommunication" fait 5 octets, et commence par 0x81...
La réponse fait 8 octets, et commence par 0x83...
Bref, ça ne colle pas trop.

Je te dis dès que j'ai un bout de soft qui peut servir à capturer du signal.

claudegu · Message par **claudegu** » jeu. 01 10 , 2009 9:33

Tout à mon bonheur d'avoir résolu ma panne d'UCE, je n'ai pas fait la vérification que tu me demandais. J'ai rendu le TEP donc, je ne peux plus la faire pour l'instant.

J'ai acheté un TEP sur Ebay également, comme ça, j'aurais tout le temps de m'y intéresser de près.

Je ne sais pas si il est possible de trouver un vieil outil de développement pour ST90, car celui du TEP n'est pas soudé....

pdelagrange · Message par **pdelagrange** » jeu. 01 10 , 2009 15:03

Je vois que nous avons les mêmes valeurs

Je vais voir ce qu'on peut trouver.

claudegu · Message par **claudegu** » jeu. 01 10 , 2009 15:30

Oui, c'est plus fort que moi, un microcontrôleur, j'ai toujours envie de voir son programme.
Par contre, je ne pense pas qu'il y ait eu de système de développement, genre carte d'essais pour l'enseignement, pour ce genre de micro.

pdelagrange · Message par **pdelagrange** » jeu. 01 10 , 2009 16:03

Tadam!

Voilà:
http://www.st.com/mcu/inchtml-pages-st9_tools.html
http://www.yuan-ying.com/product_catalo ... evtool.htm

et une chtite formation en prime:
http://www.st.com/mcu/files/mcu/1069066144.pdf

C'est du gcc, dont c'est gratuit et on devrait avoir toute la suite binutils avec, donc entre autres le désassembleur.

Je va télécharger ça, miam miam.

Pour la programmation, on a le protocole il me semble; mais je ne sais pas si on peut facilement dumper le programme existant.

claudegu · Message par **claudegu** » ven. 02 10 , 2009 10:21

Il semble que ce soit au sujet des ST92 et non pas ST90, tu crois qu'ils sont compatibles?

pdelagrange · Message par **pdelagrange** » mer. 07 10 , 2009 2:13

J'ai téléchargé la suite ST9... on va voir ça.
Sinon j'ai fini mon analyseur logique du pauvre à base de port série (voir fichier attaché)

C'est un soft en ligne de commande qui fonctionne sous windows et auquel il suffit de donner le nom du port com ("com1" par défaut) et qui crache une ligne à chaque événement, avec le temps (en usec), le nom du signal, et sa valeur.
On peut observer 4 signaux en parallèle (sur CTS, DSR, RING, et CD).
Il suffit d'appuyer sur n'importe quelle touche pour arrêter le programme.

On peut enregistrer le résultat dans un fichier en utilisant la syntaxe suivante:

alp com1 > toto.txt

et on obtient un truc du genre:

Code : Tout sélectionner

         0 CTS  0
         0 DSR  0
         0 RING 0
         0 CD   0
   3247903 DSR  0
   3526741 DSR  1
   4186225 DSR  0
   4438268 DSR  1
   4526939 DSR  0
   4659917 DSR  1
   4752593 DSR  0

Après on importe ça sous Octave ou Matlab (ou Excel, ou ....), et obtient une jolie courbe, on peut faire des mesures, etc.

Je n'ai fait que des tests très très basiques et n'ai pas mis à l'épreuve la précision du soft en situation réelle.

claudegu · Message par **claudegu** » mer. 07 10 , 2009 13:17

Super!!!
Effectivement, on doit pouvoir regarder ce qui se passe de manière plus simple qu'avec la carte son.

pdelagrange · Message par **pdelagrange** » jeu. 11 11 , 2010 1:15

Bon, je déterre ce truc pour dire que le sujet n'est pas enterré, bien au contraire. Ca commence à faire un bon moment que je travaille d'arrache-pied sur la question.
J'ai bien évolué par rapport au soft "alp" qui en fait n'est pas du tout assez précis.
Avec une analyse de type "carte son", j'ai pu calculer la vitesse du port série (ce n'est pas standard).
Ensuite j'ai fait un analyseur du type "alp", mais avec 1 octet par ligne.
J'ai ainsi pu débroussailler le protocole:
- toutes les 100ms: une requête venant du TEP, puis une réponse du scooter. Le nombre d'octets de la requête et de la réponse est variable.
ça n'a strictement rien à voir avec l'OBD, en fait. C'est même à peine compatible d'un point de vue électrique car j'ai dû arracher la résistance de pull-up de mon interface OBD pour pouvoir espionner le bazar (sinon ça perturbait les communications entre TEP et scooter).
Comme ça communique toutes les 100ms, j'ai fait évoluer mon soft pour reconnaître les paires requête/réponse, en afficher une par ligne, et n'afficher une ligne que si c'est différent de la précédente. Beeeaucoup plus lisible.

J'ai enregistré une séquence de diagnostic dans laquelle je suis passé par la plupart des menus du TEP (sauf les tests et le menu spécial).
A partir de là j'ai pu aller plus loin dans l'analyse du protocole: je sais maintenant de quoi sont constitués les en-têtes de message et le checksum. Je me suis fait une liste d'identifiants de messages connus, mais il me reste à analyser les données.

Pour analyser les données, j'ai fait un autre soft qui émule les réponses données par le scooter (à partir de la liste connue); je peux modifier les données en live et voir le résultat sur le TEP, ça facilite l'analyse (et je peux faire ça au chaud/sec).
Pour l'instant j'ai analysé les messages suivants:
- nombre d'Ah chargés/déchargés/surchargés
- nombre de minutes à plus de 50°C
- identification de l'UCE (année/semaine de fabrication, version soft, n° de série)
- la plupart des codes de défaut (permanents, intermittents). A priori pour les défauts intermittents, il y a comptage des occurences.
- quelques bits d'état (béquille, contact, charge, etc)
- cause de disjonction (tension, courant, écart commande)
Je n'ai pas fini: il me reste les variables (courant, tension, vitesse, etc), et plein d'autres trucs.

Quelques remarques au passage:
- la plupart des données ont une dynamique supérieure à ce qu'affiche le TEP: par exemple les Ah surchargés sont sur 2 octets en 1/16 d'Ah, donc jusqu'à 4096Ah. Pour les Ah chargés/déchargés, c'est 3 octets, donc plus de 1 million d'Ah.
Donc ce n'est pas parce que le TEP affiche 99999 que la donnée sous-jacente sature.
- le défaut "mise en eau" dans le menu état, c'est la même chose que le défaut "ouverture trappe de mise en eau".

Je vous tiendrai au courant quand je pourrai proposer un émulateur de TEP96 (ou mieux...).

claudegu · Message par **claudegu** » jeu. 11 11 , 2010 10:14

Alors là................BRAVO!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Je n'ai plus les scootelec, ni le TEP, mais je suis content du résultat que tu as obtenu (quel boulot).

Vraiment : félicitations.

Claude

Message par **Remdo** » jeu. 11 11 , 2010 10:35

claudegu a écrit :Alors là................BRAVO!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Je n'ai plus les scootelec, ni le TEP, mais je suis content du résultat que tu as obtenu (quel boulot).

Vraiment : félicitations.

Claude

Alors il va falloir que tu mettes ton profil à jour