Projet Tripmaster : cahier des charges

Palm35

Participant hyperactif
Inscrit
18 Nov. 2005
messages
2,548
Score de réaction
755
Localisation
Rennes
Véhicule
Sol Pack IPA 2006, Kangoo Electri'cité, C-Zéro
hello,
maintenant que le forum dispose d'informaticiens maitrisant bien les différents languages et la Prius, il serait intéressant de développer un Tripmaster pouvant servir par exemple :cool: aux rallyes de régularité type RMCVEA.

Ce projet/logiciel comprend (pour moi) de base au minimum 2 fonctions:

-1°) étalonnage et/ou vérification
-2) tripmaster

Voici un début de cahier des charges:
point 1: étalonnage

On part d'un point A pour arriver à un point B et cette distance a été mesurée par les commissaires de courses.
C'est cette distance qui fera référence pour la vitesse de référence.
Attention, dans certains rallyes (italiens par ex) cette distance peut être différente de la vraie valeur.
C'est à dire que 1000m réels peuvent faire 1200m dans le rallye.
C'est pourquoi cet écran d'étalonnage est important

Il faut dans cet écran:

-un bouton départ point A
-un bouton arrivée point B
-la distance parcourue calculée par la Prius et ses capteurs de roues en mètre ou kilometre et si c'est en kilometre avec 2 décimales: la précision sera donc de 1m ou 10m
-la distance réelle donnée par la direction de course

ensuite un bouton permettant d'ajuster la distance parcourue par rapport à la distance officielle.
Cet ajustement peut être en % en plus ou en moins par rapport à la distance.
Ce coefficient "correcteur" servira dans le calcul du prochain écran

point 2: tripmaster

je posséde un petit program Palm qui n'est pas parfait mais qui donne une idée de ce que devrait afficher le programme:


zr2.jpg


