elm327 BT / Android

J'ai quasiment fini la partie P2 qui est fonctionnelle et testée depuis ce matin.
Dans les dernières tâches avant commit :
- supprimer la virgule des ampères qui cache sur mon 320*480, le SOC (au passage, merci à Planétaire pour m'avoir corrigé l'erreur du fichier codes_P2 pour BATT_AMP)
- indiquer la valeur de SOC, je ne l'avais pas mise en fait !
- ne requêter que (mais je suis ouvert à toute discussion)
7e2 21c3 (c4 aucune donnée nécessaire selon moi)
7e0 0104 et 0105 (ICE_TEMP, ICE_RPM les autres ne sont pas spécialement nécessaires) que je vais séparer par fréquence, ICE_RPM aussi fréquent que 21C3, ICE_TEMP moins fréquent car les temps en BT sont un peu longuets :cry: je cherche donc à optimiser les requêtes et les réponses.
- je dois finir la partie batterie HV mais ça peut attendre
- j'aimerai ajouter consommation, temps et distance parcourue.

Dès que cela est prêt, je commite et je m'attaque aux graphs.
 
je ne sais pas si c'est le bon endroit ici, mais, Less polluter et moi même sommes intéressés par le développement d'une évolution future du Tripmaster (développé par Planétaire sur PriusCanMonitor) sous androïd en vue du prochain rallye de Monte Carlo 2012
 
parkerbol à dit:
...7e2 21c3 (c4 aucune donnée nécessaire selon moi)...
Cliquez pour agrandir...

En effet, vu qu'à part la température du "boost converter", laquelle s'approche pas mal de celle des IGBT de MG1 et MG2, surtout parce que c'est le même circuit de refroidissement, et que de toute façon il n'y a pas de seuil de température bien marqué pour l'électronique. La bonne température c'est la plus basse.

Si tu peux avoir sans pénalité le couple de l'ICE (je me demande s'il ne peut pas être calculé d'après celui de MG1 et de MG2 que tu as dans ton pid 7e2 02 21 C3. De mémoire il doit y avoir la formule du nomograph), ajouté à la conso d'Essence (7E0 02 21 F3 prendre la durée d'injection), tu peux avoir la puissance de l'ICE et son rendement.

Quand montre-tu une petite copie d'écran, en roulant ?

A+ ;-)
 
planétaire à dit:
.....que tu as dans ton pid 7e2 02 21 C3. De mémoire il doit y avoir la formule du nomograph), ajouté à la conso d'Essence (7E0 02 21 F3 prendre la durée d'injection)....
Cliquez pour agrandir...

attention à bien enlever les 02 (spécifique CANUSB);
les demandes pour ELM327 sont:
7e2 21 C3
7E0 21 F3
 
Bonne nouvelle pour la pII, de mon côté j'ai seulement qq toutes petites modifs à committer demain.
Par contre je pense avoir trouvé sur le forum un bon candidat pour tester l'application sur Auris !
 
Je veux bien tester sur la P II ... :-D
 
Palm35 à dit:
je ne sais pas si c'est le bon endroit ici, mais, Less polluter et moi même sommes intéressés par le développement d'une évolution future du Tripmaster (développé par Planétaire sur PriusCanMonitor) sous androïd en vue du prochain rallye de Monte Carlo 2012
Cliquez pour agrandir...
Euh ... on va pas au RSMVEA ? (SM pour San Marino) en sept oct 2011 ?

Oui, ça pourrait être une idée car la base Windaz pose quelque problèmes. Ca marche impec chez moi ... sur une machine dédiée. J'y touche pas.

J'ai débriefé avec planétaire (encore une fois merci car c'était quand même mieux que lors de la première édition où on se servait de l'odo avec une précision fabuleuse d'env 5 sec ...) et au lieu de se baser sur la moyenne des 4 roues on pourrait prendre que les 2 arrière (pas de glissements dus aux accélérations).

On va refaire un cahier de charges puis si vos doigts magiques ... :-D
 
