• L'Assemblée Générale du Prius Touring Club aura lieu le 7 décembre 2024 du côté de Rennes. Si vous êtes adhérent renseignez-vous ici.

data logging ELM327

  • Initiateur de la discussion Initiateur de la discussion Atlantis
  • Date de début Date de début
La frequence du relevé est liée au timer du GPS, soit un relevé toutes les 2 secondes.

La representation graphique n'est pas très aisée avec Google Earth. Mais pour la représentation des denivelés, cela peut être interessant...
 
Vraiement chouette, le mariage GPS - CANview !
Je suis également d'accord sur la priorité à donner au loging, mais l'ouverture aux données de positionnement peut servir en temps réel d'inclinomètre. Il faudrait trouver aussi un anémomètre, et on pourrait afficher en roulant les efforts liés à ces deux variables.
 
Canmonitor / Canview

bonsoir du bar basque de soustons (il y a un bon wifi)
d'abord bravo à tungsten:jap:


je pense pouvoir combiner les données du canview (original) avec les coordonnées GPS en revisitant ce que l'on peut voir sur le site de norman.

j'imagine de combiner des serveurs d'informations :
aujourd'hui, le GPS est parfaitement intégrable que ce soit un inforad V3 ou V4 ou autres.
les données OBD pourraient être fournies par le canview; par le canmonitor à base d'ELM327 ou par le CANUSB.
des données complémentaires pourraient être fournies par un anémomètre (trés bonne suggestion) ou par un capteur de pression barométrique comme suggéré par le japonais qui m'a fourni le source sur lequel travaille tungsten.

de mon coté, je revisite le parser du CAN en utilisant des "split" , je suis persuadé que cela rend beaucoup plus lisible le programme et probablement plus efficace.

également, j'étudie le développement original
je reste un peu dubitatif sur la manière de calculer les MPG dans le pgm actuel. en fait, à mon sens il faut et il suffit d'intégrer des conso instantanées exprimées en L/H.

je suis malheureusement beaucoup moins dispo ,en ce moment, sur ce projet...
à suivre
 
Cet original là, ça fait un moment que je lorgne de ce coté. Je serais ravi d'en voir un semblable dans ma Prius, et avec en prime ce petit bijou de micro-ordinateur qu'on ne voit jamais dans nos magasins.

Pour la précision des paramètres capturés en temps réel, on pourrait ajouter un module accéléromètre comme celui proposé par Elektor, qui donnerait aussi bien l'inclinaison que l'accélération du véhicule.
G module
 
recepteur GPS

J'ai un récepteur GPS sur USB celui de M...Soft, le GPS-500 Pharos, couplé au logiciel Autoroute 2007. Je suppose que je pourrais aussi récupérer les data. Le parser NMEA de Tungsten serait-il compatible ?
 
récepteur GPS :
pour savoir si il sera compatible, c'est simple:

tu notes à quel port com correspond l'interface USB; soit tu le vois directement dans autor..exp...
soit tu recherches (dans XP , tu branches le récepteur, tu vas dans panneau de config/système/gestionnaire de périphérique/ports com et tu relève le port com correspondant).

ensuite tu utilise hyperterminal pour enregistrer dans un fichier le trafic provenant du GPS.
tu branches le récepteur, tu ouvre une session hyperterminal sur le port com précédemment localisé avec comme paramètres 4800bps, pas de parité, 8 bits , 1 bit arret et tu fais une sortie fichier.
ensuite tu nous files ce fichier et le diag sera trés rapide.
je suis persuadé que cela marchera car tous les GPS communiquent par la norme NMEA, il y a toutefois une variante sur la manière de transmettre les 0 , parfois c'est 0.00 parfois 0 et parfois rien du tout.
la variante de parser que j'ai écrite devrait s'adapter à tout.
 
Le Week end a été un petit peu prolofique pour le CAN Monitor

J'ai ajouté l'enregistrement et l'affichage du levier de vitesse.

