• 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.

elm327 BT / Android

  • Initiateur de la discussion Initiateur de la discussion priusfan
  • Date de début Date de début
pour la p2, il faut recomposer les requètes.

pour 7E2 , il y en seulement 1 (qui combine les 2 demandes)
7e2 21 c3c4

pour 7e0, il faut en fabriquer une (ou plusieurs), @ vous de choisir....
 
j'étais pas loin ;-)

Merci pour la correction, je suis content de voir que ça marche. 😀
Pour avoir les logs datés par ligne, il suffit de décommenter quelques lignes dans ResponseHandler (je l'ai fait dans la version svn chez code.google).

Pour changer les commandes à envoyer, c'est dans CommandScheduler que ça se passe (penser à modifier aussi le constructeur car j'ai hardcodé des tests pour la périodicité).

Je m'occuperai de lire des fichiers xml pour les commandes (la semaine prochaine); je vais aussi regarder pour reconstruire un tableau de bytes à partir des couples de bytes en ascii (on pourra alors appliquer les formules du fichiers excel). Ensuite il faudra communiquer ces infos à l'UI graphique (grâce à handler.sendMessage). Y-a-t-il quelqu'un qui sache comment dessiner une aiguille sur android ou faire un écran graphique qui ressemble à qqchose?

Je pense aussi rajouter une activity Settings où l'on pourra décider de logguer dans un fichier ou non, afficher ou non des valeurs dans la partie graphique, etc.

PS: Pour gérer P2/P3, etc., il suffira d'avoir plusieurs fichiers de commandes et on sauvera dans les préférences quel fichier utiliser.
 
Dernière édition:
pour gérer P2 / P3, passer par des préférences est souhaitable, mais il ne s'agit pas seulement du choix d'un fichier de séquence de commandes à envoyer.
en effet la récupération des variables est également différente.

le fait de grouper les demandes a considérablement amélioré le "throughput", mais en contrepartie le décryptage est moins souple.

pour le décodage je vois les possibilités:

  • a) une variante d'apk par modèle.

  • b) une variante d'analyse des réponses par modèle (càd suivant pref)

  • c) une usine à gaz articulée sur les principes suivant

  1. ) on reconstitue des réponses élémentaires à partir d'une réponse multiple
  2. ) on analyse chaque réponse individuelle en fonction de règles dans le fichier des préférences

pour la partie graphique, il y a du boulot pour s'approcher un tant soit peu de torque....
en attendant, gogol est notre ami et des recherches du type "java gauge class" ramènent qqs éléments.

ps: je testerai ce soir avec le truc bleu.
 
Dernière édition:
Je ne sais quel public vous visez.

Mais à priori, vu le coût réduit de la solution finale, il sera plus large que PriusCanMonitor haut débit.

Donc petite suggestion : dans Pcm j'ai ajouté une détection automatique du type de Hsd (P2/P3_Auris).
Il faut dire que c'est plus facile puisqu'on démarre en mode passif et qu'il suffit de détecter le passage de tel ou tel Pid qui n'existe que dans chaque Hsd.
Une fois le choix fait Pcm sollicite une gamme de pid ou l'autre.(Et je n'ai géré actuellement que la P2)

Mais ça complique un peu et dans votre dev je ne sais si c'est faisable facilement.
Et vues les différences de débits en nombre de Pid intéressants par seconde traités, vous allez peut-être prévoir des modèles correspondants à un type de recherche.
Exemple : surveiller plutôt le thermique ou plutôt les freins etc..

Donc vos publics ciblés sont ? ;-)

Autre remarque. Elle concerne les débits d'infos.
Entre la Prius et l'interface il est de 500kb/s. Mais entre l'interface et le "Pc" il est plus faible.
Si on prend une P2 en mode passif on a 1166 pid/seconde. Chacun a 10 octets et quelques bits nécessaires à la liaison série.
Correctif. C'est vrai mais ils sont envoyés sous forme de quartets (en héxa) ce qui nous fait plus de 3+16 octets par Pid
Soit en gros 230kb/s.
proche d'un 232kb/s possible en BT ?
 
Dernière édition:
Dans l'absolu, je préfère que l'on détecte ou que l'on spécifie dans le menu le hsd en question. Faire du spécifique par version, cela voudrait dire qu'il faudra gérer plusieurs devs en parallèle alors que le moteur général me semble très bien parti.
La lecture des xml spécifiques aux ecus (et plus encore au version de hsd) nous sera d'une aide précieuse de ce côté là.
Je vais travailler sur l'interface dès que possible, j'ai repris les devs de mon frère pour voir comment faire mais c'est pas aussi simple que ça.
 