Oui Lesspo, il faut un cahier des charges, cependant en BT on a quelques pertes parfois et des temps de réponses un peu long, je ne sais pas si c'est compatible avec ce type d'activité (odomètre s'entend)

Je peux t'envoyer par mail la version P2 non committée pour le moment.

@Planétaire
Pour la photo, ben euh faut que ma femme soit avec moi ...

@Guinness,
J'ajoute quelques variables au projet global, afin de gérer le carburant et quelques modifs graphiques qui impacteront P3 concernant le fuel notamment (juste un textview de plus pour le moment). Une fois testée, je committe la semaine prochaine. Compte tenu de ton travail très productif sur le sujet, fais moi tes remarques si des choses ne te plaisent pas, je m'adapterai.
 
Pas de problème pour tes modifs, je regarderai ça quand j'aurai le temps car en ce moment c'est pas trop le cas, j'ai filé un apk à LeViet13 pour qu'il teste sur son Auris, je vous dirai si ça a marché ou pas.

Faudrait sans doute que je revois aussi mes commandes actuelles par rapport à ce que j'affiche aujourd'hui, y a moyen d'optimiser pour la PIII aussi.
 
Les modifs sont peut être impactantes en fait mais bon on va bien trouver une solution :



l/100km ne fonctionne pas ma formule était proche de celle utilisée chez Torque mais ça ne semble pas être ça aussi je vais reprendre celle de priusfan :
// FuelFlow_mL/S mL/S =Inj_mL * ICE_RPM / 9 600 000
// FuelFlow_L/H L/H =FuelFlow_mL/S * 3,6
// mpg1 kM/L =Speed / FuelFlow_L/H
// mpg2 L/100kM =100 / mpg1
J'ai donc questionné Planétaire en privé pour avoir les infos :wink:

J'ai du aussi modifier le layout, mon affichage est 320x480, ça reste proportionnel si on augmente la résolution, j'ai testé.

J'ai gagné en perfs sur le choix des requêtes, RPM est aussi fluide que celui de Torque :)
Pour l'instant, je ne requête que ça :
"ATSH 7E0" "01050C100D" (moyenne 60+110ms)
"ATSH 7E2", "21C3" (moyenne 60+230ms)

Bugs à corriger :
- la connexion BT commence par une déconnexion
- le mode landscape réinitialise le fichier de log (grrr !)
- le layout du landscape est à refaire, ce sera celui qui sera utilisé pour les compteurs analogiques.

@Lesspo, envoie moi ton mail par MP pour le test.
 
sur P2, l'injection serait en 7e0 21 f3

le calcul de conso serait beaucoup plus juste en partant de cette info que du MAF.


pour n'importe quel véhicule,
pour calculer la distance parcourue au fur et à mesure d'un trajet, je vois 2 possibilités:
1) intégration de la vitesse (résultats assez précis et justes, mais un peu ch...t à programmer).
2) beaucoup + facile: interroger périodiquement 7e0 21 31 (ou probablement, de manière standard et + simple 7e0 01 31) qui va nous donner une distance en kM depuis clearDTC; si l'on mémorise la valeur initiale, il est élémentaire de calculer la distance depuis le départ...
 
Attention. La deuxième idée pose deux ENORMES problèmes, du moins sur P2.
-Ce kilomètrage est limité à 65535km. Sur ma P2 il ne bouge donc plus.
-On n'a pas les mêmes distances entre km compteur et km dernier dtc. Ca c'est 2009Prius sur Priuschat qui l'a découvert.

Le 1 marche bien, la fréquence d'échantillonage n'a pas une influence majeure, vu qu'elle intervient si la vitesse varie rapidement, ce qui n'est pas trop le cas quand on effectue cette mesure de km/h plusieurs fois par seconde. Là dessus les erreurs, statistiquement, sont priées de se déduire entre elles le plus souvent possible. :-D

A+ ;-)
 
Mouais ... je me remets aux maths pour faire ce calcul !
Bon ben je vais me remettre au travail ...
 
Existe-t-il une sonde Temperature d'huile du moteur sur le PII?

Je voudrai verifier la difference entre SP95-E10 et E85 de la temperature d'huile moteur.
Car le GPL augmenterai la temperature du haut moteur et je voudrai savoir si c'est le cas en E85 aussi.
 
Sur le thermique il y a une sonde de température en plus de celle du liquide de refroidissement. Je n'ai jamais vérifié si elle mesure la temp de l'huile ou de l'eau.
Elles ne diffèrent que de quelques degrés, et encore par moments.

A+ ;-)
 
intégration vitesse --> distance

l' intégration est trés simple;
la distance parcourue, en mètres, entre 2 mesures, est égale au nb de mS entre les 2 mesures multiplié par la vitesse en kM/H et divisé par 3600

