elm327 BT / Android

Bonjour,
Suite à expérience ce matin,je confirme que la réception d'appels pendant que l'on fait mumuse avec le BT n'est pas neutralisée.(en tous cas sur mon telephone HTC connecté d'une part au GPS sony xnvl77bt et d'autre part, utilisant torque).
En tentant de décortiquer torque, j'ai vu qu'il utilise soit la version native android du BT soit celle de it.gerdavax (probablement pour les versions anciennes de android).
J" y ai également rencontré ce fameux uuid "00001101-0000-1000-8000-00805F9B34FB" prévu pour le SPP...

En ce qui concerne "la version complète d'EOBD-Facile", je crois que ce sont les gars où je l'ai acheté qui l'ont développé; la clé du soft est associée à une machine.

Pour gérer les qqs paramètres modifiables sur P3, comme mentionné par planétaire, il suffit d'envoyer la séquence qui va bien sur le bus CAN , c'est donc faisable en mode console avec n'importe quelle interface CAN, à condition de connaitre la séquence à envoyer.
de mon coté, je n'ai pas noté cette séquence et je suis paumé dans les discussion sur priuschat où, en général, c'est bidouillé pour fonctionner sur scangauge.

pour info, torque marche parfaitement sur htc et archos, par contre, ni blueterm ni bluechat ne fonctionnent sur archos (en tous cas les apk que j'ai fabriqué).
en ce qui concerne bluechat, l'ajout d'un flush n' a rien changé.

@ suivre
 
...c'est donc faisable en mode console avec n'importe quelle interface CAN, à condition de connaitre la séquence à envoyer....

Sur Priuschat AdrianBlack a écrit ceci
Avec un elm327:

Enter the commands shown at 4-8 below:
4. AT H1 (Headers on)
5. AT L1 (Line feeds on)
6. AT SP 6 (Set protocol to CAN 11bit/500kbps)
7. AT DP (show you current protocol)
8. AT CAF1 (enable auto formatting)

Now, you need to tell the ELM which ECU you want to talk to:

AT SH 07C0 (this tells the ELM you are wanting to talk to ECU 7C0, which is the combination meter.)
Now, at the > prompt, type: 21 ac

Should return 7c8 61 ac 00 if backup beep is enabled or last two digits will be 40 is set to one beep.

At > prompt type 3b ac 40 to set single beep. You will see a couple responses including 7c8 7b ac which means it was set properly.
Send the Query command above to see the new answerback.

...
 
bonjour,
j'ai trouvé une appli qui marche à peu prés sur archos & htc.
http://prius-touring-club.com/vbf/imagehosting/14d19bb0f8d583.jpg
14d19bb0f8d583.jpg


il faut impérativement démarrer le BT avant.
j'ai récupéré les sources depuis un SVN et les ai zippées.
c'est le fichier attaché
 

Pièces jointes

  • android-obd-reader.zip
    222.3 KB · Affichages: 10
résultats: connection ok, mais les communications semblent envoyées par petits bouts; exemple (100% reproductible):
je tente d'envoyer ati
il reçoit
at
puis i

J'avais peu d'espoir pour le flush, mais c'était à tenter. Est-ce que le problème de délai n'apparaît que pour les commandes de 3 caractères ou plus généralement pour un nombre impair de caractères?
Il est à craindre que ce soit la stack bluetooth d'android qui fasse cette temporisation (même si c'est assez étrange), est-ce que la dernière appli que tu as testée permet d'envoyer des commandes?

PS: Merci pour les commandes pour le bip de marche arrière, ça servira pour d'autres car j'avais fait enlever le bip avant réception de ma voiture (grâce au forum :jap:); j'envisage par contre d'enlever celui des ceintures car même s'il est utile, les faux déclenchements (objets, déplacement dans parking) sont un peu pénibles...
 
la stack BT n'est pas en cause, en effet l'appli obdreader ne connait pas ce pb .
par contre, comme le dit son auteur, c'est sa première appli android (et cela se voit!!!); c'est assez brouillon, il y a du code en double, et certaines infos font planter l'appli, très probablement car plusieurs ECU répondent à une demande et son appli ne sait pas gérer cela.
Il y a quand même des parties de bonne qualité, comme ce petit bout:
Code:
    protected void readResult() {
        byte c = 0;
        this.buff.clear();
        try {
            while ((char)(c = (byte)in.read()) != '>') {
                buff.add(c);
            }
        } catch (IOException e) {
        }
    }
