elm327 BT / Android

Alors je me suis sans doute mal exprimé: je compte prendre la pin 14 du diag et la brancher sur la pin 6 de la carte et la pin 14 de la carte. La pin 6 du diag restant vide. J'ai bon là?
Je débute dans le domaine donc je ne suis effectivement pas à l'abris d'une connerie!
 
dans le cas d'un elm327 original, il s'agit de mettre la patte 6 à la masse de façon à forcer le baudrate à 9600 bps.

dans notre cas, il faut probablement faire pareil.

càd identifier la patte 6 du PICxxxx , la dessouder car elle trés probablement liée au +5v comme ses voisines immédiates et la relier direct à la masse créérait à coup sur un court-jus..

14d429d456c7bb.jpg



la masse et surtout pas le 14 de la prise diag (canL)
la masse est en 4 sur la prise diag
 
Dernière édition:
requète multipid

cela marche parfaitement :-D
on peut en enquiller jusqu'à 7 d'un coup (au moins sur la p3).
j'ai testé pour le moment seulement en mode console de eobdfacile.
je testerai avec mon pgm vb qui permet de mesurer les temps.
ci dessous un extrait de ma série de tests.
[table="head;width=60%"]cmd|reply|
atsh7E0|OK|
||
2101 |7E8 10 1B 61 01 00 00 00 00 |
|7E8 21 11 65 46 61 4A 00 00 |
|7E8 22 00 02 4A 00 2C 7D 2C |
|7E8 23 FF 62 60 9F 73 39 AD|
||
213C |7E8 07 61 3C 0D 2C 07 E6 80|
||
2149 |7E8 10 0E 61 49 00 00 00 80 |
|7E8 21 00 FF 77 1D 00 08 25 |
|7E8 22 0A 00 00 00 00 00 00 |
||
21013C49 |7E8 10 2E 61 01 00 00 00 00 |
|7E8 21 12 65 47 61 49 00 00 |
|7E8 22 00 02 93 00 2C 7D 2C |
|7E8 23 FF 62 60 9F 74 39 AD |
|7E8 24 3C 0D 2C 07 E6 80 49 |
|7E8 25 00 00 00 80 00 FF 77 |
|7E8 26 1D 00 08 25 0A 00 00 |
||
atsh7E2| OK |
||
2101 |7EA 10 18 61 01 00 65 47 2B |
|7EA 21 65 49 00 00 00 02 C3 |
|7EA 22 2C 29 51 FF 62 66 9F |
|7EA 23 65 39 11 93 00 00 00 |
||
210161 |7EA 10 1E 61 01 00 65 47 2B |
|7EA 21 65 49 00 00 00 02 CB |
|7EA 22 2C 29 51 FF 62 66 9F |
|7EA 23 65 39 11 93 61 3A 37 |
|7EA 24 3A 80 00 00 00 00 00 |
||
210161626768 |7EA 10 30 61 01 00 65 48 2B |
|7EA 21 65 49 00 00 00 02 DA |
|7EA 22 2C 29 51 FF 62 66 9F |
|7EA 23 65 39 11 93 61 3A 37 |
|7EA 24 3A 80 00 62 36 36 36 |
|7EA 25 80 07 67 80 00 80 00 |
|7EA 26 00 68 80 00 80 00 00 |
||
210161626768707174878A98 ? |?|
2101616267687071 ? |?|
21 01 61 62 67 68 70 |7EA 10 35 61 01 00 65 49 2A |
|7EA 21 65 48 00 00 00 03 39 |
|7EA 22 2C 29 51 FF 62 66 9F |
|7EA 23 67 39 11 92 61 3A 37 |
|7EA 24 3A 80 00 62 36 36 36 |
|7EA 25 80 00 67 80 00 80 00 |
|7EA 26 00 68 80 00 80 00 00 |
|7EA 27 70 39 37 4A 00 00 00 |
[/table]
dans la mesure où la séquence de la commande est connue, le découpage de la réponse ne pose pas de difficultés particulières.
 
C'est une bonne nouvelle. Reste à trouver un bon algorithme qui va avec ça.
Une question : quand tu dis 7 d'un coup, c'est séquentiel ou en parallèle ???
 
demande en 1 fois, réponse séquentielle dans l'ordre de la demande.
 
La mesure du temps global pour la requête va être fichtrement intéressante car il est très probable que cela réduise le temps pour chaque pid.

Il est quasi-certain que l'ecu interrogée traite en séquence les 7 appels, pas en parallèle.

