can_usb eeePC

[priusfan]

nouvelles du jour

le programme est stable.
le développement est vraiment pénible : 4700 lignes en C; ce langage n'est pas tolérant (et je ne le connaissais pas).
la fréquence de la liaison est passée de 115,2 kbps à 230,4
le masque et le filtre ont été adaptés de façon à récupérer les infos des pédales de frein et d'accélérateur.
les tensions et débit ont été lissés (la fréquence d'échantillonage est d'environ 50-60 par seconde).
les pédales de frein et d'accélérateur sont "loggées" , le relevé de la pédale de frein est lissé , par contre pas celui de la pédale d'accélérateur.
ci-joint mon dernier relevé
colonne A : l'heure (normalement une ligne chaque seconde
colonne B : distance en km
colonne C : Intensité (moyenne sur la seconde); positif on consomme, négatif on récupère
colonne D: tension
colonne E: SOC (état de charge de la batterie) en %
colonne F: thermique
colonne G: vitesse en km/h
colonne H: temp batterie en °C
colonne I et J intensité max acceptées par la batterie
colonne K tension batterie ; (il parait que l'on peut calculer la résistance interne de la batterie en bricolant les colonnes C,D et K).
colonne L : je dois vérifier
colonne M&N temp catalyseur amont et aval
colonne O freinage valeur absolue à la pédale (lissée sur une seconde) ; je n'ai pas relevé le maxi: pas question de filer un coup de patin avec un ordi sur le siège passager...
colonne P accélérateur , valeur abs; le maxi semble être 200 , on peut donc diviser par 2.

to do : extraire la conso et c'est vraiment tordu...
ajouter GPS ; cela a l'air encore plus tordu car le démon gpsd n'est pas trés coopératif (tendance à prendre son temps et donc à tout ralentir)

 

[priusfan]

ajout conso

version actualisée avec ajout de la conso
colonne Q : conso en L/100 durant la seconde écoulée
colonne R; conso en L depuis le début du trajet
colonne S: conso en L/100 depuis début du trajet

colonne L corrigée
colonnes O & P recalibrées


bientot un de plus : celui de Ket

 

[Mik&Toy]

Je vous suis avec beaucoup d'intérêt.

Je n'ai pas été assez rapide pour profiter de la première vague de EEEPC , mais j'ai commandé et reçu le dongle Lawicel CANUSB, et j'espère le PC fin Mars.

C'est quelle valeur, finalement, la colonne L ?
Est-ce que l'heure (colonne A) est synchronisée aux rythme de l'ODB ? ou y a t'il un glissement / rattrapage au bout d'un cetain nombre de secondes

La résistance interne, ça doit être (D - K) / C

Sur le ScanGauge, on trouve aussi FPR= fuel pressure, IGN = ignition timing, LOD = engine loading %, Map = manifold absolute pressure, ainsi que LPH = litres par heure
par contre je n'ai rien vu à propos du calage variable des soupapes (VVTi)

 

[priusfan]

la colonne L correspond maintenant à la température moteur.

l'heure (colonne A) est celle de l'ordinateur. le CAN ne connait pas l'heure.
par ailleurs OBD est l'acronyme de On Board Diagmostic qui est associé à une norme,
ne pas confondre avec odb ordinateur de bord qui correspond plus à ce que désirent y mettre les gars du marketing.

en fin d'aprés-midi, j'ai procédé à 3 tests trés courts , je confirme la stabilité du programme ; je confirme également que sur des courts trajets et en conduisant comme un kakou, on arrive à des consos faramineuses.
l'avantage du système de "logging" , c'est que tout devient quantifiable .

le source actuel est le suivant : http://priusfan.info/canmonitor/mycanscan/graphcan/graphcan02_29.c
(virer la date avant de compiler).
demain, je procède à un test "scientifik" avec un scientifique du forum ; à suivre.
le cable de ket est pret.

 

[priusfan]

pour les zamateurs , 2 zextraits tout frais de ce qui est généré par le projet en question.
le premier , environ 50 bornes sur voie rapide , temperature 14° (je ne roulais pas à l' économie) et il y avait pas mal de rafales de vent.

le second correspond à un tour du parcours de référence Ile de France en cours d'étude. (il y a eu qqs brefs arrets pour prendre des notes)

je confirme la bonne stabilité du programme.
il sera peut-etre nécessaire de recalibrer distance/vitesse; j'attends pour cela que celui de ket soit opérationnel.
la comparaison (dans les mêmes conditions) avec le canview sera également trés intéressante. pour rappel ces 2 dispositifs utilisent rigoureusement les mêmes sources d'information

 

[Pont Vert]

Je serai partant pour des mesures comparatives sur le can view mais pas avant avril voire mai !

 

[priusfan]

ok pour la comparaison quand tu es dispo.

ci-joint src de la version actuelle qui affiche en L/100 (au lieu de kms/L).

comme d'hab, virer la date à la fin du nom.

par ailleurs, pour résoudre le pb d'intégration des données GPS, je pense procéder de la manière suivante:
au démarrage de l'eeePC, si un dispo GPS est reconnu,
gpsd va démarrer automatiquement puis un programme de génération de logs.
le fichier de logs aura la même convention de "nommage" que celui du CAN ,
càd son nom sera GPS_mm.jj_hh.mm.jj.xls
le contenu sera comme son cousin du texte tabulé ,
la première colonne contiendra l'heure (comme son cousin) , cela permettra un matching immédiat entre les 2 sources de données.

avantages de ce mode opératoire :

• je ne touche pas à l'usine à gaz existante

• les 2 programmes (en fait 3 car il y a le démon gpsd) vivent leur vie chacun de leur coté.

 

[ket]

Quelques interrogations

En ce qui concerne le freinage, on voit le degré d'enfoncement de la pédale de frein, mais est-il possible de voir quand le freinage plaquettes se met en route ?

Par ailleurs je pense que la valeur du freinage recharge peut se voir par l'accroissement de cette recharge ?

 

[Pont Vert]

Sauf mauvaise compréhension ou erreur de ma part, pour la synchro des mesures de différents appareils, l'heure donne une indication. Cependant c'est une estampille de l'enregistrement par le programme qui est elle-même désynchronisée par rapport à l'heure réelle de la mesure. Les estampilles de deux programmes ou les captures via deux circuits différents peuvent être désynchronisés de quelques secondes ; c'est ce que l'on observe sur l'ODB.

 

[priusfan]

précision temporelle:
à mon avis , il y aura peu de décalage car :

• le logging est effectué chaque seconde (horloge ordinateur).

• le timestamp enregistré provient de l'ordinateur qui procède au "logging" pour les 2 applications .

• la fréquence de rafraichissement des données varie entre 0,5 et 60 hertz (suivant le type de données); là où j'ai observé un réel décalage, c'est dans l'info vitesse: elle met parfois longtemps (+ de 2 secondes) à redescendre à zéro.

• en ce qui concerne le gps, l'erreur sur le décalage temporel est inférieure à celle sur la précision du relevé; ce qui me permet de dire cela, c'est l'expérience effectuée auparavant avec le canmonitor.

 

[Hybridébridé]

Impressions d'un béotien

Je suis épaté par cette idée de priusfan qu'il est train de transformer en réalité : une véritable télémétrie de la prius superposée au terrain ! une équipe de F1 ne ferait pas mieux !

Je me demande à présent quelque chose : parmi les paramètres mesurables, y at-il une combinaison de ces derniers qui puisse caractériser l'utilisation du mode B ?

...la comparaison (dans les mêmes conditions) avec le canview sera également trés intéressante. pour rappel ces 2 dispositifs utilisent rigoureusement les mêmes sources d'information...

N'oublies pas de remettre une monte pneumatique standard avant de procéder aux comparaisons !

 

[ket]

Grâce a priusfan le programme fonctionne au poil sur mon eeepc , encore une fois merci priusfan.

Première observation - il semblerait qu'il y ait un décalage de 2 à 3 secondes entre une action et sa représentation sur l'écran.

En tout cas un fabuleux outil pour approfondir nos connaissances du fonctionnement de la Prius.

Faudra maintenant que j'étudie la manière de faire des courbes pour analyser de manière visuelle et visible 2 ou 3 données en parallèle, ( question d'échelle ou multiplicateur pour certaines données).

 

[Mik&Toy]

un de plus

Ça y est, je viens d'acheter le EeePC.
Et maintenant je sens que je vais avoir besoin de votre expérience. Vu que je ne peux pas me déplacer chez Priusfan, j'aimerai bien que vous me fassiez un petit résumé pour l'installation dans l'Asus des divers logiciels et du CanMonitor.

Au sujet des valeurs enregistrées, et au vu des tableaux Excels déjà visibles, il serait utile d'y inclure l'état de la commande de vitesse (P-N-D-B-R).
Et venant du GPS, la connaissance de l'inclinaison AV-AR du véhicule me parait essentielle à l'interprétation des enregistrements.

 

[croco78]

Et venant du GPS, la connaissance de l'inclinaison AV-AR du véhicule me parait essentielle à l'interprétation des enregistrements.

Plutôt que l'inclinaison qui est très difficile à déterminer de manière précise pour calculer la variation d'énergie potentielle, il vaut mieux prendre en compte l'altitude que fournit le GPS.

Je vois avec satisfaction qu'on s'approche à grands pas du système d'acquisition que je recherche pour analyser plus finement ma consommation de tous les jours.

Pour celà, il faut que le PC reste sous le siège conducteur la plupart du temps, qu'il démarre le programme d'acquisition à la mise du contact et l'arrête à la coupure du contact sans avoir à faire de manipulation sur le clavier.

Est-ce envisageable?

 

[priusfan]

attn mik&toy
2 possibilités :
1) tu m'envoies par la poste une SDcard de 2 gigas, je duplique mon système dessus et, je te la renvoie
cela te prend 3 minutes pour avoir un clone de ma machine.
.
2) tu me passes un coup de fil et on en discute.
(je te rapellerai sur fixe)

