Sur LinuxFR.org j'ai vu aujourd'hui que le noyau linux sortait en version 2.6.25, et il y a, entres autres, Le support des bus de données de type CAN :

"Le support des bus de données de type CAN (Controller Area Network) a été ajouté au noyau 2.6.25. Ce format de transfert de données est utilisé dans l'industrie automobile et a été développé spécifiquement pour répondre à la problématique du temps réel embarqué dans un environnement perturbé electro-magnétiquement. Les données sont complètement protégées par des sommes de contrôle et le protocole est simplifié au maximum afin d'éviter les erreurs. Pour implémenter le bus CAN la première solution avait été de passer par le bus série traditionnel et de mettre les détails spécifiques au protocole en espace utilisateur. C'est la solution rapide et vilaine car elle ne permet pas de profiter de tous les avantages de la pile réseau Linux (mise en queue, maintien de la qualité de service, utilisation de l'API socket traditionnelle...etc) et elle oblige le développeur à coder toutes ces fonctions lui-même. La vraie solution est bien entendu d'implémenter ce format CAN de transfert de données au sein même du noyau et c'est à cette tâche que se sont attelés des ingénieurs de la société Volkswagen. Les patchs implémentant la nouvelle infrastructure PF_CAN ont été réécrits plusieurs fois car les développeurs noyau et les ingénieurs automobiles viennent de deux mondes différents et ont eu des difficultés à communiquer.
Jonathan Corbet a demandé à l'auteur principal de PF_CAN de résumer ses problèmes: "Plusieurs développeurs de CAN avaient l'habitude des micro-contrôleurs et avaient des difficultés à comprendre l'approche orientée réseaux. D'un autre côté les gens des réseaux ont souvent trouvé le design de PF_CAN étrange et difficile à comprendre (pas d'adresses, pas vraiment de couches) par rapport aux autres protocoles. En conséquence, cela nous a pris plus d'un an de discussion sur la liste de diffusion socketcan avant de nous mettre d'accord sur l'architecture actuelle."
Naturellement, étant donné les cycles longs de l'industrie automobile, il va falloir attendre un certain temps avant de trouver du Linux+PF_CAN dans nos autos mais on ne peut que se féliciter de l'approche choisie par Volkswagen de collaborer avec le monde du libre au lieu de développer ses outils dans le secret et sous une licence propriétaire."

http://linuxfr.org/2008/04/17/23919.html

carto ICE

En regard de cette cartographie du moteur de la Prius, j'ai trouvé dans les paramètes du CAN, quelque chose qui y ressemble :
[/IMG]
où l'on voit une relation entre le régime du thermique et l'injection d'essence (-> consommation -> puissance) dans des zones privilègiées de fonctionnement.

Nuage

C'est fou ce qu'on peut lire dans un nuage.
Evidemment il me vient des questions à l'esprit ...

-les points 'isolés' au-dessus de 1500tr/mn et disons en dessous du trait horizontal 900 sont-ils réels ou des parasites.
Parce que s'ils sont réels il y aurait alors l'explication du graphique duquel j'ai sorti la cartographie et qui indiquait des zones de fonctionnement tout à fait en dehors des indications de Toy.

-les points isolés en dessous de 900 tr/mn sont-ils possibles : injection de carburant à 0 ou quelques centaines de tours/minute. Etonnant, je pensais que le thermique était d'abord lancé (et en face MG1 a les moyens) avant de recevoir la moindre goutte ou vapeur.

Très instructif, en fait.
A+

Trés juste interrogation sur la validité des enregistrements réalisés. C'est toujours LA question fondamentale !

Les moyens de mesure à ma disposition donnent pour l'instant une valeur moyennée par seconde. Donc il peut y avoir des points du nuage qui sont fantômes - il y en a forcément - soit par les ordonnées, soit par les abscisses, soit par les deux.

Je cherche pour l'instant à identifier des paramètres donnant les valeurs verticales : consommation, puissance, couple. J'en ai donc trouvé. Il me reste maintenant à les accoupler, à leur cadence d'origine (entre 60 et 100 Hz), le problème étant qu'ils arrivent séparément, et à des rythmes différents.

Et je dois ajouter , avec un décalage temporel qui est parfois très visible, entre des mesures de capteurs et des valeurs calculées par les ECUs.

Suite de mon investigation sur les paramètres utilisables à partir du CAN :

Zoom d'un enregitrement effectué lors d'un redémarrage après le passage d'un péage.
Forte accélertion au départ (à partir du trait rouge), puis gèné à deux reprises par un véhicule plus lent, puis établissement à 128 km/h (134 compteur).
Noter le décalage entre l'appel immédiat de courant pour MG2 , et le démarrage du thermique, environ 3 secondes plus tard.
Noter également le freinage régénératif enclenché dès le lacher de l'accélérateur, sans appui sur la pédale de frein.
Noter le chevauchement des régimes ICE (Throttle) et MG2, correspondant aux phases d'accélération.
Reste à trouver le moyen d'utiliser les 3 paramètres ICE allumage injection et extra et d'en découvrir d'autres !

à quoi correspondent les 2 premières courbes DisAmp et ChgAmp ?
à ma connaissance, il y a une seule donnée

Whaou !

Fichtrement intéressant.😎

Etrange en effet DisAmp et ChAmp Décharge et Charge en même temps...

C'est bien les freins à disque que l'on voit en rouge (brake) ?

Il y a une mesure toutes les ?? secondes ??

J'arrête mes questions là ..........

A+

Le paradoxe des valeurs moyennes : il peut y avoir dans une même seconde une partie de la seconde consacrée à la charge et l'autre partie à la décharge.
Bien que provenant de la même mesure, le courant batterie transmis à une cadence d'environ 60 mesures par seconde, j'ai dû scinder en deux et cumuler séparement les valeurs positives et les valeurs négatives, pour ne rien perdre.
C'est pour cette raison que j'ai fait apparaître le quadrillage vertical à la seconde, et les petits tirets sur les courbes = 1 point par seconde.

Les informations sur le freins ne sont pas celles de la pédale seule, mais la consigne finale de pilotage (pédale + calculateur) qui s'appliquent à l'ensemble du dispositif (MG2 en générateur + freins à disques + ICE en compresseur)
Il doit sûrement exister quelque part séparement la pression du pied sur la pédale, et la pression des mâchoires de disque. Je cherche.

Pour l'instant, on peut avec les données fournies, distinguer la partie régénérative du freinage, en suivant l'évolution du courant de charge lors d'une décélération du véhicule.
Mais, pour tout ce qui concerne le courant batterie, il y un manque de visibilité sur la part de courant qui va et vient à travers MG1, et qui peut faire par exemple que du courant généré par l'un des deux moteurs électriques soit intégralement pompé par l'autre, sans que rien ne soit dérivé vers la batterie, ou tout autre "arrangement" entre eux. MG1 est très "sournois" vu du CAN !

bonjour,
hier j'ai acquis un eeePC 900 chez le corsaire (pour 399 zeuros).
cette machine est équipée de 2 disques ssd de 4 et 8 gigas, de 1 giga de ram.
il a le même format que son ainé le 701.
xp est préchargé; l'écran occupe toute la largeur du couvercle et a une résolution de 1024x600.
son alim est passé de 9 à 12 volts.
la batterie a une capacité de 5200mAH.

j'ai été stupéfait du bon comportement de xp sur cette machine; c'est probablement dû au temps d'accés de la mémoire flash qui tient lieu de disque dur.
j'ai installé dessus l'application canmonitor ; elle tourne normalement.
je vais également y tester l'application mycanscan sous linux.
la partie graphique de cette appli doit etre adaptée à la plus grande résolution et de toute façon l'usage des fontes est à reprendre intégralement (trés mauvaise définition, effets d'escalier).