Pour le découpage de la réponse on a juste besoin de connaître d'avance le nombre d'octets de chaque réponse. De plus il y a un octet qui répète la demande.

A priori pas vu d'octet de type crc ?

A+
 
CAN Snuffing

voila le résultat des courses, on gagne environ 1 seconde sur la séquence du post 93.
les trames sont bien formées et leur contenu est exploitable.
si on élimine la demande des temps du pot cata et le niveau du réservoir, on arrive à 1 sec.
[table="head;width=60%"]Commande|t1|t2|t3|t4|t5|moy|
AT SH 7E0|
63​
|
47​
|
125​
|
63​
|
125​
|85|
01 3C 3E|
250​
|
109​
|
78​
|
93​
|
93​
|125|
21 01 3C 49|
265​
|
266​
|
282​
|
266​
|
266​
|269|
AT SH 7E2|
63​
|
63​
|
46​
|
62​
|
78​
|62|
21 01 61 62 67 68 |
281​
|
265​
|
282​
|
282​
|
281​
|278|
21 70 71 74 87 8A 98|
266​
|
297​
|
281​
|
281​
|
282​
|281|
AT SH 7C0|
62​
|
47​
|
47​
|
47​
|
62​
|53|
21 29|
110​
|
109​
|
125​
|
109​
|
109​
|112|
total|
1360​
|
1203​
|
1266​
|
1203​
|
1296​
|1266|
[/table]
 
guinness à dit:
Merci pour les échanges, dans la série augmenter la vitesse il y a aussi ce produit qui n'est pas donné mais qui a plusieurs avantages...
Cliquez pour agrandir...

bon, et bien moi aussi j'ai "brické" mon interface :oops:.
la bleue par contre marche encore correctement et c'est avec elle que j'ai procédé au test ci-dessus.

j'ai donc commandé le produit cité par guinness; il a l'air effectivement beaucoup plus fiable et performant.
je l'ai commandé ici , c'est plus rapide qu'une commande aux US et, en fait, revient certainement moins cher du fait du transport et des taxes.
(j'ai commandé celui qu'ils avaient en stock).
 
Mouarf, on peut savoir comment? :-D

Bon du coup j'ai craqué aussi et j'ai trouvé un distrib au uk pour à peu près le même prix + les frais de paiement hors zone euro (selon banque).
Pour les autres il vaut mieux attendre que le distributeur de priusfan se ré-approvisionne.

