data logging ELM327

bravo pour ces réalisations.
une proposition :
plutôt que raisonner sur un nombre d'échantillons , je suggère une approche temporelle ;8)8)8) ; (j'aime bien me gargariser:grin:)
que ce soit pour des extrêmes ou des moyennes.
ces temps seraient eux-mêmes paramétrables;
par exemple :
0,5 sec
1 sec
1 mn
en effet , vu du coté conducteur, le nombre d'échantillons est une totale abstraction alors que le temps correspond à certains points de repère.
 
« Tu peux mettre des barres qui donnent la valeur instantannée, le maxima et le minima des xx dernières mesures et la valeur moyenne. »

C'est LA solution pour se dégager des échantillonnages, à réaliser sur toutes les valeurs à afficher.

Et pour la PIII, vous croyez que la prise diagnostic va nous sortir les couples et les courants des moteurs électriques.

Il y a aussi à rechercher pour la PII le témoin et le pourcentage de mise en action des freins à disque.
 
Au niveau des emplacements dispo dans la Prius III, il va être très difficile d'installer son eeePc ou son Scangauge.

On va regretter la petite trappe sous l'autoradio
 
Après plusieurs autres trajets je confirme la constante 1296 000 000 pour obtenir la conso en temps réel en mililitres. (J'ai corrigé mon message N°144)
L'écart de mesure est de 1 à 2 millièmes par rapport à la mesure précédente. Infime.

Donc l'influence des "bouchons" sera prise en compte.

Je trouve cette valeur en litres plus "parlante" qu'en litres/100 km.
C'est vraiment ce que l'on vient de consommer.
Dans l'exemple que je viens de publier ("Ma prius tousse") elle a consommé 5 mililitres pendant ses 6 démarrages (c'est approximatif, le Pid 520 est lent).
Mais on est si habitué aux litres/100km.

A+ ;-)
 
Dans ce cas tu devrais pouvoir vérifier que la Prius consomme environ 1,5 litre à l'heure à l'arrêt moteur tournant à 1250 / 1275 tours par minute.
 
Comparaison en côte.

Je ferais cela dès que possible, parce que pour l'instant j'ai au maxi 5 secondes sans accélérer et thermique vers 1000-1250 tr/mn et c'est hyper imprécis, l'ordre de grandeur et du mililitre pendant ces 5 secondes, à 1 mililitre près...

Par contre j'ai déjà un premier résultat concernant 2 grimpettes d'une côte qui est sur un de nos trajets possibles.
-Une montée en limitant les tr/mn vers 2300-2400 : conso 0,172 litres
-une autre fois en accélérant d'abord jusqu'à 3170 tr/mn et en laissant redescendre lentement les tours vers 2700 : 0,180 litres.

2 personnes à bord + quelques kilos dans le coffre. Longueur de la montée 1250 mètres, mesure donnée par la Prius. Dénivellée 70 mètres. Même vitesse finale = 57 km/h, initiale 16-17 km/h. Même température thermique 88°C. Le Soc bouge au maxi de 0,5% et vers 62-63%.

A+ ;-)
 
Groupe électrogène : rendement

Premier essai d'utilisation de la consommation "instantanée".
C'est une utilisation de la Prius en Groupe électrogène: en Mode D et pied sur le frein.

1671497387b667350.png


Pour ce graphique mon tableur a calculé la conso sur chaque point (9 par seconde) avec la même formule que dans PriusCanMonitor.
j'ai supposé que l'essence a 9 kWh par litre.

En vertical le rendement de la conversion essence -> électricité fournie aux accus.
En horizontal les Wh produits (maxi 20 kW)
Durée du test : 35 secondes. Tours/mn de 1150 à 1850. Le Soc est passé de 62 à 66%

Comme je ne suis pas totalement sûr de cette réflexion, n'hésitez pas...
Enfin c'est assez basique : calcul de la conso en litre/heure. Multiplié par 9.
A comparer aux kW lus (ampères * volts). D'où le rendement.


Autre sujet : la conso à l'arrêt.
Plusieurs cas se présentent.
-En position parking: à 1472 tr/mn le paramètre injection n'est que de 279 ce qui donne 1,14 l/heure
-Lors du test ci-dessus en D à 1472 tr/mn avec le frein, injection = 902 soit 3,7 litres/heure.
à 1280 tr/mn injection 727 soit 2,58 litres/heure.
(Thermique vers 50-55°C)

-Je confirme la conso indiquée sur 5 secondes (le temps à attendre au dessus de 72°C pour passer au stade 4.): 1 mililitre de SP95. soit 0,72 litre/heure.

A+ ;-)
 
Est-ce que tu as vérifié la vraisemblance de la consommation totale durant ton test ? Une façon d'y arriver est de rouler 1 à 5 kilomètres et de relever l'ODB tous les 500 mètres.
 
Test

