Reprise du message précédent :
ca marche impeccable,
exactement ce que je voulais  
il ne manque plus qu'un tableau de bord allégé, voir configurable à volonté, (avec les compteurs qu'on veut)
pour que tout soit parfait!
merci pour ton boulot, c'est vraiment bien!

Je m'ennuyais en cours de robotique, alors j'ai couché sur le papier la mesure de puissance/couple temps réel en évolution continue avec correction de puissance potentielle par GPS, et par conséquent les formules pour le rendement énergétique du moteur D'ici peu je pense que je vais pouvoir sortir mes premières patatoïdes d'isorendement

 
euh, et traduit en Francais, ca donne quoi?  
 
sinon, est-il possible d'integrer un bouton "pause" pour la lecture du graphe et la vue compteur, histoire de pouvoir synchroniser plus facilement avec une vidéo?

Ok, j'y penserai.
En français ça veut dire que je vais faire marcher l'indicateur de puissance, et que je pourrais sortir les courbes d'isorendement énergétique du moteur (en gros histoire de dire dans quelle plage faut rouler pour être le plus économe).

J'ai commender un recepteur GPS, je vais bientot pouvoir tester ca !!  
 
Petite note ( j'ai trouver des DV pour l'essai d'incrustation video, c'est vraiment niquel en fluidité !! )

---------------
envoi PROUT au 82600
Pour RICO envoi morue au 82700  

Faudra aussi que j'uniformise la capture gps avec la capture obd un de ces 4.

 
c'est quoi comme récepteur, ca m'interesse aussi
 

un tracé du trajet, avec un point qui se déplace, le tout sur le même écran que le tbd et le graphe, je réve  

C'est le prochain point prévu

je sens que je ne vais plus te lacher

http://www.expansys.fr/p.aspx?i=140985 pour le gps  

Moi je vais suivre ca de très très près

Je commence à m'occuper du tracé du trajet ce soir.

Ca avance Maintenant la partie GPS est entièrement fusionnée avec la partie OBD, la gestion des circuits/routes est en cours ...

S'en suivra chronométrage GPS, puis calcul de puissance puis calcul de rendement.

 
parfait, ne relaches pas ton effort  
n'oublies pas de faire une version configurable, pas que ce soit trop "usine à gaz"
 
 
(par ex. moi, je me fous de la conso, de la puissance, couple charge, ainsi que de la t°admi et pression turbo)
 
pour que l'écran reste lisible, il faut qu'il n'y ait pas trop d'info. compteur, compte tours (pas trop grands) graphe et tracé GPS me suffirait largement
l'idéal serait évidemment de pouvoir choisir ce qu'on veut voir apparaitre

kawah c'est quand ton prochain passage sur le nurb ? Histoire que je puisse jongler entre codage de ce soft, un autre et mes partiels.

au printemps, t'as le temps  

Un logiciel typé comme ceux des formules 1 fin du HS  

---------------
http://critique.forumactif.net ( ouvert )
 
Je m'en moque de la crevette Sebi71.

Et encore coco t'as rien vu, tu verras quand ce sera fini

 
Ok j'attend avec impatience.  

---------------
http://critique.forumactif.net ( ouvert )
 
Je m'en moque de la crevette Sebi71.

.
 
+1

Up pour cozim !  
 
Je suis en train de faire un truc a peu prés similaire avec integration des données moteur ds une video temps reel, j'aimerai bien pouvoir mettre le tracé du circuit mais je t'avoue que je seche un peu sur la representation graphique, moi et la geometrie Aurais tu une astuce niveau programmation pour dessiner la courbe sur un plan !
Je te remercie d'avance !

---------------
envoi PROUT au 82600
Pour RICO envoi morue au 82700  

Ca dépend quel objet de représentation tu utilises. Moi j'utilise un composant de type bitmap qui autorise les modifications pixel par pixel (changement de couleur) et tracer des lignes colorées. Après je vais une conversion "arbitraire" coordonnées GPS->pixel (je transforme "l'heure" de longitude/latitude en un truc décimal, base 10 normale et je normalise). Bien sur je prends que les coordonnées X/Y. Pour les projections perspectives issues d'une représentation 3D, on verra quand j'aurai trouvé comme utiliser des matrices en C++ Ce qui ne saurait tarder ...
Tiens moi au courant ton projet m'intéresse

je reveille un peu le topic, plus de nouvelles?  

