Module programmable Honda_MiniDash

[DipDip]

Madmax_1664, je reviens sur mon message en réponse à ton interrogration :

Hello dipdip,
J'ai pas bien saisi le taux de rafraichissement des données sur l'afficheur (non pas le defilement des pages) ? ok pour les valeurs qui ne fluctuent pas trop rapidement, mais pour le rpm ? Comment ces valeurs seront visibles ? Il y a des tempos d'affichage c'est ca ?

Comme tu me semble avoir certaines notions puisque tu as posé une question bien précise et avec les termes exacts ( "taux de rafraichissement des données sur l'afficheur" ), voici quelques informations supplémentaires afin que tu te rend mieux compte :
- Interrogation et réponse écu pour 16 données = 42,5 ms
- lectures des données locales (capteur 1, capteur 2, capteur 3, état jour/nuit) = 0,7 ms
- calculs (mise à l'échelle et mise en forme pour affichage) des deux groupes de données ci-dessus = 0,4 ms
- Mise à jour du contenu de la page affiché = de 3ms à 6,7 ms suivant la page affiché.

Tous ces temps sont des temps réels mesurés et non donnés par un simulateur logiciel.
Cela nous fait un temps maximum de gestion de 50,3 ms (42,5 + 0,7 + 0,4 + 5,7).

Actuellement je n'ai pas encore fini la gestion des diverses alarmes donc pas de temps de gestions correspondant mais j'estime que ce ne sera que de quelques ms.

Tout ceci pour indiquer que le taux maximum pourrait monter à 10 Hz (100 ms) soit 10 fois par seconde mais dans ce cas j'ai peur que les données qui varient rapidement soient difficilement lisible.

Si tu as tout type de commentaires, je suis à ton écoute.

[madmax_1664]

Merci DipDip de ces détails.

4Hz c'est suffisant pour une lecture confortable.

Pour être honnete je suis un peu sceptique sur les valeurs instantanées provenant du calculateur. En gros chaque valeurs aura été intégrée sur une durée de 1ms maxi.

Du coup peut etre qu un traitement de packet de données pourrait s'avérer nécessaire avant l'affichage (lissage).

[DipDip]

Dans le programme Honda de l'écu, les valeurs récupérés à un instant t sur la "K-Line" sont :
- les valeurs directes données par les capteurs à l'instant t pour : température eau moteur, température air admission, position papillon, pression collecteur admission, tension lambda. Calculé avec une résolution de 5 mV et transmise avec une résolution de 20 mV
- le régime moteur est calculé tous les demi tours de vilebrequin et la valeur transmise à l'instant t est la valeurs calculé à l'instant t. La valeur est calculé avec une précision de 0,15 tr/mn et transmise est avec une résolution de 0,25 tr/mn.
- la vitesse véhicule est calculé sur une période de 295 ms avec une précision de 0.05 km/h. Elle est transmise avec un résolution de 1 km/h.
- le temps d'injection d'injection transmis à l'instant t est la valeur qui pilote les injecteurs à cet instant t. La résolution du calcul et transmise est de 4 us.
- l'avance à l'allumage transmis à l'instant t est la valeur qui pilote l'allumage à cet instant t. La résolution calculé et transmise est de 0,234375 °
- la correction d'injection à court terme est, comme son nom l'indique, une correction à court terme (je n'ai plus la période en tête). Elle est d'une résolution de 0,78125 %
- la correction d'injection à long terme est, comme son nom l'indique, une correction à long terme (je n'ai plus la période en tête). Elle est d'une résolution de 0,78125 %

peut etre qu un traitement de packet de données pourrait s'avérer nécessaire avant l'affichage (lissage).

Tu peux développer

[madmax_1664]

Oui D'accord, j'ai confondu le temps d'intérogation et réponse de l'ECU avec le calcul intrinsèque de chaque valeur effectué par les capteurs. Quelle erreur grossière...

Ensuite, de part la grande vitesse de fonctionnement de certains capteurs, je pense que leurs valeurs ne sont pas toutes prise en compte par le calculateur qui ne va réagir qu'a un résultat de paquet de valeurs (analysé sur un temps plus long defini dans sa trame). ==> C'est pour cela que je crains qu'un affichage rapide de valeurs (dont certaines tres courtes et non representatives), puisse surprendre. Valeurs quant a elles totalement gérées par l'ECU.
Donc finalement moins souvent on demande les valeurs a L'ECU et moins on a de chance de se récupérer des artefacts.

Question idiote n°2 : On ne sature pas la bande passante du calculateur en le questionnant trop souvent ? Car moi si tu me parle trop souvent pendant que je conduis, il y a fort a parier que vienne à louper un virage..

[DipDip]

Ensuite, de part la grande vitesse de fonctionnement de certains capteurs, je pense que leurs valeurs ne sont pas toutes prise en compte par le calculateur qui ne va réagir qu'a un résultat de paquet de valeurs (analysé sur un temps plus long defini dans sa trame). ==> C'est pour cela que je crains qu'un affichage rapide de valeurs (dont certaines tres courtes et non representatives), puisse surprendre. Valeurs quant a elles totalement gérées par l'ECU.
Donc finalement moins souvent on demande les valeurs a L'ECU et moins on a de chance de se récupérer des artefacts.

Non, pas de risque dans le programme Honda, relis tranquillement et en détail mon message ci-dessus.

Exemple de deux valeurs qui peuvent varier rapidement :

- régime moteur : la valeur est calculé tous les demi tours de vilebrequin.
A 1200 tr/mn => 40 calcul de régime instantané par seconde pour une interrogation que de quatre fois pas seconde.
A 6000 tr/mn => 200 calcul de régime instanaé par seconde pour une interrogation toujours que de quatre par seconde.

- position papillon : c'est la tension fournit par le potentiomètre de recopie de papillon qui est transmise. Le programme lit cette tension 20 fois pas seconde pour une interrogation que de quatre fois par seconde.

De toute façon, dans le programme, tant qu'une nouvelle valeur n'est pas recalculer, la variable assigné contient la valeur à T-1 donc impossible d'avoir une valeur fantôme ou ne correspondant pas à la réalité.

Question idiote n°2 : On ne sature pas la bande passante du calculateur en le questionnant trop souvent ? Car moi si tu me parle trop souvent pendant que je conduis, il y a fort a parier que vienne à louper un virage..

Quand tu parle de bande passante du calculateur, je suppose que tu parle de la puissance de calcul du processeur (parfois appelé aussi : taux d'occupation en 100% du système).
Si c'est le cas :

Déjà pour faire relation avec ton exemple : la vitesse de calcul et d'action d'un processeur est sans commune mesure avec nos performances.

De plus, dans le processeur qui équipe cet écu, la liaison série est en logique câblé (donc "hardware" et non "software") ce qui dans ce cas ne prend aucune ressource logicielle. La celle ressource logicielle est l'interprétation de la demande/réponse et prends quelque dizaine de us.
La seul limitation est la vitesse de transfert, imposé par le programme Honda, au niveau du port "K-line" et qui est de 9600 baud.
Le temps de transfert (interrogation/réponse), dans le cas présent, avec le protocole Honda, est de 39 mots de 10 bits (start, 8 bits, stop) => 1/9600*390 = ~41ms.
La fréquence d'interrogation est donc limité en premier lieu par la vitesse de transfert à 9600 baud soit dans le cas présent à 24 interrogations/réponses maximum par seconde et je ne suis qu'à quatre interrogations/réponses par seconde (1/6 ième du maximum possible).

[DipDip]

Le programme du module est pratiquement finalisé
Pratiquement, car je suis en train de faire tous les contrôles de calibration et cela prend pas mal de temps afin de bien tous vérifier.


Pas beaucoup de réponse dans le sondage.................

[Shinji66]

Combien y a t il de forumeurs réellements actifs sur le forum? une vingtaine?

[DipDip]

Combien y a t il de forumeurs réellements actifs sur le forum? une vingtaine?

Je suis incapable de faire une estimation fiable ou approchante.
Il y a eu actuellement 1025 visites de ce sujet et 8 votes au total pour des quatre choix (qui inclus le choix : "Je n'en vois pas l'utilité pour moi.").
En admettant que 25 visites soit du à la rédaction de mes messages ou leur édition, il reste 1000 visites.
1000 visites / 8 votes = 125.
Cela voudrait dire que chacun des votants serait venu en moyenne 125 fois
D'ou le fait que je sois surpris du ratio visites/votants.

[glurk]

Combien y a t il de forumeurs réellements actifs sur le forum? une vingtaine?

Je suis incapable de faire une estimation fiable ou approchante.
Il y a eu actuellement 1025 visites de ce sujet et 8 votes au total pour des quatre choix (qui inclus le choix : "Je n'en vois pas l'utilité pour moi.").
En admettant que 25 visites soit du à la rédaction de mes messages ou leur édition, il reste 1000 visites.
1000 visites / 8 votes = 125.
Cela voudrait dire que chacun des votants serait venu en moyenne 125 fois
D'ou le fait que je sois surpris du ratio visites/votants.

Oui mais: non car les visites ont commencées des la première page et le premier message, puis le sondage n'est apparut que vers la fin, donc, des participants du début des discutions ne l'ont pas vu

et moi, j'ai voté " je n'en ais pas l'utilité" mais sans avoir participé à la discutions (car je veux garder mon horloge, et j'ai deux "manos" de temp pressions d'huile, et un ECU communiquant)

[DipDip]

Très bonne remarque car je n'avais pas pensé que l'ajout du vote est récent.

Tu a voté pour le choix 4.......hors aucun vote pour ce choix :

[Benji24]

Moi aussi je trouve ça surprenant si peu de vote mais je suis de l'avis de shinji66 finalement il doit y avoir peut de membre actif, si on rajoute ce qui consulte occasionnellement, ceux qui attendent que le projet soit totalement finalisé et testé tu devrait avoir quelques votes supplémentaires avec un peut de patience

[DipDip]

J'étais simplement surpris du ratio visite/vote sans que cela me tracasse plus que cela donc sans chercher personnellement d'explications.
Merci pour vos divers messages qui apportent partiellement des éléments d'explication.


Le test dans ma voiture approche à grand pas, malgré que j'avais prévu de le faire ce W.E. , mais je préfére bien border le logiciel comme je l'avais fait pour la conception et la C.A.O.
Dans la foulé : vidéo de démo et rédaction d'un récapitulatif comme l'avait suggéré Rouxte à juste titre.

[Benji24]

Prend ton temps on a bien 5 min . Frenchement je trouve que entre l'idée, la conception, la commande des éléments et l'assemblage, quand je vois que tu est en train de tout finalisé respect t'a vraiment pas mit longtemps

[k-devil974]

moi franchemnt j'aime bien ca sera plus discret que les rampe de mano en ligne

et ca fera un truc propre


moi je suis pour a 100%

[DipDip]

L'ajout et l'emplacement d'une rampe de manomètre est en fonction des gouts de chacun et généralement dicté sur les ratios emplacement discret /emplacement voyant /aspect sobre /aspect "blingbling" / fiabilité dans le temps / fiabilité valeur affiché / cout / fonction(s) additionnelle(s).

Mon système est qu'il est accès sur les paramètres suivant :
- prend peu de place.
- discret.
- grand nombre de valeur consultable.
- de nombreuses valeur que l'on ne peut consulter avec aucun manomètre additionnel car fournit par l'écu moteur, valeur sur laquelle je rajoute la possibilité d'avoir une alarme.
- gestion des nombreuses alarmes avec indication externe par un voyant, ce que ne font pas les manomètres d'un cout raisonnable.
- gestion spécifique de l'alarme de pression d'huile moteur. L'alarme de pression trop basse est indexé au régime moteur comme l'on peut le voir sur le graphique ci-dessus (zone verte = Ok et zone rouge = Problème de sous pression dangereux pour le moteur) : Cliquez sur l'image pour l'agrandir


Il me semble que la gestion des alarmes est prioritaire pour la longévité d'un moteur qu'une multitude d'afficheur que l'on ne regarde pas forcement tout le temps et surtout quand il y a une valeur hors norme (j'en ai fait l'expérience comme surement bien d'autres personnes).


PS : la forme de la courbe est une estimation de ma part mais est totalement paramétrable par l'utilisateur selon ces désirs.