Sinon avant ta mise en garde j'avais branché mon setup (canL voiture sur canH et canL dongle) et je l'avais testé sur notre seconde voiture, une nissan micra (la cnx bt s'est faite mais pas de dialogue concluant avec le dongle); la voiture marche normalement (pas de voyant), vous pensez qu'il y a un risque que j'ai endommagé le bus de la voiture? :eek:
A l'avenir je serai un peu plus prudent... :-?
 
Bon finalement pas de stock aux UK, je vous envoie l'échange de mails car il parle d'interface bt pas tip top (mais ça reste un peu vague, je viens de lui demander des précisions):
I am sorry to inform you there is no stock of Bluetooth OBDLink at the moment. I am not sure if and when we will be getting more stocks. I can send you the USB version and refund the difference in cost or I can cancel the sale and refund the payment.
If you can let me know what you wish to do.
Cliquez pour agrandir...
No problem, consider it done but a word of advice, the bluetooth is not good on the OBDLink, this is the reason why we do not have any for sale anymore. I just thought I should let you know.
Your refund will be processed tomorrow, (Monday 31)
Cliquez pour agrandir...
 
intéressant...
je pense recevoir le mien demain ou après demain.
je le testerai depuis XP, avec ma petite appli qui fait passer un cycle de test;
d'abord en BT puis en usb.
ce qui est sympa,c'est d'avoir des points de repère avec d'autres interface en BT.
pour info, auparavant, les 60 interros par seconde me paraissaient "normales"....
 
Bon, c'est rassurant, voici sa réponse:
Hello,
When I mean it is not good, I am comparing it to the USB option I guess if you are happy with that then it will be ok for you.
Cliquez pour agrandir...

En gros, il dit que c'est décevant par rapport à USB, et il a raison, on n'atteindra jamais les mêmes débits, mais si ça marche bien à 115k, on devrait pouvoir faire presque 3 cycles par seconde, ce qui me parait bien suffisant.

Sinon de mon côté les tests vont être en standby pendant quelques temps, faute d'interface, mais j'essaierai peut-être dimanche prochain si la météo est pourrie d'implémenter une fonction basique requête + réponse dans la même thread (il ne restera plus grd chose de btchat) pour pouvoir benchmarker avec moins de variables (mon implem initiale qui ne cassait par la philosophie btchat était peu optimale)...
 
les italiens ont commencé en BT , ils disent récolter 15 échantillons par seconde et qu'ils peuvent superviser 32 variables (mais attention, une à la fois).
ils sont ensuite passé à l'usb pour une question de vitesse d'acquisition.
le développeur du canblue est très "réservé" , j'ai filé à ce sagouin une feuille excel présentant le résultat de mes recherches sur la p3; en échange, il m'a filé un petit exe de son truc (rigoureusement inutilisable pour moi).

il y avait sur leur forum un certain tigre72 qui a commencé à développer sous xp en vb pour un tactrix;je lui avais filé le mécanisme de collecte en vb pour tactrix; il ne publie plus sur leur forum, il m'a envoyé un mail me disant qu'il avait eu un très grave accident (ne précisait pas s'il jouait à l'ordinateur en conduisant)....
 
@guinness
le système de obdreader me semble tout à fait convenir (lecture suit immédiatement la commande).
dans ton prochain dev, ce serait bien de ne pas faire du "one shot", càd pouvoir relancer le cycle à volonté :D.
 
obdlink

je l'ai reçu.
marche normalement avec torque en BT
marche normalement avec le truc de obdfacile en BT
marche normalement avec le truc de obdfacile en USB

pas pû tester avec mon appli de référence:

  • ports comms étonnant (19 en BT , 21 en USB).

  • plus de batterie sur mon portable.

  • et surtout, froid de canard dans le garage...
 
des tests, des tests !

J'attends de voir si tes tests montrent que les requêtes/réponses vont 2 fois plus vite qu'avec le dongle bleu avant d'acheter (de toute façon j'aurai de l'attente puisque plus de stock)...
Pour l'instant j'ai renoncé à continuer à jouer avec mon dongle (même si j'ai identifié les numéros de pins sur le PIC18F2480, j'ai pas de garantie qu'ils respectent les specs de l'elm), je vérifierai d'abord avec le nouveau que je n'ai rien abîmé sur la micra :oops:
 
Le PIC18F2480 est un microcontroleur de chez microchip.
Il se trouve que j'ai commencé à travailler sur ce type de PIC et que j'ai de quoi lire et écrire dans les mémoires donc lire le code programme et écrire un nouveau prog. Mais en brochage DIL, pas en cms soudé.
En bref c'est un ordi avec des mémoires permanentes qui contiennent le programme que l'on télécharge et des données et des pattes d'E/S.

La solution propre serait d'écrire dans les zones ou sont stockées les données...
Ce qui dépend du programme qui a été installé dedans...

Pour un reset ils parlent au chapitre 4 d'un MCLR (broche 1) voir page 43.
Mais je crains que cela ne fasse que redémarrer le prog à l'instruction 1.
Ils disent que la plupart des registres ne sont pas raz à ce moment, §4.6

Pour la vitesse en baud c'est page 332 et +

Chez microchip le brochage est normalisé.
Pour flasher un prog ils utilisent un protocole dit icsp (in circuit serial programing). Mais un programme flashé remplace celui présent donc l'efface.


attention c'est sûrement du mosfet donc prudence avec l'électricité statique.
 
planétaire à dit:
La solution propre serait d'écrire dans les zones ou sont stockées les données...
Ce qui dépend du programme qui a été installé dedans...
Cliquez pour agrandir...
Ben c'est là tout mon problème (outre le fait que j'ai jamais fait d'électronique :-D), l'elm327 définit une procédure hardware pour effacer les PP (Programmable Parameters - là où j'ai fait la boulette qui rend mon dongle aussi utile qu'une disquette 5 pouces 1/4 aujourd'hui); mais je ne sais pas comment transposer cette manip sur le PIC ni en fait si elle a été programmée.
De toute façon vu que j'ai fait le gros boulet en manipulant les broches de la prise, je ne suis même pas sûr qu'il fonctionne encore (sur ma dernière manip en rebranchant la nappe, je n'ai même pas vu le clignotement de toutes les led à la mise sous tension en IGN-ON).
C'est pas grave, ça a été une expérience intéressante, je sais un peu mieux à quoi m'attendre maintenant et j'attends avec impatience le résultat des tests de priusfan sur le modèle USB+BT.
 
obdlink premiers tests

ce soir, un peu flemmard; je lance le test de guinness sous android...

résultats un peu glop:
Code: 
21:47:07:530 Sent: AT SH 7E0
21:47:07:559 Received: OK

21:47:07:564 Sent: 01 3C 3E
21:47:07:590 Received: 7E8 07 41 3C 0F ED 3E 0B C2 
STOPPED

21:47:07:597 Sent: 21 01 3C 49
21:47:07:624 Received: 7E8 10 2E 61 01 65 00 31 01 
STOPPED

21:47:07:631 Sent: AT SH 7E2
21:47:07:657 Received: OK

21:47:07:661 Sent: 21 01 61 62 67 68
21:47:07:690 Received: 7EA 10 30 61 01 65 25 3F 31 
STOPPED

21:47:07:700 Sent: 21 70 71 74 87 8A 98
21:47:07:751 Received: 7EA 10 2A 61 70 45 3D 4B 00 
STOPPED

21:47:07:753 Sent: AT SH 7C0
21:47:07:784 Received: OK

21:47:07:795 Sent: 21 29
21:47:07:845 Received: 7C8 03 61 29 1E 00 00 00 00 
STOPPED
à première vue, les temps sont très bons,
oui mais
de 2 choses l'une:
soit il ne gère pas spontanément le multiframe (ce qui serait rédhibitoire).
soit on l'a interrompu systématiquement avant qu'il termine sa phrase...

je referai des tests avec mon appli en vb pour en avoir le coeur net...


:-D:-D:-D
addendum 23h06
pas de pb avec l'interface, il gère parfaitement le multiframe, mais comme il est plus réactif que l'autre, il n'aime pas etre interrompu (talkie/walkie).

sequence de test passe sans pb.
je dois finaliser un autre pgm de test pour les chronos car je dois gérer ce port com par les API de windows !!!!
cela sera fini pour demain soir.

sur interface, il y 5 loupiotes trés pratiques pour mise au point...
 
Dernière édition:
glop

J'ai plus trop confiance en mes modifs de bt-chat pour faire du talkie-walkie, je referais qqchose de plus proche de ton vb dès que je trouve le temps.

J'attends tes chronos pour lancer ma commande (toujours pas en stock de toute façon), quoiqu'il arrive ce module a quand même l'air un cran au dessus des modules bt de Chine...

Merci pour les news :jap:
 
proposition de gestion des séquences à envoyer (et de leur fréquence)
but externaliser une partie du paramètrage de l'ordonnancement.
je suggère l'usage de 2 fichiers externes de paramètres (localisés là où guinness a mis le logging).
le premier par exemple init.txt contiendrait la séquence d'initialisation.
le 2ème, spécifique au modèle, contiendrait 3 infos:
a) groupe
b) fréquence
c) commande
les groupes permettraient de regrouper des bouts de séquence liés (sélection d'un ECU suivi de la commande)
le contenu pourrait ressembler à cela:
[table="head;width=60%"]Groupe|Fréquence|Commande|
A|10|atsh7e0|
A|10|2101|
B|10|atsh7e2|
B|10|2101|
C|20|atsh7e2|
C|20|216162|
D|50|atsh7e2|
D|50|216768|
E|100|atsh7e0|
E|100|013c3e|
[/table]
cela vous inspire ?
 
Dernière édition:
Pour gérer au mieux la bande passante

Peut-être devrez-vous exécuter certains pid en tenant compte d'1 condition.

-Par exemple ne demander la durée d'injection que si on a des tr/mn sur ICE.
Ceci afin de gérer au mieux la bande passante.

-Ou encore faire varier la fréquence d'un pid en fonction de sa valeur !
exemple l'accélérateur n'a besoin d'un rafraichissement qu'aux faibles % d'enfoncement.
 
@planétaire
conditionnement de l'échantillonnage: oui et non.
oui, si on est vraiment limite dans la bande passante.
non, car la programmation devient du jésuitisme.

amha, c'est la partie traitement des données qui doit faire le tri entre ce qui est pertinent ou non, en fonction des conditions à un moment donné;

de cette façon, la tache de récolte des données brutes vit sa vie de manière autonome et fiabilisée.
 
Intéressant. Je vais discuter algorithmes avec mon frere pour que ce soit performant et facile à mettre à jour.
 
Identifiez-vous ou inscrivez-vous pour participer.
Pages vues depuis le 20 Oct 2005: 313,226,585
Retour
Haut Bas