en français : une réponse est complète quand l'elm balance le signe ready ">"

je viens de commencer à lire un pavé de780 pages sur la programmation java; cela me permettra de proposer des bouts de code pour le décryptage des trames OBD...

Mon idée est de stocker dans un array tous les octets de DATA d'une réponse, qu'elle soit simple ou multiframe.

Cela permettra par exemple de récupérer le SoC de la P3 dans le 22ème octet de la réponse à la demande 21 01 adressée à l'ECU 7E2

7EA 10 18 61 01 51 1D 3B 2B
7EA 21 65 5B 13 80 00 01 1A
7EA 22 2B 29 51 FF 57 D8 8F
7EA 23 DC 38 EA AC 00 00 00
 
bonsoir,
je m'amuse avec obdreader.
je pense que c'est une bonne base (au moins la liaison BT marche parfaitement...).
je tente une variante valable pour tous les cas de figure pour ventiler la réponse à une demande, que la réponse soit mono ou multiframe.
d'une manière générale, il faudra utiliser des filtres pour attaquer telle ou telle ECU de façon à ne pas se poser trop de questions lors du traitement de la réponse.
mais c'est trés simple :
at sh 7e0 pour cibler ICE
at sh 7e2 pour cibler la partie hybride

l'original:
Code:
    public String formatResult() {
        String res = getResult();
        String[] ress = res.split("\r");
        res = ress[0].replace(" ","");
        return res;
    }
et ma première approche:
Code:
    /* extraction et mise en forme des octets significatifs.
     * principe : 
     * a) les lignes sont éclatées en tableau
     * b) dans chaque ligne, on éclate dans un autre tableau en utilisant
     * le séparateur " " ( obtenu par ATE1 au démarrage).
     * 
     * c) suivant le contenu du poste 1, on extrait telle ou telle partie 
     * des octets significatifs.
     *
     * le résultat est retourné dans un tableau contenant les couples utiles.
     * par exemple le SoC de la P3 serait en res3[21] (22 ème ).
     * 
     * 
     * 
     * 
     */
    public String[] formatResult2() {
        String[] res3= new String[50] ;
        
        String res0 = getResult();
        // res1 tableau de string, 1 élément par ligne
        String[] res1 = res0.split("\r");
        // on traite successivement chaque ligne
        for(int i =0; i < res1.length ; i++){
            // pour chaque ligne, on récupère les couples de data significatifs
            // dans le tableau res2
              String[] res2 = res1[i].split(" ");
              int tst1 = Integer.parseInt(res2[1]);
              int tst2= 0xf0; // masque pour isoler partie gauche
              int tst3 = tst1 & tst2; 
              //tst3 doit contenir 0 ou 1 ou 2
            switch (tst3)  
            {
            // case 0 : on prend les groupes de 4 à max
            case 0: for(int j =4; j < tst1 +1 ; j++){
                res3[j-4]=res2[j];
                }
            break;
            // case 1 : on prend les groupes de 5 à 8 (4 octets)
            case 1: for(int j =5; j < 8 +1 ; j++){
                res3[j-5]=res2[j];
            }
            break;
            // case 2 : on prend les groupes de 2 à 8 (7 octets)
            //          et on les place là où il faut...
            // càd si 21 on démarre à 4
            //     si 22             à 11
            //     si 23             à 18
            //     si 24             à 25
            case 2: 
            int base = (tst1 - 33)* 7 + 4;
            for(int j =2; j < 8 +1 ; j++){
                res3[base + j - 2]=res2[j];
            }
            break;
            }
        }
        return res3;
    }
pour valider le truc, il faut que je greffe une sortie log vers la sdcard.

@suivre
 
