data logging ELM327

Tachymètre

un tachymètre en VB :
réalisé en utilisant les propriétés X1,X2,Y1,Y2 d'une ligne épaisse

1/ Ajouter dans MainForm :
Code: 
Dim Cadran_actif As Boolean

    If (Cadran_actif = True) Then Call Cadran_RPM.Cadran_bouge
ainsi qu'un bouton "callCadran" :
Code: 
Private Sub callCadran_click()
    Cadran_actif = True
    Cadran_RPM.Show vbModal ' affichage compteur régime moteur
End Sub

2/ Créer un autre Form "Cadran_RPM" contenant l'image du cadran et l'aiguille :
Code: 
Option Explicit
___________________________________________________________
Public Sub Cadran_bouge()
Dim gradu As Double

   '    ziguy_rpm.X1 = 3600
   '    ziguy_rpm.Y2 = 6600 ' rayon = 6600 - 3600 = 3000

        gradu = (MainForm.rpm + 90) * 3.141592 / 3000 ' angle en degrés
        ziguy_rpm.X2 = 3600 - 3000 * Sin(gradu)
        ziguy_rpm.Y2 = 3600 + 3000 * Cos(gradu)
    
        CadranRpmValue = Left$(Format(MainForm.rpm, "0000"), 3) & "0"
    
End Sub

la feuille "Cadran_ RPM" et l'image sont joints en .zip

nota:
avec cette instruction "Cadran_RPM.Show vbModal" on obtient une nouvelle fenêtre qui vient en partie masquer la fenêtre principale, et bloque ses contrôles.

Question aux spécialistes de la vitesse d'exécution du CanMonitor 500K:
Cet ajout positionné sous le timer 1 seconde ralentit-il par trop le programme, ou pourrait-on au contraire augmenter sa cadence , dans un timer à part au 1/10 éme de seconde par exemple.
 
1) Il y a un timer, déjà de 100 ms. Il s'appelle "Timer1"
2) Dans ce bout de prog Timer : dans "Private Sub Timer1_Timer()" Les auteurs initiaux font un test:
"If triptimerupdate >= 100 Then" que je n'avais pas analysé mais il revient à ne tester la suite qu'au bout de 10 secondes depuis qu'on a mis le contact ???
auquel j'avais rajouté:
"If CarStartMins <> OldCarStartMins Then 'Une minute s'est écoulée"
qui permet de calculer la conso moyenne par minute sans ajout de timer.
3) A ma connaissance les timer sont une ressource rare. Je pense, après utilisation de la version 9600k sur laquelle j'avais testé toutes sortes de temporisations, que:
-le délai n'est pas garanti
-ils interrompent (provisoirement bien sûr) le déroulement d'une autre partie du prog.
Je pense qu'ils ralentissent le prog. Mais il faut relativiser : 10 fois par seconde c'est peu.

Quand à l'aiguille sous forme d'un trait qui tourne ça évite d'installer flash. Tu peux donc déformater ton Pc :grin:
Et j'aime les idées simples comme celle-là.:-D
L'as-tu essayé ?


Par contre tu aurais un blocage, à cause du contrôle ?

Du coup tu me fait découvrir qu'il y a un 2ème timer pour le Gps de 2,05 secondes...

A+ ;-)
 
J'ai fait tourner ce cadran pendant quelques heures sans le moindre problème ni en temps réel ni apparamment dans les tableaux de log. Mais je n'ai pas vérifié si il y avait des sauts dans la progression du timer enregistré.
simplement, là ou il est appelé, on voit bien des saccades de l'aiguille dans les changements rapides. reste à savoir si ils sont dûs à un cadencement insuffisant, ou si si c'est inhérent à l'acquisition du rpm. c'est pourquoi je pense intéressant d'augmenter sa cadence en lui donnant un timer à lui tout seul.

