Pcm

thierryb

Participant hyperactif
Inscrit
20 Janv. 2011
messages
1,968
Score de réaction
1,032
Localisation
Yvelines
Véhicule
Prius 2 sol pack ipa 2008 verte
Bizarre, je n'ai pas vu de discussion sur PCM en général
Si je me suis trompé, il suffira de déplacer mon message.

PCM permet d'enregistrer de nombreux paramètres.
Mais je ne suis pas sur de les comprendre tous.

Il semble que la consommation est calculée à partir du paramètre 520, multiplié par RPM (&H3C8 ), multiplié par le temps passé depuis la dernière mesure du param520 ou du RPM, ou de la réception du paramètre &H3CA (vitesse, mais pas utilisé dans PCM), mais pas calculé quand la vitesse est obtenue par le paramètre &HB4, ni quand le RPM est obtenu par le paramètre &H1C4 pour la P3; et pour la conso totale, il faut sommer toutes ces consos.

Ce paramètre 520 est enregistré dans la colonne notée inject

Le paramétre Rpm, qu'il vienne du &H3C8 ou du &H1C4 est enregistré dans la colonne Tpm

Mais PCM enregistre dans une autre colonne Tr/mn Ice. Cette valeurs est très corrélée à Rpm, encore que l'on puisse trouver des bizarreries. Elle est calculée à partir du paramètre &H348, mais n'est presque pas utilisée.
Quelles différences entre ces deux mesures ? Pourquoi préfères tu Rpm ?

Par ailleurs PCM enregistre deux autres paramètres liés à l'injection dans les colonnes MlEssence et MsInject par la réponse 7E0 02 21 F3

J'aurais pensé que la multiplication de les deux paramètres m'aurait donné comme valeur celle du parametre 520, ce n'est pas le cas, même s'il semble y avoir parfois une corrélation. (Je fournirai un graphe plus tard)

Planétaire peux-tu m'expliquer les liens entre ces 3 valeurs, s'il y en a.

Mais ce qui m'inquiète, c'est que je peux avoir une injection (520) à 0, alors que Ml et Ms sont tous les deux différents de zéro.

Je pense avoir la réponse, tu mets artificiellement le paramètre 520 à zéro quand le Rpm est égal à O ; mais tu ne le fais pas quand tu reçois le RPM, mais quand tu écris le 520 dans le fichier excel. Pourquoi le fais-tu aussi tardivement ? Ne devrait-on pas aussi le faire (mise à zéro) pour ces deux paramètres aussi ?


Planétaire, il me semble que je peux enlever le calcul de conso lors de la réception du paramètre &H3CA. Il me semble qu'il y a un risque d'erreur de calcul de la conso dans le cas de la P3, puisqu'un changement de RPM n'est pas tout de suite pris en compte comme sur la P2. Mais cela doit être négligeable. Dans ce cas, autant simplifier aussi pour la P2.

Merci par avance planétaire.
 
Pcm a évolué avec le temps. Plusieurs programmeurs on travaillé dessus.
Donc il peut y avoir des tests qui seraient mieux placés.

La conso est calculée d'après l'injection 520, les tr/mn et le temps écoulé entre 2 calculs.

Le test qui raz la valeur520 si rpm = 0 fait lors de l'écriture est en effet tardif. Le commentaire associé n'est d'ailleurs plus à jour. Je ne pense pas que cela changera les résultats en volume de carburant consommé car dans le calcul de rpm en 3C8 si celui-ci est à 0 la multiplication donnera 0.

Une des difficultés avait été le paramètre 520 qui n'est plus émis quand le thermique tourne sans injection. C'est une logique qui lui est propre.

Pour rpm il avait été utilisé par les précédents développeurs et j'ai conservé ce pid.
La vitesse était auparavent le 3CA mais j'avais montré qu'il était trop en retard et pcm utilise 0B4. Toutefois le calcul n'a pas été déplacé vers 0B4 pour toucher le moins possible au programme. A priori il peut être déplacé dans le pid 0B4 mais pas enlevé. Le calcul doit être fait chaque fois que les tr/mn ou la vitesse changent. Le retirer de cet endroit réduirait la précision du calcul.

Pcm ne fonctionne pas pour P3 ou Auris. Juste quelques pid lus.