il faut dans cet écran:
-la vitesse de régularité imposée par le Rallye (que l'on peut programmer/entrer)
-un bouton départ/arrivée et intermédiaire qui peut être dédié à une touche de clavier
-la distance parcourue
-la vitesse moyenne de la Prius depuis le début de la Zone de Régulation
-le chrono indiquant le temps écoulé depuis le départ de la ZR
-la vitesse actuelle
- un affichage 'GAP' en minutes-secondes-centièmes qui est la différence entre le temps idéal par rapport à la vitesse imposée et chrono réel depuis que vous roulez
Sur cette copie d'écran, on voit qu'on est 'pile poil' à 28 centièmes près !
le moins -00:00.28 indiquant d'aller moins vite. Ma position est la voiture rouge qui est devant la grise, quand on est OK les 2 voitures doivent être superposées
-un affichage 'GAP' en métres précédé d'un signe moins ou plus (moins vite ou plus vite) indiquant la différence entre la distane idéale de la moyenne imposée et votre distance effectuée.

Ainsi, avec ces deux 'GAP' on peut parler en secondes ou en mètres

On peut/pourra ensuite ajouter d'autres fonctions comme l'enregistrement des données ou autres ...

La précision donnée par les capteurs de roues est meilleure que la précision du compteur kilométique de la Prius.
Je crois savoir que lors de l'étalonnage, Mik&Toy était exactement à la valeur donnée par le Rallye

Voila mes premières idées......
 
L'équipage N°32 de la Honda Insight utilisait un Tripmaster Blunik
Leurs temps dans les ZR sont 'intéressants'.
Mais je suis persuadé qu'un trip master spécial Prius est plus performant.
Le Blunik est vendu 759€.
Si nos génies du forum en concoivent un, on peut le vendre un certain prix !!!
ou bien il faut cotiser à l'association pour l'avoir ....:grin:

il y a un simulateur sur leur site
et aussi le mode d'emploi
(on y lit notamment que la précision du paramètre Wheel diameter est de 5 chiffres, ce qui représente une précision de 1 m tous les 10 km, si la lecture est d’une impulsion par tour de roue.)
 
Dernière édition:
Je suis en bonne voie de résoudre le TripMaster spécial Prius.
Quelques points à résoudre:
1/ la précision de la vitesse moyenne, obtenue par division de la distance parcourue par le temps écoulé, est assez fluctuante dans les premiers kilomètres. un lissage s'impose.
2/ à l'usage - en simulation - il me réapparait ce que j'avais ressenti en réel lors des ZR, à savoir la difficulté à converger sur la position 0 .
Quel pourrait être le moyen d'aider le pilote en lui proposant une modification de sa vitesse la plus efficace pour ne pas avoir ni à trainer le retard j'usqu'à ce qu'il soit impossible à rattraper, ni à freiner d'urgence pour faire baisser une moyenne trop rapide. Les TripMaster existants ne proposent rien de ce genre, et c'est pourtant le point essentiel pour la régularité.
3/ je propose sur le même tableau à la fois l'écart en mètres par rapport à la position actuelle, et l'écart en temps prévisionnel sur la date d'arrivée, basé soit sur la vitesse actuelle, soit sur la moyenne déjà réalisée, soit sur la moyenne de régularité imposée. pas facile à lire tout ça en même temps.

ci joint une première ébauche :
le menu d'initialisation
131049e4e8b2ca58c.png

et les variables en roulant, avec le supplément ZR
131049e4e8b2b97fe.png
131049e4f25761078.png
 
Dernière édition:
1/ la précision de la vitesse moyenne, obtenue par division de la distance parcourue par le temps écoulé, est assez fluctuante dans les premiers kilomètres. un lissage s'impose..

Dans les premiers kilométres ?
C'est à dire , 1 -2 kms ?
Utilise par exemple les mètres comme unité de distance au lieu des km si c'estce que tu as fait ?



2/ à l'usage - en simulation - il me réapparait ce que j'avais ressenti en réel lors des ZR, à savoir la difficulté à converger sur la position 0 .
Quel pourrait être le moyen d'aider le pilote en lui proposant une modification de sa vitesse la plus efficace pour ne pas avoir ni à trainer le retard j'usqu'à ce qu'il soit impossible à rattraper, ni à freiner d'urgence pour faire baisser une moyenne trop rapide. Les TripMaster existants ne proposent rien de ce genre, et c'est pourtant le point essentiel pour la régularité.

A part brancher le tripmaster sur le régulateur de vitesse, je ne vois pas trop ...:grin:
C'est au pilote d'accélerer ou de ralentir.....

3/ je propose sur le même tableau à la fois l'écart en mètres par rapport à la position actuelle, et l'écart en temps prévisionnel sur la date d'arrivée, basé soit sur la vitesse actuelle, soit sur la moyenne déjà réalisée, soit sur la moyenne de régularité imposée. pas facile à lire tout ça en même temps.

Il faut je pense:
-le gap en métre
-le gap en mn:sec avec le signe + ou - : +01.12.00 indique qu'il faut aller plus vite car on a 1mn 12s de retard

L'écart en temps prévisionnel sur la date d'arrivée ???
Tu veux parler de l'heure d'arrivée dans le cas d'un secteur et non d'une ZR ?

Je pense qu'il faut distinguer 2 cas et peut être 2 écrans différents ?:
-le cas des ZR et le cas d'un secteur.
-ZR: c'est essayer de suivre la vitesse imposée pour passer au temps pile lors des contrôles cachés.
-secteur: c'est indiquer au copilote des infos par rapport à l'heure d'arrivée connue et en fonction de la vitesse et de la distance parcourue.

Le fonctionnement du simulateur du Blunik donne une bonne base de travail....
 
nota : j'ai rajouté des graphiques dans le message précédent.

pour celui des ZR le rectangle vert se déplace de haut en bas proportionnelement au retard , avec le temps affiché dedans. le carré jaune symbolise la position de régularité. Aux deux exrémités sont indiquées les distances théoriques qui te séparent des concurrents voisins (par exemple à 1 mn , règlable)

J'utilise des mètres et des secondes. mais la distance est une accumulation des produits des vitesses relevées sur le CAN au 1/100 de km/h par la durée entre deux acquisitions (environ 100 fois par seconde) . il doit y avoir qqch à creuser de ce coté.

Pour l'aide, je pensais ajouter la vitesse à pratiquer pendant un temps donné pour rattraper, par exemple, monter à 80 km/h pendant 10 mn, ou arrêter pendant 5 secondes. Il est clair qu'il faut des réactions trés vives pour retrouver le phasage et qu'il serait bon de pouvoir faire confiance à un calcul pour en être convaincu .

Le simulateur blunik est fait par écrans séparés de 4 valeurs chaque. Est-ce meilleur de tout afficher à la fois ?
 
Dans cette image je ne comprends pas:
La carré vert est dans le jaune, donc je suis "régulier: je devrais avoir un temps de 0 seconde
Ou alors si j'ai un temps de +10s c'est que je suis en retard de 10sec et que les carrés jaune et vert ne sont pas superposés, non?
 
Dernière modification par un modérateur:
erreur de ma part, j'ai recopié la fenêtre de programmation, pas en test, je vais corriger => voir message #3

On doit pouvoir remplacer par des lièvres et des tortues, ou par des tutures vertes, et rajouter des graduations en fond.
 
Hello Racers,

Je vais rajouter mon grain de sable. Perso il me suffirait, à moi et mon copilote, les infos suivantes :

Pour la ZR

Moyenne à réaliser 48.2 km/h (saisissable)

Temps écoulé 4:05 (depuis le top départ)

Distance parcourue 3 250 m (depuis le top départ)

écart distance - 150 m (- signifiant qu'on a du retard)

écart temps + 0:10,0 (+ signifiant qu'on a du retard)

C'est tout. Pas la peine de s'encombrer d'autres infos.

L'info à rentrer serait la moyenne (on pourrait prévoir une version avec comme paramètres en entrée la distance à parcourir et le temps imparti, de fois que ce soit ça fourni par les organisateurs, à partir desquels serait calculée la moyenne) et chose hyper importante, un très gros bouton pour donner le top départ.
Voire 3 boutons : 1er permettant de démarrer le "PriusTrip" 10 secondes avant, un 2e pour le faire 5 secondes avant et le plus gros pour le top départ. Pourquoi ces 3 boutons. Ben... dans la précipitation, l'excitation et les secousses du départ le clic peut facilement déraper et là ... on est mal, on est décalés. En lançant 10 secondes avant on peut vérifier tranquillement si on est synchro avec l'horloge officielle, si on l'est pas on peut encore corriger à 5 secondes et au départ.

Pour quoi aussi peu d'infos ? De part l'expérience vécue savoir l'écart par rapport à la moyenne ne m'avance à rien. Savoir combien de mètres de retard j'ai me permet de visualiser facilement où je devrais être (un peu comme avec les voitures "ghost" dans les jeux vidéo) l'écart en secondes m'est préférable en cas d'avance (je peux sensiblement ralentir en faisant un décompte dans ma tête) ou très gros retard (là c'est plus parlant que la distance).

J'ai aussi pensé à la 2e partie, permettant de gérer le pointage au prochain CH. Là il faudrait se baser sur l'heure exacte en entrant l'heure d'arrivée et la distance à parcourir, le tout corélé avec la distance parcourue. Chose importante, il faudrait que les infos ne se perndent pas lors de l'arrêt de l'ordi ou de la voiture (cas de pauses pipi ou autres).
Attention, il peut y avoir 2 cas de figure :
1) l'heure de pointage est immuable (cas du CH de fin de l'étape de concentration) où il serait préférable de saisir l'heure d'arrivée
2) l'heure de pointage peut être modifiée par les organisateurs (comme c'était le cas dans les secteurs des étapes comportant des ZR du fait des retards des Huns et des Barbares) où il serait préférable d'entrer le temps imparti l'heure d'arrivée étant calculée à partir du top départ du secteur/ZR (le gros bouton du "PriusTrip"

