Quelques infos glanées au fil de mes lectures (studieuses !) et quelques interrogations :
1/

Communications with CAN232 via a terminal application:
send "V" command. You'll see "V1220" version info received.
send "N" command. You'll see "NB743" serial number.
send "X1" command to enable AutoPoll function.
send "S6" command to set 500 kbps CAN speed.
send "O" command to open the CAN port. You'll see a lot of CAN messages.

Cliquez pour agrandir...

Le message "S6" doit onc être envoyé à chaque initialisation pour assurer un débit correct, je suppose. Est-ce le cas pour toutes les applis CAN ?

2/

ICE (Internal Combustion Engine) power is calculated as prescribed by Norm Dick, the inventor of CAN-View, ascribing 58 kW to 238 in the CAN output for fuel flow and assuming linearity..

Cliquez pour agrandir...

Ce qui fournirait l'étalonnage de la donnée "injector timing", mais ne serait pas lié au régime moteur. Étrange !.
De plus, il doit y avoir une incidence notable du paramètre "VVT-i" (0x39-2) sur la conso, que je ne trouve explicitée nulle part, bien que tout monde vante les économies de carburant réalisées par ce moyen !
3/

Altering the SOC (SOC spoofing)
The OEM battery broadcasts a message on the CAN bus approximately every 100ms which includes the SOC. It has been discovered that the Prius's HV ECU listens to the last message received. Simply rebroadcasting that message immediately after it was originally sent with an altered value for the SOC (and altered checksum), causes the car to believe that the SOC is the altered value without intercepting the original message. This allows a conversion to spoof the SOC in a low cost and simple method which does not require altering the OEM battery's ECU or taps. The agent doing the rebroadcasting can be a computer with a device such as CANUSB or a small embedded system with a CAN interface.
Any system which uses SOC spoofing must be careful not to over discharge or overcharge the OEM battery

Cliquez pour agrandir...

Ce qui expliquerait les bidouillages possibles pour les plug-in amateur.

Suite à un recherche sur Priuschat voici une relation entre conso en litres/heure et durée d'injection:



et le lien qui pointe directement sur l'image originale: là

Mince, c'est pas vraiment une droite...

Cela semble venir de l'utilisation d'un Canview.

A+

si l'on veut tirer une corrélation entre le temps d'injection et la conso;
il est impératif de commencer par multiplier cette donnée par la vitesse de ICE de façon à obtenir un débit
et ensuite on pourra comparer ce produit à une conso (en tenant compte de la vitesse bien entendu)
cf explication de yoshi....