Il faut bien noter que les pid arrivent avec un décalage temporel. On ne peut par principe avoir deux messages en même temps. Donc on peut avoir le pid520 à zéro et les pid actifs avec un léger retard. Surtout celui actif qui donne la quantité injectée qui est visiblement une intégration faite par l'ecu d'après la durée d'injection.
De plus on ne connait pas (sauf je pense avec tactrix) l'heure exacte d'émission d'un pid, seulement l'heure à laquelle on reçoit l'info, et encore avec un elm on reçoit un paquet qui a été buffeurisé par le ftdi.

Bon la conso d'essence je n'y touche plus et la regarde de moins en moins... As tu remarqué que pcm calculait déjà les Wh et Ah avant même qu'il y ait une P2 plug-in à même de s'en servir ?

A+ ;-)
 
Merci planétaire

Pour les wh, as-tu essayer de faire un bilan énergétique globale et mesuré les fuites dans les freins, ou dans la batterie ?
Peux-tu me préciser comment faire un bilan avec les données que PCM calcule et enregistre ?
 
Consommation par PID 520

J'ai une interprétation beaucoup plus simple du PID 520, mais qui n'est utilisable que si on ne saute aucun PID :

Chaque donnée correspond à un paquet d'essence, et l'unité est 0.888 µL. C'est étalonné avec mon ODB, donc en réalité, c'est un peu plus de 0.9 µL.

L'intervalle entre deux transmissions de ce PID est égal à 1180/RPM. Cela est cohérent avec le fait qu'en multipliant la valeur par les RPM, PCM obtient un débit !

Grosso modo, on a donc un PID 520 tous les 20 tours moteur. De mémoire, il ne me semble pas avoir observé que cette loi souffre de dérogation. Planétaire, tu sembles dire que le PID n'est plus émis moteur tournant sans injection. Nous sommes en contradiction. Avant que je me replonge dans mes relevés, tu maintiens ?

A+
 
Tu me fait douter, ça fait un bail que je n'ai pas touché à cette partie du code.
De mémoire le problème que l'on avait est que ce pid 520 à un stade n'est plus émis et on gardait la dernière valeur connue. Et à d'autres moments on recevait bien la valeur zéro.

On avait donc un calcul de conso alors qu'on ne consommait pas. Ce qui veut dire qu'il y avait à ce stade des tr/mn.

Mais cela fait plusieurs années et donc si tu as des explications plus précises sur la présence de ce pid520, quand il est nul ou pas.

Ton observation sur la fréquence d'apparition du pid520 est capitale. Par contre tu ne mentionnes pas le contenu de ce pid 3 octets dont 2 changent. Pcm utilise ces 2 octets comme un entier 16bits dans son calcul, en plus des tr/mn et de la durée entre 2 passages.

