Paramètres de la Prius 2

Chaque petit trait en bas c'est 0,1s.
Donc en tout 40 secondes.

Ces paramètres sont sollicités avec un espacement de 0,4s environ.
(Durant un cycle de 0,4 seconde 8 paramètres sont lus, espacés de 0,05s)

Les km/h changent peu et les tr/mn du thermique sont dans la gamme 1200-1300 tr/mn.

On doit probablement pouvoir augmenter le rythme de sollicitation.
J'y songe pour approfondir ce phénomène étrange.

Qu'as-tu constaté sur la P3 pour ces 3 couples ?
 
Couple MG1. Pompe à essence.

J'ai trouvé un peu de temps pour revoir Pcm7.
Mon épouse aussi, pour faire des captures en roulant il faut forcément être 2.

Le problème du couple de MG1 est résolu, un des 2 octets oublié.

On a bien la pointe de conso au démarrage du thermique, presque à chaque démarrage !
Je me permets de supposer que c'est parce que cet appel de courant doit être extrêmement bref et n'être pas vu parfois.

En résumé lors du démarrage du thermique MG1 et MG2 fournissent un couple de même sens.
C'est pareil lors de l'arrêt sauf que ce sont des couples de sens inverse de celui du démarrage: il y a freinage piloté du thermique.

Je confirme aussi que le couple résistant du thermique lors de son démarrage peut être de 120 Nm. C'est beaucoup. Heureusement MG1 ayant un petit pignon bénéficie d'une démultiplication pour son rôle de démarreur.

J'ai aussi regardé le fonctionnement de la pompe à essence.
En dessous de 65 km/h réel elle démarre avec le thermique et s'arrête 2 secondes après l'arrêt de celui-ci.
Au-dessus de 65 km/h elle tourne tout le temps. Du moins le signal que j'étudie le dit.

Et quelque soit la vitesse:
Ce qui n'a pas encore d'explication est la présence en plus d'un bit qui apparaît seulement après un certain temps de trajet (par exemple 1/2 heure) lors du fonctionnement du thermique et avec un léger retard par rapport au démarrage de celui-ci. Il se remet ensuite à 0 lors de l'arrêt du thermique.

A+ ;-)
 
Sur priuschat un pid bien amusant: le poids du passager(ère), au gramme près !!
Code:
[FONT=Courier New]82 5b f0 21 18. . . . . . . . Query Passenger Weight (KWP2000 bus)[/FONT] 
[SIZE=2][FONT=Courier New]86 f0 5b 61 18 xx xx xx xx. . Reply - multiply by 1.02 for grams[/FONT][/SIZE]
[SIZE=2][FONT=Courier New]. . . . . . . . . . . . . . . Sample: 0x00010000=141.16 lbs[/FONT][/SIZE]
Mais il y est question du bus kwp2000.

Faut quand même que j'essaye ;-)
 
Oh ... mais c'est génial ça !

Enfin un truc vraiment intéressant et utile.
:bravo:

Je le veux, je le veux, je le veux. :smile:

Pour la St Nicolas (c'est avant Noël)
 
La bible des pid de la p2

J'ai mis la main sur la bible des pid de la P2 ! :sourire:

c'est ici prendre le fichier 0199-ME02-K.xls du 1er mars 2009.

Il y a des infos sur le freinage etc...

Des mois pour comparer avec ce qu'on sait et ne sait pas.

Hébergé sur le site berkeley.edu

Pourvu qu'ils ne fassent pas appel au bus kwp que tactrix ne sait pas gérer selon des avis sur priuschat.
Et je crains que les appels du type 82 .. .. .. (il y en a plein dans ce fichier xls) soient justement des appels via ce bus.


A+ ;-)
 
Oh ... :coolman:

Sinon pour Santa (Claus) c'est après demain ...
 
Message juste pour rappeler que 2 messages plus haut il y a un lien sur la bible des pid.