Pas trop eu le temps entre la fin des cours, un projet prioritaire à avancer et le début du stage ... Je sais même plus où j'en étais
Rappelle moi juste quelle était la version minimaliste qui t'intéressait ?

 
Bah pour la mise à l'échelle c'est pas compliqué
Pour l'incrustation oui c'est assez chaud, et je fonctionne principalement sous borland c++ builder, et c'est quasi impossible à faire fonctionner. La seule chose que j'ai réussi à faire jusqu'à present c'est récupérer le flux preview de ma carte TV. Bon me concernant je continue pas cette piste, c'est juste histoire de faire un petit démonstrateur, ça vaut bien de passer quelques minutes sous premiere pour faire une vidéo, comme de toute façon je vais pas faire de capture en temps réel.
 
Sinon concernant les formules, ce que j'ai dans mes softs c'est 100% dérivé de la mécanique newtonienne, tu peux tout faire avec les trucs basiques de terminale S. Pour le reste c'est un peu de chimie/physique simple. Pour la mesure de puissance pareil, c'est méca newtonienne peut-être plus compréhensible avec le cours de physique prépa PCSI jusque année scolaire 02-03 (changement de programme après, disparition des notions de couple/inertie de solides en rotation), SI de PCSI pour les élements de frottements solides et physique de PSI (voire PC) pour les éléments aérodynamique (mécanique des fluides). Me concernant je ne me suis pas référé à ces cours directement, j'ai fait un bilan des forces comme on fait en terminale. J'ai appris quelques trucs sur le tas sur FA, et pour finir j'ai affiné le formalisme en raisonnant en terme de puissance.

