data logging ELM327

Merci à tous d'entretenir mes neurones (le contraire de la pile Wonder). sans vous, je me légumifierai. Mais ce qui à de bien à la retraite, c'est qu'on choisit soi-même son job, encore faut-il trouver avec qui on le partage. donc merci encore.

revenons à nos boutons : il faudrait en insérer un sur la prise diagnostic, car je crains pour ses pinoches.

Pour le hub, eh bé, j'y avions point pensé tout seul !
Par contre, je recommande la confection (y en à pas en magasin) d'un prolongteur usb coudé pour sortir le long du PC et ne gèner personne. S'pa, Priusfan, qui à bien regardé le mien.

pour le port COM , j'ai un petit doute sur la nécessité, ou la possibilité, ou pas, de configurer manuellement la vitesse du port série, qui ne semble pas d'ailleurs pouvoir monter à 500000.

Et pour le protocole, j'ai quelques idées sur des petits moments particuliers facilement obtenables et probablement comparables, comme 1/ le groupe électrogène - à froid - à chaud -, 2/ la fusée au décollage d'un péage, 3/ la côte bourrin 5% à 110/120/130 régulateur, 4/ le feu vert pulse 55 kmh et glide jusqu'à 30, et d'autres trucs comme çà qui durent pas trop lngtemps.
Pour la régularité d'un long parcours, c'est plus délicat à faire tous pareil, il me semble ...
 
...
pour le port COM , j'ai un petit doute sur la nécessité, ou la possibilité, ou pas, de configurer manuellement la vitesse du port série, qui ne semble pas d'ailleurs pouvoir monter à 500000..
le port série est un port tout à fait particulier , il est géré par le driver du FTDI ; il permet des vitesses tout à fait "anormales" par rapport à un port standard. cf doc ftdi
 
J'aurais donc installé tout ça à l'insu de mon plein gré ! J'avoue que je l'ai pas vu passer, et surtout j'ai pas été questionné sur des fenêtres de conf . matérielle de Windows. P'têt bien que je ne suis pas passé par là, il va falloir que je vérifie ça en détail demain.
 
Voici ma première collecte départ Issy-les-Moulineaux arrivée à Nanterre j'essaye de faire en permanence du pluse et glide
issy-nanterre.JPG
 
Super !:super:

Premier avis à chaud:
-on voit bien le démarrage à froid et le thermique qui tourne vers 1300 tr/mn
-le pied droit bouge pas mal pendant les pulse. Mais peut-être y-a-t-il plein de voitures devant qui gènent. Dans le milieu du trajet le régime moteur est souvent faible : 1200 tr/mn. Te serait-il possible de monter à au moins 1500 tr/mn voire 1700 tr/mn, avec du coup des glide plus longs ?
-A priori tu ne te laisse pas avoir avec la température du thermique quand il passe au-dessus de 72°C.

Alors tes impressions en roulant ?:-x

A+ ;-)
 
@ Planétaire : une matinée de CanMonitor : Tu peux piocher là dedans pour me dire ce que tu en penses.
(attention : comportement saccadé des L/100 - je n'ai pas compris)

Il y a dans l'ordre , un échauffement sans intervention, une attente au parking, un rouler EV puis hybride (coupé en 2), un coup de groupe électrogène, et un autre bout de parcours (coupé en 2) , le tout en zone agglo.

@ Priusfan : j'ai bien mon FTPI correctement installé (quand c'est branché - allumé). Mais je ne vois pas ces fenêtres, comme indiqué dans le pdf "FTDI_Drivers_Installation_Guide".
 
Pour la conso c'est parce que tu as une version un peu ancienne qui ne gère pas correctement les conso à l'arrêt.
Priusfan l'avait prédit. Mais comment vous vous dém..z pour consommer à l'arrêt :sad:
Je proteste, c'est un complot.8)
je t'ai donc envoyé par email la dernière version dans laquelle la colonne conso en litres tient compte de cette situation, pas encore les colonnes en L/100km. Ca va venir.

je regarderais et surtout comparerais les .csv ce WeekEnd.:hehe:

A+ ;-)
 
Rendement thermique

Toujours à la recherche du rendement du thermique, j'ai trouvé sur Cleanmpg les infos suivantes:
Tr/mn - durée d'injection
1500 tr/mn - 5,1 à 5,2 ms
1800 tr/mn - 5,5 à 5,7 ms
2000 tr/mn - 6,0 à 6,2 ms
3000 tr/mn - 6,8 à 7,0 ms

