elm327 BT / Android

Je n'ai pas voulu creer un nouveau post mais c'est pour faciliter les screenshot à partir d'un device Android.

Voici un tuto détaillé de comment faire pour Mac OS X et Windows, à la fin du tuto je vais mettre comment faire pour Windows y'a juste 1 truc qui change

Premièrement il faut disposer du SDK 2.2 que l'on peut télécharger ici => http://developer.android.com/sdk/index.html
Ensuite vérifiez que votre téléphone ait la fonction debugging usb activée que l'on trouve sous bouton Menu puis Paramètres/Applications/Dévelopment cocher Debogage USB .


parametres.png


applications.png


debugusb.png



Une fois tout cela est vérifié, on peut enfin brancher son appareil mais veillez à ne pas monter la carte sd comme un disque mais en charger seulement

Allez dans le SDK que vous venez fraîchement de télécharger ensuite dans tools et cliquez sur "ddms".
Une console va apparaître en quelques secondes pour faire place à une fenêtre qui ressemble à ça :

consoleddms.png


En haut à gauche cliquez 1 fois pour sélectionner votre appareil puis faîtes ctrl+S pour afficher son écran et voilà

ecran.png



La seule différence avec Windows c'est que vous devez installer le logiciel "SDK Manager.exe" . Il est dans le dossier racine du dossier sdk.
puis "ddms.bat" dans le dossier tools
 
merci pour l'info, effectivement DDMS est bien pratique.

j'ai recensé la séquence pour alterner mode passif et sollicité.
cela pourrait ressembler à ça:

switching to passive mode
example for tank level 5A4

AT CA F0 ' Auto Formatting Off
AT CF 5A4 ' set Filter to 5A4
AT CM FFF ' set mask to get only this one
AT MA ' set to passive mode

stop at first valid answer: buffer starts with 5A4 and contains one crlf

à tester : remplacer la séquence CF CM par CRA 5A4


cancelling passive mode
send one or 2 caracter
AT CA F1 ' Auto Formatting On

attention, d'aprés la doc elm, ce changement de mode peut prendre du temps...
14d3176fe42668.bmp


:-D addendum: fuel level P3 est dispo en actif.

j'ai retrouvé dans mes archives un mp de Eric Boyd
Hi frenchie, I just got the following from adrianblack:

Quote:
Fuel Level
7c0 21 29
7c8 61 29 3f = 31.5L

I don't know the math of 3F yet, but I presume you just divide by 2 to get Liters. 3F = 63 in decimal / 2 = 31.5....
I find it odd that the requests and responses are not on the same frames (7EA & 7E8) as the ones in your spreadsheet.
 
Niveau réservoir p2

...AT CF 5A4 ' set Filter to 5A4
AT CM FFF ' set mask to get only this one

...
Le 5A4 ne fait une apparition que toutes les 5 secondes (dixit Atila Vass fréquence 0,2)

Proposition (pour P2).

Soit tu peux dire: au bout de yy mS j'abandonne si rien reçu. (une option de l'elm ?)

Soit comme il faut prévoir le pire, donc 5 secondes d'attente !, il sera peut-être préférable d'écouter tous les 5xx, décider qu'au bout de yy mS on a autre chose de plus urgent à faire même si le 5A4 n'est pas passé. On retentera plus tard. Le fait d'écouter tous les 5xx fait que l'on est sûr de recevoir quelque chose durant ces yy mS et donc de garder le contrôle.

Comme c'est le niveau de carburant, une réponse par minute ou plus n'est pas un défaut.

A+ ;-)
 
btChat continued

Bon alors j'ai testé le code écrit hier soir et apparemment ça attend bien de recevoir > avant d'afficher la réponse.

