Projet Tripmaster : cahier des charges

[thierryb]

Mauvaise nouvelle, pas de pb de communication entre le pc et l'odblink, mais impossible de faire communiquer l'odblink avec la prius (avec PCM).
Par contre avec torque, pas de pb pour faire les deux communications.
j'appellerai priusfan demain s'il a une idée.

 

[planétaire]

Peut-être utilises-tu la reconnaissance automatique du port que fait pcm ?
As-tu configuré le numéro du port com dans pcm ?

 

[thierryb]

Oui, j'ai désactivé la reconnaissance automatique et j'ai configuré le bon port. Mais je vérifierai demain. Peut-être étais-je négligent.

Mais dans ce cas la communication entre le pc et le dongle ne marcherait pas, non ? or cette communication marche.

 

[planétaire]

Entre le pc et le dongle c'est de l'usb (pas du bt j'espère ?). Qui doit être ok puisque torque fonctionne.

 

[thierryb]

oui avec le pc je suis en usb.

 

[Palm35]

l'OBDLink que j'ai, est celui ci.
Tu as bien configuré l'ODBLink pour qu'il fonctionne en 500kb ?
Moi, en le recevant, je ne l'avais pas fait et donc il ne communiquait pas.
Et dans le menu réglage de PCM, tu mets ELM327 et non CanUSB ?

 

[thierryb]

Non je n'ai pas configuré l'odblink.
si tu sais comment faire, n'hésite pas.
sinon je finirai par trouver.

 

[kinetik]

Pour la mesure de la distance il se peut qu'en prenant une roue AR on ait la mesure la plus précise. Actuellement Pcm utilise la vitesse pid passif 0B4, qui est supposée une vitesse moyenne des 4 roues. Il en déduit une distance parcourue.

Bizarrement, 0B4 donne la moyenne des deux seules roues avant 0B1, divisée par 1.02 et ne prend pas directement en compte les roues arrière 0B3.
Ce coefficient 1.02 est toutefois amené à changer lorsque les mesures des roues AR et AV sont recalées les unes par rapport aux autres !

0B4 continue de transmettre un peu de vitesse alors que 0B1 s'effondre à 2,5 km/h.

Et l'odo 230, pcm n'en veut pas ? Il est sur les roues arrière lui.
Mais bizarrement, il gagne plusieurs mètres sur 0B3 en cas de freinage moyemmement poussé. Comme c'est un odomètre, on peut louper des données sans risque. Mais il ne faut pas attendre plus de 600 m.

 

[planétaire]

Quand tu as un facteur 1.02 il faut penser à 1024 / 1000.

Le 230 n'a pas été testé. Le 0B4 donne une très bonne précision et il indique "en temps réel" la vitesse. Le pid 3CA qu'utilisait pcm auparavent était en retard.
Un tel retard fausse différents calculs.

Donc 0B4 ce sont les seules roues avant. Il serait alors déduit de MG2 ?

A+

edit priusfan, ajout illustration 0B4 / 3CA

 

[priusfan]

obdlink
le contrôleur est un STN1100 et pas un elm327, sa doc est ici.

dans ce type de dongle, il y a 2 vitesses à paramétrer:
a) une du module BT vers le contrôleur
b) l'autre du contrôleur vers le module BT. (et l'USB)
le paramétrage du module BT peut se faire en BT
le paramétrage du contrôleur peut se faire en USB & en BT

en ce qui concerne le BT. il est nécessaire d"avoir des vitesses identiques, sinon on a un truc briqué
je ne me rappelle plus la dernière vitesse que j'ai utilisé pour torque.

pour PCM, qui marche en USB, il faut simplement que le contrôleur soit paramétré à 500k. sinon cela débute normalement, mais on se choppe quasi instantanément un "buffer overflow"

concrètement:
il faut relever la config actuelle avec la commande
AT PPS (et noter lle paramètre 0C)

puis forcer une communication à 500k par la commande
STBR 500000
suivi de : ST WBR
puis réinitialisation du truc

pour accéder au paramétrage de ce type de module, j'utilise realterm

@thierry: si cela coince, tu m'appeles

 

[thierryb]

merci, je venais juste de trouver la doc que tu me proposes. Avec tes commentaires ça aide encore plus.

j'ai aussi trouvé ce lien
http://www.scantool.net/support/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=42&nav=0,2,9

Il semble que la façon de faire depende de la version du firmware.

A suivre.

Mais pourquoi ce n'est pas PCM qui fait cela comme Torque le fait ?

 

[thierryb]

Effectivement, maintenant ça marche.
J'ai déjà eu deux erreurs à deux endroits différents. Je corrige et vous publie un exe. Ce serait bien que vous l'utilisiez pour s'avoir s'il reste des bugs.
Ensuite, je fais des améliorations que vous voulez.
Ensuite je porterai le code sur la PCM 7 Tactrix pour moi, pour le rallye, si je confirme ma participation.

 