Ok, je te remerci pour les info.
J'ai effectuer quelques recherches cette aprem et j'ai degoter ca (c'est un post de forum )  
I'm trying to calculate a vehicles bhp based on acceleration.  
I'm using RPM time stamped in milliseconds.
 
Tire Dia= 0.62738 meters
R&P= 3.23
3rd Gear= 1.66
Mass= 1500 Kg
 
Wheel speed= Engine RPM/(R&P*Gear)
Velocity= WS*Tire Dia*0.0523598
M*(Dia/2)*1000*((v2-v1)/(t2-t1))=Nm
Nm*0.001341022/5.3618= Ft.lbs
Ft.lbs*RPM/5252=hp
 
Alors plusieur truc me chiffone, comme le R&P , kezako ?? ( jai beau me casser les neurone ) , le reste je pense comprendre un peu. Je pense qu'il faut aussi ajouter le coefficent dyno et les perte du a la transmission et au friction de pneu et de penetration dans l'air . Suis je sur la bonne voie ?
 
Edit:
Apres googlage, R&P serait le ratio Ring & Pignon.
 

---------------
envoi PROUT au 82600
Pour RICO envoi morue au 82700  

à vue de nez, c'est le rapport de pont

rapport conique ?
 
------
 
suites des recherches !  
 
velocity =  displacement/time (m/s )
acceleration = ( v2 - v1 ) / t (m/s²)
average acceleration =  (v2-v1) / (t2-t1)
force = mass * acceleration ( n )
POwer = force * velocity OU work / time  
work(nm) = force * displacement =  mass * acceleration *displacement
so .. P = (mass * accel * displacement ) / time  
 
ou pour notre cas .. work= (POwer * 5252) / RPM
ou HP = (work*rpm)/5252
 
Reste a calculer le displacement en fonction du temps ecouler, du rpm, du rapprot de boite, et du  diametre de la roue ..
 
reedit :
 
vitesse du vehicule a 1000 tours :
vc = (Ct * Ve) / ( Grv * Grd ) = ( Pi * diam * rpm ) / ( rapport de boite * rapport du differentiel)
 
distance pour 1 RPM : d = Ct / (Grv * Grd) = diam * Pi/(Grv * Grd)
 
( me demande bien a quoi sert l'equation Vc  )
 
en soustraiant les rpm et le temps on devrai pouvoir avoir le displacement
exemple ( avec les données voiture du post forum et des donné moteur bidon )  :
1.145 sec 1450 rpm
1.340 sec 1620 rpm
d pour 1 rpm = 0.62738 * 3.14 / ( 1.66*3.23 ) = 0.367 m
soit 1620-1450= 170 rpm soit 170 * d = 62.4m en 0.195s
Apres je pense qu'il faut extrapoler la valeur sur 1 seconde non?

---------------
envoi PROUT au 82600
Pour RICO envoi morue au 82700  

  peut-on avoir cette version pour que je puisse l'essayer avec un globalSAT GPS bluetooth et un mobydic 3200 bluetooth ? Merciiiii  

Pour le moment rien de tout ça n'est fait. La gestion GPS et la gestion obd sont encore parfaitement découplées.
Néanmoins : http://sites.evc.net/cozim/telegpsobd.zip

N'empeche, OBD + GPS + Accéléromètre, ça commence à faire une solution sacrément complète, si je faisais des sorties sur circuit je pense que je serais carrément plus motivé
Au fait, faut que ton GPS soit compatible NMEA pour que ça fonctionne.

  "NMEA-0183 output protocol" ( j'espère juste qu'il y a assez de ports COM déclarés dans ton inferface   ).

C'est bon La couche windows que j'utilise peut gerer 10 COM.

Je suis en train de moderniser / fiabiliser un véhicule ancien V6 3235cc produit en 1974. Donc pré-ECU et pré-OBD.
 
J'ai fait des acquisitions de données concernant l'allumage (capricieux) et la pression d'essence (instable - vapour lock) via DAQFactory http://www.azeotech.com/ncreatingscreens.php et LABJack U3 http://www.labjack.com/labjack_u3.php mais je voudrais passer en numérique.
Je m'apprête à faire des acquisitons portant sur la carburation via installation de plusieurs sondes O2 BOSCH LSU4 et via installation de plusieurs sondes de température PT200 , dans les échappements.
 
J'estime que pour des raisons de sécurité et de fiabilité (calage - déréglage), il faut virer l'allumage d'origine (bobine, rupteur, vis platinées, rotor) et passer à un waste-spark, peut-être le FORD EDIS-6. Je n'ai pas de solution au problème de fuel vapour lock (calage systématique après 2 minutes lorsqu'on redémarre le moteur bien chaud), dès lors j'envisage le remplacement du simple carbu 45DFC par une triplette de carbus 40DCNF, plus aérée, et si pas satisfaisant, passage à l'injection.
 
J'avais pensé installer un boîtier de gestion bien connu tel Megasquirt http://www.megasquirt.info/ ou Microsquirt http://www.microsquirt.info/ , mais maintenant que j'ai vu ce qu'il est possible de faire via scan OBD, je me demande s'il je ne ferais pas mieux de me recentrer sur quelque chose qui obéisse au standard OBD, principalement pour pouvoir interroger les capteurs à ma guise. Comme vous le faites, brillamment.
 
Donc, si vous visualisez bien le chantier, je voudrais que des véhicules anciens pré-ECU et pré-OBD deviennent gérés en OBD de la façon la plus progressive qui soit.
 
Commencer par refaire l'allumage, que l'on met au point et que l'on optimise via OBD. Qu'est-ce que vous verriez comme solution avec comme paramètres à l'entrée : le régime, la position de l'accélérateur, la pression d'admission, la température d'air à l'admission, la température de l'eau de refroidissement ? Connaissez-vous un petit contrôleur d'allumage compatible OBD ? Recup d'un Motronic et hacking ? Je ne pense pas que cela existe ...
Ensuite, diagnostiquer et optimiser la carburation via sondes à oxygène large bande (BOSCH LSU4) et sondes de température d'échappement. Pour les irréductibles, garder le ou les carburateurs (soit un DFC45, soit trois DCNF40), et juste se contenter de mesurer la richesse, ce qui permet de sélectionner les gicleurs et les ajuteurs. Gestion en boucle ouverte, donc. Pour les progressistes, virer les carburateurs et passer à l'injection (injecteurs placés sous les papillons des corps de carbus, ou bien plus loin, près des soupapes d'admission). Possibilité de gestion en boucle fermée. Là non plus, je ne connais aucune solution "do it yourself" qui, pour ce qui est du diagnostic et de l'optimisation de la carburation, maintienne une stricte compatibilité avec le scan OBD.
 
Je suis ingénieur en électronique. Je me demande donc s'il n'existerait pas, tout de même, une gestion moteur "do it yourself" qui mette dans le cahier des charges la compatibilité OBD-scan ce qui permettrait, comme vous le faites, de réaliser les réglages et l'optimisation via d'une application entièrement découplée, tierce, qui se base exclusivement sur le scan OBD, ce qui permet de rallonger considérablement le cycle de vie de la solution. C'est cela qui m'a interpellé dans votre approche. La pérennité de la solution, et la souplesse.
 
Dans le pire des cas, si rien n'existe, pensez-vous que Microsquirt (cfr lien Internet plus haut) puisse convenir ?  Pouvez-vous m'indiquer quelles seraient les spécifications minimales qu'un tel Microsquirt devrait avoir pour qu'il soit utilisable avec votre application de scan OBD ? L'avantage de ce module MicroSquirt, c'est qu'il se programme en C, donc y greffer une fonction OBD n'est finalement pas si compliqué que cela; c'est de la messagerie en tâche de fond, et l'on peut garder 100% du code temps réel de gestion allumage / injection, l'important étant de bien repérer les variables, et de bien les formatter lorsqu'on les "sort" via OBD.
 
Pour les différents capteurs, nombreux si l'on veut faire l'optimisation cylindre par cylindre (déjà 12 capteurs si lambda et EGT pour chaque cylindre), je vais devoir construire des modules d'acquisition qui communiquent via CAN, aussi je me demande si je dois opter pour une architecture distribuée (à une requête OBD, selon la requête, c'est soit MicroSquirt soit les capteurs intelligents qui répondent), ou si je ferais mieux de centraliser (par exemple, que ce soit toujours MicroSquirt qui réponde, après avoir éventuellement interrogé le sous-réseau de capteurs). Comment voyez-vous les choses ? Quelle est la solution retenue par les constructeurs d'automobiles, et pourquoi ? Ne font-ils pas appel à deux sous-système ? Devrait-on s'en inspirer ?
 
Enfin, voilà, le post est déjà bien trop long et si quelqu'un peut conseiller l'une ou l'autre approche, ce serait formidable.
 
Steph
de Bruxelles

Une réponse rapide en attendant mieux : je ne connais aucun controleur compatible OBD (en meme temps je n'en ai jamais cherché).
Pour le reste, l'obd c'est plus qu'une simple messagerie, la mise en oeuvre est je pense assez lourde.
Sinon une solution temporaire pourrait être l'acquisition d'un ECUSIM özen, qui comporte 5 ou 6 potentiomètres et donc autant d'entrées CAN qui permettraient de renvoyer des infos au format OBD. Cependant les PID sont fixés (rpm, spd, maf, O2, me rappelle plus des autres). Bref projet vraiment très intéressant, mais je pense que pour ton application tu aurais plus vite fait de faire un systeme de dialogue batard avec le PC.
Je m'explique : si tu ne trouves pas de solution avec obd embarqué, c'est trop compliqué je pense d'en émuler un soi même. Par contre, tu peux créer ton propre systeme de dialogue pour peu que les trames qu'il accepte et qu'il envoie soient compatibles avec les logiciels existants. Je schématise la chose :

Actuellement en système OBD classique :
Voiture  <---(protocoles : ISO, KWP, CAN)--> Interface traductrice <---(requetes IO type : mobydick, ELM32x) ---> PC (logiciel compatible avec les trames IO type : mobydick, RLM32x)

Il faudrait tendre vers :
Voiture  <---(OBD simplifié émulé, IO requêtes directement traduites : mobidick, ELM32x)---> PC (logiciel compatible avec les trames IO type : mobydick, RLM32x)

Autrement dit, au lieu d'émuler le comportement complet de l'OBD, tu émules le comportement de l'obd au travers d'une interface traductrice déjà compatible avec tous les logiciels existants, ce qui est beaucoup plus simple ! Tu as juste à étudier le fonctionnement des ELM ou du mobydick (je te conseille le mobydick, ce sera plus simple à mettre en oeuvre, mais si t'es chaud l'elm jouit pour l'instant d'une compatibilité avec plus de softs (sauf pour mes productions perso, seul dynobd est compatible elm)). Pour le reste ça revient à ce que tu dis exactement, de la messagerie.
Je rappelle également que l'OBD ne permet que de visualiser les paramètres et pas de faire de modif de paramètres.

  je penses que tu y as déjà songé mais un PIC16F (ou dénomination différente) n'est pas plus intéressant à l'usage (et à la programmation) ?
 
Il y a bons nombres d'applications industriels (boitier de pilotage en chaîne de montage) qui l'utilise ainsi que bons nombres d'applications grand-publique (émulation fantôme pour la liaison contrôleur-lecteur DVD sur les consoles Wii).
 
Il est bien plus simple qu'une solution propriétaire (que tu cites plus haut) car tu reste maître sur l'implantation CI ainsi que la possibilité d'en cascader plusieurs en liaison I²C pour la com entre eux.
 
Je ne vois pas l'intérêt de la rendre standard OBD car tu n'auras que ta console pour aller interroger correctement les parties intéressantes...alors, autant faire de la visu. à rajouter par la suite via un PIC dédié et un afficheur à mémoire des défauts.
Bien plus "d'accessoires" sont disponibles et directement compatible pour les PIC que pour le standard OBD qui reste du SOFT standardisé sans application directement physique (ce que tu requiert en premier lieu).
 
  Mon avis. ( je pousserais pas jusqu'à te proposer un automate programmable crouzet puisqu'il y a de l'allumage qui requiert la capacité rapide de traitement d'un PIC).

Y'a pas que les PIC dans la vie
Mais sinon je plussoie, sauf s'il veut utiliser absolument un soft OBD.