« Par contre tu aurais un blocage, à cause du contrôle ? »
non, , simplement je ne maitrise pas l'instruction "Cadran_RPM.Show vbModal ".j'ai essayé "vbModeless" sans succès. je n'ai pas trouvé le moyen d'incruster le cadran dans la "mainform" en conservant les accès aux boutons comme "Arrêter". il me faut fermer la fenêtre "cadran" d'abord.

@ planétaire : j'aimerais connaître précisement le coef que tu appliques actuellement pour passer du produit [ fuel inject(pid520) x rpm(pid348 ) / speed(pid0B4) ] à la conso en litres aux 100 km.
Je concocte une moyenne glissante sur la dernière minute (qui effacerait les pics qui effraient les débutants !) , et je ne sais pas si je vais trouver le même résutat que toi.

ps: le coup du programme qui plante quand tu manoeuvre le "shiftlever", j'en ai connu un plus bolide avec Priusfan, du EeePC qui en glissant légèrement sur son support, fait passer en mode "N". avec celui-là il y a un moment de perte de confiance dans la Prius, le trou !
 
Calculs de conso

Comment sont calculées les conso en litre et litre/100km:

Ça se passe en deux temps.

-Au passage N par le pid 520 et même action pour le pid 3C8, 3CA (*) il y a mémorisation d'une valeur (OldSp95) qui est le produit de l'injection par les tours/mn.
Si on est dans le 520 c'est le produit de l'injection "actuelle" par le dernier nb de tr/mn connu.
Si on est dans le 3C8 ou 3CA c'est le produit du nb de tr/mn "actuel" par la dernière valeur d'injection connue.

-Au passage suivant dans ces pid cette valeur est multipliée par le délai écoulé depuis le précédent passage (en millisecondes) et on cumule ainsi ces petits produits dans ConsoSp95.
Ce cumul est un volume de carburant.

Pour avoir des Litres diviser ConsoSp95 par: 1 296 000 000 000.

Pendant ce temps on cumule la distance parcourue en mètres selon un principe également à 2 temps:
-passage N dans le pid 3CA on note le temps en millisecondes et la vitesse
-passage suivant on multiplie la vitesse du précédent passage par le délai entre les 2 passages. On a une distance.
Celle-ci est cumulée dans DistanceTot.

Pour avoir des mètres diviser DistanceTot par 3600.

A partir de ces 2 cumuls tous les autres calculs sont possibles.

Il suffit, pour par exemple avoir une conso par minute, de mémoriser ces 2 valeurs au début de la minute, effectuer 2 soustractions en fin de minute (conso et distance) et obtenir des millilitres consommés sur une distance et pendant une durée d'1 minute.

(*) Le 3C8 et 3CA remontent à l'époque où le prog n'utilisait pas le 0B4. Un point à améliorer, donc. Mais prudence celui-ci est + rapide et on risque d'avoir des erreurs en cumulant beaucoup plus de plus petites valeurs.

Avec cette méthode de calcul peu importe si les timer sont bien réguliers puisqu'on mesure le temps qui s'écoule entre chaque passage. D'autant plus qu'il est important de noter qu'on reçoit des grands paquets de pid (toujours en retard avec l'évènement) puis on rend la main à windows et au "pilote de l'elm" puis de nouveau un grand nombre de pid. C'est comme des salves et entre deux salves la durée écoulée est "grande à l'échelle de calcul du prog en VB".
Ça doit être les saccades que tu vois et donc interrompre par un Timer ne changerait rien car tu n'est pas maître de l'instant où tu reçoit les valeurs de Rpm.

A propos de sacades il FAUDRA lisser l'affichage des ampères. Au dessus de 60 km/h il y a comme un cycle charge/décharge qui est néfaste. On ne sait plus si on charge ou décharge (quand les Ampères sont faibles).


Quand au coup du passage en mode N j'ai donné aussi, au début mon Pc avait glissé sur sa tablette dans un virage :grin: C'est alors plusieurs longues secondes d'intense réflexion lorsque plus tard on veut réaccélérer (dans une côte dans mon cas) et qu'il ne se passe rien. Mais c'est plus possible maintenant.

