• L'Assemblée Générale du Prius Touring Club aura lieu le 7 décembre 2024 du côté de Rennes. Si vous êtes adhérent renseignez-vous ici.

MBED, Arduino , STN1110 & BT

  • Initiateur de la discussion Initiateur de la discussion priusfan
  • Date de début Date de début
Bien. Bien.
Et bien d'accord.
Je m'y mets dans quelques semaines pour communiquer dans l'autre sens avec le MDEB.
Cela me donnera l'occasion de mettre à jour l'heure dans le MBED, et de récupérer les DTC, et les effacer (surtout si je me remets au E85).

Je pense que LessPoluter, Ceif et d'autres pourraient aussi être interessés, M8.
Peut-être pouvez vous vous organiser !
 
thierryb à dit:
Je pense que LessPoluter, Ceif et d'autres pourraient aussi être interessés, M8.
Peut-être pouvez vous vous organiser !
Cliquez pour agrandir...

Merci beaucoup !
Et avec plaisir pour une organisation ! Je vais contacter tout le monde 🙂
 
Il faut faire attention que les caractéristiques des composants de remplacement soient identiques ou meilleures, mais aussi que les branchements soient les mêmes, ainsi que les tailles. Sinon, pas de platine, et peut-être pas de soft fonctionnel.
Le réglage du soft m'a pris tout l'été 2012 !
 
M8, pourquoi n'es tu pas adhérent du PTC ?
Le cout n'est pas très élevé.
Et cela contribue à l'existence du forum
 
Ah et bien à mon arrivée j'avais cherché mais finalement je pensais que l'adhésion c'était plus d'actualité.
Autant pour moi je vais essayer de régler cet affront rapidement😀

Pour les composants on va prendre les mêmes dans la mesure du possible 😉
 
ci-joint un scan de platine annoté.


cela permet de vérifier le brochage du module BT et du régulateur.

les valeurs des résistances et des capas ne sont pas vraiment critiques:
on trouve un peu de tout suivant les montages sur la toile.
 
Merci PriusFan, avec ça plus les autres documents normalement pas de soucis !

Par contre j'avais 2 questions de débutant :

- pourquoi du BT en 115 000 bauds ? avec Planétaire sur nos BT il me semble que c'est en 9600 pour le BMS .