je continue à étudier obdreader.
le surclassement de java, c'est bien, mais en abuser n'est pas efficace... (et nuit gravement à la compréhension).
ci dessous une petite récap de la hiérarchie des classes dans cette appli:
[table="head;width=60%"]class|hierarchy|
||
AverageFuelEconomyObdCommand|Thread , ObdCommand|
CommandEquivRatioObdCommand|Thread , ObdCommand|
DtcNumberObdCommand|Thread , ObdCommand|
EngineRunTimeObdCommand|Thread , ObdCommand|
FuelEconomyObdCommand|Thread , ObdCommand|
IntObdCommand|Thread , ObdCommand|
MassAirFlowObdCommand|Thread , ObdCommand|
ObdMultiCommand|Thread , ObdCommand|
TimingAdvanceObdCommand|Thread , ObdCommand|
TroubleCodesObdCommand|Thread , ObdCommand|
FuelEconomyCommandedMAPObdCommand|Thread , ObdCommand , FuelEconomyObdCommand|
FuelEconomyMAPObdCommand|Thread , ObdCommand , FuelEconomyObdCommand|
FuelTrimObdCommand|Thread , ObdCommand , IntObdCommand|
PressureObdCommand|Thread , ObdCommand , IntObdCommand|
SpeedObdCommand|Thread , ObdCommand , IntObdCommand|
ThrottleObdCommand|Thread , ObdCommand , IntObdCommand|
EngineRPMObdCommand|Thread , ObdCommand , IntObdCommand|
TempObdCommand|Thread , ObdCommand , IntObdCommand|
IntakeManifoldPressureObdCommand|Thread , ObdCommand , IntObdCommand , PressureObdCommand|
FuelPressureObdCommand|Thread , ObdCommand , IntObdCommand , PressureObdCommand|
AirIntakeTempObdCommand|Thread , ObdCommand , IntObdCommand , TempObdCommand|
[/table]

je vais donc tenter d'intervenir au + haut dans cette hiérarchie pour mettre en table le résultat dans ObdCommand...
 
Première Mondiale

Qu'est-ce que cela peut bien être ? :cool:

1514d26e0d2415d5.jpg
 
Euh... oui, certainement, mais encore ?
 
Bon, une autre porrite quelques instants plus tard de plus près :cool:

1514d26e0eceda06.jpg
 
Et voui, c'est une ANDRIUS :cool:
 
Bon allez, on va être sympa.

Oh! le bel écran bien lumineux que tu as fixé en bas.

C'est pris à clichy/bois ?
 
Tu projettes un android sur l'écran de la prius ?
Je veux bien en savoir plus !
 
Bref, avec un Archos 32 Internet Tablet sous Android on peut balancer l'image sur le MFD. Pendant ce temps l'image disparaît du tablet mais son écran se transforme en touch pad avec l'apparition de la flèche sur le MFD.