A+ :dactylo:
 
chalut
je pense que mettre cette aiguille dans une Form n'est pas souhaitable du tout, il vaut beaucoup mieux la mettre dans une PictureBox.
en effet gérer simultanément 2 forms ,dont une seule peut être active à un instant donné, est drôlement tordu (et bonjour les pertes de focus).

en ce qui concerne le moment d'afficher un compteur, cet évènement doit etre géré de manière asynchrone (il faut oublier les timers).
pour des raisons d'efficacité , c'est seulement quand on constate une différence significative , par exemple 2% , entre la valeur affichée et la nouvelle valeur que l'on procède à une actualisation.

enfin
pour lisser les valeurs et éviter les saccades, une formule (trés classique) est de mixer 20 ou 25% de la nouvelle à la valeur précédente.
cela pourrait s'écrire dans le cas des rpm:
en utilisant les variables
rpmn rpm new
rpma rpm affiché

rpma = (rpmn + 4 * rpma ) / 5
 
si tôt dit si tôt fait, je l'ai réintégré, l'aiguille et son cadran dans une Picturebox. ça fonctionne de même. et j'ai ajouté le test sur l'évolution à 5%.
je teste demain

j'aimerais, planetaire, que tu me dise si je fais bien de déplacer la mise à l'échelle de 1/170 de l'injection pid520 directement dans sa case d'acquisition, avec l'offset de 85, et le forcage à zéro en cas d'arrêt moteur. et que de cette façon, la constante du chef pour la conso passe à 3600/170 = 21.17. l'ai-je bien descendu ?

sur les 3 ajouts de conso que tu as installé, (dans les pid 3C8, 3CA, 520), j'ai mis en plus un cumul de tous les ticks pour voir ce qui va manquer au final sur chaque seconde.
 
Le pid520 est enregistré dans le csv brut de lecture. Je souhaite garder la compatibilité avec tout l'historique et toutes les courbes déjà tracées.

Par contre oui, la question se pose car les calculs de conso sont actuellement effectués avec le pid520 brut sans retrait des 85 (0,5ms).
Cette valeur est multipliée par les tr/mn. A priori valeur un peu + élevée que la réalité, donc. Mais on fait ensuite une soustraction. Si le nbre de tr/mn n'a pas changé le résultat est idem. S'il a changé il y a un pouième de différence entre le calcul en tenant compte du 85 ou pas. Tantôt dans un sens et tantôt dans l'autre selon qu'on accélère ou ralentit.

D'une manière générale j'ai conservé les valeur des pid en effectuant des divisions, soustractions tardivement.
En effet il faut se méfier des endroits où le prog travaille avec des nombres entiers.
Il y a alors perte d'info. C'est pourquoi j'utilise des virgules flottantes de + en +.
Dans ce cas il n'y a pas perte de précision mais juste augmentation du nombre de calculs effectués (on ne sait pas quand pourrait se produire une éventuelle saturation du Proc)

Lors de mon dernier plein j'ai effectué la vérif suivante sur 1227 km et 50,5 litres (d'après la Prius et la pompe):

Dont une estimation de 56 km (peut-être 58 à 4,6 l/100) effectués par mon épouse, donc sans le Pc, j'arrive à 4 km de moins et 1,1 litre de moins selon le Pc.
Donc Le pc+56km donne 1223km et 49,4 l (Dont 2,57 pour les 56km).

Différence: -0,4% sur le km et -2,2% sur la conso.

Mais ce n'était pas la même pompe, à mon avis un peu plus de pente vers l'avant ce qui a permis de remplir un peu +.

Parfait sur les km, sur la conso c'est déjà exceptionnel que j'ai pû faire la vérif (on est deux à utiliser la Prius). Il faudrait le faire sur plusieurs pleins...