[thierryb]

Pour une raison inconnue, de temps en temps PCM reçoit des données erronées.
Ensuite ces données sont utilisées dans des calculs, et des fois cela dépasse la limite.
J'ai donc mis dans certains cas des valeurs max, comme cela il n'y a plus de risque que cela saute.
C'est bizarre car certains des endroits que j'ai corrigé sont aussi dans pcm 7 tactrix, et je n'ai jamais eu le problème.

deux exemples :

                Case &H30
                    ' Pédale de frein 030.5
                    If dlc >= 5 Then
                        ds = "&H" & Can(5)
                        If IsNumeric(ds) = True Then BrakePedal = CInt(ds)
                        If BrakePedal >= 128 Then BrakePedal = 128  ' thierryb
                    End If

j'ai corrigé là, mais ça plantait plus bas :

Angle = BrakePedal * 90 / 128

car brakepedal valait 7289

                Case &HB4
                    ' vitesse (en centièmes de km/h) Ajout 31/12/08 0B4.6 0B4.7
                    If dlc >= 7 Then
                        ds = "&H" & Can(6)
                        If IsNumeric(ds) = True Then
                            ds2 = "&H" & Can(7)
                            If IsNumeric(ds2) = True Then
                                If CInt(ds) >= 128 Then ds = 128 'thierry
                                ds = CInt(ds) * 256 + CInt(ds2) '<=== plante là
                                Speed_kmh = ds / 100

 car ds vaut 198 et ds2 33

lien supprimé car obsolète. Voir post #48

 

[thierryb]

Il y a encore plein de dysfonctionnements. La cause est probablement des caractères perdus et donc des messages mal découpés. Je vais voir comment rendre plus robuste tout cela en étant le plus générique possible. À demain.

 

[planétaire]

Ca ne suit pas derrière

Pour une raison inconnue, de temps en temps PCM reçoit des données erronées.

Très intéressants tes tests.

Hypothèse: Comme le stn1100 est plus rapide qu'un elm327: on peut avoir un problème de temps de réponse. Soit de Pcm qui ne lirait pas assez vite, soit du driver du port com virtuel qui ne suivrait pas assez vite.
Pcm fonctionne en événementiel au niveau du port com. Il ne va pas chercher les données sur le port virtuel, il est interrompu quand un buffer ou autre est rempli. Donc on partirait alors en dépassement de pile ou autre. C'est possible, au tout début j'avais eu ce phénomène.
Un tel dépassement peut aller jusqu'au blocage. Par comparaison pcm 7 tactrix ne fonctionne pas ainsi. Je l'avais réécrit quand à cette logique.
As-tu tout désactivé sur ton pc: économiseur, services inutiles et autres trucs et machins choses.

Cette hypothèse doit pouvoir se vérifier en comptant le nombre de pid par seconde et en comparant avec un elm de base. Pas avec un tactrix car pcm_tactrix sollicite pas mal les ecu.

A+

 

[thierryb]

planétaire, peux tu me confirmer que chaque Can() devrait être sur 8 bit ? toutes les fois où ça plante c'est quand certains Can() font 2 ou 3 x 8 bits.

L'idée est de rendre plus robuste PCM, pas de trouver comment booster le PC. Mais mon intuition est que le pb vient de l' odblink.

 

[priusfan]

@thierry
bonsoir,
si ta machine (ce dont je ne doute pas) est suffisamment puissante, peux tu logger tout le trafic (brut de fonderie) pour analyse?
càd timestamt + réception.
de ce coté, je pense pouvoir t'aider pour le décannage.

 

[kinetik]

Quand tu as un facteur 1.02 il faut penser à 1024 / 1000.

Le 230 n'a pas été testé. Le 0B4 donne une très bonne précision et il indique "en temps réel" la vitesse. Le pid 3CA qu'utilisait pcm auparavent était en retard.
Un tel retard fausse différents calculs.

Donc 0B4 ce sont les seules roues avant. Il serait alors déduit de MG2 ?

Non, 0B4 n'a rien à voir avec MG2. On met d'ailleurs très bien en évidence des sautes brutales de vitesse entre les deux, qui traduisent le jeu lorsqu'on change de régime entre acélération et décélération.
0B4, c'est la plupart du temps directement la somme des deux 0B1, à un facteur près qui n'a rien a voir avec 1.024, je pense. C'est plus probablement pour corriger une hypothèse fausse dans la définition des diamètres de roue pour 0B1 et 0B3. La voiture part avec trois hypothèses de diamètres de roues. Identiques pour 0B1 et 0B3, avec un facteur 1.02 pour 0B4. Au bout de quelques minutes (ou fraction de minute ou hectomètres je ne sais), les diamètres utilisés par 0B1 et 0B3 sont changés pour qu'ils fournissent des vitesses proches, mêmes si les pneux sont différents. Le facteur de 0B4 est aussi modifié à ce moment là.