(C'est une partie du code de pcm à laquelle je ne touche plus, surtout parce que pour vérifier la véracité des modifs il faut faire plusieurs pleins.)

@Thierryb. Les Wh et Ah sont calculés en entrée/sortie des accus. Sur un trajet au cours duquel les Ah reviennent à zéro à un moment, les Wh ne sont pas nuls. Ce sont les pertes dans les accus, du moins je suppose.
Ces Wh et Ah sont calculés par pcm et sont un cumul depuis le début du trajet.

Dans un tableur tu peux faire des intégrations sur le temps d'autres données (exemple les kW mécaniques) en multipliant chaque ligne par la durée qui la sépare de la précédente.

A+
 
Tu me fait douter, ça fait un bail que je n'ai pas touché à cette partie du code.
De mémoire le problème que l'on avait est que ce pid 520 à un stade n'est plus émis et on gardait la dernière valeur connue. Et à d'autres moments on recevait bien la valeur zéro.

On avait donc un calcul de conso alors qu'on ne consommait pas. Ce qui veut dire qu'il y avait à ce stade des tr/mn.

Mais cela fait plusieurs années et donc si tu as des explications plus précises sur la présence de ce pid520, quand il est nul ou pas.

Ton observation sur la fréquence d'apparition du pid520 est capitale. Par contre tu ne mentionnes pas le contenu de ce pid 3 octets dont 2 changent. Pcm utilise ces 2 octets comme un entier 16bits dans son calcul, en plus des tr/mn et de la durée entre 2 passages.

(C'est une partie du code de pcm à laquelle je ne touche plus, surtout parce que pour vérifier la véracité des modifs il faut faire plusieurs pleins.)
A+

Je confirme mes dires. Je viens d'analyser 68 trajets totalisant 81386 PID 520, donc 1,6 millions de tours moteur. Entre deux PID 520, je n'ai jamais eu plus de 37 tours moteurs ; nombre mesuré en sommant les PID 3C8,
et en multipliant par 65.5e-3*32/60 (65.5 ms délai entre deux PID 3C8, 32 t/min unité du PID 3C8, 60 s/min). Sur la grande majorité des parcours c'est 23 tours max. Le 37 correspond à une anomalie ponctuelle.

Le moteur ne peut donc pas tourner entre deux PID 520 de plus des 20 tours réglementaires à 3 tours près !

Soit ton véhicule était différent, soit PCM ne se remettait à jour qu'avec les PID 520, en oubliant de multiplier par la vitesse du moteur PID 3C8, reçue toutes les 65 ms.

Pour préciser le PID 520 : il n'existe pas si le moteur ne tourne pas, il est nul si le moteur tourne sans consommer (au dessus de 70 km/h par exemple).
Le premier octet vaut chez moi toujours 164, les deux suivants forment l'uint16 qui nous intéresse.

J'ai fait mes contrôles de véracité en comparant avec l'ODB sur des trajets de 26 km max. La meilleure précision est obtenue pour des trajets très courts, et une consommation en L/100 km gigantesque. Avec un affichage en km/L, ce serait mieux mais je ne sais pas faire.

C'est seulement pour évaluer la véracité de l'ODB qu'il faut attendre plusieurs pleins.
 
Pour préciser le PID 520 : il n'existe pas si le moteur ne tourne pas, il est nul si le moteur tourne sans consommer (au dessus de 70 km/h par exemple).
Le premier octet vaut chez moi toujours 164, les deux suivants forment l'uint16 qui nous intéresse.
merci, c'est super clair
 
Des symptômes, mais une cause bien planquée

Des news au sujet de Pcm version phev.

J'ai passé un temps fou à chercher un problème d'utilisation de pcm et canusb sur ma P2.
M8mat avait parfois lui aussi des plantages en roulant.
Il avait surtout constaté une forte dégradation en passant au samsung Q1ultra.
Or je viens de passer aussi au Q1ultra et les plantages se sont multipliés à un niveau vraiment inacceptable. De plus mon canusb a lâché et a été remplacé (sous garantie) par le vendeur (en france c'est lextronic)

Donc j'ai cherché du côté électronique un problème.
Genre mauvais contact dans le connecteur usb, soucis d'alimentation, je plantais le Q1ultra systématiquement en débranchant/rebranchant son alim, bien que sa batterie soit bonne. recherche des mA attribués sur chaque périph usb (canusb c'est seulement 60mA, même pas les 100mA de base).

Les symptômes étaient un fort ralentissement de pcm durant qq secondes puis blocage qui réclamait par exemple de débrancher canusb lequel clignotait rouge (donc en défaut).

J'ai aussi effectué des tests de diverses versions des pilotes ftdi, car sur le site lawicell on peut devoir les changer. Inutile.

Bref je vous la décrit façon courte, c'était une fausse piste. :sad:
Le soucis était dans pcm, et à mon avis depuis des années, depuis le début ?

Pcm reçoit un flux de données, des buffer de 4Ko, environ 16 fois par seconde.
Il les analyse et effectue des affichages et écriture dans des fichiers log.

Il se pose un gros problème si pcm est ralentit. Le flux, lui, continue à arriver avec le même débit.
A un moment, pendant l'étude d'un flux, un autre arrive.
On est en "multi-tâche", ou encore en réentrance dans des procédures déjà actives.
Un soucis d'écriture de pcm faisait que pendant qu'il analysait le premier buffer la deuxième réception lui faisait analyser à la fois le flux précédent concaténé au nouveau
Et ainsi de suite. Les chaînes devenaient de plus en plus longues.
j'ai trouvé dans un log créé pour pister le travail de pcm des chaînes de caractères allant jusqu'à 20Mo !!!!!!! au lieu de 4Ko.
C'est là que ça ralentissait et finissait on ne sait pas où.

Quel rapport avec mon branchement/débranchement de l'alim ?
Et bien windows attribue des portions de temps cpu à chaque tâche.
La gestion de l'alim en est une et en étant active pcm avait moins de ressources cpu.
Il recevait plus de données qu'il n'en traitait.
J'ai reproduit ce soucis en lançant une autre tâche.
Ca m'a permis de mettre au point pcm dans mon garage, nettement plus confortable et sûr que sur route ouverte.

Mais la réflexion ne s'arrête pas là.
Que faire en cas de débordement de l'entrée ?
Actuellement il y a un mélange des données dans cette situation.
c'est à dire que pcm écrit dans le csv des données du premier buffer, et en même temps des données du deuxième, décalées d' 1/16° de seconde.
Il y a interpénétration des écritures des 2 buffers, je pense.
Pour l'instant j'ai juste corrigé le beug et ça ne déborde plus du tout.
Je vais regarder de quelle marge on dispose, c'est à dire quel est le temps libre entre la gestion des entrées et leur traitement. On peut se dire qu'on va prendre du retard et afficher plus tard, mais à un moment trop de retard devient inacceptable. Ca se corse. Il faut sabrer dans les vieilles données.

Mais au fait, pourquoi le Q1ultra plantait autant ?
Par rapport au Q1 il a plus de périphérique, webcam, hsdpa ...
Peut-être ça plus de nouveaux services occupait trop le cpu.

Sur celui que j'ai maintenant (nettement plus lumineux que la Q1) j'ai désactivé plein de programmes, antivirus et autres services.
Sur mes derniers trajets de 140km en ev il a fonctionné parfaitement.
Le QI ultra est aussi plus bas, environ 2cm par rapport au Q1 et c'est nettement mieux. Il a plus de résolution, 1024x600.
Cerise sur la gâteau il a deux mini claviers bien sympas pour tapoter un peu.

A+ ;-)
 
d'où l’intérêt d'utiliser des filtres....
l'application ne voit arriver que les trames intéressantes et cela soulage drolement le besoin en débit et la gestion des buffers d'entrée...

mbed permet cela et également les trucs de OBDLINK à base de STN11xx.

Pour mémoire, avec la ion, on passe de 1625 trames/sec à 425/sec exploitées....
 
Et avec la dernière version du programme du MBED, le nombre de trames par seconde est un paramètre.

A part cela, je n'avais jamais constaté ce que tu constates, mais j'avais suspecté /constaté des problèmes de réentrance, de dépassement du buffer de Comm, de problème de gestion des chaines longues.

Mais PCM plantait à cause d'un manque de contrôles qui aboutissait à des dépassement des entiers quand un entier était fabriqué à partir de deux mots.

Bonne continuation.
 
Je crains que le soucis soit chez bill.

J'ai ajouté un affichage dans pcm pour connaitre le % de temps passé ici et là.

Pcm a deux procédures où il occupe le cpu:
-mscomm+parse c'est à dire la réception du paquet de données, leur analyse et le traitement de celles qui nous intéressent. C'est le SE+Vb qui décident quand on est là. En temps normal c'est très régulier, c'est tous les 4Ko reçus.
-un timer toutes les 100mS qui récupère ces données, les stocke en fichier(s), les affiche et effectue quelques stat. Très régulier THEORIQUEMENT. Occasionnellement, c'est à dire 2 fois par seconde, traitement des données des accus A123. Très rapide à faire.

Le premier occupe 12 à 13% du temps
Le deuxième aussi. Au total 25% dans le pire des cas, c'est à dire timer qui interrompt mscomm+parse, donc les deux "en même temps".

Donc il y a beaucoup de marge pour que le cpu fasse autre chose.

Je crains plutôt que quand une autre tâche est active elle squatte trop le cpu. Faudrait même voir ce qui se passe au niveau de mscomm et du timer.

Donc quelque soit le débit en entrée pré-mâché ou pas il y a un risque de saturation.
 
J'ai effectivement de temps en temps des "ralentissements".
Je n'ai toujours pas compris la cause.
 
:lecteur: TU SAIS, IL ARRIVE QUE DANS LES COUDES DE FILS, LES ELECTRONS RALENTISSENT...............
 
Mais je fais attention de ne pas les couder.
 
Pages vues depuis le 20 Oct 2005: 308,290,892
Retour
Haut Bas