Cette correlation injection / débit n'avance à rien. Si on veut en faire une, c'est en partant de la formule citée par Priusfan (produit du temps d'injection par le régime moteur), en effectuant une division par la vitesse , et en comparant cette consommation (exprimée en litres aux 100 km, la seule qui soit significative pour un véhicule roulant) avec la consommation réelle obtenue par une autre canal que le CanView, c.à.d. soit l'affichage OdB (mais on retombe sur les mêmes sources, et la comparaison ne peut être que visuelle), soit sur la conso relevée à partir du remplissage du réservoir et des km parcourus.

C'est là, à mon avis le seul intérêt du CanView (ou tout autre analyse des donées de la prise diagnostic), que de savoir fournir une valeur instantanée exacte de consommation (et des km parcourus), et de pouvoir ainsi retomber sur le total mesuré à la station-service.

litres / 100km

Effectivement, comparer une durée d'injection avec une conso en litres/heure ne permet pas de tirer de conclusion.

J'ai fait des essais tout à l'heure pour essayer d'obtenir la constante qui redonne des litres aux 100 à partir du paramètre injection, des tours/mn et de la vitesse.
Ca s'approche de: l/100 = injection * tr/mn divisé par km/h et par 3600.
Avez-vous une meilleure formule ?

A+

ok pour l'approche de la formule ,à un facteur k prêt , qu'il reste à déterminer.

la formule avec coef

Yoshi said "The key number is the 14052 (for 0.001 liter) fuel parameter."

Ce paramètre varie entre 0 et 1500 (constaté sur mes enregistrements)

Je suis sur le point de pouvoir vérifier cette proportionalité
(de 1 miliLitre pour une mesure brute du temps d'injection de 14052),
qui doit donc s'ajouter aux conversions d'unités, ce qui donnerait donc :

Pour chaque cylindre, la quantité d'essence débitée à chaque ouverture d'injecteur :
Volume (miliLitre) = [ injectionTiming / 14052 ]

Pour un 4 cylindres 4 temps (4 x 1 injection tout les deux tours), on doit multiplier par 2.
Le débit est obtenu en multipliant ce volume par le nombre de tours de moteur par unité de temps :

Débit Essence = [ 2 x injectionTiming / 14052 ] x [ Régime moteur / 60) ]
(miliLitre/seconde) . . . . . (brut -> miliLitre) . . . . . (tour/minute -> tour/seconde)

soit D (mL/s) = (iT * Rm) / K1 avec K1 = 14052 x 30 = 421560

ordres de grandeur pour estimer la valeur d'entrée iT = K1 x D / Rm
- pour un débit de 1 mL/s (valeur basse de 3.6 L/h) , avec un faible régime de 1800 tr/mn on a une valeur d'njection de env. 421000 / 1800 = 234 brut (16 % de l'échelle)
- pour 10 µL/s (valeur haute 36 L/h), avec un régime plus élevé de 4800 tr/mn, on obtient 421000 x 10 / 4800 = 877 brut (58 % de l'échelle), ce qui semble correct et conforter cette mise à l'échelle.

La consommation s'obtent en divisant le débit par la vitesse du véhicule :

Consommation = [ Débit x (3600 / 1000) ] / (Vitesse / 100)
(Litre/100km) . . . . . (mL/s -> Litre/heure) . . . . . (km/heure)

soit C (L/100km) = K2 x (D / V) avec K2 = 360

ordres de grandeur correspondant aux cas de figure choisis précédement :
- pour 1 mL/s à 1800 tr/mn, en prenant une vitesse de 90 km/h (cas de vitesse stabilisée sur route plate), on obtient 360 x 1 / 90 = 4 L/100
- pour 10 mL/s à 4800 tr/mn en prenant une vitesse de 120 km/h (cas de forte accélération en dépassement), on obtient 360 x 10 / 120 = 30 L/100

formule trés intéressante , mais tant qu'à faire , il faut ,d'aprés yoshi, enlever 0,5 mS au temps réel d'injection.

revenir ici : http://prius-touring-club.com/vbf/showpost.php?p=55667&postcount=157

Si on finit le calcul de Mik&Toy on obtient une constante de 421560/360=1171 (les 0,5 mS c'est plus du fignolage)

Au vu des premiers essais et de l'interprétation des mémorisations effectuées dans les fichiers .csv il faut s'attendre à une constante de l'ordre de 3500-4000. (La valeur d'injection varie d'environ 300 à 1200 soit le même ordre de grandeur que les valeurs citées par Mik&Toy)

Soit un facteur d'au moins 3.

Alors le 14052 n'est valable que pour le super-mid de Yoshi ?

Retenez-moi si je me trompe.

A+

C'est bien la question que je me pose !
J'ai l'impression pour l'instant que les chiffres affichés en instantanné, l'OdB d'ne part et mon CanUsb de l'autre, ne correspondent pas entre eux.

ps: coquille : c'est 421560 / 360 qui fait 1171

@ Priusfan: enlever 0.5 mS c'est bien joli, mais sur quelle valeur faut-il appliquer cette correction, vu qu'on passe directement d'une valeur brute (0~1500) à un volume en miliLitre. je suppose qu'il faut l'interprèter à partir de « When the pulse width is 6 msec, the count value is 1200 » , donc une échelle de 200 brut par mS, ce qui reviendrait à retrancher 100 à la valeur brute.

Remarque sur la formule de conso :
il faut noter que sur un véhicule à boîte de vitesse, une fois un rapport de démultiplication choisi, le rapport [ vitesse véhicule / régime moteur ] est constant, d'ou une conso proportionnelle au temps d'injection, et réciproquement. Il n'y a qu'un changement de rapport de boîte qui puisse faire varier cette proportionalité.
Sur la Prius, c'est différent, puisque le régime moteur n'est plus lié à la vitesse du véhicule, mais plutôt à l'effort demandé. La consommation est découplée de l'injection, qui peut rester constante, pendant que le régime moteur s'ajuste à la demande. Et même que le régime du thermique peut être modifié finement et rapidement par contrôle du régime de MG1.

Après un trajet test hier soir, je constate que la constante dite de PriusPlanck (3600)
est très proche de la bonne valeur.
On obtient une conso instantanée de 0,1 à 0,3 litres plus élevée que celle de l'odb.
(enfin vu l'elm327 que j'ai pour l'instant, lors des phases de vitesse quasi-stabilisée,
le reste du temps il affiche la conso de la seconde précédente)
Et comme l'odb est pessimiste au niveau de la conso moyenne...

Un exemple de trajet de 2x20km en pulse&glide.

Les points jaunes correspondent à la consommation instantanée, bien sûr.
La moyenne est de l'ordre de 3,5 à 4 l/100 sur le trajet.


Vous remarquerez qu'il y a 3 groupes de points:
-ceux à 0 litres : glide
-ceux entre 65 et 85 km/h vers 4 litres : conduite sans pulse&glide
-ceux qui sont en haut, les plus nombreux, où on voit que la conso instantanée augmente quand la vitesse diminue.

La vitesse est la réelle, ce qui explique le petit trou vers 65 km/h là ou il vaut mieux
être tout en dessous ou tout au dessus (en p&g).
Et encore j'ai retiré la phase de démarrage à froid qui dépasse même les 100l/100km.

A+

Linux ou XP - C ou VB

question de performances:
Force m'est de constater après utilisation et plongée dans le code, que sur un même EeePC, le programme CanMonitor développé en VB6 sous XP donne des résultats décoiffants par rapport au GraphCan développé en C.
Je n'y aurait pas cru sans ce test comparatif.

Et pourtant le langage C laisse imaginer qu'on est au plus près du processeur et d'un langage d'assemblage.
Il faut croire que non, ou alors serait-ce parce que le compilateur C sous Linux ne mettrait en oeuvre qu'une émulation de processeur et pas directement le processeur lui-même ?

Toujours est-il que tous mes efforts pour accélérer le Graphcan se sont soldés par un maigre 50 kbps, là où le VB se paye du 500 kbps.
Je trouve ça dommage , parce que la programmation en C coté code est moins bourin, mais il faut reconnaitre que l'aspect graphique ainsi que le temps réel du VB sont nettement plus accessibles.

Il manque quand même la rotation des rectangles, à moins qu'on puisse trouver un add-on qui n'oblige pas de passer par le FLash, un peu lourd pour juste afficher un angle, c'est pas de la video en streaming que je demande !

performances :
le langage utilisé est à mon sens un peu secondaire:
pour moi le principal ,et de loin, c'est d'utiliser un algorithme efficace.
concrètement il faut collecter toutes les données aussi rapidement que possible,
ne rentrer dans le détail des traitements que lorsque c'est réellement utile,
et n'afficher que les changements.

en ce qui concerne l'affichage, je te souhaite bonne chance :
j'ai passé des mois à chercher une solution efficace et n'ai trouvé que le biais du flash.

de toute façon, je considère que c'est trop casse-gueule de regarder un bel écran en conduisant.


pour info, less polluter envisage d'utiliser un système de collecte de données lors du prochain rallye VEA; si cela l'intéresse, je lui prête mon matos eeePC, elm327 , alim et 1 inforad.

pour ce type d'usage, il me semble qu'il faudrait revenir à un pgm qui crache dans un fichier log seulement les paramètres connus (dont les infos GPS) ; ce pgm devrait etre bétonné : pas de plantage possible.
j'imagine de fixer l'eeePC au sol par du velcro (en neutralisant la mise en veille, on peut parfaitement faire tourner le pgm de capture écran fermé).

il semble également interessant de développer un pgm pour avoir des fonctionalités du genre tripmaster pour les épreuves de régularité.

cékikisicolle ???

Ok

Mais c'est le co-pilote qui doit regarder !

Je verrais qand même une interface acoustique qui renseignerait en temps réel des approches de la conso minimum, pas des causettes, (comme le passage en EV sur le Graphcan !) juste un son musical , en jouant sur la hauteur, peut-être sur un rythme, pour ajuster sa pédale d'accéléateur et savoir dans quel sens.

là aussi, qui s'y colle ? Je pense que ça ferait un tabac.

pour le tripmaster, je suis déjà dessus, coté VE, mais pas encore bien spécifié.

En effet, je viens d'en parler avec priusfan.

Au départ je pensais me donner un avantage certain avec un tel engin mais finalement j'ai abandonné l'idée d'avoir une chose pareille dans mon champs de vision.

Je me propose donc devenir juste le collecteur des données brutes.
A quelle fin ? Je n'en sais rien !
Peut-être qu'on en tirera quelque conclusions. L'idéal aurait-été qu'une autre voiture, voire plusieurs, en fassent de même. On pourrait comparer.
Quoi ? Je ne sais pas !
Ca doit être l'anniversaire du barde qui me fait rimer ... J'arrête sinon ça va barder.

Pour l'efficacité de conduite on line il faudrait un programme carabiné (qu'on développera peut-être pour l'édition prochaine, j'ai pas dit suivante) style : en prennant en compte la moyenne à réaliser et le positionnement par rapport à elle, en anticipant sur le rélief et les virages grâce au trajet rentré, guider visuellement (en utilisant un HUD pendant qu'on y est ) le conducteur sur le dégré d'enfocement des pédales (en y ajoutant le dégré de braquage du volant on pourrait gagner en poid en se débarassant du conducteur et du copilote - à voir pour la P3 équipée du radar anticollision) de sorte à puiser +/- sur la batterie.

Trève de rêveries. Passons au sérieux à savoir le tripmaster :
cet aprèm je me suis vite concocté un minitableau Excell à rentrer sur un PDA qui permettrait de se situer par rapport à la moyenne à tenir.
On saisi avant le départ : la moyenne à tenir et la distance à parcourir. Au départ on enclenche le chrono et pendant le trajet quand on en a besoin on saisi la distance parcourue et le temps qu'affiche le chrono.
La feuille repond en affichant : la moyenne en cours, la distance qu'on aurait du parcourir si on avait respecté rigoureusement la moyenne cible, l'écart par rapport à la distance qu'on aurait du parcourir, écart de temps par rapport au point où on est, le temps et la distance qui restent à parcourir ainsi que, surtout, la nouvelle moyenne à réaliser pour atteindre la moyenne cible. Rien que ça !

L'idéal aurait été que l'ordinateur calcule ça en temps réel (pauvre copilote si je lui demande de tripoter le PDA toutes les 30" va perdre le nord) avec un affichage sexy aussi, mais bon, gros chiffres bien disposés pourraient faire affaire. Le temps réel serait déjà pas mal. Bien sur il y aura toujours une marge d'erreur due à l'étalonnage du compteur de la Prius.

Alors si quelqu'un se sent de fourmis dans les doigts.
J'enverrai demain mon minitableau.



P.S. Waw, j'aime bien l'approche acoustique. Ca va faire l'ambiance Intruder ça. Pas celui là mais celui là (pilote et copilote côte à côte - décidement le barde) 5 targets à 10h !!!

Mik&Toy à dit:

question de performances:...Toujours est-il que tous mes efforts pour accélérer le Graphcan se sont soldés par un maigre 50 kbps, là où le VB se paye du 500 kbps....

Cliquez pour agrandir...

Parce que tu parles de la vitesse entre l'Elm et le Pc. Elle est d'abord gérée par le pilote (driver) et pas par le prog en c ou vb6.
Les données sont stockées (bufferisées), ensuite pour vb ou le c c'est un bête travail de découpage de chaines de caractères et quelques petits calculs arithmétiques.
Toutes les écritures dans les fichiers (jusqu'à 3 aujourd'hui) sont également bufferisées, donc pareil de simples copies d'octets en mémoire, c'est Windows qui décide quand c'est le meilleur moment pour écrire réellement sur disque, un volume de données qui est ... faible.

Aujourd'hui les Micros sont tellement puissants que ce qu'on leur demande là leur laisse beaucoup de "temps libre" (Il suffit d'afficher le gestionnaire de taches pour le voir)

Cela veut dire que le prog soit écrit en c ou en vb6 il reste minoritaire dans le pourcentage d'utilisation du CPU. Et donc x fois rien reste négligeable.

Less Polluter à dit:

.

Cliquez pour agrandir...

j'avoue que depuis quelques temps je pense ajouter un petit écran (genre 7" branché sur la sortie Vga) sur le tdb juste devant le volant avec juste les 4-5 infos utiles en temps réel. Pas vu d'Hud grand-public autre que des Gps.
Parce que regarder vers la droite c'est pas l'idéal en roulant (même remarque au sujet de l'odb actuel de la Prius)
C'est à dire guère plus que sur une autre auto: tr/mn, température moteur...% Soc, Ampères et une cinquième pour étudier un nouveau pid.
Et retirer de sa place actuelle le Pc.
Peut-être , mais là c'est le gâteau sous la cerise, pouvoir afficher en cliquant sur un mulot bluetooth d'autres écrans de temps en temps: valeurs moyennes, cumulées, histogrammes, un peu comme sur l'odb de la Prius.

Pour revenir sur le projet tripmaster
Un point très important avec la Prius est l'anticipation de la pente à venir.
Donc si vous pouvez prévenir le pilote de la prochaine montée/descente afin que soit il vide un peu sa batterie avant une grande descente, soit il prenne la descente en 'roue libre' ou au contraire qu'il y recharge sa batterie vous pourrez optimiser la conduite. Peut-être lui indiquer dans la montée à venir la pente et donc les tours/mn à avoir, voire la vitesse initiale en bas...

Au niveau acoustique ça fait un moment que je voudrais bien avertir le conducteur que son thermique tourne alors qu'il n'accélère pas, après la phase de démarrage initial à froid.

A+

Je parlai d'une estimation de la vitesse en fonction du nombre de paramètres réellement traités dans la seconde (j'ai mis un compteur sur chaque Pid reçu). Et là je me rends compte que tout ajout de calcul et d'affichage en plus de la simple acquisistion et mise sous fichier fait ramer le biniou comme c'est pas permis.
en log simple, sans affichage et sans calcul, j'arrive pratiquement à obtenir tous les paramères émis, et j'en moissone sur Graphcan beaucoup plus que ce que je vois sur CanMonitor (en fait tous, y compris les plus rapides en cadence, du 0x21 au 0xB4)
C'est bel et bien le traitement processeur à l'affichage qui tient pas la route. Vu que le Graphcan provient d'une première mouture pour Zaurus, il doit y avoir une conversion du rafraîchissement du buffer graphique qui n'est pas adaptée à l'EeePC.
Donc le traitement devrait être minoritaire, et il ne l'est pas. Le CPU n'est peut ètre pas surchargé, mais surement mal utlisé.

Pour l'affichage, je rejoins planétaire sur l'écran simplifié posé devant le conducteur. je vais m'acheter dès que possible un de ces petits OLED programmables et connectables par USB pour voir si ça tient la route.

Pour le tripmaster et la pente à venir, je ne vois guère de solution. Aucun site de cartographie ou traitant le GPS ne founit de pente, mais seulement des dénivellés, très approximatifs dès qu'on grimpe dans les collines, la précision étant totalement insuffisante pour déterminer la puissance à fournir à chaque instant.

Attention je crois que sous graphcan tu traites aussi bien les pid reçus que ceux sollicités. Cela oblige à interrompre le flux et cela fait perdre le temps de reprogrammer l'Elm et relancer le flux. PriusCanMonitor ne traite pas les Pid sollicités.

En plus tu as un problème d'affichage qui bloque d'autres traitements. Là je ne sais.

A+

planétaire à raison à propos de trucs sollicités (mais pas à propos d'elm puisque c'est un tout autre interface).
les trucs sollicités sont seulement les Temps du pot catalytique.
en ce qui concerne l'efficacité de la programmation graphique , il me semble assez logique que des primitives graphiques implémentées au niveau du noyau de l'os soient moins gourmandes que des bidouilles programmatiques.

Vous avez dit "bidouilles"
Mais mon cher monsieur , le langage C n'est pas de la bidouille.
Il a fait la promesse de s'attaquer au noyau et aux instructions du processeur.
Est-ce pour de vrai ou fait-il seulement semblant ? That is the question.
A mon avis, l'émulateur graphique est en cause. Je dirai pas pourri mais quand même …

Ah au fait, le rectangle qui tourne en VB c'est un gros trait X1.X2.Y1.Y2. yapuka sin/cos, etc …

Ci joint le lien vers la feuille Excell faisant office de tripmaster
http://dl.free.fr/rljl9RlLZ
Avant de partir on saisi le champs en gris (distance totale du tronçon et la moyenne cible) puis les champs en blanc.
Désolé pour la propreté des formules mais c'était vite fait. J'sais même pas comment le faire calculer sur la format heure alors j'ai fait avec les moyens du bord (puis ne pas être obligé de saisir les ':' sur un PDA dans une voiture en mouvement ça aussi ses avantages)

Attention l'objectif principal dans un tronçon de spéciale est de respecter le parcours et les points de passage. Il est également fondamental de conserver un co-pilote en bon état de fonctionnement.

Ensuite des feuilles de kilométrages par rapport aux moyennes à respecter sont suffisantes pour se recadrer de temps à autre sauf si bien entendu on vise à la perfection comme un équipage il y a deux ans qui lors des deux premières spéciales (4 contrôles) n'avait eu qu'un seul point de pénalités.

Une autre possibilité est d'avoir un GPS qui donne la vitesse moyenne depuis le départ du tronçon. Cela suffit pour savoir si on est en avance ou en retard par rapport à cette moyenne. Inconvénient potentiel : en zone de montagne le GPS peut perdre le signal et du coup plus rien.

Tout cela pour dire que je ne compte pas utiliser ou demander à mon co-pilote d'utiliser un ordinateur en temps réel. 🙂

Oui, je suis assez d'accord. Demander au copilote de vérifier ça toutes les 30" était une boutade.

Je me permets de théoriser un peu dans le but louable d'atteindre la perfection.
Justement j'avais oublié de dire que idéalement notre tripmaster_can_usb2 devrait aussi pouvoir nous conseiller quant au choix de conduite à adapter en prenant en compte l'incidence des points négatifs dus aux écarts de moyennes et à la consommation. Ce serait pas beau ça ?!
En gros le meilleur rapport moyenne/conso traduit en points.



A propos des éditions précédentes : j'ai vu passer des feuilles des résultats sur le forum mais les images sont tellement petites qu'on arrive pas à les exploiter. Y en aurait-il de plus grande taille ?

Les résultats du rallye de 2007 sont en ligne sur le site du RMCVEA.

Voir RMCVEA résultats 2007.

pour la partie tripmaster:
le plus simple utiliser un tomtom
et y installer un plugin :
http://www.webazar.org/tomtom/tripmaster.php?lang=fr