Sur 0B1 et 0B4, je peux très bien compter les tours de roues, parce que la vitesse oscille. Balourd, décentrement du capteur ABS ?

 

[planétaire]

@Thierryb
Dans chaque position du tableau can() il y a un octet stocké sur 2 caractères. Chaque caractère peut avoir une valeur de 0 à 9 et A à F. Donc l'octet est stocké dans deux héxadécimaux.
Dans chaque can() on a donc une valeur comprise entre 00 et FF. C'est sous cette forme que le dongle envoit le pid vers le pc.

Si tu as plus de 2 hexa dans un can() c'est que les espaces intercalaires sont bouffés !

d'où la reflexion qui n'a rien à voir avec ta question (réflexion autour du débit d'une liaison bt):
On pourrait donc occuper deux fois moins de place, voire même trois fois car il peut y avoir un espace entre les séquences en hexa.
Ce qui ramène le débit nécessaire de 500kb/s à 250 ou 166 !

 

[planétaire]

...Sur 0B1 et 0B4, je peux très bien compter les tours de roues, parce que la vitesse oscille. Balourd, décentrement du capteur ABS ?

Et si c'était le bus can qui crée ces oscillations ?
Car ce bus gère des collisions possibles entre émetteurs. donc des ré-emissions en retard.
Maintenant si tu as une variation de la vitesse angulaire parfaitement cyclique, cette hypothèse du bus can "saturé" ne tient pas.

 

[thierryb]

@Thierryb
Dans chaque position du tableau can() il y a un octet stocké sur 2 caractères. Chaque caractère peut avoir une valeur de 0 à 9 et A à F. Donc l'octet est stocké dans deux héxadécimaux.
Dans chaque can() on a donc une valeur comprise entre 00 et FF. C'est sous cette forme que le dongle envoit le pid vers le pc.

Si tu as plus de 2 hexa dans un can() c'est que les espaces intercalaires sont bouffés !

Murci planétaire. C'est ce que je pensais. Cela va donc être facile de consolider ton programme.
On devrait avoir une release stable demain.

 

[thierryb]

@thierry
bonsoir,
si ta machine (ce dont je ne doute pas) est suffisamment puissante, peux tu logger tout le trafic (brut de fonderie) pour analyse?
càd timestamt + réception.
de ce coté, je pense pouvoir t'aider pour le décannage.

merci Priusfan, si l'étape précédente ne resoud pas définitivement les pbs, ensuite je passe à celle-là.

 

[thierryb]

Voila une version qui devrait être plus stable, mais je ne l'ai pas testée. Trop tard pour sortir. On fera un test demain matin.

lien supprimé car cette version avait encore des bugs
voir le post 71 pour la version suivante

 

[kinetik]

Et si c'était le bus can qui crée ces oscillations ?
Car ce bus gère des collisions possibles entre émetteurs. donc des ré-emissions en retard.

La plupart des paquets du bus CAN sont remarquablement bien synchronisés. Si je prends le PID 244 par exemple, j'ai une période moyenne de 24.57445 ms en été, avec un retard n'excédant pas 25 ms. Ce retard inclus le délai du bus USB et de mon programme Python/Ubuntu.


En hiver, j'ai observé une période un peu plus courte de 24.57430 ms. Ici j'ai eu une saute de près de 100 ms sur le parcours


L'écart des périodes à 6 mois d'intervalle vaut 150 nanosecondes. Je le dis pour impressionner, mais il faut comparer à 25 ms, cela donne 6x10^-6, ou encore une demi-seconde par jour. Notez que je ne sais pas si c'est la Prius ou mon Dell qui dérive. Mais c'est de bonne qualité métrologique.

 

[kinetik]

Maintenant si tu as une variation de la vitesse angulaire parfaitement cyclique, cette hypothèse du bus can "saturé" ne tient pas.

Voici une démonstration magistrale que c'est bien un balourd des roues.
Je trace la vitesse des roues avant, en fonction de la somme des PID 244, divisés par 60 pour avoir la vitesse de MG2 en t/s, et multipliée par la période de 0.02457445 s, dont je viens de montrer la qualité, et multipliée encore par le rapport de transmission de 468/1925. Cela me donne des tours de roues avant, comptés par MG2.

Et maintenant je compte 100 oscillations. Comme on est dans un virage, les vitesses des deux roues diffèrent. Je compte 99.77 rotations théoriques pour une roue et 100.17 pour l'autre. En moyenne, cela donne 99.97 tours. Soit une erreur de 0.03 %, compatible avec la précision de mon pointage.
Accessoirement, il est donc confirmé que le PID 244 donne des t/min.