Maintenant je n'y connais rien en elm327 (j'ai reçu mon dongle il y a 3 jours et je n'ai pas encore bien digéré tous les posts de ce sous-forum) donc je ne sais pas trop interpréter.
Voici deux screenshots de mes essais (je ne teste pas trop longtemps car ça bouffe la batterie HT de rester sur IGN-ON trop longtemps - tiens d'ailleurs j'ai une question: vous enlevez le dongle à chaque fois que vous coupez le contact car ça reste alimenté en 12v, c'est bien ça?).
Le premier je ne savais pas trop quoi entrer donc j'ai repris qq commandes de la première page de ce post, on peut voir que le echo n'est pas toujours bon, c'est un peu bizarre (le tel était en dehors de la voiture, porte fermée, ceci explique peut-être cela, sinon y a un bug :-D).
28244d31a2a7b71d2.jpg


Et pour le deuxième, j'ai juste refait la manip pour désactiver les bips de ceintures:
28244d31a2a7a6440.jpg

Là tout a l'air OK.
 
parfait tout ça.

je te suggère d'envoyer AT E0 (echo off)

de consulter le classeur excel que j'ai mis sur le ftp

de me contacter sur skype: fx.moya


dongle restant branché:
le mien reste en position, mon épouse utilise tous les jours la watture
et je n'ai aucune idée de la conso.
pour cela il faut mettre un ampèremètre en série sur la batterie et je ne l'ai pas encore fait...
 
@Guiness pour des essais (sur P2) on peut se contenter de la deuxième position accessoire. Ca consomme moins, tout le systeme hybride n'est pas connecté.
Les Ecu répondent.

On vide la 12v quand même (la pompe du systeme hybride doit tourner). ;-)
 
mais j'ai plutôt bufferisé côté handler, voici ma proposition de modif dans BluetoothChat.java (pas encore testée, je vais me coucher):
Code:
        case MESSAGE_READ:
+++
            case MESSAGE_DEVICE_NAME:
Même si ça marche, il y a surement moyen de faire mieux, notamment de gérer le cas (improbable?) où un message contient plusieurs '>', mais ça sera pour plus tard...

Où as tu mis ça exactement ?

Je suis en train d'écrire une partie de code pour logger dans un fichier.
 
Dans BluetoothChat.java, une recherche sur un des deux 'case' doit permettre de trouver, c' est dans une sous classe de handler (je ne suis pas devant mon pc).
Fx je te contacterai peut-être quand je me serai documenté un peu plus.
Je n'ai plus bcp de temps ce week-end.
 
nouvelles du front

bonjour,
je viens de tester la propal de guinness, cela marche.
j'ai toutefois du déclarer "buffer" sinon il signalait une erreur de variable non déclarée/non initialisée.
je l'ai fait comme ceci, au début du source BluetoothChat.java
Code:
    // Member object for the chat services
    private BluetoothChatService mChatService = null;

   [COLOR=Red] private StringBuffer buffer = null;[/COLOR]

effectivement la suppression de l' echo est utile (ate0).

j'ai également procédé à un test d'appel sortant depuis l'autoradio alors que j'étais connecté à btchat,
cela a marché parfaitement et sans déconnecter btchat.

je rappelle que je n'utilise pas la radio d'origine mais un gros truc sony.
 