D'après la cartographie que j'avais publiée
où on a en moyenne 1150 sur le pid520 à 3000 tr/mn pour 6,9 ms.
1000 sur le pid 520 à 2000 tr/mn pour 6,1 ms
Le pid 520 est donc environ 170 fois la durée en millisecondes. C'est une valeur bizaroïde.

Pour retirer les 0,5 ms indiqués par Ken je retire donc 85 au pid 520.

Après modif du programme PriusCanMonitor et affichage en temps réel, j'ai constaté un rendement qui peut monter entre 33 et 34% au mieux.:victoire:

Pour l'heure ce n'est pas évident de savoir, en roulant, pourquoi on a 31 au lieu de 32 par exemple.:-(

Par contre plusieurs constats:
-à froid (40°C) le rendement peut être au-dessus de 30% :p
-Avec le régulateur sur autoroute, dans une descente de faible pente qui réclame un poil de thermique le rendement chute, chute..:pastop: Déjà qu'il montait le thermique haut dans les tours si on voulait 130 km/h dans certaines côtes...


A+ ;-)
 
Voilà du nouveau.
Sur Priuschat je suis passé par : captures issues du canview.
Jusque là pas terrible, les fichiers sont en .bin illisibles.
Et justement en cherchant le programme de décodage je suis tombé sur ce programme fourni avec ses sources.

Si vous regardez le prog Can_packets.cpp dont le rôle est de décoder les pid:

Code:
    //---------------------------------------
    // 38 - Fuel Flow
    //---------------------------------------
    } else if (packetId == 0x38) {
 
  [COLOR=blue][B]fuelFlowNum = Round(convertFuel(bytes[1]) / 10,[/B][/COLOR] .01);         // setting fuelFlowNum
  data.updateField(CANDataMgr::fuelFlow, fuelFlowNum);   // [COLOR=red][B]Get L/hr by dividing by 10 then round it to the nearist .01[/B][/COLOR]

Le byte 1 est le 2° octet, ils comptent depuis 0. Ils ont des litres/heure sur un pid 038 donc rapide. Flow traduit in french c'est "écoulement".

Ils décodent aussi le 520
Code:
    //---------------------------------------
    // 520 - Fuel Injector
    //---------------------------------------
    } else if (packetId == 0x520) {
        data.updateField(CANDataMgr::fuelInj, getUnsigned16(&bytes[1]));

suivi du calcul suivant:
Code:
 //---------------------------------------
    // 602 - Last calculations
    //---------------------------------------
 } else if (packetId == 0x602) {
  // Calculate iKM/L or iMPG
  if ((speedNum <= 0) && (fuelFlowNum <= 0)){  // Set kmlMPG to 0 if speed and fuel flow are both 0
   kmlMPG = 0;
   data.updateField(CANDataMgr::kmlMPGnum, kmlMPG);
  }
   else if ((speedNum >= 0) && (fuelFlowNum <= 0)){  // Set kmlMPG to 999.99 if moving but fuel flow is 0
    kmlMPG = 999.9;
    data.updateField(CANDataMgr::kmlMPGnum, kmlMPG);
   }
     else {
      [COLOR=blue][B]kmlMPG = Round(speedNum / fuelFlowNum,[/B][/COLOR] .1);  // Calculate iKM/L or iMPG and round to .1
      data.updateField(CANDataMgr::kmlMPGnum, kmlMPG);
     }

A étudier à mon avis. :dactylo:
 
Je viens d'extraire d'un dump fait sous Graphcan, effectué à sa cadence max, le Pid 038-1 , éligible pour le débit d'essence ?, entouré de ses amis :

-----

en valeurs brutes 0~255. 1 graduation horizontale par seconde
Le Pid 038.1 en rouge.
Le Pid 038.2 en marron.
l'injection timing Pid 520 en points successifs avec l'échelle de droite 0~1800)
À noter les deux courbes en bleu clair, la vitesse acquise par le Pid 0B4.5|6 (vitesse roues divisée ici par 32) que l'on retrouve à l'identique dans le Pid 244.4|5 (accompagnant la pédale d'accélérateur).
le régime moteur Pid 348.2|3 (ICE throttle) en vert (divisé par 200)
le Pid 03A.1, en bleu, décalé de + 128

la correlation entre ce paramètre et le produit que l'on a utilisé juqu'ici = régime moteur X injection timing
ne semble pas des plus évidentes, même si il y a de çà !
 
OUI, il faut comparer le 038.1 (fuelFlow) divisé par 10 et le 520 (injection) multiplié par les tours/mn et divisé par 3600. On compare alors des litres/heure.

Le 038.1 (FuelFlow) me parait plus intéressant que le 520.

-il arrive dès qu'en enfonce l'accélérateur et s'arrête brutalement dès le début de l'arrêt du thermique ce qui parait plus logique. Alors que le 520 arrive en retard et on force sa coupure lors de l'arrêt du thermique. De plus on a bien plus de valeurs par seconde.
-Seul problème, il vaut environ 1,2 fois les litres/heure qu'on calculait déjà et qui tiennent la route ! 1,2 c'est pas terrible comme coef.

La corrélation que tu as n'est pas parfaite à cause de ce décallage temporel entre les 2 valeurs de litre/heure.

Donc je l'ai ajouté sur l'écran et dans le .csv de PriusCanMonitor et on verra si on peut (disons plutôt comment) remplacer le 520 par le 038.1. en comparant sur des totaux d'un trajet conséquent.


P.S. le pid 038.1 fuelflow arrive vraiment dès le tout début du démarrage du thermique, même quand il n'a que quelques tours/minute. A la reflexion cela peut être très logique: lors de l'arrêt précédent il restait dans le collecteur d'admission un mélange air/essence (à cause du cycle atkinson qui "refoule du mélange vers l'admission"). Il faut déclencher des étincelles avant de le rejeter à l'échappement, sinon cela pollue et c'est une perte. Même si en en retire fort peu de couple. Pour le vérifier il faudrait synchroniser les courbes avec celle des étincelles


P.S2. L'affichage des ampères mériterait en effet une échelle logarithmique. Pour l'instant j'utilise les chiffres.

Et les cadrans de Prius_Pilot on n'en voit plus ?

A+ ;-)
 