Sur le cumul des ticks, je ne pense pas qu'on puisse perdre de ms car dans chaque intervalle on reprend comme début la fin du précédent, sans perte possible de ms. Donc raccourcir ou rallonger chaque intervalle de mesure ne doit pas changer le cumul des ms. Mais le vérifier c'est mieux.
A priori plus on a d'intervalles et + on est précis.


P.S. Il y a une convention concernant les variables: tout code-variable dont le nom se termine par "value" est celle affichée dans un contrôle.

A+ ;-)
 
Je vous soumets quelques reflexions et travaux appliqués au CanMonitor:

1/ Suivant une suggestion de Priusfan (faite à propos de GraphCan) sur les difficultés de repèrage des variables, j'ai entrepris une normalisation des noms de variables avec en préfixe leur type informatique et leur origine, et en suffixe leur unité physique. (des exemples dans les extraits ci-dessous)

2/ Pour continuer dans ce sens, j'ai également essayé d'expliciter les différentes constantes de conversion utilisées, en particulier pour calculer le rendement du thermique, et ajouté la valeur d'injection "calibrée" en millisecondes, en plus de celle en valeur brute.

Code: 
constantes de conversion : rpm > radian/seconde , injection > ms , rendement
Const rpm2rds As Single = 3.141592 / 30 ' = 0.1047
Const kmh2mps As Single = 3600 / 1000 ' = 3.6
Const scaled520 As Byte = 170 ' unités par ms
Const offset520 As Byte = 85 ' unités pour un offset de 0.5 ms
Const Sgl_Rendemt_coef As Single = (388 / 170)  ' env. 2.286

ce dernier, issu de la formule [ (Couple/Inject)*(3.14*360000*100)/(30000*9,7) ] tient compte de la conversion préalable de l'injection en ms

Code: 
 If Cdn3C8_RegimeICE_rpm = 0 Then ' le Pid520 ne s'efface pas, au lieu de zero il n'est plus émis...
     Sng520_injection_ms = 0
 Else
   If (Cdn520_injectim_raw < offset520) Then
         Sng520_injection_ms = 0
   Else
         Sng520_injection_ms = (Cdn520_injectim_raw - offset520) / scaled520
   End If
 End If

Puissance développée par le thermique ,utilisant le paramètre CoupleTh.
(avec les réserves que j'ai déjà émises concernant l'authentification de ce paramètre comme valeur réelle du couple)
Code: 
    Sgl_PowerTh_W = CSng(Can039_CoupleTh_Nm) * Sng348_ToursICE_rpm * rpm2rds  ' Watt = N.m * radian/s

Rendement du thermique : énergie utile / énergie fournie (formule indépendante du régime moteur)
rappels : puissance (Watt) = Couple (N.m) x vitesse de rotation (radian/seconde)
: énergie (Joule) = puissance (W) x temps (s) = Couple (N.m) x Angle (radian)
application : on calcule les énergies consommées et disponibles par tour de moteur
énergie utile disponible par tour moteur = Couple (N.m) x 2 pi (radian)
énergie fournie par la combustion du volume d'essence injecté durant un tour moteur
= durée d'injection(s) * calibrage(L/s) * 9700(W/L) (avec 9700 W par litre de sp95)
avec un calibrage estimé des injecteurs à 0.284 L/s = débit d'essence fourni par les 4 injecteurs
d'où une formule compilée pour ne conserver qu'un seul coefficient de multiplication :
rendement = Coef (ms/W) x CoupleTh (N.m) / durée d'injection (ms)
avec Coef = ( 2 pi x 1000 ) / ( 0.284 (L/s) * 9700 (W/L) ) = 2.28 (ms/W) (idem 388 / 170)

Code: 
     Rendemt = Sgl_Rendemt_coef * CSng(Can039_CoupleTh_Nm) / Sng520_injection_ms