Le tout prépararable à l'avance (saisie des paramètres, savegarde, puis rappel).

Chose à envisager pour les liaisons, correction de la distance en fonction des errances (eh oui, il nous est déjà arrivée de nous écarter et là les indications kilométriques du road book n'était plus bonnes par rapport à nos odomètres).

Last but not least, un "PriusTrip" avec gestion d'alèrtes !!!
En préparant une étape on peut rentrer les points kilométriques marques dans le roadbook pour les changements des direction. Notre machin ferait retentir une alerte à l'approche d'un tel "Way Point" pour avertir l'équipage. Idéalement on pourrait y associer des groses icones avec les symboles de changement de direction (façon road book) ou la descritpion piquée à partir de la planification d'Autoroute 2007. C'est là que la correction de la distance aurait son importance.

Voilà, a pu k, faucon (dommage que la dernière fois que j'ai programmé c'était au siècle dernier ...)

:)
 
Merci, Less Polluter, ya pas que la programmation qui compte, l'avis de l'utilisateur est primordial. Je vais travailler dans ce sens.

Je prépare également un fond de carte pour la localisation directe en GPS. À partir d'une copie d'écran d'un parcours programmé sous Autoroute2007, ou de tout autre fournisseur de cartographie, je visualise la position actuelle reçue par la puce GPS, comme le fait Autoroute2007, avec différentes échelles de zoom, pour s'affranchir si possible du deuxième EeePC, et avec en plus une correlation à la mesure de la distance réellement parcourue.

