can_usb eeePC

Messieurs, vous êtes en avance sur l'avenir

nvidia-3.jpg



nvidia-2.jpg



Source : http://www.cartech.fr/news/affichage-3d-nvidia-39502409.htm
 
ce soir une petite manip effectuée dans la base de registre pour diminuer la taille du buffer d'entrée du canusb (valable idem pour elm327) .
il est passé de 4k à 2k.
résultat : l'évènement de réception est déclenché 15 ou 16 fois par seconde au lieu de 8 ou 9.
la qualité de réception est toujours parfaite avec un buffer contenant systématiquement 1984 octets.
cela m'a permis de vérifier le temps de réponse à un PID sollicité : c'est toujours inférieur à 0,1 sec.
 
sollicitation PID

la sollicitation à haute fréquence est ok !!!!! (en plus de la collecte normale).
chaque 1/10 sec je sollicite 2 PID en alternance.

l'analyse (avec powergrep) du gros fichier de log montre une parfaite régularité.

je viens de procéder à une capture de 24 minutes (qui commence par une belle marche arrière en pente pour sortir de mon garage).
le nombre de trames capturées est de 2 400 999
ce qui fait une moyenne de 1667 trames / sec
le nombre de réponses à des sollicitations est de 12 672 soit 189 trames/sec.


yapuka analyser le csv pour trouver affectation des données.
l'ensemble dont le csv zippé est dans PCM605

@planetaire : dans cette version, j'ai déplacé temporairement les boutons pour qu'ils soient accessibles sur petit écran.

rappel: le buffer du ftdi (port usb) a été ramené à 2k au kieu de 4k.
 
.....

Le pid 7EA 22 est découpé ainsi: un octet après l'octet de valeur &h22 puis deux mots de 16 bits puis un octet.
Ces deux mots ont une valeur très proche.....:grin:
précision analyse du 7EA 22 (découpage identique tableau pgm)
l"octet 1 est à 22

l'octet 2 varie de 0 à 255 je pense qu'il correspond au poids faible d'un mot dont l'octet de poids fort vient de 7EA 21 octet 8

le mot composé des octets 3&4 correspond trés exactement au pid348
le mot composé des octets 5&6 correspond exactement au nb de tr/mn de ICE
l'octet 7 est toujours à 0
l'octet 8 varie de 4 à 128
 
...l'octet 2 varie de 0 à 255 je pense qu'il correspond au poids faible d'un mot dont l'octet de poids fort vient de 7EA 21 octet 8...

Excellent.
Même avis et donc ces 4 pid sont chainés, ce qui est nouveau.

Le Pid 7EA 21 commence par 2 octets concernant le freinage.
Ils sont la plupart du temps identiques mais peuvent différer de 1 ou 2.
J'ai un instant rêvé qu'on avait la pression sur les disques de frein mais ces octets peuvent être inférieurs ou supérieurs à l'enfoncement de la pédale de frein.:cry: Au contraire ils indiquent plutôt une notion de récupération d'énergie. Ils peuvent repasser à 0 avant le relâchement de la pédale de frein, à très basse vitesse. Ils restent à 0 si freinage à très basse vitesse.
Alors la différence avec le pid_frein serait-elle le freinage plaquettes ?

A ce sujet, il y a une situation pas normale en ligne 12230: le frein est vers 60% (donc fort) le Soc 51%, la vitesse vers 30 km/h et brutalement l'intensité de freinage chute de 70A elle passe sous les 10A. Les 2 octets 7EA 21 , 1 et 2 repassent à zéro également. Un nid de poule ?

Le Pid 7EA 24.3 augmente lentement. Eligible à une température ?

A+ ;-)
 
il y a plein de trucs qui pourraient être des températures ,
il faut normalement soustraire 40 et suivre cela.

je suis absolument certain que le couple d'octets p10.5 et p10.6 correspond à la vitesse de MG2 (signée) : cf ce qui se passe en marche arrière et à Vitesse max. (je ne sais pas encore le convertir pour les trucs négatifs)