l'ideal pour vérifier cette hypothèse du pid 038 serait de comparer avec les infos fournies par le supermid (pour rappel il s'agit du temps réel d'injection indépendamment de tout ce qu'il ya sur le bus can).
je n'ai pas gardé de collectes de données complètes associées au supermid...
il faudra donc que je bricole un pgm de capture simultanée des infos. facile ...

petit pb, j'ai prété mon interface elm327 à volkan et ma fille m'a piqué mon eeePC (aprés qu'elle se soit fait piqué son portable dans le RER).
l'interface supermid étant accroché à ma watture, on attendra une prochaine rencontre...
 
pour la correlation il s'agit bien de la comparaison que propose Priusfan entre le 38.1 et le produit 520 x 348. et aussi j'ai pensé au décalage temporel.
Mes trois données étant issues directement du flot continu sur le bus, j'ai interpolé les valeurs les plus rapides (520 et 348 ) aux instants de fourniture du 520 et j'y ai inclu pour chacune un décalage temporel ajustable. il y a peut-être un optimum pour 1 ou 2 dixième de secondes. mis il reste toujours un élément "perturbateur", essentiellement pour les valeurs élevées.

et pour le pulse d'injection au redémarrage du thermique, je pense que l'évènement de redémarrage sur un abandon du mode EV est le plus violent pour bien voir cette avance de l'injection sur la rotation.
 
Vvti

Toujours dans le prog Can_packets.cpp cité + haut on découvre un décodage du pid 526 : VVti.
Jusqu'à présent dans PriusCanmonitor on stockait un (gros) mot de 16 bits.

Pas eux.
Il prennent seulement l'octet N°2 du Pid, le divisent par 2 et soustraient 16.
Du coup l'octet 3 n'est plus utilisé.

Hasard, hier j'ai été contraint à cause d'un &#}/¤$! de camionneur de donner un coup d'accélérateur à fond, jusqu'à 4900 tr/mn. Le Vvti est monté à 33.
A l'inverse il vaut 0 à 1600 tr/mn et devient un peu négatif en-dessous.
A chaque démarrage et surtout arrêt du thermique il devient négatif, -16 lors de l'arrêt.
Non décodé cet octet varie de 0 à 97 (à 4900 tr/mn).

Dans les doc Toy il y a deux angles pour l'admission:
- +15 à -18° ouverture avant Top? Dead Center (Excursion de 33° donc)
- 78 à 105 fermeture après Bottom Dead Center (Excursion de 27°)

Je ne sais qu'en conclure.

A+ ;-)
 
PID 526, aussi dénommé "ignition timing" : l'octet 3 n'a pas dans mes enregistrements de signification autre qu'un supplément de précision de l'octet 2 , qui en à déjà suffisamment (excursion observée de 0 à 90 ).
À certains moments, je le vois suivre avec beaucoup de fidélité les valeurs du régime moteur Pid 348 "ICE throttle" :
correlation pid 526 (x 2.5) / pid 348 :
 