Reste à ajouter un bouton pour dire qu'on vient de faire demi-tour, et puis qu'on vient de retrouver la bonne route, pour retrancher deux fois cette distance au parcours planifié.

On doit pouvoir aussi ajouter des images des carrefours à problèmes pour peu qu'on les ai repèrés à l'avance (je me souviens sur la ZR3 d'un T sur la D21 qu'on avait pas prévu)
 
Attention quand même à ne pas trop complexifier le bazar.....

Quand on regarde ce qu'il y avait dans les voitures du rallye, c'était tous des tripmaster assez simples:
-soit de chez ATB
-soit plus sophistiqué comme le Blunik.

Ils fonctionnent avec une sonde ou plusieurs
Utilisons donc les données transitant dans la Prius pour ne pas ajouter de sondes, car on a déjà dans la Prius tout ce qu'il faut.

Ensuite, pour moi, le copilote a deux outils à sa disposition:
-un tripmaster et un itinéraire.
On peut très bien utiliser le PriusTripMaster de Mik&Toy et utiliser Autoroute Express comme logiciel d'itinéraire.
Le tripmaster doit plutôt être utilisé comme un "instrument de mesure", (je suis à quelle vitesse moyenne, quand arrive-je, suis je en avance ou en retard?) et le logiciel d'itinéraire nous dit si on est ou pas sur la bonne route.

Pour les carrefours à problèmes dans les ZR, y' a le roadbook qui les mentionnent !
 
J'abonderais dans le sens de Palm35.

J'ai décrit un outil hyperperfectionné ce qui serait bien mais ... c'est à se demander si un copilote servirait encore à quelque chose ? Comme le règlement en impose un, il y a fort à parier qu'il roupillerait et si cet outil se loupait (on ne peut pas tout prévoir, ne serait-ce qu'à cause d'indications km du roadbook parfois erronées - on en a relevées plusieurs notamment dans l'étape de concentration) on serait dans les choux. Donc je reviens un peu sur mon idée. Disons qu'avant d'en arriver là y a déjà de petites choses sympas à faire qui faciliteraient grandement la tâche.

Ainsi avec :
- un EeePc relié au canbus pour faire le tripmaster
- un autre EeePC équipé d'Autoroute pour se situer sur la carte
- un TomTom pour voir les virages à l'avance dans les ZR et qui calcule assez bien l'heure d'arrivée des étapes
- le roadbook
y a déjà ce qu'il faut et largement de quoi faire ...

Pour le tripmaster je le retiendrais le plus simple possible avec seulement la correction de distance si on s'est loupé et l'alerte d'approche d'un WayPoint.

Un seul outil c'est un peu dangereux car en cas de dysfonctionnement ... Au début on s'était basé sur le TomTom hyper bien préparé mais très vite on s'est aperçu que dans le contexte du rallye on ne pouvait pas lui faire confiance car il recalculait souvent en fonction de ses propres critères et sans nous en avertir ... "vous vous êtes trompés, pas de problème, tous les chemins mènent à Valence, mais pas forcement par les CP de l'organisateur ..." Donc on a passé notre temps à tout remettre en question.