-Même si on ne s'intéresse pas aux pid au sens informatique, leur liste et leur signification ouvre des connaissances sur ce qui est géré et stocké dans une prius 2 que l'on ne soupçonnait pas. :jap:

-Pas sûr que ce lien durera. Donc servez-vous avant qu'il n'y en ai plus 8)

A+ ;-)
 
Pour les androïdà2pattes voilà les pid sollicités utilisés actuellement dans pcm:

commençant par 7e0 02 21 puis suivi par:
F3 ou
3C ou
3E ..
0E
CD
EE
06
07

exemple 7e0 02 21 0E

Commençant par 7e2 02 21 suivi de

11
C3
C4

enfin pour les accus 7e3 02 21 CE

A+ ;-)
 
038[1]

Je reviens sur le second octet du PID passif 038.
Mes mesures sur Prius 2 correspondent parfaitement (2% près) à une consommation de 25µL/s, 1.5mL/min, 0.090L/h :
- intégré sur le temps du trajet, j'ai la consommation totale donnée par l'ODB.
- lors de la chauffe, cet octet passe à zéro 50 ms après que la température moteur 039[0] ait atteint 50°C.
Quels sont les arguments qui motivent le rejet de cet octet comme débit de carburant ?

planétaire, tu as écrit

> Un paramètre qui était en attente d'explication: le 038.2 appelé fuel flow.
> Interprété à tort au début à une conso d'essence en Litres/heure.
> D'après un document de David Roper, qui attribue à Norm Dick (Norman Dick ?) l'interprétation de ce paramètre ce serait la puissance du thermique.
> Calculée ainsi: Pid038.2 * 58/238 = kW

Or le document http://www.roperld.com/science/prius/triprecords.pdf indique

> ICE (Internal Combustion Engine) power is calculated as prescribed by Norm Dick, the inventor of
> CAN-View, ascribing 58 kW to 238 in the CAN output for fuel flow and assuming linearity

Cette hypothèse de rendement constant est douteuse, mais le discours semble montrer que Norm Dick mesure le flux de carburant et en déduit la puissance. As-tu des infos plus fraîches ?

Pour renforcer mon point de vue, j'ai analysé rapidement une situation d'accélération maximale dans une condition de mauvaise adhérence (gravillons sous la roue droite). On observe très bien des diminutions brutales du paramètre. Lorsque l'adhérence est bonne, ce paramètre croit progressivement avec la vitesse de rotation. J'ai atteint 228 ( et non pas 238 ) à la rotation de 4990 RPM. Mais la vitesse était comprise entre 85 et 100 km/h. Peut-être pas assez rapide pour que le thermique délivre sa puissance maximale. Manip. à refaire sur autoroute.
 
J'avais aussi écrit "il y a des différences au niveau temporel"

Le rendement du thermique, je l'ai publié sur le forum, est maximal vers 2000 tr/mn et descend ensuite lentement.
Ce n'est qu'aux bas regimes qu'il devient mauvais et descend vers les 20% voire moins.

On peut donc théoriquement avoir une assez bonne corrélation entre essence consommée et puissance fournie, disons très approximativement au-dessus de 1400 tr/mn

Tu peux comparer avec l'injection officielle (celle de teachstream) dans le pid actif.
Un 7E...

Peut-être aussi faire des tests à régime faible (1100-1200 tr/mn) et comparer si ta constante est la même qu'à régime + élevé.

A+ ;-)
 
J'avais aussi écrit "il y a des différences au niveau temporel"
...
Tu peux comparer avec l'injection officielle (celle de teachstream) dans le pid actif.
Un 7E...
A+ ;-)