Remarquable la corrélation.
Et du même avis sur l'octet 3 : des décimales.

Mais es-tu sûr du terme ignition timing ? Ca fait plutot penser à l'allumage qu'aux soupapes d'admission ?

A+ ;-)
 
Ce terme "ignition" vient du doc CAN de Attila Vass. Des docs sur la Prius I parlent effectivement de Vvti.
Je précise pour la correlation, qu'il y à d'autres moments où ces deux paramètres se séparent nettement. il faudrait imaginer une sorte de régulation basée sur le régime moteur (comme le celui de Watt, mais zélectronik, bien sûr!)

Pour mesurer un angle, je vois mal un capteur angulaire ayant cette précision de plus de 12 bit. je pencherai donc pour une mesure de créneau temporel. mais dans ce cas, pour un angle donné, le crénau serait inversement proportionnel au régime moteur, donc se serait plutôt un timing d'allumage.
 
les aiguilles

Il y a quelchose qui cloche avec le VB6 comparé au VBA sous Excel :
On peut facilement sous Excel faire pivoter presque n'importe quel objet, avec une seule instruction écrite en macro VBA, du genre
" shapes(xxx).rotation = valeur (0~360) "
J"ai essayé de le transporter sous VB6, mais ça ne marche pas.
et les docs en ligne ne semblent pas en parler, à part pour faire de la rotation en 3D, encore avec des add-ons.
Ce qui justifierait le recours au VB flash ActiveX por réaliser un cadran animé.

Y en a t'il un parmi vous qui pourrait m'éclairer sur ce sujet ?
 
répartition de puissance

Il y a peut-être un moyen de traquer les différences de comportement des Prius en essayant de voir comment elles répartissent la puissance demandée entre thermique et électrique.

En simulant des conditions d'équilibre (accélération nulle, courant batterie nul), on s'aperçoit qu'il y a tout un domaine de possibilités de balance de la puissance entre le chemin [ICE - ring - traction] et le chemin [ICE - sun - MG1 - MG2 - traction].
J'ai noté ci-dessous quelques points, à différentes vitesses :

Code:
		ICE			MG1-MG2		Traction
balance	kmh	rpm	Nm	kW	Nm	kW	kW
							
100%	130	3427	76,8	27,9	0,8	0,4	27,9
70%	130	4485	59,3	27,8	13,6	6,7	27,9
							
100%	90	2575	41,4	11,2	2,8	1	11,2
70%	90	3292	33,4	11,2	9,6	3,3	11,2
50%	90	4390	24,4	11,2	15,2	5,2	11,2
							
100%	50	1584	20,5	3,4	3,2	0,6	3,4
50%	50	2914	11,3	3,4	10	1,9	3,5
30%	50	4321	7,7	3,5	12,8	2,4	3,5

il faudrait voir de quelle façon on peut faire apparaître cette répartition à
partir des enregistrements effectués.

ajout 03/03
une autre corrélation, avec le paramètre "Volt MG1", visible après extraction de la vitesse MG1 :

j'aime bien les "volutes" mais je ne sais pas si on peut y trouver un intérêt dans notre quête de la conso !
 
logique floue

J'aimerais bien qu'on essaye d'établir la logique du comportement du HSD vis à vis des températures du thermique et du SOC batterie. Quand et pourquoi le thermique démarre, quand et pourquoi le mode EV est refusé, ...
On pourrait écrire un bout d'algorithme qu'on ajouterait au CanMonitor avec un affichage ad hoc.

@ planetaire : pourrais-tu nous proposer une ébauche de logique, qu'on affinerait au fil des observations ?
 
Seuils du Hsd.

Voici un petit rappel (cf message 122) des températures du liquide refroidissement du thermique.

-40°C: En cas de démarrage à froid le thermique tournera jusqu'à l'atteindre. Déconseillé d'interrompre cette procédure. On risque de se trouver dans une phase de démarrage entre xx (30?) et 40°C et alors le thermique tournera jusqu'à environ 48°C !

-65°C concerne le chauffage/ventilation de l'habitacle: tant qu'on n'y est pas le thermique tournera si on demande le chauffage/ventilation de l'habitacle. Là pour arrêter le thermique il faut et relâcher l'accélérateur et couper la ventilation (off), en mode D.
Si on roule par exemple à 66°C en glide et que la température passe sous les 65 et qu'on demande chauffage/ventilation le thermique redémarre.
Il y a alors l'astuce à 66°C de passer en mode N, même sous 65 il ne redémarrera pas. Mais c'est sans doute pas malin, le thermique il faut le garder chaud.

