supermid

j'ai reçu hier le dispositif en question.
je l'installe demain.
voici qqs détails:

Hi Francois,
Thank you for your waiting.

Just sent you the SuperMID M-1.5.


The cable color for the interface box is...
red: 12V
brown: GND
yellow: INJ
purple: SPD

I have the ECU connection point for Japanese PRIUS.
http://priusdiy.fc2web.com/TACHO.html#ecu
Hope you'll find yourself for your EU model.

There are six buttons on it.
On the right, from top to bottom...
[MENU]
[UP]
[DOWN]
[ENTER]
Please refer to the attached operation chart.

On the left, there is one button works as same as [DOWN]
button which is used for changing display channels on
the normal mode.

On the back, there is a RESET button. This one should be
used for an emergency purpose only, such as no display
when power-on.

The Dsub-9 female connector is for the RC232C communication.
It sends following data every 0.5 second which is compatible
with the Prius CAN Monitor software using 38400bps.

000330,000086,00071,0756
000330,000086,00072,0740
000331,000086,00072,0744
000331,000087,00073,0744
000332,000087,00073,0000

The each column means...
000330: 330 seconds since power on
000086: 860 m (10m unit) drove since power on
00071: 71 milli-liter consumed since power on
0756: 7.56 milli-second injector on time
You can see the data using any terminal emulator software.

There is one red LED on the left.
It shows the status that fuel is injected on normal mode.
When you keep pressing the MENU button when power on,
you're in programming mode, the red LED is on and
no display on the LCD.
When new version software on the Atmega168 is available,
I'll send it to you, then you can update the software
by yourself using the Atmel's AVR Studio 4 utility.
http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2725

That's all as of today.
Please feel free to ask any questions you have.

Cliquez pour agrandir...

le programme canmonitor permettra d'établir une éventuelle corrélation entre le temps réel d'injection et ce que l'on récupère sur le bus CAN.

et + 5