d'ailleurs ouala la preuve:
à gauche échelle en kM/H
à droite RpM de MG2
formule : rpm_mg2 = (p105 - 64) * 256 + p106
à l'extreme gauche, c'est une marche arrière non traitée , qui fait d'ailleurs apparaitre une vitesse non signée.

 
.... donc ces 4 pid sont chainés, ce qui est nouveau....
en fait les 5 pid notés p21x...p25x arrivent toujours ensemble et résultent de la demande: Call SendCANCommand("t7E283000000000000000", False)

dans les test précédents, je sollicitais seulement C3, par la commande
t7E280221C30000000000
dont la réponse donne la vitesse de MG2
je vais tenter de solliciter C4
t7E280221C40000000000
(avec un peu de chance il correspond à MG1)
 
il y maintenant un nouveau dossier PCM606 , il contient entre autres un nouveau zip.

particularités :
il y a maintenant en plus une réponse au C4
du fait d'avoir demandé le C4 , la réponse au 30 est très différente , avec seulement 2 pid 21 & 22 ......

complément d'info
en fait on va récupérer plein d'infos (56 octets exactement) en procédant de la manière suivante :
1a) envoi de : t7E280221C30000000000
1b) la réponse 7EA8102761C3xxxxxxxx donne 39 octets (27 hex) 4 octets (5 à 8 ) tout de suite puis 35 à suivre en faisant:
2a) envoi de : t7E283000000000000000
2b) la réponse donne 35 octets , 5 trames (21 à 25) de 7 octets (2 à 8 )

3a) envoi de : t7E280221C40000000000
3b) la réponse 7EA8101161C4xxxxxxxx donne 17 octets (11 hex) 4 octets (5 à 8 ) tout de suite puis 13 à suivre en faisant :
4a) envoi de : t7E283000000000000000
4b) la réponse donne 14 octets , 2 trames (21 & 22) de 7 octets (2 à 8 ) dont on utilisera les 13 premiers.

en conséquence , il faut mémoriser l'action 1a ou 3a pour en traiter correctement la réponse en 2b ou 4b
 
Dernière édition:
C3 C4 touché

Après les récentes pluies de Pid, le service décryptage va devoir mettre tous ses limiers sur l'affaire... :-D

Mais au fait pourquoi 13 et pas 14 ? Aurais-tu vu un CRC ?

Et d'où viennent ce C3 et ce C4 ? y'a un C1, C2, C5, C6 ??

A+ ;-)
 
Après les récentes pluies de Pid, le service décryptage va devoir mettre tous ses limiers sur l'affaire... :-D on compte sur toi :jap:

Mais au fait pourquoi 13 et pas 14 ? Aurais-tu vu un CRC ? parceque les trames sont systématiquement remplies avec 8 octets de data.

Et d'où viennent ce C3 et ce C4 ? y'a un C1, C2, C5, C6 ?? cela vient de la bible (la genèse revue par ATTILA) :cool:

ce soir je viens de procéder à un enregistrement de très bonne qualité en parcours vallonné avec qqs accélérations de kéké.
je me suis limité au C3 et sa descendance , de façon à pouvoir les capturer à haute fréquence et il y a déja pas mal de boulot de devinettes avec celui là...

j'ai localisé les vitesses de MG2 et MG1 (mais je ne sais pas traiter les signes négatifs:oops: ) ainsi que qqs paires d'octets qui font des gros mots.
il y a la dedans les couples de MG1 et de MG2
probablement la vitesse de ICE et sa consigne.
probablement plein de températures.

je te suggère de ragarder le zip dans PCM607 , c'est une feuille excel trés prometteuse.
tout en haut, il y a les min et max de colonne
j'ai regroupé par couleur ce que je pense etre des gros mots.
 
la suite du décodage aprés analyse de mon test d'hier soir
Code:
MG2 est en[B] C3_01 & C3_02[/B]  mini : -129   maxi:   3235 à 90,2 kM/H
MG1 est en [B]C3_07 & C3_08[/B]  mini: -6223  régénération en descente 
                 maxi : 10015 accélération de kéké en tirant 137A de la batterie