attn croco:
tu connais l'adresse, tu es bienvenu pour discuter du projet.

 

[Mik&Toy]

@ Priusfan : les deux ! je commence par la poste.

@ croco78 : Est-ce que le GPS peut fournir les écarts d'altitude à chaque seconde avec assez de précision pour en déduire la pente, et donc le couple induit, et en finale le supplément de puissance, à comparer avec la position de l'accélérateur.

Ma version de eEEpC :
EEEPC4G-W017 / MB 701 rev 24 / SN : 820AAQ139018
RAM : 512MB SOD PC2-3200 CL3
sans connecteur PCIe

3 soucis:
1/ je découvre d'origine une RAM 512 en 3200 (pas standard) au lieu des 4200 annoncés
quelle vitesse dois-je prendre en 2 Go, 4200 ou 5300 ?
2/ avez vous testé une SD 8 Go ?
3/ dans ma version, il n'y a plus de connecteur PCIe sous la trappe arrière à coté de la RAM.
en avez-vous un sur le vôtre ?

 

[priusfan]

logging gps:
j'ai enfin réussi à adapter un programme de logging;
le résultat brut est visible ici
une petite transfo avec gpsbabel permet d'en faire un kml utilisable ici

il y a quand même un gros pb: ce salopiaud de programme verrouille l'autre; il faut que j'arrive à le faire tourner en tache de fond (comme un démon). hoper à l'aide !!!