To be continued (et j'ai commencé à traduire le logiciel pour les allergiques à la langue de Shakespeare)
 
as tu inclus les courants maxi de charge et décharge?
de mon coté, je n'ai pas pu avancer...
 
module CanUsb & co

Lextronic fournit des modules intéressants pour nos besoins :
un module de conversion CAN-USB
ainsi qu'un afficheur LCD graphique USB programmable.
Et Conrad un localisateur GPS enregistreur
 
le convertisseur vendu par lextronic est le produit de lawicell, c'est le module utilisé par Attila VASS , c'est également le module utilisé par le japonais qui a dévéloppé le canmonitor original.
pour la partie GPS, un inforad coute beaucoup moins cher et peut ,(accessoirement) servir à autre chose...
 
documentation ODBH

Un lien sur des recommandations constructeur concernant l' ODBH (3 articles)
 
UDP client serveur

mon test :
un pgm d'analyse GPS qui balance en UDP des infos structurées
un pgm serveur qui écoute et les affiche

le pgm serveur a l'air trés stable
étape suivante : le tester avec 2 clients (cela tombe bien , j'ai 2 inforads)
étape suivante : le 2ème client sera l'extracteur OBD

par contre le mécanisme du client ne me plait pas car il change de port à chaque envoi.

je suis quand même optimiste sur l'approche
 
premiers test client serveur en UDP trés satisfaisant.

c' est parfaitement stable et en fait trés simple à implémenter (quand on sait comment)

ma prochaine démarche est de tester le canmonitor en tentant de communiquer à 500kbs , c'est assez pointu car il faut lui donner un ordre de changement de vitesse puis fermer le port com, en changer la vitesse, le rouvrir et recommuniquer avec le elm327 pour savoir si tout va bien....,

l'intérêt si cela marche est (peut-être) de permettre de virer tout le filtrage tournant du programme.

si ok, je tenterai peut-être de fonctionner exactement comme pour le GPS :
par un timer au lieu de caractère par caractère.
avec découpage des trames en 2 étapes:
1) extraction lignes
2) éclatement des lignes.


nota : dans mes tests actuels, j'ai descendu le timer du GPS à 1 seconde sans aucun pb.

pour celui du CAN je vais tenter de descendre à 1/5 sec (ou même moins...)

comme je n'ai pas ce WE mon portable, je vais d'abord étudier cette histoire de commutation de vitesse.
c'est un peu tordu car on va utiliser des vitesses non standards de mscommx , mais j'ai vu qqp un truc pour gérer cela.


je vais également étudier la possibilité de rendre modulaire le dev de tungsten. càd en isoler la partie collecte de données.
 
passionnant:-D
en tous cas trééééééééééééééééééééééééééééééééés pointu.

le fait d'avoir des modules séparés , permettrait à terme d'intégrer le canview .
Norman (le papa du canview) a demandé sur priuschat si qqn pouvait faire qqc de bien avec ses données et il demandait des suggestions à propos des données qu'il resort sur port série.
je vais luis suggérer d'utiliser un format comme le NMEA en plus simple mais avec quand meme le principe de générer un fichier ascii avec un caractère de synchro (début de ligne) et un caractère de contrôle en fin de ligne.
comme la ligne a un format fixe, l'exploitation deviendrait facile.
 
canmonitor & UDP

aprés qqs heures,
j'ai enfin créé une version dont le module de parsing a été refait
et qui crache en temps réel en UDP.
dans l'état actuel, c'est seulement un PoC (Proof of Concept).
cette version devrait avoir une présentation basique (sans graphiques ni calculs) notamment les calculs de mpg.


je l'ai testé avec mon module serveur, cela marche correctement : càd il reçoit des données correctement formatées.

c'est dans mon ftp , le dossier est Canmonitor_srv
nota cette version crache simultanément dans des fichiers (mise au point)

le changement de vitesse sera étudié aprés purge de tout ce qui ne servira plus.
 
gauge

partant du principe que :
  1. les pgm de collecte de données et le pgm de logging et visu sont indépendants,
  2. que les ocx pour vb6 sont chers et/ou laids
  3. il est plus facile de faire qqc de zouli avec visual studio
j'ai commencé à expérimenter le pgm de visu en VB de Visual studio 2005 avec la dll aGauge détail ici :

http://www.codeproject.com/useritems/A_gauge_part_2.asp

aprés qqs heures , j'ai enfin réussi à fabriquer cette dll et voila le premier test

http://priusfan.info/canmonitor/agauge/agauge.pdf

j'ai également balancé la sauce dans mon ftp , d'une part dans agauge et d'autre part dans le sous dossier /srvfxm/test_serveur_UDP.NET/ ; il y a même un truc de déploiement dans dep

147434a9b7f4ba.png


 
avec le truc pour gérer les "gauges", il est possible de n'utiliser que l'aiguille superposée à une image générée ailleurs:
petit exemple fait à partir de la photo d'un compteur de camry:
1474453b0538cf.png
 
Excellent Travail mon cher Priusfan...

J'ai pas mal de boulot sur d'autres projets informatiques....mais je vais essayer de consacrer un peu de temps sur la partie CAN UDP...
 
Gps