Rendement énergétique instantanné en Watt.Heure par kilomètre parcouru
= puissance fournie (W) x temps de parcours (hr) / distance parcourue (km) = puissance (W) / vitesse (km/h)
avec : puissance fournie (W) = CoupleTh (N.m) x Régime (tr/mn) * pi/180

Code: 
If (Cdn0B4_accuSpeed_dmh > 0) Then
    Dbl_Energetic_Whkm = CDbl(Can039_CoupleTh_Nm) * (Dbl_348_ThrottleICE_rpm * rpm2rds)
    Dbl_Energetic_Whkm = Dbl_Energetic_Whkm / (Dbl_0B4_accuSpeed_kmh)
note : formule corrigée au niveau des coefficients de conversion

3/ interrogations sur l'usage du type "Double"
il me semble qu'au niveau de la précision, on peut se contenter des type "Integer" en fixe et "Single" en flottant.
je ne sais pas ce que ça apporte comme ralentissement d'utiliser les conversions "CLng, Csng, Cdbl" sur des fixes, au lieu de créer des variables en "Double" dès le départ.
 
Avis de recherche :
N'auriez-vous pas vu passer, durant vos recherches concernant le bus CAN et le CanMonitor, un paramètre de mesure de la pression atmosphèrique ?

On est en droit d'attendre d'un système de gestion d'un moteur thermique , qu'il se préoccupe de cette information, et qu'elle soit numérisée. Mais où ?
 
En ajoutant le Pid 023 aux acquisitions de CanMonitor, j'ai vérifié qu'il y avait bien deux capteurs d'accélération longitudinale fournissant des informations différentes :


log sur 4 minutes en ville avec vitesse (rouge-violet) et altitude GPS (vert-bleu) en regard.

Les deux capteurs sont probablements couplés à angle droit et positionnés symétriquement par rapport à l'axe longitudinal, un à 45° vers le bas, l'autre à 45° vers le haut.

Il se pourrait qu'on en extraye à la fois et séparement l'inclinaison du véhicule (composante "accélération de la pesanteur") et la force d'accélération/freinage. Il faut que je re-potasse le doc indiqué par Priusfan. pour l'instant, ce que je vois c'est du bruit, et d'autre bruit aussi en essayant d'extraire les dérivées de vitesse et d'altitude GPS. pas simple.
 
Une petite remarque suite à un plantage (du Pc) en roulant: division par zéro. Là je m'en suis sorti par une copie d'écran récupérée après arrêt, car le message est minuscule, et en roulant illisible.

La cause est, je pense :
Le fait de retirer 85 au paramètre Pid520 peut mener à une valeur nulle.
Bien que ce Pid navigue habituellement largement au dessus de 300, lors des arrêts il peut, manque de bol, valoir 85.
Donc tester avant de diviser par (Pid520-85)

A+ ;-)
 
Nouveau projet de CanMonitor, avec histogramme.
167149d7477909e4c.jpg


Cet histogramme peut afficher ce qu'on veut. Ici c'est la conso pour chaque minute.

Au fait je pense essayer d'autres affichages, mais ne sais pas comment récupérer la frappe d'une touche clavier dans VB ? Priusfan le sait-tu ?
Je pensais soit la frappe de la touche espace (large et facile d'accès) soit la touche F1, donc une touche très facile à atteindre en roulant (voir n'importe quelle touche, au début on peut faire un changement circulaire entre quelques valeurs à afficher).
J'aurais aussi préféré que les pointillés restent au-dessus des pavés bleus.

Pour cet histogramme, 30 picturebox que l'on redimensionne à l'exécution, tout simplement. On peut même mettre un bitmap dans chacun, mais ça va + occuper le proc. Et avec eeePc ??

Il ne reste que 6 bargraph (qui pouraient être aussi des picturebox redimensionnés dynamiquement) et encore le bargraph température batterie risque de dégager aussi, je n'en ai pas d'usage en conduisant.
J'ai ajouté la dénivelée depuis le départ, instructive et fort importante pour expliquer certaines consos.