eeePC 900, c'est quoi ? un ordinateur ? 😱 😱 😱

J'imagine que la question est une blague !

On en parle dans presque tous les messages ci-dessus et il y a même des photos.

Non, c'est un test pour voir si on est aussi zen qu'on le dit !!!

Ah bon !!!!

Ca gratouille (*) de plus en plus, je vais peut-être acheter un convertisseur odb2->usb (j'ai déjà un petit portable sous win xp)

Dans le message 110 il y en a un avec en plus sortie coudée sur l'odb2. Où le trouve-t-on ?

Sinon j'ai vu sur ebay un convertiseur à base d' elm327 par exemple Celui-ci (ils sont plusieurs à vendre exactement le même équipement)

Le soft Scantool a l'air freeware ?

Qui sait ?
(*) Pour Mik&Toy: pas seulement dans la montée...

Pour la prise coudée, on en prend une droite, on la coupe en onglet, et on ressoude le plastique au fer à souder. C'est ce que j'ai fait. Par contre il va aussi falloir que je fasse subir ce traitement à la prise USB, chose moins aisée mais faisable. je pense vous montrer ça bientôt.

Première étape : l'équipement

Je suis très impressionné par vos développements sur eeepc.

Quelques petites questions concernant le convertisseur odb2->Usb
Et j'essaie d'évaluer le coût:
1) quel convertisseur utilisez-vous ?
2) est-il prudent au sens sécurité du véhicule (car si j'ai bien compris via la prise diag il est possible d'envoyer des paramètres à la voiture, risqué ?)
d'utiliser un convertisseur tels que ceux qu'on trouve sur ebay (cf mon message juste au dessus).