Si 038[1] arrive avant l'injection officielle, c'est un indice de plus en faveur du fait que c'est bien le débit de carburant. Cela ne peut pas être une puissance, qui arriverait en retard sur l'injection. La différence temporelle ne peut-elle pas être expliquée par le retard des PID sollicités ? Pour l'instant je n'ose pas envisager d'interrompre l'acquisition de _tous_ les PID passifs (espacés parfois de 200 µs) pour avoir quelques PID sollicités. Ai-je tort ? priusfan a-t-il réussi complètement ? L'acquisition de tous les PID passifs est extrèmement instructive. On arrive à voir les points de compression du moteur lors de son arrêt : il y a deux-trois sautes de puissance batterie. On arrive aussi à mesurer le jeu mécanique de le transmission dans les différences de rotation des roues et de MG2. au moment des transitions accélération/déccélération. Un jour ou l'autre j'aurai branché une seconde interface CAN (via une carte arduino). Je ferai alors ces tests.
 
Très intéressant tout cela. :jap:

Je ne me souviens pas exactement de l'étude du 038. N'hésite surtout pas à l'étudier.
Elle avait dûe être graphique par comparaison avec d'autres, sans doute les tr/mn.

Oui les passifs sont très intéressants. Tous n'ont pas été expliqués !
Mais, à priori, on a besoin de quelques actifs pour, par exemple, les températures de l'électronique et d'autres inconnus en passif.
Teachstream, le prog de toy utilise des actifs.
Les passifs ont un autre avantage : certains sont reçus à fréquence quand même "élevée" 100/seconde.

Donc Pcm utilise les 2 types avec canusb et tactrix. Avec elm tu as dû voir que j'avais fait des tests en en utilisant 2. Un en réception et l'autre (qui peut être + lent) en émission.

A+ ;-)
 
Confirmation de la qualité du second octet du PID 038 comme mesure du débit de carburant, avec une unité égale à 25 µL/s : j'ai fait un enregistrement couvrant à la fois un long bouchon dans lequel j'ai essayé de consommer le plus possible :oops: puis un trajet plus rapide. Il me semble que l'accord entre l'intégration du PID (483290 points de mesure) et les quelques relevés de la consommation moyenne sur le trajet, donnée par l'ODB, coïncident parfaitement. J'ai juste triché en décalant de 140m le chemin parcouru. J'aurais peut-être simplement dû décaler le timing de l'ODB. De toutes manières l'ODB est un peu farfelu : ll bouge alors que moteur et véhicule sont à l'arrêt.


43004e0dafe4d5ac5.png
43004e0db39364d53.png
 
J'aime bien la simplicité et la clarté de ces graphes... réalisés avec quoi ?
 
@kinetik:
idem shadoko: quel outil pour faire ces graphes?

manifestement tu sais extraire la sustanfique moelle des infos can :jap:.