Je viens de me procurer un convertisseur Odb2->Usb.
Une des premières remarques faites est que la vitesse lue (à l'aide du logiciel scantool.net) est la vraie (celle également lue à l'aide d'un gps) et est donc inférieure de 5 km/h avec celle affichée par la PRIUS.

Alors ce serait donc à l'insu de notre plein grès que Toy rajouterait 5 km/h !!!

Intentionnellement, vu que tout ceci est du numérique !

bonsoir,
quel est le type de ton interface ? (je parle ici du type complet, pas de la connectique)

j'en connais 2 pour lesquels on a un peu de soft spécifique prius.

• à base de elm327
• à base de canusb (http://www.canusb.com/)

pour la version canusb, il y a des dev sous linux et windows
pour elm327 pour windows.

Salut, Priusfan

Elm 327.
Et mon pc est sous win xp

Je suis très très interessé par un soft car scantool.net est Hoorible.

A+

des nouvelles du japon à propos du SuperMID:

Hi François,
Thank you for the status.

The 2572 distance parameter is based in the industry standard
and the display value on trip and odo of the vehicle should be
dead on with the SuperMID because we use the same algorithm.
The real driving distance and displayed distance can be varied
by tire size, air pressure, tire wear and others, but our
observation is within 0.5% error with the standard tires.
So, I think you don't have to change the distance parameter.

There is another story on the fuel parameter.
The injector size has some manufacturing tolerance, say approx
2%, and you can buy expensive injectors within 1% variance
calibrated by a tune-up shop.
As you may already know, our MFD mileage number is approx 2.5%
better than the real world.
The default 14052 is our average number for the real fuel usage,
you can change it to approx 13700 to meet the MFD number if
you like.

Thank you for the elm327 number.
I also think the 160 frames per second is too small.
I believe it is something like 1500 or 2000 frames per second.
Anyway, please keep up a good work.

Regards,
Yoshi Mimura

Cliquez pour agrandir...

bonjour,
ces derniers temps, j'ai pas mal bossé en VB6 pour utiliser l'interface à base de elm327.

j'ai décidé d'utiliser VB6 plutot que les versions plus récentes pour des raisons de performance et également car il est impossible d'installer visual studio sur un eeePC car il est nécessaire de disposer de 1,4 giga sur le disque C: .

j'ai également décidé de créer des petits programmes indépendants de capture et d'exploitation des données (pour des raisons de mise au point considérablement facilitée et de façon à avoir des processus indépendants , càd faire du multithreading sans trop s'embéter).

j'utilise un minihub USB car cela commence à faire de la filasse ....
il y a un truc empoisonnant : les ports com du GPS et du SuperMID changent souvent et il faut donc les vérifier systématiquement; on peut imaginer au démarrage une boucle de détection de l'emplacement des dispositifs...

ces programmes envoient leurs données en UDP , cette technique est intéressante car il n'y a pas d' "acknowledge" donc aucun frein au niveau des programmes de capture , si le (ou les) programmes d'exploitation des données sont à la traine,, cela n'influe pas sur les captures.

CanSPY collecte les données du bus CAN , il communique avec l'interface USB à 500kbps. le filtrage des trames est applicatif. j'en capture entre 1200 et 1400 /seconde dont environ 1/3 nous intéresse.
les données récoltées sont émises en UDP sous forme de trames 10 fois par seconde.

MidSPY collecte les données de l'interface SuperMID , il communique à 38400 bps avec l'interface et envoie également une trame en UDP chaque seconde.

GpsSPY collecte et interprète les trames NMEA d'un inforad et retransmet les infos latitude,longitude et vitesse sous forme de trame également en UDP.

POC (proof of concept) écoute ces 3 fournisseurs de données et écrit chaque seconde dans un fichier log (séparateur ; ).
ce dernier programme essaie de calculer les valeurs moyennes des 10 trames/sec en provenance du CAN , et de temps il plante car il n'y a pas encore de gestion des erreurs.

j'ai mis l'ensemble de ces trucs sur mon ftp dans le dossier canmon6, ainsi que les premiers résultats de capture.
cela devrait permettre de trouver une corrélation entre les paramètres de consommation du CAN et la conso réelle mesurée par le SuperMID.

@suivre

ps: ci-joint un lien vers un fichier d'analyse

une petite explication à propos de la conso en provenance du supermid.
copie d'un mail de l'auteur du produit:
[QUOTE]Hi François,
Thank you for your data. Also, received the whole package.

Nice to know the CAN_injector/1.5 is very close to
the SuperMID one.

Let me explain how I measure the fuel usage...
- The injector width number is raw number.
- There is some mechanical delay between the electric pulse
width and the actual mechanical open time.
- I assume the delay is 0.5 msec.
- The SuperMID counts the electric pulse width in 0.005 msec unit.
- When the pulse width is 6 msec, the count value is 1200.
- The program extract 100 count(0.5 msec), then the 6 msec
count(1200) becomes 1100(5.5 msec).
- When the accumulated the count value becomes the fuel parameter
(14052), the 1 cc counter is incremented.
- We saw the fuel usage value is within 1% error, therefore
the 0.5 msec assumption is acceptable number.

Hope this helps your project.

Anyway, the Google Earth GPS image is very interesting.
Thank you again for your great work.

Regards,
Yoshi
[/quote]

consommation instantanée exprimée en débit.

j'ai demandé à yoshi la chose suivante:

>
> I am trying to find the factor between injection_ms, RPM & speed to get mpg.
> I have no success at this time.
>
> In fact, I am trying to get fuelflow in L/H
> I think it could be something like:
>
> flow = k * injection_ms * RPM
> or flow = k * (injection_ms - 0.5) * RPM
>
> and after, it is easy to get mpg in L/100km (like we do in europe)
> mpg = flow / speed
>
> Do you have any ideas ???

Cliquez pour agrandir...

et voila sa réponse , il y a un peu de grain à moudre pour les forts en math:

Hi François,
Thank you for your idea and I agree it is good to know
the instantaneous fuel usage.
My SuperMID's instantaneous km/L value is still accumulating
the injector ON pulses during 32 speed sensor count, and
the accuracy is so so.

The key number is the 14052(for 0.001 liter) fuel parameter.
Let's do calculation for liter/minute.

I: observed injector pulse width(msec)
R: engine rpm number

The SuperMID counts only one injector and the engine is
4 cycle. This means two injections per revolution, then
we need to adjust the rpm number as R/2.

liter/minute = ((R/2)*(I-0.5)/0.005)/(14052*1000)
then
liter/minute = R*(I-0.5)/140520

I confirmed the formula works using my pulse simulator.
Please let me know your observed results.

Regards,
Yoshi

Cliquez pour agrandir...

je ferai un grand trajet en milieu de semaine prochaine et j'espère collecter suffisamment de données pour valider cette approche...

dev sur eeePC.
je m'embète comme pas permis avec visualstudio pour essayer de mettre au point un pgm de visu.(qui utilise les données transmises en udp par les 3 pgms précédents).
je développe et teste sur un portable trés puissant (et assez encombrant) puis je transfère l'appli via une clé usb vers l'eeePC

j'arrive à visualiser en temps réel sur des compteurs des infos transmises 10 fois par seconde; l'eeePC tient fort bien le choc .
sur l'image jointe, 3 compteurs sont gérés :Amp, Volt et RPM. (les 3 compteurs du bas) on voit à coté la charge CPU.


yapuka faire des beaux compteurs et organiser tout ça......

C'est bien beau !

Je sens que je vais devoir me commander l'ELM327 !

2 questions :
1/ y a t'il moyen d'afficher un moniteur de charge (task monitor) sur le EeePC 700 sous Linux ? pour voir ce qui coince toujours avec mes modifs de graphcan

2/ pourrais-tu me montrer l'évoution du nombre d'acquisitions par seconde, avec ton appli, d'un paramètre rapide, comme le courant batterie ?

J'ai effectué des calculs sur la conso à partir du paramètre d'injection. ça suit bien l'ODB, mais je dois corriger la vitesse transmise par le CanUsb de 5% en plus pour tomber sur les distances relevées à l'écran de l'ODB. et je dois appliquer un facteur 1500 (1460 en fait) sur le produit timing x régime pour tomber sur le chiffre de conso de l'ODB.

Salut, priusfan
C'est très zoli.
Donc ton eeePc est sous WinMachin ?

Que comptes-tu mettre comme indicateurs ?
à priori
-Tr/mn
-Ampères batterie Ht
-Tension Ht, mais n'est-elle pas toujours liée au % de charge SOC
-Vitesse ?

Température thermique ?
SOC ?

Et peut-être un jour
Pourcentage ou durée de fonctionnement du thermique
Durée du trajet
...

Bon je sais, c'est si simple d'écrire un message et autre chose de mettre au point un prog.

Voilà c'est un GROS encouragement.

A Mik&Toy, attention j'ai des soucis entre PriusCanMonitor et mon Elm327 direct du pays des jeux olympiques. Ok seulement en dessous d'environ 55km/h.

A+

Ah Ah des pbs sur l'ELM327, mais encore ? cela ne viendrait-il pas du seul logiciel PCM. Je m'inquiète !

Pour les idées d'affichage, il y en a une qui me taraude à chaque modif du logiciel Graphcan que je tente de réussir, c'est la recirculation du courant entre MG1 et MG2. Le courant batterie est un faux frère en ce qui concerne le réel courant de traction ou de freinage qui circule dans MG2. On serait tenté à première vue de les confondre, mais des fois il doit en avoir beaucoup plus dans MG2 que ce que la batterie fournit, des fois beaucoup moins.

Le problème que je rencontre est que PCM fonctionne parfaitement jusqu'à une vitesse d'environ 55-57 km/h et là il se met en erreur :

Erreur d'exécution 340
L'élement du groupe de contrôle 51 n'existe pas. (Je l'ai en français maintenant)

Il faut attendre d'être redescendu vers 50-52 km/h pour qu'il ne plante pas, sinon dès le lancement il plante.

Sauf une seule fois où il a planté au dessus de 60 km/h !

P.S. Ma config: pas de GPS. Win Xp. La vitesse du port est 9600.
Par contre ScanTool 1.13 fourni avec l'Elm327 ne plante jamais en 9600. Mais il ne gère pas les codes PRIUS, n'enregistre rien et l'affichage est sur 8 écrans etc...

Concernant la vitesse je ne sais pas si on peut aller audelà de 9600. Faut que je fasse des essais.

Quelques résultats:

Concernant les courants batterie Ht j'ai constaté que quand les flèches batterie sont éteintes, le courant est 2 à 3 ampères de décharge.
Et même quand on a un "début" de flèche verte on peut être en train de décharger un peu encore (1 ampère environ) ! Quelqu'un a déjà constaté ?
En tout cas ça colle avec des constats faits où lors de longs glide la batterie pouvait perdre une barre voire 2.

A partir d'autres mesures faites en sortant de chez moi en montant la côte à froid, je constate que le thermique se laisse transporter et que tout vient de la batterie pendant disons 45 secondes. Ensuite on peut accélérer au thermique seul progressivement. De là à se demander s'il ne faut pas le laisser chauffer avant pour éviter d'utiliser la batterie.....

En combinant les 2 soft j'ai pu déterminer par exemple que sur un trajet de 15 km A et 15 retour fait entre 60 et 70 km/h le thermique a tourné 24% du temps à l'aller et 28% au retour donc en moyenne 26%, en Pulse & Glide. C'est peu. A l'aller vitesse moyenne 43 (moteur froid+côte..) et retour 50 km/h.

Voilà.

A propos de la place mémoire restante sur EeePC 900 :

Il y a moyen de dégager plus de 1 Go du répertoire C: en déplaçant un sous répertoire de windows "C:\Windows\SoftwareDistribution\Download" vers D:.
Egalement en créant un deuxième répertoire surr D: pour le Fonts encombrantes (près de 500 Mo, suivant programmes ajoutés).

Ce qui permet d'y installer la suite VisualBasic

Mik&Toy à dit:

A propos de la place mémoire restante sur EeePC 900

Cliquez pour agrandir...

t'es passé du 700 au 900 ?
Avec Linux ou XP ?
Je suis bien tenté par le 901 ou le 1000h.... (sous XP)
(je galère trop avec Linux quand les mises à jour auto se font mal ! icônes disparues, blocage, etc..)

Oui, j'y suis passé ! Comme Priusfan. J'ai les deux , le 700 en Linux pour le CanUsb & graphcan, et le 900 pour attendre les développements en cours de Priusfan.

Le 900 tient la route avec un vrai XP comme les grands et toutes les applis qu'on veut sur D: (8 Go), comme VB6. Avec seulement 4 Go sur C: pour le système, ça nécessite des accomodations comme susdit. Et j'ai toutes les mises à jour, SP3 et IE7 et Java et .NET , etc...

Etonnant, les perfs du 900 ! j'ai même installé un jeu assez conséquent (5 Go sur clé USB) le GTA-SA (pour les connaisseurs) sans le moindre lag ni saccade dans les graphiques.
Et il me sert aussi comme balladeur vidéo pour les DVD et DivX avec un disque dur externe et comme terminal TNT.

En voyage, un régal !

Mik&Toy à dit:

Le 900 tient la route avec un vrai XP comme les grands et toutes les applis qu'on veut sur D

Cliquez pour agrandir...

Le 901 est identique sauf qu'il est sous Atom (autonomie augmentée) et il a le bluetooth.
A noter que DMH a aussi acheté un 900

mais que devient le Graphcan ?

Je suis toujours en train de me battre avec l'appli Graphcan sur EeePC 700.

A proppos de l'original, j'ai bien vu que la collecte des infos batterie (charge, decharge, et freinage régénératif) ne permettait pas, étant donné la démarche retenue, d'exprimer les puissances avec exactitude, les courants et les tensions étant cumulés séparement. La méthode retenue dans la version Priusfan est nettement plus précise, les puissances étant calculées pour chaque échantillon reçu, puis cumulées chaque seconde.

J'ai néanmoins remarqué un problème lié à la régularité, ou non des échantillons reçus : il faudrait, soit s'assurer que la cadence est constante, soit si il s'avère qu'elle ne l'est pas (et j'en ai bien l'impression) tenir compte pour chaque échantillon du temps qui le sépare du précédent.

Et c'est vrai aussi pour les calculs qu'on envisage pour la consommation d'essence. Et aussi pour une meilleure précision sur la distance parcourue, qui est actuellemnt obtenue en sommant les vitesses de chaque échantillon pour chaque seconde (l'info de base du nombre de tours de roue n'étant pas transmise).

et bien d'autres choses , probablement , sur lesquelles je ne suis pas encore tombé !

En ce qui concerne les mesures réalisées avec le can view, les relevés ne sont pas étalonnés dans le temps.

J'ai nénamoins constaté que les intégrales en se basant sur des constantes de calcul du temps, de la vitesse, et de la consommation instantannée donnent des résultats assez répétitifs. Ces constantes varient relativement peu d'un essai à l'autre.

Dans l'ensemble les mesures doivent être bonnes avec une marge d'erreur de quelques pourcents. Les courbes en fonction de la distance parcourue ou du temps représentent probablement assez bien la réalité.

Je ne cois pas qu'il soit possible d'obtenir des mesures continues précises au pourcent près. De même toutes les observations montrent des variations importantes entre des essais dans des conditions similaires de 10 à 20% dans les valeurs mesurées sans que je ne puisse identifier les causes de ces variations.

de mon coté, je laisse tomber les dev avec vb.net, c'est vraiment trop galère...
je pense me rabattre sur des composants en flash inclus dans une appli en VB6.

en ce qui concerne la capture des infos transmises sur le bus, je suis sur de les capturer toutes et l'échantillonage est assez régulier.

en ce qui concerne le truc de planétaire, une communication à 9600 bps est ,à mon sens, vraiment insuffisante. je pouvais communiquer à 115200 avec l'appli sur elm327

vb6 + flash

enfin, j'arrive à piloter du flash depuis VB6.
les ressources sur ce thème sur le web sont quasi inutilisables / inexistantes et cela m'a pris un temps fou pour y arriver

les +

• permet de gérer des vrais objets graphiques

• c'est stable

• peu de charge CPU

les -

• nécessite de manipuler le flash (donc de le connaitre un peu)

• en VB on ne peut gérer les transparences ni les superpositions;cela impose d'inclure le fond dans le flash.

ci joint un lien vers un test qui manipule 3 aiguilles indépendamment ; les valeurs sont modifiées 50 fois par seconde.
le source est dans le zip ainsi que les trucs en flash

je vous invite à regarder ce qu'il est possible de faire en flash ici

l'écran ci-dessus correspond à une image prise en charge forcée.
les programmes interagissent correctement
le rafraichissement a lieu 10 fois / seconde.

tous les sources sont ici

Super parce que :

La version PriusCanMonitor corrigée (elle dépasse le 50 km/h) et un peu optimisée, en 9600 bauds on obtient:
-une trentaine de mesures par secondes
-dont une quinzaine de mesures qui nous intéressent (vitesse, rpm, conso....)
-une mise à jour du fichier csv 2 fois par seconde
-une mise à jour de chaque paramètre toutes les 1à2 secondes.
Mais sur un trajet on voit quand même une forte pointe de courant au démarrage du thermique : + de 100Ampères, ce qui échappait aux versions précédentes.

Tout ce temps perdu sans doute à cause de l'application successive de 5 masques et filtres.

Le seul intérêt de cette version est l'achat d'un Elm327 très bon marché (venu de H.K il innonde la marché avec des débits toujours limités à 38400b et encore le mien ne le passe pas et reste à 9600b)
De toute façon il y a deux catégories d'Elm327: ceux qui passent les 500kb et les autres.
Avec 500kb Priusfan ne perd rien sans filtre et masque, les autres obligent filtres et masques et on a les débits et taux de rafraichissement indiqués ci-dessus.

Les modèles acceptant les 500 000b sont très rares et + chers.

A+

speedy 327

Vu les difficultés que j'accumule à essayer de faire fonctionner le logiciel Graphcan sous linux/Xandros/EeePC701 avec l'interface CanUsb, je suis client pour une version rapide de ELM327, et le développement de Priusfan.

Peut-on envisager une commande groupée / y a t'il d'autres amateurs ?

Interessé/achat groupé. Je suis actuellement en train de faire le tour de ce qu'on trouve/net:
Il y a:

En allemagne
ElmcanII-USB: http://www.obd-ii.de/kabelst.html
(C'est celui de Priusfan qui passe le 500kb prouvé) livré 126€ à l'unité

Elmscan: http://www.kds-online.com/Shop6a/catalog/product_info.php/cPath/21_86_90/products_id/2189
J'ai un doute sur la vitesse, sur le site (que l'on peut demander en anglais) il y est indiqué 500kb à un endroit mais plus bas 115200b. Livré 115€

En Angleterre.
Ecufix: http://www.ecufix.com/shop/index.php?main_page=product_info&products_id=199
Livré 92,56€ avec rallonge droite.

Mais avant d'acheter il faut être sûr du débit de 500kb écrit sur le site, ça c'est une précaution suite à mon Elm327 soit-disant passant le 38400b (mais c'est un clône d'Elm327, pas le modèle original Canadien)

Qui d'autre est intéressé par un achat ?

A+