HybridAssistant

Comment on fait pour tester les batteries HV, svp ?
J'ai bien cliqué sur test batterie, mais après ?

C'est le bouton check tout en bas à gauche.

Si l'appli est connectée, une fenêtre doit s'ouvrir et on doit voir quatorze barrettes représentant les tensions des quatorze blocs. Ca s'agite à cause du bruit de mesure. Tant qu'on est dans cette fenêtre, HA enregistre. Donc soit on ne bouge pas (mesure à vide), soit on fait une charge et une décharge (voir plusieurs) pour la mesure en charge. Quand on sort de la fenêtre, l’enregistrement cesse et reste en RAM. Quand on quitte HA, l'enregistrement est rangé dans la flash. Il faut alors utiliser Report Viewer pour récupérer et visualiser les données.
 
Qqs précisions:

on doit voir quatorze barrettes représentant les tensions des quatorze blocs.
et bien cela dépend du modèle ( de 8 P+ à 17 Rav4h)

Quand on sort de la fenêtre, l’enregistrement cesse et reste en RAM.
Faux, les infos étaient stockées en temps réel dans une base de données SQLite dans la Flash.

Quand on quitte HA, l'enregistrement est rangé dans la flash.
Quand on quitte HA, la BD et les fichiers ouverts sont fermés, épicétou.
On ne passe pas notre temps (dans HA) à gonfler la RAM avec les données du trajet...

Il faut alors utiliser Report Viewer pour récupérer et visualiser les données.
c'est hexa
 
Dernière édition:
@GrosOurs

Soit en roulant une accélération qui consomme des électrons suivit d'un freinage régénératif qui emmagasine ces électrons.
Ou inversement.

C'est vrai qu'à l'arrêt mes 14 barres bleues dansent un peu.
 
Ces barres donnent l'impression de danser car l'échelle est dynamique et s'adapte à la plage utile.

En fait, le frétillement est ridiculement faible.

Prenez le temps de regarder l'échelle à gauche avant d'accuser Murphy , Brown ou Shannon :grin:
 
Bon j'ai réussi en tripatouillant dans le téléphone, pas évident pour quelqu'un qui n'est pas tombé tout jeune dans ces machins informatiques
 
Bonjour,

1Er essai d'HA ce matin pour allez au travail...donc sur mon autoradio android, il me faut redémarrer 2 fois l'appli pour que ça se connecte, après c'est OK.

Sinon les données de consommation ne fonctionnent pas, je n'ai que la vitesse moyenne. Avec torque j'ai toutes les données. Que faut il faire?
Autre point, si j'ai bien compris, il est possible de contrôler le ventilateur de la batterie, hors, quand je n'arrivais pas à me connecter, j'arrivais à activer l'icone du ventilateur , ce matin il ne se passe rien quand j'appuie sur l’icône (sécurité car trop froid ?).
Concernant le graphisme, je trouve dommage que les indications temps, km et % (en bas au centre) prennent autant de place, je vois pas trop l’intérêt.

Dernier truc pour ce matin! la fin de mon parcours se termine par 1 km de plat à faible vitesse, donc en EV sans le vouloir. Donc l'icone EV est en rouge. Je veux bien qu'il estime que j'abuse de l'EV, mais je ne peux pas faire autrement!

Sinon encore merci!
 
Ok OK, j'ai lu beaucoup de page du topic, mais j'ai loupé quelques pages! désolé.:oops::oops:
 
Bonjour. Avant d'acheter L'OBDlink LX sur amazon.de, j'aimerais savoir si je peux mettre cet adaptateur ou équivalent : https://www.obdauto.fr/interfaces-d...aptateur-pour-opel-10-broches-vers-obdii.html. Je m'explique sur ce choix. J'ai une Prius II sol et j'ai donc acheté un GPS garmin bluetooth, mise à jour carte à vie et téléphone main libre. Avec ce garmin j'ai acheté eco route HD (https://buy.garmin.com/en-US/US/sho...rmin-mechanic-with-ecoroute-hd/prod38354.html) qui me permet d'avoir température liquide refroidissement, compte tour, position accélérateur, vitesse gps, avance de temps, voltage batterie, lecture et effacement code erreur etc mais aucun renseignement sur batterie HV, freinage, rapport et beaucoup d'autre chose que donne HA. J'aimerais pouvoir avoir les deux en visu. Est ce possible. Merci aux pros de vos réponses. Possibilité de choix des langues, ma version est en fraçais
 
Dernière édition:
Bonjour. Avant d'acheter L'OBDlink LX sur amazon.de, j'aimerais savoir si je peux mettre cet adaptateur ou équivalent : https://www.obdauto.fr/interfaces-d...aptateur-pour-opel-10-broches-vers-obdii.html.