Les litres/heure tels que décrits sur Priuschat me semblent faux et ne sont plus affichés, seulement écrits/csv. En effet on devrait avoir égalité à 100km/h réels entre l/h et l/100km ce qui n'est vrai que vers 90 km/h.
De plus au démarrage à froid ce paramètre est faux ce qui engendre un décallage variable (selon la température initiale) quand on compare sur de grands trajets la conso selon 2 Pid l/100 (520h) et l/h.

Pour cet essai l'histogramme défile de la gauche vers la droite, le contraire de l'odb de la Prius. Je ne sais que préférer.

A+ ;-)
 
pour gérer les touches clavier , ya ka demander , voici une recette garantie opérationnelle.

Code: 
[COLOR=DarkGreen]au début :[/COLOR]
Private Sub Form_Load()
[SIZE=4][COLOR=Blue][B]Me.KeyPreview = True[/B][/COLOR][/SIZE]

[COLOR=DarkGreen]puis une routine :[/COLOR]
[COLOR=Blue]Private Sub Form_KeyDown(KeyCode As Integer, Shift As Integer)
If KeyCode = vbKeyF1 Then  ' F1
    ....................................
End If

If KeyCode = vbKeyF2 Then  'F2 
   ...................................
End If 

If KeyCode = 32 Then   ' gestion barre espace
          Unload Me ' par exemple , fin du pgm
End If

[B]KeyCode = 0[/B]
End Sub[/COLOR]
TB le graphe , reste à préciser axe des abscisses kM ou Temps et unité sur axe des ordonnées.
TB l'idée de changer le type de graphe en cyclique par appui sur barre d'espace, c'est très accessible.
 
Première approche pour définir des groupes d'infos. Donc deuxième projet tout chaud de ce week-end.

IMAGE RETIREE, C'ETAIT UNE VERSION PROVISOIRE.
Veuillez voir plus loin dans un autre message sa remplaçante.


La partie utile fait presque 1024x600. Juste un poil trop en vertical. J'ai pas réussi à retirer le titre de la fenêtre, sinon ça serait bon.
(J'ai un peu réduit la taille de la copie d'écran (90% de réduc) pour rester sous les 1280 en jpg.)

1) En haut-gauche c'est l'exception : les infos les + utiles pour conduire
dont l'altitude fort utile pour les glides sur faux-plat (on se trompe facilement quand la pente est faible jusqu'à croire que ça monte quand ça descend et vice-versa)
2) Groupe thermique
3) Groupe pédales qui agissent sur le groupe du dessus et du dessous
3) groupe électrique

plus loin du regard
4) A droite des stats
4) Histogramme

A prévoir : échelle non linéaire pour les ampères et la pédale d'accélérateur.

A+ ;-)
 
superbe !!!

pour virer la bordure, au niveau du Form, tu mets la propriété "BorderStyle" à 0-None.
mais comme cela fait gicler la croix d'arrêt, il est nettement souhaitable de gérer les touches clavier et de sortir du pgm par F4 par ex...

tu peux virer les infos GPS, en gardant seulement une loupiote clignotante pour montrer l'activité.
 
J'ai utilisé ce codage pour l'accès par le clavier, en créant un "TextBox" "ZoneClavier" dans un coin de l'écran, ce qui permet de n'activer les frappes clavier que si le pointeur souris est cliqué sur ce rectangle. sinon il est inactif.
Code: 
' appels d'affichages depuis le clavier à partir d'une zone de texte focus souris
Private Sub ZoneClavier_keypress(KeyAscii As Integer)
    
    Select Case KeyAscii
    
    Case Asc("h") ' help
    
    Case Asc("m") ' master trip
        Call TripSetup_click
    
    Case Asc("b") ' répartition puissances
        Call ActiveMPower_click
    
    Case Asc("n") ' nomographe
        Call ActiveNomo_Click
        
    Case Asc("v") ' tachymètre
        Call ActiveCadran_click
                
    Case Asc("o") ' quit
        Call CloseCANPort
        
    Case Asc("p") ' start
        Call OpenCANPort
    
    Case Asc("s") ' setup
        SetupForm.Show vbModal
    
    End Select
        KeyAscii = 0