-72°C: C'est plus délicat à expliquer. Cela permet de franchir un stade dans la logique du calculateur de la Prius au cours D'UN trajet.

Si on ne s'arrête pas passé cette température et qu'on lâche l'accélérateur sous 60 km/h le thermique tournera quand même.
Si on ne s'arrête pas passé cette température et qu'on lâche l'accélérateur au-dessus de 60 km/h le thermique ne tournera pas.

Si on roule thermique tournant au moins 5 secondes sans accélérer et sous 10 km/h on franchit un seuil et il s'arrête.
Mais pas vérifié, tant que sa température reste au-dessus de 40°C.

On atteint le stade S4 dans lequel cette température n'a plus d'effet et où le thermique ne répond plus qu'aux 2 autres température 40 et 65°C. Mais comme on est déjà au-dessus de 72°C on a de la marge.

Attention au 72°C on peut se faire avoir parce que le temps de ralentir et de s'arrêter elle peut descendre à 71 ou autre et alors c'est pas valable.

-Concernant les températures batterie c'est Pont Vert qui a les bonnes infos.
Juste constaté deux fois le refus du mode Ev à 0°C extérieur, accepté en-dessous et au-dessus !

-Au niveau du SOC seuils constatés de 79,5% (charge en groupe électrogène refusé) et 45% (mode électrique impossible) plus ceux donnés par Pont Vert. L'équilibre est vers 63%.

-Seuils de vitesse-compteur:
10 km/h et en-dessous on peut passer au stade 4
48 km/h fin du mode Ev au bouton
au-dessus de 60 km/h courants batterie différents (oscillations entre plus et moins) de ceux en dessous.
au-dessus de 70 km/h le thermique tourne (sauf astuce mode N)
au-dessus de ??? km/h en roue libre le thermique ne tourne plus vers 960-990 tr/mn mais plus vite.

A+ ;-)
 
Le Pid Fuel Flow 038.1 dit litres/heure vu sur Priuschat pose problème.
Au démarrage à froid il est à zéro pendant que le thermique tourne !
Sa valeur n'augmente que quand on accélère à ce moment et retombe à zéro si on relâche l'accélérateur pendant cette phase de mise en chauffe, même en roulant.

Ce paramètre est visible sur le canview puisque le prog que j'avais cité décodait les données brutes reçues du canview.

Donc problème. 8)
 
J'ai la nette impression qu'on à affaire à une variable interne de contrôle des ECU , plutôt qu'à une mesure. D'ailleurs les capteurs sont en nombre limité.
par contre, vu le nombre d'ECU, il doit bien y avoir un certain nombre de signaux de nature informatique imporants et significatifs qui se balladent à travers le HSD, et qu'il est possible de retrouver sur le CAN.
 
Il peut se bloquer.

J'ai fait chauffer aujourd'hui le programme PriuscanMonitor. Presque 700 km. (Là j'ai mis une alim sur la prise "allume-cigarette".)
Mais hélas il y a eu deux blocages : il n'écoutait plus l'elm.
Une des 2 fois c'était en attendant à une zone de travaux (feux alternés)
La solution a été (après garage) clic sur la croix en haut_à_droite puis patience et confirmer l'arrêt du programme et bien sûr répondre "ne rien envoyer à microsoft", pas de wifi dans ma Prius :grin:(Le plus stupide de cette question c'est quand elle vient à cause de la perte du réseau internet...):sad:

A+ ;-)
 
Le blocage du programme est expliqué:
je suis coupable. :grin:
Parfois... je prends appui sur le Pc pour actionner le Joystick. C'est pratique, en fait.
Donc quand on appuie alors sur une touche du clavier : y'a blocage.

Voili, voilà. :siffle:

Par ailleurs j'ai vérifié la distance obtenue par le même programme, comparée à celle affichée par la Prius (compteur Trip A, pour avoir les centaines de mètres)
Au bout de plus de 330 km : 200 mètres de différence. Disons 0,15 %. Rien. Parce que d'ailleurs pas sûr que la Prius ait raison. Mais allez vérifier, sur 330 km ! Rien que la façon de prendre les virages, l'usure des pneus...
 
Pages vues depuis le 20 Oct 2005: 311,038,032
Retour
Haut Bas