à propos de précision de l'altitude avec le gps, mes résultats sont significatifs : beaucoup trop d'imprécision (cf ma feuille brute).

j'envoie des photos du mien tout à l'heure.
vitesse de la ram , je pense tout à fait secondaire car horloge processeur trés basse par rapport aux machines actuelles;
sdcard : ce qui importe c'est d'avoir de la HC ; ket en a une de 8gig sans pb, moi une de 4.

 

[Mik&Toy]

Pour la pente, il faudrait donc prévoir un inclinomètre, un capteur accélération/ gyromètre avec interface usb. on doit pouvoit faire çà avec les modules de Lextronic.
Peut-être même qu'un capteur de lacet comme celui de la Prius pourrait le faire en le montant perpendiculaire à son axe habituel.
Il y a aussi un capteur d'inclinaison sur le réservoir "canister" des Prius US.

 

[Hybridébridé]

En ce qui concerne l'altitude, avec Google earth, on a un fond topographique qu'on peut espérer fiable. S'il y a un moyen de rapatrier l'altitude donnée par Google Earth pour chaque point d'acquisition du GPS en x,y où la précision doit être de quelques mètres, on devrait obtenir le parcours en x,y,z avec une précision suffisante pour en déduire pente et vitesse ascensionelle, non ?

NB : J'ai des problèmes avec le lien vers le fichier brut xls

 

[Mik&Toy]

J'imagine que la pente moyenne d'un parcours puisse être assez précisement déduite des mesures GPS lorsqu'on circule sur une route dont la pente varie lentement, mais pas à l'arrêt, durant les manoeuvres (rampes de garage), ni lors des démarrages aux feux , là où l'on utilise une forte puissance.

 

[shadoko]

Lors des démarrages, tu n'utilises pas de forte puissance mais un fort couple (puissance = force x vitesse). Si la puissance est forte à vitesse nulle, alors le couple tend vers l'infini...

 

[Mik&Toy]

Oui, tu as raison, le couple c'est physique, n'empèche qu'il y a une puissance dissipée à perte quant un moteur électrique exerce un fort couple, donc un fort courant, à vitesse de rotation nulle, et que j'attends de vérifier l'ampleur de cette dissipation (effet Joule dans la résistance interne du bobinage moteur et pertes "fer" magnétiques) que je suppose non néligeable, d'ou la confusion liée à cette préoccupation.

 

[priusfan]

j'ai corrigé le lien

 

[Mik&Toy]

GPS pente

J'ai essayé une interprétation ici sous Excel du fichier GPS de Priusfan.
Ça chahute beaucoup du coté des altitudes, d'ou une estimation de la pente très problèmatique.

coté paramètres CAN, peut on changer la colonne Q (conso en L/100 durant la seconde écoulée)
pour avoirà la place la conso en miliLitres par seconde, ce qui permettrait de mieux apréhender les consos à vitesse nulle.

 

[Mik&Toy]

Photo du parcours pour ceux qui n'utilsent pas le tableur Excel