End Sub

J'ai également ajouté un timer pour fractionner les fichiers logs de manière à tenir le rallye san pb (un fichier sur une heure contient environ 32000 lignes). Je perds en moyenne 1 ligne (1/10éme de seconde) lors de la transition.

Code: 
Private Sub TiMinute_Timer() ' interval = 60000
Static Horo As Integer

' Changement régulier (base horaire) de fichier de log afin d'éviter la saturation
    Horo = Horo + 1
    If Horo > 60 Then Horo = 0
    If Horo = 60 Then
        Call WriteCloseCSVFile
        Call WriteOpenCSVFile
    End If
    
End Sub

autre observation à propos du log gps : ça ne sert à rien d'enregistrer ces infos chaque 1/10 s vu qu'elles ne sont rafraîchies que toutes les deux secondes. un fichier indépendant incrémenté à cette cadence me paraîtrait plus efficace.
 
Version un peu plus aboutie.
167149dcd4f22cd13.jpg


Là les données sont entièrement simulées.
Il y a enfin le quadrillage au dessus de l'histogramme.

Le test des touches clavier marche parfaitement. Il ressemblait tellement à son équivalent dans d'autres languages que j'ai déplacé la remise à zero de la variable touche uniquement si on l'a utilisée. Si on n'y touche pas Windows la traite alors, ce qui est le cas du alt_F4 par exemple.

Par contre la bordure fait de la résistance même avec le param à 0.

La zone Gps reste encore là parce qu'il faut avant de la retirer caser les boutons démarrer et config ailleurs.

En un mot c'est pas facile de tout caser correctement.
A suivre mais je ne sais quand, faire plus joli. Des icônes par exemple...

A+ ;-)

P.S Le nombre sur fond violet a l'air délavé. C'est la compression jpg qui l'a fait ! Y'a rien à gratter là.

@Mik&Toy Pour le rafraichissement du Gps oui c'est toutes les 2 secondes mais un fichier à part pose le problème de la re-synchronisation dans le tableur. Les fichiers logs (csv) sont de toute façon automatiquement coupés à 65000 lignes.
 
j'ai repris ta remarque sur le pid 038.4 L/H en le comparant au résultat de la multiplication du Pid injection (après correction de 0.5s et suppression des valeurs maintenues lors de l'arrêt du thermique) par le Pid régime. Il y a bien quelquechose de commun, mais il y a beaucoup trop de dispersion pour que ce soit ce paramètre. Une valeur de pilotage sûrement.
j'ai aussi comparé les résultats du calcul de la conso (quotient des L/H calculés précédement par la vitesse) entre celui fait en temps réel et celui refait à partir des logs. c'est pas tout à fait identique :
131049da3fcbde41a.png


ps : pour l'histogramme, je crois qu'on peut accepter des barres moins larges, et donc plus nombreuses.
de mon coté, j'ai réalisé une moyenne glissante sur la dernière minute, avec l'idée de la tracer.
 
Comparaison conso.

1) Il est normal que la comparaison entre calcul de conso en temps réel et le même effectué d'après le log soient légèrement différents.
La raison est que le calcul en temps réel utilise une mesure du temps en millisecondes qui n'est pas mémorisé dans le log. Dans le log les millisecondes sont celles de l'instant de l'écriture dans le fichier (GetTickCount), légèrement en retard avec l'instant du calcul.

Par contre le cumul consommé sur tout le trajet reste forcément identique.

2) On peut rétrécir les barres de l'histogramme sans problème. Mais peut-être pas dès le début. Il faut déjà attendre 1/2 heure avant de remplir toute la largeur. Peut être passer à 60 barres au bout d'1/2 heure ?
Ou alors, comme pour la P3, ajouter l'historique du trajet précédent dans une autre couleur?