Effectivement j'avais oublié de donner la déclaration; ce n'est pas la peine de la mettre si haut dans btchat puisque la variable n'est utilisée que dans le handler, je l'avais déclarée ici:
Code:
    // The Handler that gets information back from the BluetoothChatService
    private final Handler mHandler = new Handler() {
    	// For MESSAGE_READ bufferization until '>'
    	StringBuffer buffer = null;
Pour l'appel téléphonique j'avais déjà testé par hasard et effectivement ça fonctionne.
 
Vitesse de réception des pid sur P2 avec Elm327 v1.2

Une des préoccupations est celle de la vitesse de rafraichissmement des infos.

Suite à un "sinistre" dans mes boitiers interface (*) je me suis replié sur l'elm327 à 9600 bauds.

En VB6. Après avoir suivi le conseil de priusfan j'ai désactivé la gestion actuelle du port com (mscom...) et mis un timer de 20 mS (on peut mettre plus lent) qui lance les lectures-écritures. En n'émettant que quand la réponse précédente est totalement arrivée.

La série de 6 Pid sollicités (les 21 C3,C4,CE,CD et 01 05,0D) se déroule en 1 seconde, le délai maxi entre demande et réponse est de 0,33s pour le pid le plus lent.

Or l'ensemble de ces réponses à 6 pid occupe en gros 1ko.
Ce n'est donc pas la vitesse entre elm et pc qui coince.

======================================================

(*) J'ai eu de gros problèmes avec mes deux boitiers: Tactrix et ElmCan.
Ils ont tous les deux dégagés.
La cause très probable est un mauvais contact sur la prise Usb du Pc !
Le pire a été le Tactrix qui a mis en défaut ma Prius2.
Celle-ci affichait sur le mfd le triangle suivi de "probleme" avec un gros bip et refus de démarrer.
Heureusement après retrait du tactrix puis 3 démarrage-arrêts avec toujours le même message d'erreur au 4ième elle est repartie.
Je manquais de temps et donc roule le temps que le thermique dépasse les 40°C. Ensuite, en roulant sur un chemin de campagne désert je rebranche le tactrix.
Ma Prius s'est de nouveau fachée et re-triangle plus message problème mais comme c'était en roulant elle a coupé toute traction et c'est en roue libre (la vraie) que je me suis posé au bord du chemin. Retrait du tactrix.
Re 3 démarrages avec le triangle puis au quatrième tout est OK.

Je roule quelques km et branche ma solution de secours : l'elmcan qui était un elm327 Usb rapide. Ca marche et au bout de quelques km plantage du programme priuscanmonitor.
J'ai pas insisté.
En fait les 2 interfaces ne fonctionnent plus du tout.
L'elmcan n'est plus reconnu par aucun Windows sur terre
Le Tactrix met ma Prius en défaut mais fonctionne bien côté Usb. Il n'est pas en court-circuit côté Odb il y a 40 kohms entre broches 6 et 14.
C'est donc avec l'ultime solution, pour l'instant 8), qui me reste que je fais des essais.

LA PRIUS va bien et fonctionne toujours à merveille.

Le conducteur garde le :-D
 
Petite hypothèse, c'est pas du au manque de jus de la batterie accessoire :eek: ?
 
Merci pour l'hypothèse.

Mais pour l'elmcan c'est sur que non, je roulais et donc la batterie était à 14v quand je l'ai branché.
 
le délai mentionné par planetaire de 0,33s me parait extrêmement long.
d'ailleurs, je t'avais parlé de 10mS et pas de 20

j'ai préparé 2 listes d'enchainement de commande:
la 1ère est la séquence d'initialisation.
ATI
ATSP6
ATE0
ATH1
ATL1


la 2ème est une séquence de tests pour la P3
AT SH 7E0
01 3C
01 3E
21 01
21 3C
21 49
AT SH 7E2
21 01
21 61
21 62
21 67
21 68
21 70
21 71
21 74
21 87
21 8A
21 98
AT SH 7C0
21 29


j'ai tenté de modifié obdreader pour enchainer ce truc, mais je m'y suis perdu...

il est important amha de vérifier que cette séquence de tests puisse passer en boucle sans pb et de vérifier le temps de réponse de chaque commande et du cycle complet.
cela suppose de logger avec timestamp l'enchainement Q R.
attention au principe du talkiewalkie : attendre signal "ready" avant de causer.


quand ce premier test sera satisfaisant, on pourra définir la périodicité de ces interrogations (pas vraiment utile de demander 10 fois par seconde le niveau d'essence ou la température du pot catalytique);

puis aborder la partie décodage, et celle là, je la maitrise...
 
le délai mentionné par planetaire de 0,33s me parait extrêmement long.
d'ailleurs, je t'avais parlé de 10mS et pas de 20...

J'ai fait la comparaison:
-20mS délai 1032 mS
-10mS délai 985 mS (gain 4,5%)

C'est normal que ce soit moins long avec 10 mS et c'est tout aussi logique que la différence soit faible.

Car réduire ce délai permet de réduire le temps perdu lors de la réception de la fin d'un pid. Donc pour un multitrame de la fin de la dernière trame.

Le test indiqué au dessus est avec 7 Pid dont celui des accus Nimh (multitrame) qui peut être évité, il ne sert pas à la conduite. On peut gagner 200 mS. Ce qui met le cycle à 785 mS.

Ce qui va être intéressant est de voir ce que vous obtenez avec un Elm plus rapide.

Pour mon test la logique adoptée est la suivante:
-demande d'un pid
-doevents (pour que la demande soit traitée par VB et Windows)
-délai du timer
-doevents
-on vient voir s'il y a une réponse
-si pas complète re timer
-si complète émission demande suivante

Pour les rares pid monotrame je ne sélectionne pas d'Ecu, je crains que cela ne fasse perdre plus de temps (dès qu'on émet il faut attendre que l'elm soit dispo avant une autre émission) que de recevoir plusieurs réponses identiques de 3 Ecu.

A+ ,-)
 
j'ai procédé à un test par un pgm en VB.
il s'agit de la séquence mentionnée plus haut, et pour chaque commande j'ai mesuré le temps d'execution entre lancement et fin de la réponse.
cf tableau ci dessous.
je procèderai à des tests en tentant de monter à 115200 bds au lieu de 38400.
[table="head;width=60%"]||||
cmd|answer|
mS
||
AT SH 7E0|OK|
62​
||
01 3C|7E8 04 41 3C 1D 7E |
110​
||
01 3E|7E8 04 41 3E 1B 14 |
94​
||
21 01|7E8 10 1B 61 01 00 00 00 00 |
171​
||
|7E8 21 12 66 54 61 6C 00 00 |||
|7E8 22 00 00 00 00 29 79 29 |||
|7E8 23 FF 5C 5A 99 7A 38 C3 |||
21 3C|7E8 07 61 3C 00 00 00 00 80 |
110​
||
21 49|7E8 10 0E 61 49 00 00 00 80 |
125​
||
|7E8 21 00 00 FF 00 00 08 25 |||
|7E8 22 0A 00 00 00 00 00 00 |||
AT SH 7E2|OK|
47​
||
21 01|7EA 10 18 61 01 00 66 54 30 |
172​
||
|7EA 21 65 6C 00 00 00 00 00 |||
|7EA 22 29 29 51 FF 5C 60 99 |||
|7EA 23 6C 38 3A A5 00 00 00 |||
21 61|7EA 07 61 61 75 76 76 80 00 |
125​
||
21 62|7EA 07 61 62 70 72 72 80 00 |
109​
||
21 67|7EA 07 61 67 80 00 80 00 00 |
109​
||
21 68|7EA 07 61 68 80 00 80 00 00 |
110​
||
21 70|7EA 06 61 70 46 46 4B 00 |
93​
||
21 71|7EA 06 61 71 47 45 4B 00 |
94​
||
21 74|7EA 10 0B 61 74 47 46 47 4F |
110​
||
|7EA 21 00 01 C4 01 C3 00 00 |||
21 87|7EA 10 0A 61 87 49 6B 57 A8 |
109​
||
|7EA 21 5A C5 57 54 00 00 00 |||
21 8A|7EA 04 61 8A 81 56 |
125​
||
21 98|7EA 10 0A 61 98 81 4E 51 AA |
125​
||
|7EA 21 00 84 84 80 00 00 00 |||
AT SH 7C0|OK|
62​
||
21 29|7C8 03 61 29 31 |
94​
|2156|
[/table]

@planetaire mon pgm est assez bestial; voici le sendcommand:
Code:
Sub SendCanCommand(cmd As String)
    s0 = ""
    ok = 0
    Log = "xxx" & Format(GetTickCount, "0") & "w" & cmd & "w"
    Comm_CAN.Output = cmd & vbCr
    Do Until ok > 0
        s0 = s0 & Comm_CAN.Input
        If Len(s0) > 1 Then
            ok = InStr(1, s0, ">")
        End If
        If ok > 0 Then
            Log = Log & Format(GetTickCount, "0") & "w" & s0
            Print #1, Log
        End If
        DoEvents
    Loop
End Sub
 
Pour comparaison sur une P2 avec un elm 1.2 à 9600b:

[table="head"]|||

cmd| mS|rôle principal|ECU|

0105|125| Temp ICE|023|
010D|140| km/h|023|

21CD|110| Tr/mn Nm ICE..|0|
21C3|220| Volts. MG1 MG2..Ampères(à vérifier)|2|
|| Temp MG1 G2||
21C4
|125| Accél (à vérifier)Temp converter|2|
21F3|80| Inject essence|0|

21CE|190| Accus nimh|3|

[/table]

Ces valeurs varient. Par exemple le C4 peut être à 125 ou 140 mS.
 
correctif

Bon, j'ai jeté un oeil aux anomalies dans mes copies d'écran et à mon avis c'est un bug de synchro de threads quand on reçoit les réponses en deux fois très rapidement.
Il faut déplacer:
Code:
            	// read the message
                byte[] readBuf = (byte[]) msg.obj;
à l'intérieur du bloc synchronisé pour éviter ça.

Sinon j'ai les idées un peu plus claires sur le cahier des charges grace à vos posts sur les commandes/réponses, par contre je n'aurai pas trop de temps avant le week-end prochain.
A suivre donc.
 
Ampères en sollicité

Bonne nouvelle pour les proprio de P2. Le pid 21C3 réponse 24 contient bien les ampères batterie nimh (en avant dernière position).

Le doc xls de berkeley contient des erreurs. Pour les ampères ils disent de prendre deux octets: de multiplier le 2ème par 2 et ajouter le premier. C'est forcément faux (quand on utilise 2 octets on multiplie toujours le premier par 256 et on ajoute le deuxième). Ici il ne faut prendre que le deuxième et le multiplier par 2. Cela nous fait quand même des limites de + et - 256 ampères ce qui est largement suffisant (il vaut 128 pour zéro ampères)

Par contre il va falloir trouver le signe ... ailleurs...!

Correctif 17h30.

Le signe est bien là. En fait il faut lire en inversant le sens charge/décharge (simple question de convention)


A+ ;-)
 