Pour ce qui est du reste un peu moins de précipitation devrait faire l'affaire.
Si on s'est pas loupé dans la ZR3 c'est grace à une Prius (devinez laquelle) et une friteuse carburant aux rébuts de FastFood qui ont obstrué le carrefour. On a été obligés de relentir et devant votre hésitation (merci les gars) on étaient incités à bien réfléchir où aller ce qui n'était plus le cas dans la ZR4 où on s'est plantés à cause du passage trop rapide dans un carrefour (vu trop tard, trop tard pour bien consulter le roadbook d'ou l'importance d'alertes car on était trop concentrés avec mon copilote sur la moyenne à tenir)

:D
 
Lors du dernier rallye, j'avais un GPS GARMIN qui donnait la vitesse moyenne (au dizième), la distance parcourue (centaines de mètres) et le temps écoulé à la seconde.

J'ai été surpris de sa capacité à enregistrer assez fidèlement le parcours y compris dans les épingles en soirée.

Pour les directions nous lisions juste avant l'épreuve le road book détaillé avec les photos des intersections difficiles et nous utilisions la GPS de la ¨Prius pour visualiser le parcours.

Le hasard y est sans doute pour beaucoup (voire pour la totalité) mais cela nous a permis de terminer 5ème de la seconde zone de régularité, zone dans laquelle Palm35 était le meilleur sur un des deux contrôles avec seulement 0,2 s d'écart par rapport au temps imposé.

Dans les deux dernières zones de régularité, une fois que le ratard est pris, la seule stratégie c'est d'aller le plus vite possible sans se foutre en l'air et aucun appareil de mesure n'est vraiment utile.
 
Dernière édition:
Tout à fait d'accord avec la simplicité.

Mais, n'en étant pas arrivé à la phase finale du projet, j'essaie d'identifier et de couvrir toutes les pistes possibles. L'informatique ayant comme qualité première d'être modifiable à l'infini, il sera toujours temps de fournir au final l'affichage que chacun désire. Faut-il encore assurer que les calculs effectués sont exacts et la méthode utilisée efficace.

Le plus par rapport au GPS me semble être dans la mesure exacte du chemin parcouru. Ce pourquoi on à vu bien des véhicules du rallye ajouter un capteur de roue pour leur tripmaster. Cela permet d'afficher à l'avance les difficultés du parcours (virages et intersections) ce que ne sait pas ou ne tient pas à faire aucun des GPS que j'ai pu voir (à part les sorties d'autoroute). Donc faire mieux que les 2 secondes de retard de la mesure GPS.

L'autre problème, aussi bien d'un GPS autonome que de Autoroute2007 est la lenteur de rotation de la carte aux carrefours en particulier. Ou bien choisir la carte toujours orientée au Nord, ou ce qui serait mieux au Sud quand on va vers MC, ou l'empêcher de tourner dans certaines occasions comme les rond-points.
 
Maintenant que cette discussion a été remise à jour et déplacée dans ce forum 'Dossiers Techniques'>'Canmonitor'>'Projet Tripmaster', à nous et vous de le faire vivre pour améliorer ce programme créé cette année avant le RMCVEA 2010.
Il nous a bien servi, mais je pense que quelques améliorations le rendront parfait !

Peuvent donc prendre part à la discussion, les anciens participants à un RMCVEA qui ont sûrement plein d'idées et qui peuvent tester (Pont Vert, Less Polluter, Mik&Toy, DoubleHybride, etc...) et les développeurs du forum (Planétaire, Priusfan, Persus, etc...) ainsi que les autres intéressés
 
Je peux éventuellement vous aider dans la conception, à condition de comprendre les contraintes.
Je comprends qu'il y a un parcours à faire en passant par des points précis, à des durées depuis le top départ précis. Est-ce exact ?
Combien de temps à l'avance connaissez vous le parcours, les points et les temps ?