3) A propos d'historique. Maintenant que le prog est bien stable et que les conso sont probablement très proches de la réalité, il serait intéressant de conserver des historiques des trajets précédents. Pourquoi pas créer un petit fichier qui serait la synthèse des trajets (un enregistrement par trajet) permettant d'avoir des cumuls, par exemple, sur un plein. Ou les 30-60 dernières minutes ?

4) Dernières modifs faites: échelle non linéaire sur l'accélérateur (avec loupe sur les 5 premiers %), idem pour les ampères (avec loupe sur -10 +10A). Ajout de deux bitmap : photo d'un moteur thermique et d'une batterie. C'est + joli.

A+ ;-)
 
oui, trés bien, conserver les logs du trajet précédent pour ne pas redémarrer à zéro à chaque départ, et in extenso pour la conso et le kilomètrage.

Pas certain que les cumuls soient identiques car il s'agit de produits/quotients de trois paramètres très variables et pas d'un seul.

Quand au pilotage à partir du GPS, ce délai de 2 secondes est très trompeur. déjà dans les carrefours en patte d'oie pour indiquer la bonne sortie, on doit attendre qu'il se stabilise, mais pour l'altitude là, je suis plus que dubitatif sur la possibilité de contrôler l'accélérateur.

Et alors sr la PIII, sur l'écran, ce ne serait que la position de l'accérateur pour faire des économies ?
 
J'ai actualisée la capture d'écran dans le message #244.
Avec deux bitmap de la Prius 3 et ajout des ampères max en charge/décharge.

Au sujet du Gps, il a du mal surtout quand on tourne et en ville. Par contre en campagne l'altitude varie assez correctement. J'hésitais même à en déduire la pente de la route en %.

A+ ;-)
 
PriusCanMonitor

Dernière version du prog.

-écran dimensionné à 1024x600
-conserve l'historique du dernier trajet et l'affiche systématiquement dans le bas (en bleu clair) puis il glisse vers la droite poussé par le trajet en cours;
-conserve et affiche la conso moyenne depuis ... quand on veut (*)...par exemple le dernier plein.
Tout simplement au démarrage la conso en l/100 en haut à droite est cette moyenne,
-lisse les ampères (les 50 dernières valeurs ont été nécessaires)
-affiche les ampères maxi charge/décharge sous le bargraph des ampères (ici 114A et 105A)
-échelles "exponentielles" de : accélérateur et ampères_batterie.
-affiche les kW (ou watts pour la batterie si <500w) thermique et accus,
-mémorise une synthèse de chaque trajet dans le petit fichier trajets.csv dans le but de les afficher dans l'historique, .. pour + tard.
(Durée en secondes cumulée, conso en litres cumulée et distance en mètres cumulée)
-La région du gps a été retirée, seule subsiste l'altitude et le mot "altitude" est de couleur différente selon le nombre de sat (même couleurs qu'avant pour le mot "sat")
(Ici il est en vert: il y a suffisament de sat)
167149e4c8006a59a.jpg


(*) actuellement il faut, par exemple, déplacer le fichier trajets.csv pour réinitialiser les cumuls ou bien les modifier directement.

Jeu gratuit: Il y a eu un petit montage dans paint. Cherchez l'incohérence qui le prouve..

Et pour le style vous avez reconnu le thermique et la batterie de la P3 ainsi que la logique de l'historique, (mais inversé gauche/droite).

A+ :photo:
 
question technique :
Si il est préférable de faire apparaître des cadrans dans des "picturebox" plutôt que dans des "Form" , peut-on néanmoins basculer l'ensemble du "MainForm" et le remplacer par un autre écran complet d'une autre manière que de lui coller une "picture box" qui prenne toute la surface.
 
Identifiez-vous ou inscrivez-vous pour participer.
Pages vues depuis le 20 Oct 2005: 314,211,586
Retour
Haut Bas