Dernière édition:
Dongle reçu

Je viens de recevoir mon dongle BT. J'ai fait un test rapide avec Torque ça fonctionne.
Question à ceux qui ont le même dongle que moi ici. Est-ce que le dongle se clipse correctement?

Comme je debute sur Android, java et tous le reste je recherchais un site pour débutant. Ma dernière programmation était en shell unix en 2005, gloups.
Donc pour me former j'ai trouvé le site www.android-pour-les-nuls.fr
et la surprise j'ai vu comment obtenir le code source des applications Android

Premier test sur Torque.v1.2.47.Full.apk et ça marche
 
Dernière édition:
Juste une petite précision. Ton lien est vers un elm bluetooth, pas wifi.
 
oui c'est des dents bleu je me suis trompé
 
Intégration à base d'Archos 32 (image statique en 400 x 240 pixels).

1514d39bd2ee5e39.jpg


A la place de mon support vertical il existe des horizontaux pour Coyote (19,9 € à la Fnac) qui se fixent de la même façon sur la grille d'aération.

1514d39bd3e803af.jpg


L'Archos peut facilement prendre place dans le vide poche simple DIN, le cache en plastique translucide ferme sans problème.

1514d39bd4c0f926.jpg


De là on peut envoyer l'image sur le MFD (l'Archos se transforme en touch pad, y a juste un petit problème, pas su activer les ascenseurs, mais pas essayé le multitouch)

1514d39bd659ba42.jpg


De plus près cela donne ça. Les caractères sont légèrement flous mais exploitables.
:D
 
Pages vues depuis le 20 Oct 2005: 313,224,694
Retour
Haut Bas