Mes idées : découper les sections en sous sections, certaines où l'on sait que l'on peut régler sa vitesse (lignes plutôt droites) et certaines où il vaut mieux passer à une vitesse standard de confort (les courbes).
Prendre en compte uniquement les sous sections "droites" pour recalculer les vitesses dans ces sous sections.

Je veux bien aller plus loin dans ma réflexion si cela vous intéresse et si je ne suis pas à coté de la plaque.
 
@Palm, en réponse à un courriel dans lequel il demande un odomètre précis au mètre près, sous Android.
- il y a un odomètre qui compte le nombre de 96ème de tours des roues arrières. Cela donne une résolution de 1 cm :cool: Mais il s'arrête si la vitesse est trop lente :cry:
- Il y a un odomètre qui mesure la rotation du MG2 au vingtième de degré. Cela donne une résolution de 66 µm 8) Mais il est n'est exploitable qu'à très basse vitesse.
Me peux m'amuser à créer un programme qui combine les deux pour arriver à ce qu'il souhaite. Mais ce sera au départ sous Linux, avec un lien par cable et boitier OBDLink :jap:
 
Très intéressant comme cahier des charges, on peut mettre bt-android à contribution, c'est le pgm android de Guinness, Priusfan pour la P3 et moi-même pour la P2, bien que je n'ai toujours pas fini de lui greffer une interface digne de torque.
Maintenant, faut trouver les bons PID qui vont bien.
 
Merci de vos réponses.
En fait Planétaire a déjà sorti un 'truc' qui va bien et qu'il a incorporé dans PriusCanMonitor.
On part donc de la prise ODB avec un ODBLink relié par câble sur un PC .
Malheureusement, on a trop souvent des errors runtime au moment où il ne faudrait surtout pas. D'où un peu mon appel à développer sur autre support.
Donc les PIDs dont on a besoin sont déjà bien identifiés.
On va regarder si on peut pas débugguer sérieusement ce PCM sous Windows, avant le prochain rallye fin mars, mais ensuite, on pourra essayer de démarrer la même chose sous ODB Bluetooth et devices Androïd.
L'intérêt dans ce cas, est la multiplicité dans le choix des devices et de leurs tailles: smartphones, tablettes, etc, et comme pendant le rallye le copilote n'a pas toujours de place...
Autre avantage, pas besoin de charger l'OS à chaque fois comme le fait windows. Donc rapidité de mise en oeuvre.
Avec Less Polluter, on n'a pas mal d'idées de réalisation, et je peux vous dire que si un tel programme fonctionnait super bien, il aurait un vrai succés dans l'Androïd Market. Enfin dans la niche des gens qui en ont besoin...
 
Le tripmaster n'est basé que sur la distance et une horloge. Donc c'est un pid passif.
Ce qui veut dire qu'avec un cable odb en Y vous pouvez brancher deux dongle ensemble. Par exemple un elm bluetooth et un autre en usb.
Maintenant plus il y a de connecteurs et plus grand est le risque de mauvais contacts.
Pcm n'aime pas les mauvais contacts entre le Pc et la prise odb. Il se fige ou sort en erreur.
Théoriquement, en cas de coupure franche il devrait se reconnecter tout seul, mais le nombre de couches logicielles traversées plus le fait que les contacts peuvent être juste un peu mauvais (et en numérique un mauvais contact ça ne pardonne pas, j'ai eu ce genre de problème dans mon bms) font qu'en pratique c'est pas évident.

Pour la mesure de la distance il se peut qu'en prenant une roue AR on ait la mesure la plus précise. Actuellement Pcm utilise la vitesse pid passif 0B4, qui est supposée une vitesse moyenne des 4 roues. Il en déduit une distance parcourue.

A+ ;-)
 
En attendant une version android, j'ai récupéré chez Priusfan la version de PCM qui contient tripmaster ainsi que son odblink.
Je viens d'installer le driver d'odblink, et pcm communique avec lui.
Demain, je roule avec pcmtripmaster, je vous tiens au courant.
 