exemple : distance parcourue en 1 Sec à 36kM/H (soit 10 M/S)

1000 * 36 / 3600 = 10 Mètres, cqfd


méthode:
1) mémoriser le "time" lors de chaque relevé de vitesse et calculer la vitesse en kM/H.
2) calculer nbmS le nb de mS depuis la mesure précédente.
3) éxécuter formule
distancetotale = distancetotale + (nbmS * Speed / 3600)

voila comment cela s' écrit en VB
Code: 
    New_Ticker = GetTickCount                         ' What time is it ?
    Millisecs = New_Ticker - Old_Ticker               ' millisecs since last time
    Old_Ticker = New_Ticker
    ' calc distance
    Distance = Distance + (Millisecs * Speed) / 3600! ' distance from start (unit is Meter)
ps: attention à la précision, ne pas travailler avec seulement des entiers...
 
ok pour la formule mais je ne l'ai pas encore implémentée, je n'ai pas eu le temps ce week-end, trop de travaux à la maison.
J'attends un retour de mon frère sur cette question des compteurs.
 
Euh ... si je puis me permettre ...
C'est bon pour des vitesses constantes. Et en cas d'accélération (forte) ? Je ne pense pas qu'on puisse s'approcher des valeurs d'un jet mais il vaut mieux que l’échantillonnage soit "serré".
Y a pas plus simple, compter le nombre de tours des roues ?
 
bonne question;

1) no pb : échantillonnage supérieur à 3/sec

2) le nb de tours de roues n'est pas accessible.


ce qui est important, c'est de garder de la précision dans le nb de mètres (surtout dans le cas des faibles vitesses)...

ben quoi, le priusfan il est (lui aussi) ingénieur en mécanique...
 
Dans ce cas je me dis quand même qu'une détection de l'accélération s'impose (valeurs /franchement/ différentes) avec l'algo qui va bien pour en déterminer la valeur.
 
Pour les inquiets il sera possible de brancher en // les deux systèmes:
un elm327 passif avec un pc
et un elm327 bleu actif et une tablette.

Installés dans la même voiture, à l'arrivée même Einstein ne mouftera pas. ;-)

Complément: Il est possible de simuler ce qui va se passer:
-prendre un log d'un trajet dans un tableur et faire le calcul de distance soit avec les 10 mesures/secondes mémorisées, soit avec moins et comparer.
-recommencer avec d'autres trajets.
 
Ce n'est malheureusement pas avec du BT que l'on va arriver à ce niveau de précision :siffle:
Personnellement je le vois comme une aide à la conduite, d'autant que les informations sont pour le moment limitées et c'est tant mieux.
Ce manque d'échantillonnage en BT pourra d'ailleurs faire que le mode graphique par compteurs aiguilles sera peut être inexploitable (sauf à faire que l'aiguille ait une fréquence de rafraîchissement très supérieure à celle du BT, ce que je vais tenter !) :cry:

on a donc deux ingénieurs en mécanique sur ce forum :-D
 
En réfléchissant un peu plus que d'habitude, je me dis que l'erreur de calcul sur la distance est dûe au fait que la courbe de variation de la vitesse en fonction du temps est une courbe.:-D
Nul doute qu'en prenant un pulse&glider de chez Singer, ce seraient de splendides droites dessinant de magnifiques triangles et l'erreur serait nulle.
Mais est-ce que l'erreur de calcul lors de l'accélération, à priori un calcul sous-estimé de la distance, ne serait pas compensée par l'erreur lors des freinages ?

Mon pif me susurre que oui :grin:
 
J'sais pas. Mais ce serait bien qu'on puisse disposer d'un prog encore plus ultra précis pour le prochain RMCVEA. Ceux qui ont gagné la régularité ont carrément branché un truc de l'UTAC au moyeu de la roue arrière.
 
Dans ce cas, ce n'est pas avec le BT et android qu'on y arrivera et la solution d'un compteur de tours sur moyeu de roue est une obligation !

Une petite modif à mon message, hormis l'horreur que c'est, ça ressemble à ça le compteur moyeu ?
2011-Fiat-siena-spyshot.jpg
 
Identifiez-vous ou inscrivez-vous pour participer.
Pages vues depuis le 20 Oct 2005: 313,226,595
Retour
Haut Bas