Concernant un premier logiciel : scantool
3) je ne souhaite pas installer linux sur le portable que j'ai, mais garder xp.
Et donc dans un premier temps utiliser scantool.net par exemple qui semble freeware ?

Qu'en pensez-vous ?

Tu peux installer Linux en parallèle d'XP.

Pour l'instant les ordres que l'on sait envoyer au calculateur de bord sont des demandes d'acquisitions ("data on request"). Pas vraiment risqué !
Si il y en a d'autre sorte, je suis preneur. Ca me tenterai bien de pouvoir imposer l'arrêt du thermique en "glide" sans avoir à titiller l'accélérateur !

je vous invite à aller visiter ce site http://www.hybrid-synergy.eu/showthread.php?tid=3060

je ne parle pas l'italien, mais je m'y suis inscrit....

Tient,comme par hasard,on y retrouve "the tramp"

Quel dommaaaaage de ne pas parler italien.

(Trigone est forcément plongeur !!!!!!!!)

Avez-vous vu les post 54, 63 ?
Ils seraient en bluetooth entre le can et le pc ? Là

Thank's Priusfan.

bonjour,
perso , je ne conseille pas la version "dent bleue" .
pourquoi :

• parce que le débit est trés inférieur à l'usb.

• parce que le paramétrage et le fonctionnement du BT sont assez fantaisiste (par rapport à un port série classique ou un port USB).

• parceque cela fait un gros truc qui pendouille à la prise de diag au lieu d'une prise relativement petite avec une sortie latérale.
• et en plus , si cela ne suffisait pas, cela coute + cher.

consommation réelle.

bonjour,
je vais bientot recevoir du japon un petit dispositif permettant de suivre la consommation réelle.
le principe est de récupérer et traiter la durée de l'injection ainsi que l'information de vitesse.
ce dispositif permet d'afficher quelques infos sur la conso et également de les communiquer par port série.
le programme canmonitor utilise cette information et permet donc de suivre au plus prés cette fameuse consommation réelle.
qqs détails ici:
http://priusdiy.fc2web.com/NENPIKEI.html
le schéma tecnique est là: http://priusdiy.fc2web.com/image/M-1_SCH03.jpg

Bonjour,

Intéressant; simplissime; limpide.

Il te faudra quand même nous faire une démonstration, à l'occasion

À Martigny ?😱

Bonne journée, et merci pour ton sens des recherches "pointues"

Dis donc Prius56, tu veux bien attendre que Priusfan ai fini avant de faire des soudures sur ta PRIUS !

Mais comment as-t-il fait pour décoder du japonais ? limpide qu'il dit !

Fortich les retraités, de nos jours...