formule utilisée :
si O_pdsfort > 63 : (O_pdsfort-64) * 256 + O_pdsbas
sinon                : O_pdsfort *256 + O_pdsbas - 64 * 256


Consigne de ICE est en [B]C3_11 & C3_12[/B]    maxi : 5700
ICE est en             [B]C3_13 & C3_14[/B]    maxi : 5000

[B]C3_05 & C3_07[/B] évoluent de pair , excursion de 0 à 46 , sont liés au freinage.

je pense que [B]C3_03 & C3_04[/B] sont liés au couple de MG2
             [B]C3_09 & C3_10[/B] sont liés au couple de MG1

il y a par ailleurs un certain nombre de trucs qui pourraient etre des températures.
à vérifier en commençant enregistrement avec moteur froid.

@ suivre
 
C3.11 et C3.12

En C3.11 et C3.12 c'est exactement le paramètre litres/heure (Pid 38.2) avec plus de décimales.

Il faut prendre (C3.11*256+C3.12)/256

Ce paramètre n'est pas utilisé actuellement car bien qu'au niveau temporel il soit meilleur que la pid520, par contre sa valeur ne colle pas à froid.

Mais est-ce bien des litres/heure ?

C3.15+C3.16 sont très proches de C3.13+C3.14 ils forment également un mot et de valeur très proche. des tr/mn ?
Légèrement en retard par rapport à C3.13+C3.14.

A+ ;-)
 
ce que tu appelles des Litres/H, dans la bible, ils appellent cela " engine speed request".
en langage d'automaticien français , c'est une consigne.

 
correctif et compléments:
le couple C3_11 & C3_12 semble bien associé à la consommation.
les couples (C3_13 & C3_14) (C3_15 & C3_16) correspondent exactement à la vitesse en t/mn de ICE ; le 2ème correspond probablement à la consigne.
récap :
C3_01 C3_02 : vitesse MG2 (rpm)
C3_07 C3_08 : vitesse MG1 (rpm)
C3_11 C3_12 : conso
C3_13 C3_14 : vitesse ICE (rpm)
C3_15 C3_16 : consigne ICE (rpm)



C3_05 C3_06 : trés similaires , actifs au freinage
C3_03 C3_04 : couple MG2 ?
C3_09 C3_10 : couple MG1 ?

C3_21 , 25 , 26 , 27 , 28 , 29 températures ?
 
ecran externe.
c'est ici que j'ai acheté mon écran:
http://www.tokyo-toyz.com/proddetail.php?prod=CENTURYLCD-4300Uplusone(USBminiLCDScreen)
le manuel utilisateur est effectivement en japonais, mais le driver s'installe en 1 minute.
le résultat est vraiment super: lumineux, contrasté et avec des couleurs bien pétantes..
je prévois quand même d'utiliser un mini-hub USB alimenté pour protéger les ports USB de l'eeePC et pour limiter la filasse.
il faudra également légèrement modifier le pgm pour que les effets de zoom soient associés à la taille de la fenêtre et pas à celle de l'écran.
pour la fixation , je vais préparer 2 équerres en alu plat fixées au dos de l'écran par du velcro.
la fixation au tableau se fera par des "tapis antidérapant" d'inforad.
il s'agit de rondelles souples , épaisses d'environ 3 ou 4 mm, en élastomère translucide qui adhèrent fort bien sans laisser de traces (et qui se lavent parfaitement à l'eau tiède avec du liquide vaisselle, laissez sécher sur une vitre).
 
mise sur ftp version 610
modifs : gestion fenêtres pour adaptation à mini écran déporté
boutons de redimensionnements sont là.
gestion de l'évènement form_resize.
petite modif pour récupérer taille du form et non de l'écran.
initialisation de diff.
 
Pages vues depuis le 20 Oct 2005: 310,232,120
Retour
Haut Bas