- quelle différence y a t il en un régulateur 5v (comme tu présentes) et un convertisseur vers le 5v (comme j'utilise pour mon BT justement) ?

Merci en tout cas !! :jap:
 
N'oublies pas que tu veux recevoir tes données comme avant dans PCM, et il en faut des données.
Maintenant, tu peux prendre un 9600. Mais dans ce cas, le MBED devra choisir quoi t'envoyer pour que cela ne déborde pas.
 
Merci Thierry, maintenant je sais donc à quoi sert cette info, c'est le nombre de données qu'on peut échanger ! Merci bien 🙂 !
 
BT baudrate en 2 mots et à la louche:
@ 9600 on peut faire transiter au maximum 900 Caractères/Seconde (en pratique 400).
@115200, 10 fois plus....

- quelle différence y a t il entre un régulateur 5v (comme tu présentes) et un convertisseur vers le 5v (comme j'utilise pour mon BT justement) ?
Cliquez pour agrandir...
Ce que je préconise est un "buck down converter".
2 raisons:

  • Le montage consomme beaucoup moins (conso divisée par 2.5) qu'avec un 7805.

  • Le régulateur ne chauffe pas du tout, alors qu' avec un régulateur linéaire, je devais utiliser un radiateur...
.
Ton convertisseur est fort probablement du même type que celui que je préconise.
 
Le convertisseur de m8 est assez proche mais différent: mais il est isolé, inutile ici. Donc il a un transfo HF lui.

(Le module BT pour le bms plug-in ne fait transiter que 150 caractères/seconde d'où seulement 9600 bauds, en plus c'était plus facile au niveau des pic.)

Ce qui veut dire que notre objectif est de faire dialoguer le PC avec deux modules BT "en même temps", un en 9600b et l'autre en 115200b

J'ai une question: vu que le module mbed+bt est alimenté par la prise odb, est-ce qu'un système de mise en veille a été implanté ?
 
Non, pas de mise en veille.
Mais il ne fait plus de calcul (ou quasiment plus) quand il ne reçoit rien.
Je pense que priusfan avait mesuré la conso dans ce cas.
Mais, je ne le débranche jamais. Je le ferai peut-être si je laisse ma voiture à l'aeroport pour plus d'une semaine.
Un PC peut communiquer avec plus d'un Bluetooth, le mien communique déjà avec le MBED et mon GPS. Et j'envisage d'ajouter une communication avec une tablet Android, sans inquiétude.
 
A priori nous serions donc 5 à être intéressés. Dès que j'ai un peu de temps je me penche sur les commandes à réaliser.... 8)
 
J'ai enfin fabriqué mon cable Y pour enregistrer toutes les 1670 trames par secondes au moyen de l'ODBLink http://www.scantool.net/obdlink.html avec USB 2 Mbits/s ainsi que des trames sollicitée émises par une carte arduino. Première surprise, il refuse de lire le CAN si la pinoche 12 V n'est pas alimentée, bien que l'USB l'alimente. Pour l'arduino, il suffit des deux fils de signal. J'ajoute tout de même la masse.

Mon problème maintenant est que l'ODBLink ne lit pas les trames multilignes en mode ATMA. Voici un extrait

0.108750:7E0 02 01 0C 00 00 00 00 00
...
0.111872:7E8 04 41 0C 00 00 00 00 00
0.111876:039 28 00 10 75
0.112749:7E0 02 21 CD 00 00 00 00 00
0.112754:03B 00 0D 00 DC 29
0.112757:038 C0 00 08 00 00 00 07
0.114839:7E8 10 0D 61 CD 00 00 00 80
0.115713:030 84 00 00 00 00 20 00 DC
...
0.621375:7E0 02 01 0E 00 00 00 00 00

La trame à 0.114839 devrait être suivie d'une autre ligne, que je ne vois pas.
J'ai pris soin d'attendre 500 ms avant d'envoyer une autre requête.

Question pointue de la part d'un néophyte du CAN :
- Est-ce que l'ECU émetteur de ces trames attend que celui qui a fait la requête les lise pour poursuivre. Il est vrai que je ne poursuis pas la lecture avec l'arduino, mais je croyais que le fonctionnement du CAN était du type broadcast.
- Ou est-ce que l'ECU émet ses deux lignes mais c'est l'OBDLink qui ne lit pas tout ?

[edit] : l'ECU émetteur attend. On trouvera une explication très claire ici : http://www.canbushack.com/blog/inde...-layer-yes-it-can-be-fun&more=1&c=1&tb=1&pb=1
 
Dernière édition:
kinetik à dit:
On trouvera une explication très claire ici : http://www.canbushack.com/blog/inde...-layer-yes-it-can-be-fun&more=1&c=1&tb=1&pb=1
Cliquez pour agrandir...

Et ça marche ! On remarquera que l'émission de La "Flow Control Frame" "30 00 00" permet de débloquer la suite de l'émission par l'ECU "7E8 21 ..."

16.078269:7E8 21 11 00 00 00 00 18 22
16.085279:7E0 02 01 05 00 00 00 00 00
16.088283:7E8 03 41 05 44 00 00 00 00
16.192268:7E0 02 21 CD 00 00 00 00 00
16.197301:7E8 10 0D 61 CD 00 00 00 80
16.198170:7E0 30 00 00 00 00 00 00 00
16.198176:7E8 21 11 00 00 00 00 18 22
16.205134:7E0 02 01 05 00 00 00 00 00
16.209185:7E8 03 41 05 44 00 00 00 00
16.310245:7E0 02 21 CD 00 00 00 00 00
16.318134:7E8 10 0D 61 CD 00 00 00 80
16.318135:7E0 30 00 00 00 00 00 00 00
16.318136:7E8 21 11 00 00 00 00 18 22

Maintenant j'aimerais bien comprendre pourquoi je dois émettre des trames de 8 octets et non pas seulement 3.
 
Tu as répondu avant moi à ta question.
Mais je ne connais pas la réponse à ta deuxième question.
 
Mais Thierry, tu as peut-être observé si avec MBED vous envoyez des requêtes de 3 ou 8 octets. Je souhaite charger le moins possible le bus CAN.

A propos de charge du bus, cela ne me semble pas absurde de le surcharger un petit peu avec des messages maison
- GPS position spatiotemporelle
- altimètre
- boussole
Cela faciliterait le problème de l'enregistrement des données. On leur attribue quels numéros ? Des 6xx pour minimiser l'impact bien sûr.

Attention, cela risque de se balader prochainement sur ton véhicule si tu n'y mets pas un veto.
 
bonjour,
pour répondre à la 2ème question, donne plus de détails sur ton interface arduino/shield et le bout de code pour envoyer des requètes...
d'après mes souvenirs, cela devrait etre possible en précisant le nombre d'octets de la requète, mais cela dépend de l'interface:
tactrix/elm327/canusb/stn1110


à propos de l'obdlink, il est effectivement nécessaire de l'alimenter en 12V, (l'alim via USB n'alimente que le ftdi).
 
@Kinetik. Oui, dès que tu as reçu la première réponse tu émets le 30 00 ...00
J'ai un lointain souvenir que l'ecu numh n'acceptait pas n'importe quel délai entre ce 30 00 et le premier envoi 7Ex... Elle n'est peut-être pas aussi véloce. Mais c'est un lointain souvenir.

Pour ce qui est d'utiliser le bus pour des messages maison, prudence. Norman a eu des soucis. Visiblement certains d'entre eux sont prévus mais pas émis !
Avec bms+ il utilise les 555h et 556h.

La règle de priorité est du nombre le + petit vers le + grand. Les plus petits ont priorité. Donc ceux qui attendront si besoins sont les 7xx.
 
priusfan, je nettoie le code et je le poste un peu plus tard

planétaire, tu penses pouvoir retrouver la liste de soucis de Norman, ou puis-je le contacter ? Je préfère multiplier les types de trame que m'aventurer dans l'écriture de multilignes.

planétaire, je ne suis pas certain de comprendre le problème de délai. Il faut attendre avant d'émettre le 30 00 00, ou écrire autre chose genre 30 xx xx pour demander un délai, ou mentionnes-tu juste le fait que la suite va se trouver un peu loin dans le temps ?
 
Ici norman a utilisé aussi le 554 mais:
Pour le pid à ne pas utiliser je ne retrouve pas de suite son code,
Edit le voilà:
!!the 4 sets of new codes labeled XXoct162 below are to replace all previous codes because I screwed up when I previously added a new diagnostic message 554 from BMS+ and BMS2. A little-used Toyota diagnostic message also exists at 554 so CAN-views did not always display my message. This diagnostic message (which nobody yet uses) is now at CAN559 instead.!!!
Cliquez pour agrandir...



Le délai c'est entre réception de la trame 1 et émission du 30 00 pour avoir les autres trames.
C'est flou dans ma mémoire. Mais ce qu'il faut retenir est que si tu as un soucis avec cette ecu et pas les autres, c'est qu'elle est un poil plus lente et je doute que cela soit dû à la longueur du câble, certes cette ecu est loin dans le coffre et le délai d'émission/réception est supérieur mais ce sont des électrons quand même.

P.S. J'ai jeté un coup d'oeil dans les sources de pcm-tactrix (Tactrix qui est super rapide avec lequel on a plus de 2000 trames/seconde). Avec tactrix on émet 8 octets aussi. Thierryb confirme ?
 
si l'interface est de type elm327 ou stn1110, le fait de mettre dans la séquence d'init AT CA F1 permet la génération automatique du message de "continuation" (le fameux 30 00 00 00 00 00 00 00).

c'est fort intéressant, car ainsi tu ne perds pas de temps avec un timer.

ce mode, appelé "Auto Formatting On", n'est pas compatible avec le STMA qui permet de lire tout le trafic; mais comme tu utilises l'arduino comme un simple séquenceur de requêtes, cela est parfait pour ton besoin.

par ailleurs, je dispose d'un shield OBD2 pour arduino dont je n'ai pas l'usage, je te le filerai bien volontiers si tu en as l'usage.
 
Pas de doute, Quand il vous manque un truc, genre programmateur de can view ou autre shield, avant d'aller sur alibaba ou autre voleur il y a bien plus simple. :grin:
 
Identifiez-vous ou inscrivez-vous pour participer.
Pages vues depuis le 20 Oct 2005: 316,276,160
Retour
Haut Bas