@planétaire
la détection auto ne devrait poser aucune difficulté:
demander à 7E2 21C3 va nous donner un début de réponse discriminant.

@guinness:
tu écris dans CanInterface.java
Code:
    // Is this specific value important?
    protected static final UUID MY_UUID = UUID.fromString("00001101-0000-1000-8000-00805F9B34FB");
// non seulement c'est important, mais c'est nécessaire pour activer le SPP....cf modif BTChat pour amorcer un dialogue avec dongle

je suis subjugué par l'architecture de ton appli :jap: .

en ce qui concerne le "préformatage" des réponses, je suggère de commencer par procéder à un split de getResponseString, le séparateur étant l'espace, mais en virant (avant ou après) les "/n/r" .
je ne sais pas le faire de manière efficace, et je risquerai de donner du boulot au garbage collector...
ensuite, comme tu le mentionnes, une mise en array de byte des couples ascii qui nous intéressent.
@suivre
 
pour le décodage je vois les possibilités:
  • a) une variante d'apk par modèle.
  • b) une variante d'analyse des réponses par modèle (càd suivant pref)
  • c) une usine à gaz articulée sur les principes suivant
  1. ) on reconstitue des réponses élémentaires à partir d'une réponse multiple
  2. ) on analyse chaque réponse individuelle en fonction de règles dans le fichier des préférences

En Java il est facile de charger une classe de manière dynamique (en lisant le nom de la classe dans un fichier), il nous suffit donc, une fois le modèle de HSD identifié (la solution de Planétaire me parait la plus user-friendly: c'est toujours mieux quand le user n'a rien à faire!), de charger dynamiquement la classe qui va interpréter les réponses (je mettrai le nom de la classe dans le xml des commandes); la solution b) me parait donc la plus adaptée.
 
en ce qui concerne le "préformatage" des réponses, je suggère de commencer par procéder à un split de getResponseString, le séparateur étant l'espace, mais en virant (avant ou après) les "/n/r" .
Je vais essayer de trouver qq minutes cette semaine pour faire ça, c'est pas sorcier, j'en profiterai pour créer une classe spécifique pour l'interprétation des réponses PIII, comme ça on aura l'archi pour gérer les différents HSD.

Pour l'UUID j'avais repéré que c'était important, mais pas bien compris pourquoi...
 
excellent.
pareil, je ne comprends toujours pas pourquoi c'est important ce UUID.
 
bonsoir
ci-joint le résultat de 2 tests
l'un avec obdlink, l'autre avec le machin bleu

j'ai légèrement modifié le logging de façon à voir sur une ligne la commande et la réponse (plus facile à filtrer dans excel)

devinez lequel correspond à quelle interface....
 

Pièces jointes

La différence est énorme presque du simple au triple !!! <- du coup j'ai mis 3 points d'exclamation.

Incredible :super:
 
youhou !!!

Bonne idée de mettre les deux sur une ligne car je les imprimais en même temps de tout façon :razz:
Je suis bien content qu'on arrive enfin à des valeur qui correspondent aux limites de l'interface plutôt qu'à des limitations du programme (btchat original).

Bon ben y a pas de secret, l'interface qui est presque 3 fois plus chère va presque 3 fois plus vite (bon sauf au début, faut qu'elle chauffe :grin: :-?)...

Bon ben faut que je sois patient maintenant, pas de renouvellement de stock avant fin de semaine/début de semaine prochaine... :sad:
 
@guinness:
je te poste ce matin le machin bleu.
cela te permettra de ne pas refroidir....
 
beer !

Cool, merci!
Comme ça j'aurai pas d'excuse s'il fait moche dimanche pour ne pas coder... :-D
😉
 
mise en forme préliminaire réponses.

les réponses ont toujours la même structure et peuvent comporter n lignes.
dans les tests actuels, il y en 1 ou 7, mais cela peut varier.
exemple d'une réponse:
[table="head;width=40%"]
adr
|
seq
|
c1
|
c2
|
c3
|
c4
|
c5
|
c6
|
c7
|
7E8​
|
10​
|
2E
|
61
|
01
|
00
|
00
|
00
|
00
|
7E8​
|
21​
|
12
|
64
|
49
|
61
|
60
|
00
|
00
|
7E8​
|
22​
|
00
|
00
|
C5
|
00
|
2B
|
7C
|
2B
|
7E8​
|
23​
|
FF
|
67
|
28
|
A7
|
63
|
39
|
AD
|
7E8​
|
24​
|
3C
|
0D
|
63
|
08
|
66
|
80
|
49
|
7E8​
|
25​
|
00
|
00
|
00
|
80
|
00
|
C9
|
9B
|
7E8​
|
26​
|
1C
|
00
|
08
|
51
|
0A
|
00
|
00
|
[/table]