Tu veux dire
1) groupe électrogène puis 2) rouler en électrique sur xx mètres et lire l'odb ??

Comment as-tu fait ton essai pour avoir 1,5 l/heure ? en Mode "quoi" ?

Les contrôles effectués l'ont été:

-dans la précédente version du calcul de conso en comparant sur des trajets de plusieurs dizaines de km à plus de 100km l'écran du Pc et l'odb.
On ne peut pas trop comparer les l/100km sur de courtes distances, la conso sur le Pc arrive en avance et étant alors seul a bord après d..
J'avais obtenu comme résultat que la conso sur l'odb était légèrement inférieure à celle du Pc (0,1 à 0 l/100 environ).
-Puis j'ai comparé la nouvelle méthode de calcul qui tiendra compte de la conso à l'arrêt, mais sans avoir ce genre de situation. Et là c'est 1 à 2 pour mille d'écart entre les 2 méthodes de calcul.

A+ ;-)
 
trames sollicitées

Je commence à me débloquer (mon pb venait essentiellement de la portée d'une variable :oops: ).
J’utilise donc une lecture de buffer d'entrée déclenchée par un timer plutôt que l'événement comEvReceive.
Je vais, pour le moment, continuer dans cette voie.
Pour répondre à planétaire, cela évitera de jouer aux devinettes quant à l'affectation de telle ou telle info circulant sur le bus.
En effet, si l'on retrouve de manière systématique la valeur d'une info sollicitée associée au même pid dans le flux normal, la corrélation sera établie formellement (et il deviendra donc inutile de solliciter ce message).

Par ailleurs, il semble qu'il soit possible d'obtenir des infos supplémentaires en utilisant le 21 (au lieu du 01 standard), un espagnol est en train d'expérimenter là dessus.

Impact temps de réponse.
J’ai affiné l'affichage du temps dans le fichier de log avec un truc comme ceci:
Print #1, "=d="; Format$(Now, "hh:mm:ss") & "." & Right$(Format(Timer, "#0.00"), 2);....
je logue le moment ou je lance une commande et le moment où elle est acquittée;
et j'obtiens qqc comme le fichier attaché, on voit qu'en général, le temps de réponse est de qqs centièmes de secondes.

J’ai par ailleurs constaté qu'en mode écoute passive, on reçoit des "chunks" d'environ 4k, j'ai tenté de modifier la taille des buffers associés au port com (propriétés avancées) pour passer à 1k; sans succés...
 
priusfan à dit:
...Pour répondre à planétaire, cela évitera de jouer aux devinettes quant à l'affectation de telle ou telle info circulant sur le bus.
En effet, si l'on retrouve de manière systématique la valeur d'une info sollicitée associée au même pid dans le flux normal, la corrélation sera établie formellement (et il deviendra donc inutile de solliciter ce message).
...
Cliquez pour agrandir...

Ca serait génial. Mais une des difficultés que j'ai rencontrées est qu'il y a un décalage temporel entre des Pid liés à un même évènement. La corrélation entre deux valeurs est très difficile par programme. Il faut regarder des graphiques et réfléchir.

C'est évident par exemple sur la paramètre conso qui n'arrive pas forcément dès le démarrage du thermique.
Autre exemple les tours/mn du thermique. On a deux Pid rapides qui les fournissent. Ils sont proches mais pas moments il y a des différences.

" le temps de réponse est de qqs centièmes de secondes."
As-tu évalué le temps d'un cycle complet : bascule en mode sollicité+demande+lecture+retour mode écoute ?

En tout cas le premier qui trouve le couple du thermique. :bravo:
 
Si ma compréhension est exacte, lorsque le moteur thermique démarre, il est actionné par le démarreur dont le rôle est joué par MG2. L'injection de carburant ne devrait en principe venir qu'ensuite.
 
Presque. (Ce doit être MG1 le démarreur.)
Mais en fait c'est ma phrase qui n'est pas assez précise.
Je faisais allusion, par exemple à ce graphique:
http://prius-touring-club.com/vbf/showpost.php?p=65226&postcount=220
où on voit que le Pid de conso n'arrive pas toujours avec le même retard par rapport aux tours/minute du thermique.

L'émetteur de ce Pid n'est pas synchronisé avec la décision de démarrage du thermique.
Le même problème se pose lors de l'arrêt du thermique. Mais dans ces phases les tours/mn sont rapidement faibles donc l'éventuelle erreur commise est très faible.

A+ ;-)
 
Je pensais au même graphique. Pour interpréter les écarts, il faut être certain du "top départ" et du "top arrêt" de l'injection ce qui, me concernant, n'est pas évident. Rien n'oblige à avoir une injection synchonisée avec la rotation du thermique.

Je pensais que MG2 était le démarreur qui entraînait à la fois les roues et le thermique et que MG1 n'était qu'un "différentiel" permettant de combiner les puissances de ces deux moteurs.
 