bonsoir,
aujourd'hui, 9ème jour de grève des transports, je continue donc à faire du télétravail.
j'ai donc profité du gain de temps pour remanier assez sérieusement:grin: le module de collecte du gps.
  1. je n'accepte que les trames dont le checksum est ok.(j'ai en effet remarqué ce matin lors de tests qu'il y a parfois de la choucroute et j'en ai déduit qu'il valait mieux filtrer en amont qu'en aval).
  2. tolérance tous formats NMEA.(pb du nombre de 0 ).
  3. les lat & long sont converties pour être digestes au format kml (y compris le signe).
  4. ajout des DOP.
  5. actualisation des données à chaque trame GPRMC (et seulement s'il y a du nouveau).
le module est dans mon ftp dans GPS_srv ; il annule et remplace le précédent.
 
ai fait un petit compte rendu dans section publique.

section GPS : résultat parfait
section CAN , ai fait un gros ménage

section centralisation : se contente pour le moment de centraliser.

fonctionnement UDP trés stable

échantillonnage 1 seconde ok

ensemble à jour dans mon ftp , dossier xxxx1124


20:23
ai testé le mode magnétoscope pour relire les logs.
principe jouer avec un timer :
x1 =1000 (1 sec) , x10 timer =100 etc...
les aiguilles suivent parfaitement :-D
 
j'ai contacté attila et voila sa réponse:

Bonjour François,

I also played with GPS ( driven from my PSP ) and combine with
tire rotation from the Prius to have more accurate data...

> would you share with us some info regarding:
> mpg: do we get a fuel comsumption in L/H

You can convert from KM/L L/100KM etc. from MPG :

I didn't find the exact MPG computations ( nor did anyone I know ),
but I am using the following formula which seemed at least as good :

if(ThrottleV!=0) MPG=(float)((SpeedV*SPDSCALER_MILE)/ThrottleV);
where
#define SPDSCALER_MILE 10000.0f
ThrottleV is 0x348 ( 11.3 sample/sec 0 - 33280 )
SpeedV is 0x3CA ( 4.6 sample/sec

> torque : how do you get info

I only use RPM from 0x3C8 ( 7.1 samples/s value = 0 - 26880 )

Exact torque values are not reported as far as I know, but need
to be solicited. Which means you have to send a request on the
CAN and wait for a response :
1. Send to ID 0x7e2 : 02 21 c3 00 00 00 00 00 (len:8)
2. you should get back on ID 0x7eA : 10 27 61 c3 ?? ?? ?? ?? (len 8) these are not relevant for torque
3. Now send to ID 0x7e2 : 30 00 00 00 00 00 00 00 (len 8)
And you'll get the rest of the data
ID 7ea 21 ?? ?? ?? ?? ?? ?? ??
ID 7ea 22 ?? ?? ?? ?? ?? ?? ??
ID 7ea 23 ?? ?? ?? ?? ?? ?? ??
ID 7ea 24 ?? ?? ?? ?? ?? ?? ??
ID 7ea 25 ?? ?? ?? ?? ?? ?? ??

In all those questions marks lies MG1 and MG2 RPM, torq, temp, inv temps as well as engine speed request and eng speed etc.
Play with it and observe... ;-)

Cheers,

Attila
Cliquez pour agrandir...
 
ai modifié le style de ce forum pour identifier un salon privé.

ai ajouté JaggFab aux utilisateurs de ce salon.
 
Hi all ! :jap:

Et bien je vois que vous avez fait un bon boulot de recherche !


Comme je l'ai déjà mentionné dans ce topic, j'ai déjà réalisé par le passé un logiciel de visu OBDII. À l'époque, c'était plutôt pour de la mesure de performance sportive.
Le principal point fort de cette application par rapport à ce qui existe sur le marché (ScanGauge, etc), était qu'elle compensait la faible fréquence d'actualisation des données par des algorythmes prédictifs (logique floue + PIDs adaptatifs)
J'ai aussi participé au développement d'une application de chronométrage de circuit utilisant des données GPS.

J'ai une assez grande expérience (+ de 10 ans) dans le développement d'HMI, notamment des HMI de machines industrielles à haute vitesse.

J'ai également travaillé sur des algorythmes de reconnaissance d'image, et une des idées qui me trotte dans la tête depuis plusieurs années serait de développer un système de reconnaissance des panneaux de limitation de vitesse qui s'interfacerait au régulateur de vitesse d'une voiture.

Je vais essayer de lire ce topic ce week-end, et si j'ai un peu de temps (mais malheureusement en cette période ce n'est que rarement le cas 😢 ), j'essaierai de vous aider un peu, si c'est possible, car à première vue vous maîtrisez bien vos sujets ! 😎

A++
 
Identifiez-vous ou inscrivez-vous pour participer.
Pages vues depuis le 20 Oct 2005: 316,286,261
Retour
Haut Bas