les 4 premiers groupes de la première ligne permettent d'identifier la réponse;
tout ce qui en vert est la partie à décoder.
 
suite ( limitation à 10000 car dans un message)
une fois en tableau:
[table="head;width=20%"]
adr
|
seq
|
c1
|
c2
|
c3
|
c4
|
c5
|
c6
|
c7
|
7E8​
|
10​
|
00
|
01
|
02
|
03
|
04
|
05
|
06
|
7E8​
|
21​
|
07
|
08
|
09
|
10
|
11
|
12
|
13
|
7E8​
|
22​
|
14
|
15
|
16
|
17
|
18
|
19
|
20
|
7E8​
|
23​
|
21
|
22
|
23
|
24
|
25
|
26
|
27
|
7E8​
|
24​
|
28
|
29
|
30
|
31
|
32
|
33
|
34
|
7E8​
|
25​
|
35
|
36
|
37
|
38
|
39
|
40
|
41
|
7E8​
|
26​
|
42
|
43
|
44
|
45
|
46
|
47
|
48
|
[/table]
la partie en rouge serait l'indice du tableau.

commentaires ?
 
deux dimensions

Si ça peut rendre le code plus lisible, je peux faire des tableaux à deux dimensions un peu comme tu avais proposé en début de ce thread?

C'est comme vous voulez, ça change pas grand chose pour moi mais je me demande juste ce qui sera le plus pratique pour la interprétation des réponses.

PS: C'est quoi la limitation à 10,000 dont tu parles?
 
une seule dimension est beaucoup plus pratique, en effet, dans l'exemple précédent, la 1ère réponse (à 2101) s'étale des indices 3 à 27
la 2ème (à 2103) de 29 à 33
la 3ème (à 2149) de 35 à 46

je te laisse imaginer les jongleries si on passait à 2 dimensions...


un autre exemple concret avec un vrai message:
en rouge les différentes réponses
le SoC (State of Charge) de la batterie a l'indice 24 et vaut 9D soit 157/255=61,6% (cf feuille excel)
Code:
19:52:16:935   Sent:   210161626768   Received   (90ms):   

[COLOR=Green]7EA   10 [/COLOR]  30   61   [B][COLOR=Red]01[/COLOR][/B]   00   64   45   2F       
[COLOR=Green]7EA   21[/COLOR]   64   62   00   00   00   00   E9       
[COLOR=Green]7EA   22  [/COLOR] 2A   29   51   FF   67   2E   A7       
[COLOR=Green]7EA   23[/COLOR]   53   39   11   [B][COLOR=Blue]9D [/COLOR][/B]  [B][COLOR=Red]61[/COLOR][/B]   45   44       
[COLOR=Green]7EA   24[/COLOR]   45   80   00   [B][COLOR=Red]62[/COLOR][/B]   41   41   41       
[COLOR=Green]7EA   25 [/COLOR]  80   01   [B][COLOR=Red]67[/COLOR][/B]   80   00   80   00       
[COLOR=Green]7EA   26 [/COLOR]  00  [B] [COLOR=Red]68[/COLOR][/B]   80   3A   80   41   00
la limitation à 10000 concerne le nb de caractères d'un message, la génération des tableaux est extrêmement bavarde.




rappel, pour générer ces tableaux, j'utilise l'outil suivant:
 

Pièces jointes

OK, une dimension alors (tant mieux c'est plus simple à faire - EDIT: finalement c'est pas plus simple... 8))

Dans la foulée de la lecture des commandes en xml, je ferai le chargement dynamique de la classe pour décoder ces réponses, au début je créerai deux classes identiques P2/P3 et je laisserai le soin à un possesseur de PII de modifier celui pour la PII.

Puis-je avoir des infos plus précises sur comment faire à l'init pour distinguer à quelle génération de HSD j'ai à faire?
 
Dernière édition:
reconnaissance modèle:
en mode console interroger 7e2 avec la cde 21c3

AT SH 7E2
21 C3

la p2 va raconter sa vie dans une longue et intéressante réponse;
seul le début nous importe.

pour la p3 je teste ce soir...
 
reconnaissance modèle:
en mode console interroger 7e2 avec la cde 21c3

AT SH 7E2
21 C3

la p2 va raconter sa vie dans une longue et intéressante réponse;
seul le début nous importe.

pour la p3 je teste ce soir...

En effet les réponses commenceront par
7EA 10
7EA 21
7EA 23
7EA 24
7EA 25

Avec des tr/mn, Nm, degrés celcius.

A+ ;-)
 
Pages vues depuis le 20 Oct 2005: 316,287,851
Retour
Haut Bas