Il peut être intégré dans le vide poche sous le poste audio.
Son proc' semble être le même que celui du 101 à part la fréquence qui est de 800MHz au lieu d'1 GHz (mais je crains qu'il n'y ait plus de différences - quelqu'un e sait ? )

Quelques bémols toutefois :
ce modèle d'Archos travaille en définition 400 * 320 (c'est peu).
la qualité de son écran n'est pas terrible.
j'ai pas encore fait de tests de ce qu'une image chargé donnerait sur le MFD mais de prime abord cela semble moins pourri que ce que je craignais.
l'image de l'interface n'occupe pas toute la surface du MFD (se réperer par rapport à l'averto "contrôlez etc.", même marge ne haut) sauf en mode lecture vidéo (cf. l'image du piaf).

Je vais vous faire une récap des modèles Android de chez Archos.
 
Modèle Archos Processeur Résolution Version Sortie BlueTooth USB Mémoire Alim
Internet Tablet Cortex A8 Android Vidéo Host externe
28 800 MHz 320x240 2.2 non non oui (1) non µ USB
32 800 MHz 400x240 2.2 (0) composite oui oui (1) non µ USB
43 1 Ghz 854x480 2.2 HDMI oui oui (2) µSD HC µ USB
50 1 Ghz 800x480 2.2 HDMI oui oui (2) µSD HC USB
70 1 Ghz 800x480 1.5 HDMI oui oui (2) µSD HC Pin
101 1 Ghz 1024x600 2.2 HDMI oui oui (2) µSD HC Pin


(0) en fait 2.1 sur l'exemplaire testé
(1) câble micro USB optionnel (pas sur qu'il fasse Host et alim en même temps)
(2) via la docking station
 
Dernière édition:
@parkerbol: puisque ta watture est une pack, l'injection video est envisageable, 800 x 480 en composite, fréquences PAL.
 
Pas bête mais j'ai pas de tablette pour le moment et pas de sortie hdmi sur mon antique htc hero (sans jeu de mots !).
J'attends de le changer sous peu ... l'écran est vraiment trop petit !
Mes collègues geeks se séparent "très très" rapidement de leur matériel acheté "très très" vite (non sens écologique propre à notre métier ...), j'attends qu'une tablette se libère donc ... dès la sortie d'une nouvelle 8)

un développeur qui pourra nous aider ponctuellement sur nos devs en cours vient de sortir une horloge textuelle :
http://forum.frandroid.com/topic/38693-application-whoot-widget-horloge-textuelle/
si vous pouvez lui faire des retours sur ce widget !

@priusfan
jette un oeil à l'interface, on pourra en profiter dès qu'on a mis au point le coeur de notre application.
 
Je parle sous contrôle de prisfan. A mon sens la sortie HDMI n'est d'aucune utilité. A ce que je sais on ne peut "injecter" dans l'écran de certaines Prius (Sol Pack dites 2006 seulement) qu'un signal vidéo composite NTSC. Vu qu'à la base c'est un écran LCD ce serait logique qu'on puisse y "injecter" du HDMI qui n'est autre que le DVI avec le son.

Donc au jour d'aujourd'hui seul Archos 32 peut le faire. Les autres (5o,7o et 101) aussi à condition de passer par l'option DVR station complète (assez encombrante et chère 120€). Y a de petites DVR station qui n'assurent que l'alim' la sortie HDMI et USB Host. Elles seraient intéressantes pour une installation rapide des Archos 5o ou 7o derrière le volant.

A mon sens les Anrdophones ne disposent pas des sorties vidéo.
Par contre ils me semblent parfaits comme data loggers. On est censés les avoir sur soi et si, comme je me l'imagine et l'espère, ils peuvent établir la communication avec l'Elm 327 BT dès qu'on rentre dans la voiture, comme c'est le cas du téléphone avec le module BT de la Prius, ben on ne loupperait pas une miette de l’activité de la Prius sans devoir passer par des procédures d'installation et lancement dignes des navettes spatiales.
 
effectivement, le hdmi n'est pas utilisable...

par contre le Samsung galaxy s aurait une sortie video composite...
 
Ah... intéressant.
Et, est-ce qu'il fait du multiscreen ... :-D
Car dommage de se priver d'une aussi belle qualité d'affichage qu'est la sienne (super Amoled). Et vu son prix et ses capacités, téléphone, ça m'étonnerait qu'il reste à demeure dans la voiture (comme le petit archos) sauf à ce que la connectique soit facilement enclenchable et intègre la recharge.
 
Salut les Googoloïdes :cool:

J'ai quelque peu cogité sur les jauges.

Vu qu'on risque d'utiliser des dispositifs à l'affichage horizontal mais aussi vertical (fort probable sur les Androphones) va falloir imaginer des systèmes de pavés d'affichage pouvant facilement pivoter et respecter les dimensions (sachant que la plupart du temps ça tourne autour de multiples de 80 pixels : 240 / 400 / 480 / 800 etc)

Ci joint un petit développement de l'idée que j'ai déjà proposée

1514d2dfb407bffe.jpg


Mais qui réflexion faite n'est pas la plus mieux possible.

Voici une nouvelle un peu plus planéterienne consistant à mettre en évidence les infos les plus utiles pour les P&G-ers.

Donc plus de compte tours analogique. Je me suis aperçu qu'il ne servait pas à grand chose, je regardais plutôt la valeur digitale.

Au sommet le nirvana du P&G-er, ZERO Amps !, et juste en dessous le % d’enfoncement des gaz ou freins (on fait pas les 2 à la fois ... normalement)

En bas à gauche le Bouton Reset pour faire le RAZ des cumuls et moyennes à la volé.

En haut à gauche le bouton 'Tourner la page' pour passer aux stats. J'ai mis pardessus quelques infos somme tout secondaires : V Instant, Altitude :D , Temp ext.

1514d2dfb6c1db46.jpg
 
Dernière édition:
Ah oui, l'image est aux dimensions 800x480 pixels donc installable telle quelle pour voir sur la plupart des Androïd devices. Je vais mettre sa version réduite de moitié, 400x240, sur l'Archos 32 (on debrait plus y voir grand chose) puis l'afficher sur le MFD pour voir s'y ça reste lisible et si c'est la peine de continuer sur cette voie (Archos 32).

Chtitne question : est-ce qu'on dispose de toute la surface d'affichage ou Andrïd garde des bords pour dés besoins système ?
 
Pas mal Less. j'aime moins la partie batterie. Sur android on peut être en full screen, pas de bord si on veut notamment la barre de notification.
pour le moment, j'ai encore un 2,8" mais je compte partir sur un désire hd mon abonnement prend fin.
 
Pages vues depuis le 20 Oct 2005: 310,753,428
Retour
Haut Bas