MG2 est lié aux roues de façon fixe. Toute action sur MG2 est donc une action sur la propulsion de la voiture qui est ressentie par les passagers. C'est bien MG1 le "démarreur", même si ça n'exclut pas des actions simultanées correctives sur MG2 pour lisser le démarrage en phase de roulage.
 
[HS]
Quand ma Prius a "toussé", je n'ai pas ressenti de secousse. J'étais en train de descendre la côte devant chez moi et ai juste remarqué le bruit variable et les tr/mn sur le Pc (et une fois parce qu'à cet endroit il faut être prudent et regarder la route).
[/HS]
 
Au sujet du fonctionnement en groupe électrogène, j'ai déjà remarqué une baisse de rendement des batteries dans ce mode de charge forcée.
En comparant la SOC donnée par l'OdB (pid 3CB) et le cumul des ampères par seconde (pid 03B), j'ai constaté à plusieurs reprises une divergence très nette : on ne retrouve pas au final tout le courant qu'on y a mis.
Donc, une estimation de rendement du thermique est amha faussée par ce comportement de la batterie.
 
Dans le test que j'ai fait c'est l'électricité fournie aux batteries.
Le rendement indiqué est donc le produit de celui du thermique, de MG1 et de l'électronique de puissance (Les 2 derniers sont connus).
Ce qui en reste dans les accus, là..
D'ailleurs le SOC c'est quelle valeur ? La quantité injectée dans les accus ou la quantité qu'ils contiennent, la différence étant les pertes de charge. (Là on peut ignorer l'auto-décharge)
De toute façon les tours/minutes sont limités (même accélérateur à fond), très probablement à cause des possibilités de charge de la batterie. Et c'est vers 1800 tr/mn.
Donc on ne peut pas tracer une "courbe" (disons plutôt plage) intéressante de rendement du thermique.

A+ ;-)
 
J'ai branché un Inforad K1 sur le Pc.
Ca donne cela sur 20 km environ (près de chez moi donc pas de montagne) :
1671497b2579edaf6.png


Le résultat est en fait moyen et pas satisfaisant:
Après contrôle sur une carte Ign (au 1/125000ème donc au mètre près)
Si on a par endroit des valeurs exactes, il y a des grosses erreurs:
-Au début on ne monte pas jusqu'à 300 mètres mais 275 mètres
-ligne 4033 la descente n'est pas du tout jusqu'à 150 mètres mais 201 mètres
-ligne 7673 (au niveau de la forte conso) l'altitude n'est pas 170 mais 192 mètres.
La zone 1500-3600 est correcte, d'autres aussi.
Le départ et l'arrivée sont corrects.

Les soucis semblent venir des traversées de villages, des changements brusques de direction et vitesse ??
Le relief, peut-être au niveau 4033.

Je peux sans doute améliorer la position du récepteur Gps en le plaçant juste sous le pare-brise.

Ajout 24/01/09: Un deuxième relevé (en vert) nettement meilleur en ayant placé le Gps sur le tableau de bord (là où toyota met le gps de la version Pack)

A+ :photo:
 
Je suis étonné : tu as l'altitude donnée par l'inforad directement dans le .csv.
Ce qe j'ai obtenu de celui de Ket, c'est X Y et temps. J'ai dû restituer l'altitude à partir de gpsbabel et openrunner.
 
altitude
la version de pgm utilisée par planétaire (ainsi que prius_pilot et moi-même) , permet d'analyser les trames NMEA d'un GPS , dans ces trames, il y a entre-autres l'altitude.
mais cette info est de qualité trés variable; elle dépend essentiellement du nombre de satellites reçus et de leur répartition (plus ils sont éloignés mieux c'est.
on peut régénérer cette info avec 3droutebuilder.
 
je commence à piger les pb de comm avec le elm327.
en fait on passe par un émulateur de port comm et la gestion est assez différente d'un port comm standard.
je vais tester demain un buffer moins grand aprés un petit tour dans la base de registre et dans le fichier ftdiport.inf
je vous invite à regarder ce document. http://www.ftdichip.com/Documents/AppNotes/AN232B-04_DataLatencyFlow.pdf
 
Suite à une deuxième mesure d'altitude faite avec le Gps (Inforad K1), J'ai modifié le graphique dans mon message 171 et rajouté la courbe verte.

Le Gps a été placé cette fois au milieu du tableau de bord, sous le pare-brise juste au dessus de l'endroit où Toyota met le gps de la version Pack.

Le résultat est très nettement meilleur. Les défauts signalés ne sont plus là.
Il y a juste y avoir une erreur en fin de trajet de l'ordre de 10-20 mètres. Mais là c'est en ville avec des immeubles.

A+ :dactylo:
 
Identifiez-vous ou inscrivez-vous pour participer.
Pages vues depuis le 20 Oct 2005: 313,222,676
Retour
Haut Bas