étape suivante: tu passes me voir, je te prête un Y à brancher sur la prise diag et un mongoose mfc ; cela permet en utilisant techstream sur une branche et un logger sur l'autre de retrouver l'affectation des différents octets des différents messages... ( :-D comment j'ai décodé la P3 ???? :-D )

si tu veux, je te donne les coordonnées directes de Norm (le géniteur du canview) et tu lui poses tes questions.
 
J'aime bien la simplicité et la clarté de ces graphes... réalisés avec quoi ?
- Un programme simpliste de 40 lignes en Python pour faire la capture en ajoutant un timestamp à chaque message CAN
Code:
#!/usr/bin/python
# -*- coding: utf-8 -*-
# Noter que l'OBDLink est déjà pré-configuré pour la vitesse et les fin de lignes
import sys, serial, datetime
if len(sys.argv) != 2:
    print("Syntax = " + sys.argv[0] + " ttyUSBx")
    exit(1)
f0 = sys.stderr
d = datetime.datetime.now()
serial = serial.serial_for_url('/dev/'+sys.argv[1],
                               baudrate=2000000,
                               parity=serial.PARITY_NONE,
                               rtscts=True,
                               xonxoff=False,
                               timeout=3)
flog = ('./'+d.isoformat('-')[0:16]+'.log').replace(':','').replace('-','')
f = open(flog, 'w')
f0.write('log = ' + flog + '\n')
def serial_write_and_read(message, n):
    """ read trop simpliste ! """
    serial.write(message+'\n')
    for i in range(n):
        f0.write(serial.readline())
    f0.write('...\n')
serial_write_and_read('ATZ',5)
# Attention : 'ATL1 définitif avec ATPP0DSV0A puis ATPP0DON
serial_write_and_read('ATPPS',14)
serial_write_and_read('ATSP6',3)
serial_write_and_read('ATH1',3)
serial_write_and_read('ATCAF0',3)
t0 = datetime.datetime.now()
serial_write_and_read('ATMA',1)
il = 0
while True:
    trame = serial.readline()
    dt = datetime.datetime.now() - t0
    f.write(format(dt.seconds,'5d') +\
                '.' +\
                format(dt.microseconds,'06d') +\
                ':' +\
                trame)    
    il+=1
    if il%1000 == 0:
        f0.write(str(il)+'\n')
# fin du programme
- Un programme de 100 lignes, toujours en Python pour scinder le fichier de capture en 65 fichiers binaires (un par PID, plus celui des timestamps)
Code:
# -*- coding: utf-8 -*-

from __future__ import division

import numpy as np
import sys
import os, os.path

if len(sys.argv) != 2:
    print("Syntax = " + sys.argv[0] + " nom_du_fichier_log_sans_point_log")
    exit(1)

logdir = os.path.dirname(sys.argv[1])
logname = os.path.basename(sys.argv[1])
if logdir == '':
    dirlog = logname
else:
    dirlog = logdir + '/' + logname
#logfile = "../../logs/2011-06-24_1.log"
#logfile = "../../logs/2011-06-24_2.log"

print('hello1')

codes={\
'002':(4,'?'),
'020':(3,'?'),
'022':(8,'Lateral acceleration'),
'023':(7,'Forward acceleration'),
'025':(8,'Steering position'),
'030':(8,'Brake pedal pressure'),
'038':(7,'? ICE RPM'),
'039':(4,'? Temp'),
'03A':(7,'? Gas torque'),
'03B':(5,'Electric motor current/voltage'),
'03E':(3,'Gear rotation ?'),
'060':(7,''),
'087':(8,''),
'0B0':(3,''),
'0B1':(6,'Front wheel rotation'),
'0B3':(6,'Rear wheel rotation'),
'0B4':(8,'Speed'),
'0C9':(5,'? ABS'),
'120':(8,'Drive mode'),
'230':(7,'counter ?'),
'244':(8,'Gas Pedal/Speed'),
'262':(4,'?'),
'348':(6,'ICE'),
'34F':(5,''),
'3C8':(6,'RPM'),
'3C9':(8,'? date'),
'3CA':(5,'Speed'),
'3CB':(7,'Battery Max discharge/charge,state,temperature'),
'3CD':(5,'Battery Fault code'),
'3CF':(5,'? ICE'),
'423':(1,'? const'),
'484':(5,'????'),
'4C1':(8,'? const'),
'4C3':(8,'? const'),
'4C6':(8,'? const'),
'4C7':(8,'? const'),
'4C8':(8,'? const'),
'4CE':(8,'? const'),
'4D0':(8,'? HECU -> Batt [16, 0, 2, 3, 0, 0, 0, 0])'),
'4D1':(8,'? Batt -> HECU [17, 0, 1, 2, 0, 0, 0, 0])'),
'520':(3,'Fuel injector'),
'521':(2,'? const'),
'526':(3,'Timing'),
'527':(3,'? const'),
'528':(4,'? const'),
'529':(7,'EV Mode'),
'52C':(2,'Engine temperature [35, 49] ... [35, 168]'),
'53F':(5,'-???'),
'540':(4,'Shift lever'),
'553':(7,'? const'),
'554':(7,'? const'),
'56D':(4,'? EV'),
'57F':(7,'Lights'),
'591':(4,'???'),
'5A4':(2,'Gas gauge [99, 38] ...  [99, 36]'),
'5B2':(4,'? const [37, 0, 4, 0]'),
'5B6':(3,'Open doors [100, 193, 0] [228, 193, 128] [100, 193, 128] [228, 193, 0]) [100, 193, 0]'),
'5C8':(3,'Cruise  [36, 0, 0] [164, 0, 16] [36, 0, 16] [164, 0, 0] [36, 0, 0]'),
'5CC':(3,'? const [36, 1, 176]'),
'5D4':(2,'? const [35, 0]'),
'5EC':(7,'? const [40, 0, 0, 0, 0, 36, 58]'),
'5ED':(6,'? const [103, 8, 0, 255, 0, 0]'),
'5F8':(2,'? const [35, 0]'),
'602':(2,'? const [35, 0]')}

not_good = {}

def with_checksum(ts, k, c, il, data):
    cdata = map(lambda x: int(x,16), data[0:-1])
    adata = np.array(cdata, np.uint8)
    if adata.size != codes[k][0] - 1:
        print("Mauvaise taille ligne " + str(il) + ": \"" + l[0:-2] + "\"")
        return
    c = reduce(lambda x,y:x+y,cdata,c)
    if c % 256 != 0:
        print("Erreur de checksum ligne " + str(il) + ": \"" + l[0:-2] + "\"")
        return
    iframe = fts.tell() // 8
    np.array(ts).tofile(fts)
    fk = df[k]
    np.array(iframe, np.int32).tofile(fk)
    adata.tofile(fk)

def without_checksum(ts, k, il, data):
    cdata = map(lambda x: int(x,16), data)
    adata = np.array(cdata, np.uint8)
    if adata.size != codes[k][0]:
        print("Mauvaise taille ligne " + str(il) + ": \"" + l[0:-2] + "\"")
        return
    iframe = fts.tell() // 8
    np.array(ts).tofile(fts)
    fk = df[k]
    np.array(iframe, np.int32).tofile(fk)
    adata.tofile(fk)

def work_on_line(il, l):
    if l.find('\x00') >= 0: # Erreurs rares à signaler et corriger
        print("\\x00 dans la ligne " + str(il) + ": \"" + l[0:-1] + "\"")
        l = l.replace('\x00','')
    [l0,l1] = l.split(":")[-2:]
    if (l1[-2:] != ' \n'): # Erreur
        print("mauvaise terminaison de la ligne " + str(il) + ": \"" + l[0:-1] + "\"")
        return
    try:
        h0 = int(l1[0],16)
        h1 = int(l1[1:3],16)
        data = l1[4:-2].split(' ')
        ts = float(l0)
        if (h0 > 3) or (h0 == 0 and h1 == 32):
            without_checksum(ts, l1[0:3], il, data)
        else:
            with_checksum(ts, l1[0:3], h0 + h1 + len(data) - int(data[-1],16), il, data)
    except Exception,e:
        print("Exception " + str(e) + " for \"" + l[0:-2] + "\"")

f = open(dirlog + '.log',"r")
if not os.path.exists(dirlog):
    os.mkdir(dirlog)
df = {}
for k in codes:
    df[k] = open(dirlog + '/' + k, 'w')
fts = open(dirlog + '/timestamps', 'w')

il = 0
while True:
    l = f.readline()
    il+=1
    if il % 100000 == 0:
        print(il)
    if len(l) == 0: # EOF
        break
    try:
        work_on_line(il, l)
    except Exception:
        not_good[il] = "Exception: \"" + l + "\""
        print str(il) + " is not good: \"" + l + "\""
#
f.close()
fts.close()
for k in df.keys():
    df[k].close()
print('done')
- Quelques lignes toujours en Python pour tracer :
Code:
# -*- coding: utf-8 -*-
import numpy as np
import scipy.interpolate as si
import matplotlib.pyplot as plt
dirlog = mon_repertoire_du_jour
fts = open(dirlog + 'timestamps', 'r')
ts = np.fromfile(fts, np.float)
fts.close()
conso_at = np.array((\
# ...
 288. , 14.9,
 605.0, 10.8,
# etc. déterminé en notant les numeros de message CAN,
# ou en donnant des petits coups de volant repérés ensuite sur le PID 025. 
3960.,  4.9)).reshape(27,2)
codes={'038':(7,'? ICE RPM'), '3CA':(5,'Speed'),}
def gd(k):
    f = open(dirlog + k, 'r')
    d = np.fromfile(f, np.uint8)
    f.close()
    if k == '020' or int(k[0]) > 3:
        w = codes[k][0] + 4
    else:
        w = codes[k][0] + 3
    n = d.size // w
    d.shape = (n,w)
    id = (np.uint32(d[:,3])<<24) |\
        (np.uint32(d[:,2])<<16) |\
        (np.uint32(d[:,1])<<8) |\
        np.uint32(d[:,0]) # LOW ENDIAN
    return (ts[id], d[:,4:])
t038,v038 = gd('038')
t3CA,v3CA = gd('3CA')
def interpodo_1(t,v):
    o = np.cumsum(np.diff(t)*np.double(v[:-1]))
    return si.interp1d(t[:-1],o)
odo3CA_1  = interpodo_1(t3CA,v3CA[:,2]) # pas la meilleure vitesse, mais intégration OK
km3CA = odo3CA_1(np.minimum(odo3CA_1.x[-1],np.maximum(odo3CA_1.x[0],t038[1:])))/3600.
istart = 25000
f = plt.figure()
ax = f.add_subplot(1,1,1)
ax.plot(km3CA[istart:], 25e-4*np.cumsum(np.diff(t038)*v038[1:,1])[istart:]/(-0.140+km3CA[istart:]), 'b')
ax.plot(odo3CA_1(conso_at[:,0])/3600., conso_at[:,1], 'or')
ax.set_xlabel("$D$ [km]", fontsize=14)
ax.set_ylabel("L/100km", fontsize=14)
ax.set_xlim((0,27))
ax.set_ylim((4,16))
ax.set_title(u"PID 038 octet 1 = Débit de carburant [25 µL/s]")
ax.legend((u'$\int \; 25 \cdot 10^{-6} \cdot \mathrm{PID} \cdot dt \\times 100 / D$',
               'Ordinateur de bord'))
f.show()
La prochaine fois, je fabriquerai directement le PNG pour avoir unicité de format.

Je suis curieux de confronter ce résultat avec ceux qui auraient rencontré des problèmes avec cet octet. Est-ce une mauvaise information, ou est-ce que cet octet dépend de la version de Prius NHW20 ?
 
... De toutes manières l'ODB est un peu farfelu : ll bouge alors que moteur et véhicule sont à l'arrêt.
...

Veux-tu dire que l'odb défile par tranche de 5mn? Si c'est cela c'est normal.
C'est le "paradoxe de l'odb" de vouloir afficher des Litres sur une distance parcourue et de le faire par tranche de temps, en incluant les temps d'arrêt.
 
Veux-tu dire que l'odb défile par tranche de 5mn? Si c'est cela c'est normal.
C'est le "paradoxe de l'odb" de vouloir afficher des Litres sur une distance parcourue et de le faire par tranche de temps, en incluant les temps d'arrêt.

Je me rends compte de mon ambiguité :-?. Je corrige le post. Mes L/100, c'était la moyenne sur tout le trajet. Elle ne doit pas bouger si ni les L ni les km ne bougent. Je pense que tu parles de défilement de la consommation instantanée, hautement instable et sans intérêt sur la Prius, qui accumule de l'énergie dans la batterie HV. As-tu fait un typo : 5 mn, au lieu de quelques secondes (5 ?).
 
L'ODB affiche les informations avec quelques secondes de retard. Cela est vrai pour la consommation moyenne et la charge de la batterie.
 
Le couple du thermique !

Je déterre le problème de la mesure du couple du thermique.

Je n'ai aucun doute que ce couple défile 25 fois par seconde dans les octets 3 et 4 (quatrième et cinquième) du PID 348. C'est un entier signé sur 10 bits, qui contient directement la valeur en N*m. :D
 
D'après Attila, ce pid est émis 13,5 à 14 fois /seconde et contient les tr/mn en octet 3 et 4.
Retrouves-tu ces tr/mn ou au contraire invalide-tu ces infos ?

As-tu comparé avec le couple (supposé calculé après pertes dans le psd) issu du pid &h39 octet 3 à multiplier par 2 pour avoir des Nm.
 
J'invalide ! J'ai commencé à remplir un wiki pour mettre à jour ces informations : http://fr.kinetik.wikia.com/wiki/Prius/NHW20/CAN/PID/348

À ce propos, si j'ai connaissance d'infos à travers ce forum privé, vaut-il mieux
- les référencer même si elles ne sont pas accessibles
- y faire allusion sans les référencer explicitement (genre "2009-02-09 planétaire")
- ne pas y faire allusion

La valeur de 039.2 multipliée par 2 est assez souvent proche du couple, mais elle ne colle pas du tout lors de la phase de chauffe du moteur. Elle n'est pas non plus négative lors du démarrage et du frein-moteur.
 
Débit d'essence

Je propose une interprétation plus simple pour le PID 520 : c'est la quantité d'essence pompée (unité = 0.85 µL). Il suffit de sommer les valeurs de chaque trame pour obtenir la quantité d'essence consommée.

Cpmme la fréquence des trames est proportionnelle à la vitesse moteur (j'ai un intervalle en secondes égal à 1180/RPM sur mon véhicule)
la formule classique PID 520 X RPM trouve une explication convaincante. Je n'arrivais pas à admettre que le régime d'injection en L/tour soit transmis à une cadence aussi faible.
 
Particulièrement innovante, cette idée de fréquence variable du pid 520 en fonction des tr/mn du thermique ! :jap:

Pour ce qui est de la divulgation d'infos issues seulement de forum privés ou de mp, je serais d'avis de ne pas les communiquer par défaut, sauf accord de son "inventeur".
 
PID 03E : position angulaire de MG2

Le PID 03E correspond très bien à la position angulaire de MG2, modulo un quart de tour. Ce quart de tour est résolu sur 11 bits (un vingtième de degré !) : quatre bits du premier octet et 7 bits du second. Le dernier bit semble toujours nul. Toutes les trois émissions de ce PID, le PID 244 est émis et transmet la vitesse angulaire de MG2.

Questions en suspens

- Lorsqu'on bloque la voiture avec le P, il reste un jeu de l'ordre de 6 degrés visible sur les PID 03E et 244. Cela est-il compatible avec le mode de blocage ? D'ailleurs quelle est la pièce précise qui est bloquée par P ? Le manuel de dépannage Toy est peu clair.

- Dans cette position P, MG2 s'agite frénétiquement avec une amplitude de l'ordre de 1 degré. Il faudra que je teste en accélérant : il me semble que c'est MG1 qui tourne dans ce cas et cela devrait pousser MG2 en butée.

- Le calcul de la vitesse de MG2 transmis par le PID 244 est un peu défectueux : dans cette position P, la moyenne n'est pas strictement nulle et l'agitation frénétique entraine une dérive de l'ordre du degré par seconde. [C'est quoi le smile pour enculage de mouches ?]
 
Pages vues depuis le 20 Oct 2005: 310,363,793
Retour
Haut Bas