Ayant un peu utilisé le bus CAN en pédagogie (TP communications), je peux dire qu'a priori il n'y a pas de problème. Les transceiveurs CAN sont faits pour fonctionner en parallèle et en réception n'absorbent quasiment rien. C'est fait pour ça :razz:.

Donc ça a 90 % de chances de fonctionner. La réserve vient du fait que pour éviter les échos on met des résistances en fin de ligne. Si l'appareil qu'on ajoute a cette résistance activée, ça va poser problème si il y en a déjà une autre activée ailleurs. Mais ça ne viendra pas de l'adaptateur en Y lui-même.

:papy: A une époque il y avait sur toutes les cartes des cavaliers qu'on pouvait mettre ou enlever. Aujourd'hui on n'ose plus parler de ce genre de choses dans un mode d'emploi :cry:. Inutile de poser la question à un vendeur, pour lui c'est du :jap:.
 
NON, il est rigoureusement interdit d'utiliser en même temps 2 appareils qui vont soumettre des requêtes: interférences garanties...
Merci pour la réponse. Et si je les branche tous les deux mais que je n'en utilise et n'en allume qu'un à la fois, est ce que ça pourrait marcher.
 
NON, il est rigoureusement interdit d'utiliser en même temps 2 appareils qui vont soumettre des requêtes: interférences garanties...

Faux : le bus CAN dont le fonctionnement est expliqué sur la Wikipedia :

https://fr.wikipedia.org/wiki/Controller_Area_Network

fonctionne en CSMA/CR ce qui signifie Carrier Sense Multiple Access/ Collision Resolve. Le détail de la signification se trouve sur le lien ci-après :

https://fr.wikipedia.org/wiki/CSMA

Pour faire court, cela signifie que le bus est conçu pour supporter plusieurs émissions simultanées. La collision sera détectée et "l'objet" d'adresse la plus basse passera en premier.

Un objet - qui correspond à un capteur ou un actionneur dans une ECU - est défini par un nombre. Sur les voitures il y a plusieurs ECUs qui possèdent - par exemple - l'objet dix.

Si un émetteur demande cet objet dix, il aura autant de réponses qu'il y a d'ECUs le possédant. L'une derrière l'autre, sans problème ; les conflits et la gestion de priorité étant gérée au niveau du circuit électronique. C'est transparent.

Par principe (voir Wikipedia) on ne peut pas demander une ECU particulière. On peut juste demander des numéros d'objets (compris entre 0 et 2047 dans le cas de la PRIUS).
 
@marcolinge:
Si il y a une seule appli active, no pb.

@grosours:
Et moi, je soutiens, mordicus, que cela va foutre le bord d'aile... :-D

Car les applications qui soumettent des requêtes, attendent une réponse suite à leur requête et pas à celle soumise par une autre appli...
surtout quand ces requètes sont assez similiaires. et avec HA, nous procédons à du CAN-STUFFING ce qui complique un peu le décodage...

Par curiosité, essaie d'utiliser HA et Torque simultanément (en utilisant un diviseur en Y), et reviens me donner des nouvelles...

Si tu l'essaies, je te suggère de le faire en statique... :grin:

et je te garantis que HA racontera nimportenawak
 
@grosours:
Et moi, je soutiens, mordicus, que cela va foutre le bord d'aile... :-D

Attention : j'ai uniquement écris que le bus était fait pour supporter plusieurs requêtes simultanées. Rien de plus.

Il est évident que si la fréquence des requêtes dépasse la capacité du bus ça va planter. C'est la caractéristique "universellement connue" de tous les bus en CDMA et CSMA.

Une seule appli peut largement suffire à ça si elle abuse du bus.

C'est d'ailleurs dans un autre contexte une façon bien connue pour obtenir - par exemple - un "Service deny" sur le système informatique du Pentagone.

:papy: Sur le système informatique des caisses de retraite on en est d'ailleurs déjà là sans la participation de pirates. Pas question d'y brancher en plus HA :grin:.

P. S. : j'ai lu ces derniers jours un excellent article scientifique sur les problèmes de sécurité liés à la prise diagnostic (les mille et une manières de planter une voiture :grin:).

https://www.escrypt.com/fileadmin/e...tections_for_Vehicular_On_Board_Diagnosis.pdf
 
Je parle d'interprétation des données reçues. (qui ne correspondent pas à ce qu'on attendait)

Je ne pense pas que l'on risque de saturer le bus (mais peut-etre les ECUs qu'il y a un peu partout).
 
Le soucis n'est pas au niveau de la couche la plus basse

@GrosOurs.