Pcm n'aime pas les mauvais contacts entre le Pc et la prise odb. Il se fige ou sort en erreur.
C'est rare que cela m'arrive (la dernière fois au bout de 14h de fonctionnement ininterrompu) mais aujourd'hui, en rentrant du siège du club, j'y ai eu le droit. "Erreur #6 dépassement de capacité" si j'ai bien capté le message empressé que j'étais de relancer la machine. Je croyais qu'il venait d'interrompre un excellent run mais en fait il m'a permis de m'approcher des records de planétaire : 2,8l/100 sur une 20 aine de km entre Le Pecq et le périph parisien. Comme quoi démarrer moteur chaud même en plein milieu d'une grosse et longue montée ... Le total sur 42 km serait autour de 3,7l.

Faux contact ? Peut-être. En plus d'ELM j'avais enfiché un alim et un GPS sur la prise à côté (le tout avec les paramètres des ports USB forcés à la main) et ce foutu GPS qui n'a jamais accroché le moindre satellite (ça lui arrive). Faudra que je jette un oeuil sur les logs pour voir si le GPS n'a pas fichu la grouille (d'habitude je ne le branche pas). Une secousse peut-être ... Je me demande si je ne l'avais pas débranché un instant, pour le relancer, du côté GPS ?
 
Le GPS peut bloquer Pcm aussi. C'est certain. J'ai eu ce problème sur mon pc et ne me sert plus du Gps.
Une des 2 prises usb du pc est en cause. J'ai re soudé, re serré la prise mais n'ai fait que diminuer le problème.

Il faut dire que je me sert de Pcm pour tous mes trajets. A force les prises usb viellissent !
J'adore la liaison bluetooth. Elle fonctionne parfaitement avec mon bms. La conso électrique s'exprime en dizaines de milliwatts.
Hélas avec la prise odb le bluetooth n'a pas assez de débit pour gérer les pid passifs. Il faudrait 500kb/s.
Il faudrait un dongle avec un multi-filtrage, en éliminant les trames qu'on ne gère pas et qui sont très fréquentes. Multi-filtrage c'est à dire la possibilité d'ignorer plusieurs pid de familles différentes. Ou alors la possibilité de "compresser" les infos transmises. Pourquoi pas en n'émettant un pid que s'il a changé depuis son dernier passage (sauf pour la conso d'essence) ? Transmettre les pid sans les octets qu'on ne gère pas, dont le crc.

@Priusfan La liaison bluetooth que j'ai pour mon bms (F2M03GLA) peut aller jusqu'à 921600 (baud rate). Elle est simplement considérée comme une liaison série data. Il doit être possible de gérer 500 kb/s en bluetooth ?
 
Concernant l' instabilité de pcm, je pense également que les faux-contacts usb sont une cause majeure de plantage.

En ce qui concerne le débit BT, j'ai paramétré à 500kbps, mais dans mon dev android qui passe son temps à solliciter des PIDs et attendre la réponse, le temps de latence est mauvais; idem pour torque...
l'explication est que le module BT RN42 de RealNetworks est une bouse...(explications communiquées par Ian Hawkins, le développeur de Torque).
c'est le même module BT dans le dongle OBDLINK BT (prété à Thierry) .

je me tâte pour acquérir le dernier modèle de OBDLINK , mais son prix est hallucinant...

Où as tu approvisionné ce F2M03GLA? , je pourrais peut-être faire un test de remplacement du RN42 installé dans l'obdlink (il est sur un petit module enfichable).
 
F2M03GLA Chez lextronic (Par défaut c'est 38400. Pour le modifier il faut une liaison série rs232 car on ne peut modifier ce débit que bt non connecté à un autre bt)
Je n'utilise que l'entrée/sortie série ttl et le bt est en mode esclave. Il dispose aussi de l'usb et d'autres entrée/sorties.
Il est automatiquement reconnu par le pc qui l'interroge. Un seul pc connecté à la fois.
Il est en 3v3.
 
Dans mon cas, je n'utilise qu'une prise USB où est branché l'OBDLink.
Je n'ai rien sur les autres prises USB et pas de GPS sur prise USB

Sinon, sympa ton petit module minuscule bluetooth, Planétaire :cool:
 
Pages vues depuis le 20 Oct 2005: 308,354,635
Retour
Haut Bas