Tu t'es placé au niveau électronique. A ce niveau il n'y aura pas de soucis. Au début de chaque paquet il y a l'adresse de l'émetteur et il y a effectivement priorité à celui d'adresse la plus faible. Les autres émis au même moment vont vite se rendre compte qu'ils devront réémettre plus tard.
C'est d'ailleurs ce que ce protocole a de génial: le plus faible ne sera pas ralenti et n'aura pas besoin de réémettre, malgré la collision.
Le soucis évoqué par Priusfan n'est pas là.
Il va y avoir deux programmes qui vont émettre des requêtes.
Il peut y avoir un problème de "timing" au niveau des envois de ces requêtes, l'un envoyant alors que les réponses de l'autre ne sont pas encore parvenues.
Il faut savoir que les réponses ne sont pas adressées à un émetteur mais à tout dispositif qui écoute sur le bus. Chacun des demandeurs ne va pas traiter ses réponses mais un mélange des deux.
L'interpénétration de deux requêtes complexes adressées à une ecu n'est pas, à ma connaissance, prévu !
Ceci est vu depuis les requêteurs.
Maintenant vu par l'ecu interrogée, le résultat n'est pas prévisible.
Elle peut mal comprendre et croire recevoir une demande que personne n'a émise. Cela dépend du délai entre les deux requêtes et du contenu de chaque demande. Elle peut abandonner considérant qu'elle a reçu deux début de requêtes, ou pas.

:jap:
 
Et maintenant les cartes...

Pour vous donner une idée de ce que l'on mijote,
allez faire un tour en bas de ce "rapport" :-D

C'est déjà ça que j'ai dans mes rapports.

C'est la base pour la suite que j'ai déjà vue en avant première chez toi :-D
J'ai hâte, parce que je trouve ça super intéressant!
 
Et maintenant les cartes...

Pour vous donner une idée de ce que l'on mijote,
allez faire un tour en bas de ce "rapport" :-D

Lien vers le bon rapport ? viewer version 12. Faille temporelle ou teasing pas up to date ? :grin:

Mais bon, on a confiance, le fond de carte va venir. :jap:
 
@GrosOurs.

Tu t'es placé au niveau électronique. A ce niveau il n'y aura pas de soucis.

Effectivement, c'est bien ce que j'ai voulu dire. Désolé si je ne suis pas parvenu à me faire comprendre.

Le problème éventuel est bien au niveau supérieur comme tu le signale, Bosch n'ayant pas prévu dans le protocole au départ le cas où plusieurs "stations" disposeraient d'un objet différent (puisqu'il faut parler d'objet et non d'adresse dans le cadre du protocole CAN) mais avec le même numéro.

Le problème vient d'ailleurs des constructeurs automobiles qui se sont mis à un moment donné à faire cette salade qui apparemment marche quand même assez bien (et c'est probablement pour ça qu'ils n'ont pas été plus précautionneux).

Selon la philosophie CAN, chaque ECU (dans le cadre automobile) aurait dû disposer d'un nombre d'objets avec des numéros uniques (et je n'ai programmé que dans ce cadre, seul prévu par la norme). Les numéros n'auraient jamais dû être partagés. Ceci étant, le fait qu'une station supplémentaire rentre dans cette salade quand il y en a déjà une demi-douzaine ne change pas fondamentalement les choses.

Le problème de fond est qu'on confie la conception de chaque ECU à des équipes différentes qui ne communiquent pas, et donc la cohérence de l'ensemble n'est pas assurée :cry:. Mais comme ça à l'air de marcher quand même...

L'équipe de normalisation J-1939 devait être au restaurant quand le problème aurait dû être traité :-?. Ayant fait partie d'un groupe de normalisation réseau, je connais le problème :-D.
 
question

Coucou,

Et sur un trajet de plusieurs centaines de kilomètres ?
Le rapport ne risque t-il pas d'exploser la mémoire ?

Faut-il être obligatoirement connecté en 3G/4G avec HA ou bien on peut le faire fonctionner en mode local ( sans gps ni carto par conséquent ) ?

A plus.
 
Coucou,

Et sur un trajet de plusieurs centaines de kilomètres ?
Le rapport ne risque t-il pas d'exploser la mémoire ?

Faut-il être obligatoirement connecté en 3G/4G avec HA ou bien on peut le faire fonctionner en mode local ( sans gps ni carto par conséquent ) ?

A plus.

Même question!
Je n'ai fait que des parcours max de 5 km, mais dans quelques semaines ce sera 1000 km
 
ça fonctionne sur longs trajets sans problème.
Mais il faudra faire le ménage dans les reports de temps à autre.
ça fonctionne sans 3G 4G, par contre sans GPS il te manquera les courbes et infos qui en dépendent. Les données "hybrides" n' en seront donc pas affectées.
Pour résumer ça fonctionne parfaitement avec un vieux smartphone dédié à cette fonction sans carte SIM.
 
Pages vues depuis le 20 Oct 2005: 310,812,251
Retour
Haut Bas