elm327 BT / Android

panda56 · 13 Janv. 2011

Si tu mets l'altitude, est-ce qu'il y a une possibilité de calcul (par exemple dénivelé..? ), sur un parcours donné?

Pont Vert · 13 Janv. 2011

Petites suggestions concernant les données réservoir :
- remplacer par calcul l'échelle de 5 à 110% par une échelle de x à 100% ou afficher les litres
- afficher la distance restant à parcourir avant le prochain plein (basée sur une moyenne de consommation des x derniers km)

planétaire · 13 Janv. 2011

A propos de réservoir. Sur Prius 2 je n'ai pas vu cette info dans les pid sollicités.

Less Polluter · 13 Janv. 2011

Bonjour tout le monde et merci pour vos réactions.

La batterie : mon idée était de reprendre le principe des barres telle qu’affichées sur le MFD de la Prius en respectant le nombre et les couleurs. On y est habitué. Apporter le % de remplissage en complément est très intéressant mais seul ce dernier ne veut pas dire grand-chose, accompagné du nombre de barres beaucoup plus. Je pense que c’est le design de barres qui vous déroute. En fait les petits pavés intermédiaires sont la pour visualiser plus finement le passage entre les barres. Par exemple quand on est à 3 proche de 4 mais pas encore à ce seuil.

L’altitude est disponible sue le PriusCanMonitor version PC à condition que ce dernier reçoive l’info d’un dispositif GPS. C’est le cas si on y connecte un Inforad par exemple. Il me semble qu’il y avait le calcul du dénivelé dans le PCM. Mon idée, tant qu’à calculer, en plus du dénivelé absolu (altitude du point courant - altitude du point de départ) ajouter les cumuls des dénivelés positifs et négatifs. On peut fort bien être au total à 0 après être passé par les monts et vaux… J’irai même jusqu’à traiter ces 3 infos par tranche de calcul de conso (les barres verticales). Mais bon, ça s’est de la stat moins facilement exploitable en conduisant.

L’outil idéal d’assistance à la conduite serait un truc prédictif qui guiderait le pied, en indiquant l‘action qu’il doit exercer sur la pédale afin d’atteindre la meilleure efficacité de la chaine cinématique (efficience moteur ou récupération). Donc quasiment rien à voir avec l’affichage que je propose où on doit faire soi même sa propre synthèse en fonction de ce qui est affiché.

Concernant cet affichage, perso j’aurais préféré voir apparaitre un Wattmètre au lieu de l’ampèremètre. Ca me parle plus, mais je me trompe peut-être, vaut mieux surveiller les Ampères.
Dans le cas de Wattmètre j’inverserais la tachy. Dépense en rouge l’aguille allant vers la droite, et à gauche en vert pour la récup ou recharge. Graduation toujours logarithmique avec une grande finesse entre 0 et 10 puis beaucoup moins au-delà : 1 2 5 10 15 20 25 30.

Pour ce qui est de la jauge de carburant : je suis habitué au pourcentage donc cela ne me pose pas trop de problème. A partir de là faire le calcul mental des litres restants n’est pas très difficile. La machine peut aussi le faire. Laquelle des présentations choisir ? Pourquoi pas les litres. Direct, en chiffres car refaire des barres comme ce qu’on a déjà sur le TdB fait double emploi sans apporter plus de précision. Effectivement, calculer et présenter la distance restante en fonction de la moyenne et du nombre de litres peut être un petit plus sympa. Infos qui n’auront pas le même sens lorsque le réservoir est rempli au raz du goulot (même la Prius s’y perd en indiquant 110 % et Full pendant un bon moment sur le TdB)

parkerbol · 13 Janv. 2011

Pour revenir à android-obd-reader, j'ai audité le code (SourceMonitor)et j'ai constaté ce que j'ai lu, le code est assez complexe.
Par exemple :
- ObdReaderMainActivity.java a une complexité de 17, au-delà de 15 ça devient assez complexe d'autant que c'est la méthode la plus appelée,
- ObdConnectThread.java a une complexité moyenne de 10 pour 209 lignes et 157 statements (plus petite commande de base)
Il y a aussi peu de commentaires, ce qui n'aide pas et quelques trucs bizarres comme dans ObdConnectThread.java
ligne 91 dans run() :

Code:

           for (int i = 0; !stop; i = ((i+1) % cmdSize)) {
            	if (i == 0) {
            		long obsTime = System.currentTimeMillis()/1000;
            		results.put("Obs Time", Long.toString(obsTime));
            		data.put("Obs Time", obsTime);
            		if (uploadUrl != null && !"".equals(uploadUrl)) {
            			new ObdUploadThread(uploadUrl, service, getResults()).start();
            		}
            		Thread.sleep(updateCycle);
            	}

On sait que dès le début de la boucle i=0 et pourtant on lance un if juste après, comme il s'agit du thread de connexion, c'est un peu dommage de lire cela dans la boucle !
Ce qui me gêne le plus aussi c'est la manière de trapper les exceptions, au lieu d'une méthode globale, ils ont privilégié un mode plus bas niveau et donc pour nous plus difficile à débugger voire même de savoir ce qui se passe vraiment au niveau du bt quand on rencontre une erreur !

Bref, j'ai un peu de mal de ce côté là même si c'est une très bonne base.

parkerbol · 13 Janv. 2011

J'aime beaucoup ce type d'interface :

priusfan · 13 Janv. 2011

Bonjour,
Au sujet de l'IHM (ce que l'on visualise), c'est, amha, le dernier point à régler et on peut imaginer différents thèmes en fonction des gouts de l'utilisateur.

J' imagine un service de collecte de données,
utilisant des règles propres au type véhicule,
typiquement: les PIDs à solliciter, avec quelle périodicité, et quelles sont les données récupérées ainsi que les règles de calcul.

ensuite,un ensemble commun à tous les types de HSD:
les variables calculées: distance, conso, efficacité, conseils d'écoconduite, etc

un processus d'enregistrement en CSV sur SDCARD,
un processus d'envoi des données collectées, soit à la demande, soit en temps réel sur un serveur (qui pourrait celui de notre club);

et enfin en dernier lieu, la présentation à l'écran.

le pb évoqué par planétaire de récupération de la qté restant dans le réservoir pourrait éventuellement être traité en repassant périodiquement en mode "observation passive" en appliquant les filtres qui vont bien.

ps: cet appareillage ne doit pas détourner l'attention du conducteur, priorité à la conduite et à la sécurité.

Less Polluter · 13 Janv. 2011

Bon, même si c'est la dernière roue du carrosse j'ai continué a relooker l'interface en prenant quelques remarques en compte. Je fais ce que je peux.

J'aime bien l'exemple de parkerbol, mais je ne me sens pas encore en mesure de faire pareil.

J'ai juste essayé de regrouper les infos importantes les rendant lisibles et en utilisant au max le peu de surface d'affichage.

Ci après j'ai ajouté l’aiguille du rendement du moteur thermique (si cela peut être calculé) le sommet étant juste avant le max le nirvana but du jeu étant de faire coïncider les 2 aiguilles ... (le "45%" toujours celui de la pédale, pas le rendement).

guinness · 13 Janv. 2011

a y est

Bonjour à tous.

Ca y est, j'ai craqué, j'ai acheté un dongle BT (le même que priusfan), j'en ai profité pour désactiver les bips de ceinture (pour l'instant), grâce à la commande (saisie dans la console de EOBD facile):
at sh 7c0
3b a7 00
(remplacer 00 par c0 pour rétablir les bips).

Effectivement Torque marche bien du premier coup sur Android, mais ça manque cruellement de params spécifiques à la Prius (une feature intéressante par contre est le "mirror display" qui permet de nuit d'avoir un head-up display en posant le tel sur le tableau de bord (l'écran est alors affiché sur le pare-brise)).

J'ai l'impression qu'on ne peut pas avoir à la fois le téléphone et un PC connectés sur le dongle (c'est soit l'un soit l'autre, mais pas les deux en même temps apparemment).

Pas encore eu le temps de me plonger dans le code de bluetooth chat ou obd-reader ni de générer un apk pour les tester mais je compte essayer de trouver un peu de temps pour m'y mettre. Comment s'organise-t-on alors pour avancer à plusieurs, comment se partage-t-on nos modifs? J'ai vu que priusfan avait un serveur ftp mais je n'ai pas accès

priusfan · 13 Janv. 2011

pour l'organisation, on va voir.
parkerbol envisage un svn, cela me parait prématuré à ce jour.
je peux ouvrir un espace accessible en ftp, soit sur mon espace perso, soit sur le serveur du club.
je suggère d'attendre les premiers retours de loïc (qui a une expérience prouvée des dev sous androïd).

pour info, planétaire passe au bluetooth, (mais toujours avec des dev en vb6) suite à des mésaventures qu'il se fera un plaisir de narrer ici...

vous avez peut-être vu que les cousins germains de priuschat envisagent également un projet du même type mais, pour le moment, plus centré sur le monde de la pomme...
leur projet me semble trop ambitieux pour être réalisable...

en ce qui concerne obdreader, c'est une base qui marche, mais cela me semble réellement une usine à gaz...

je vérifierai ce WE le fonctionnement BT simultané autoradio & dongle.

priusfan · 13 Janv. 2011

photo dessin de lesspo sur téléphone:

Less Polluter · 13 Janv. 2011

Ca a l'air bien lisible (je me suis même exclamé : "waw, ça arrache !!!)

Volkan · 14 Janv. 2011

Je veux bien être votre beta testeur.
J'ai maintenant pas mal de temps disponible, le rachat de SUN par Oracle est passé par là. :sad:

Donc je suis disponible pour apprendre à développer sous Android j'ai plus de 23 mois devant moi

J'ai le téléphone qui va bien, HTC Hesire HD, mes yeux ont du mal à voir j'ai pris grand écran.

Dites moi seulement le modelé de dongle à acheter en BT.

priusfan · 14 Janv. 2011

bonjour volkan.
le dongle que j'utilise est celui là : http://www.boutiqueobdfacile.fr/elm-327/12-elm327-bluetooth.html

avant d'être alpha testeur, il faut du grain à moudre...
coté dev, je pense que la base bluetoothchat est beaucoup plus saine que obdreader.
il reste quand même à la faire démarrer...
peut-être y a t-il un pb dans la lecture, car il semble qu'il transmet les octets du buffer au fur et à mesure.
suggestion: afficher seulement à réception de ">" ?
cela se passe ici dans bluetoothchatservice

Code:

        public void run() {
            Log.i(TAG, "BEGIN mConnectedThread");
            byte[] buffer = new byte[1024];
            int bytes;

            // Keep listening to the InputStream while connected
            while (true) {
                try {
                    // Read from the InputStream
                    bytes = mmInStream.read(buffer);

[COLOR=Blue]                    // Send the obtained bytes to the UI Activity
                    mHandler.obtainMessage(BluetoothChat.MESSAGE_READ, bytes, -1, buffer)
                            .sendToTarget();[/COLOR]
                } catch (IOException e) {
                    Log.e(TAG, "disconnected", e);
                    connectionLost();
                    break;
                }
            }
        }

parkerbol · 14 Janv. 2011

Bienvenue,

Deux modèles ont été testés ici :
commandé par priusfan et guinness
http://www.boutiqueobdfacile.fr/ELM-327-Bluetooth-cbbaaaaca.asp
par moi (dongle plus petit et bleu)
http://www.diagnostic-auto.com/ELM327-h4.htm

Pour le protocole OBD :
J'ai lu http://www.elmelectronics.com/DSheets/ELM327DS.pdf
et
http://www.elmelectronics.com/ELM327/AT_Commands.pdf

Pour android :
http://developer.android.com/index.html
bonnes pratiques :
http://developer.android.com/guide/practices/ui_guidelines/index.html

Pour la gestion des sources, il faut que l'on se mette d'accord pour dire que l'on part d'obd-reader par exemple ou alors from scratch et que l'on pousse les sources sur un gestionnaire de sources type git ou code.google.com
http://source.android.com/source/git-repo.html
ou celui qui serait plus simple pour tous
http://code.google.com/hosting/createProject
(project=hsdcanmonitor, VCS=subversion, License=licence Apache 2.0 ...)

Qu'en pensez vous ?

parkerbol · 14 Janv. 2011

Nos messages se sont télescopés :-D

Volkan · 14 Janv. 2011

J'ai commandé la version de Pruifan et Guiness pour la simple raison que le logiciel est en français et que je souhaite aussi l'utiliser sur la Peugeot 206 de madame.

Maintenant il reste plus qu'à me mettre au développement sous Android-sdk-mac_x86

parkerbol à dit:
Pour la gestion des sources, il faut que l'on se mette d'accord pour dire que l'on part d'obd-reader par exemple ou alors from scratch et que l'on pousse les sources sur un gestionnaire de sources type git ou code.google.com
http://source.android.com/source/git-repo.html
ou celui qui serait plus simple pour tous
http://code.google.com/hosting/createProject
(project=hsdcanmonitor, VCS=subversion, License=licence Apache 2.0 ...)

Qu'en pensez vous ?

C'est une bonne idée. pour ma part je ne suis que lecteur pour le moment.

Less Polluter · 14 Janv. 2011

Less Polluter à dit:
Ca a l'air bien lisible (je me suis même exclamé : "waw, ça arrache !!!)

J'ai transféré l'image sur mon Htc Diamond 2 (Windaz 6,1 ... dommage) avec un relativement petit écran, 3,2" mais à grande résolution WVGA 800x480. Je suis surpris du résultat, c’est parfaitement lisible, même d'assez loin. Vais faire des tests en voiture ce soir pour voir ce que ça donne avec les secousses mais je pense que l’utilisation sur l'écran d'un Androphone est parfaitement envisageable. On pourrat même trouver un support pour le positionner dans l'axe de vue devant le TdB de la voiture. Par contre il ne faudra pas trop surcharger d'info et cadrans. Ce que j'ai mis me semble maximum pour une si petite taille.

priusfan · 14 Janv. 2011

bonsoir
une petite question technique?

dans le btchat édulcoré que j'ai préparé,
je voudrais insérer un "\r\n" au Q de ce qui a été saisi avant de l'envoyer à l'elm.

je pense en effet que tant que la cde n'est pas complète pour l' ELM327, on rentre dans un processus de timeout et le résultat peut être n'importenawak.

concrètement qui pourrait me donner la syntaxe pour ajouter ces 2 bytes dans un array de bytes?
le besoin est de remplacer la tentative en rouge par qqc de correct dans le bout de code :

Code:

public void write(byte[] buffer) {
            try {
                
                [COLOR=Red]buffer += "\r\n";[/COLOR]
                mmOutStream.write(buffer);

                // Share the sent message back to the UI Activity
                
                mHandler.obtainMessage(BluetoothChat.MESSAGE_WRITE, -1, -1, buffer)
                        .sendToTarget();
                mmOutStream.flush();

merci

ps: à moins que dans ce bout de code, il envoie byte par byte , auquel cas, c'est en amont qu'il faut ajouter ces 2 bytes

guinness · 14 Janv. 2011

Réponse rapide mais pas forcément la plus élégante (fin de semaine, tout ça..), je ferais:

Code:

byte[] newBuff = new byte [buffer.length + 2];
System.arraycopy(buffer,0,newBuff,0,buffer.length);
newBuff[newBuff.length -2] = '\r'; // ou 13.
newBuff[newBuff.length -1] = '\n'; // ou 10.

Et puis j'utiliserais newBuff par la suite au lieu de buffer

parkerbol · 14 Janv. 2011

@Priusfan, pourrais tu nous faire parvenir ton travail stp ?

@guinness,
j'aurai fait comme ça aussi. A tester néanmoins.

priusfan · 14 Janv. 2011

merci,

c'est testé, et cela donne des signes positifs.
(je me posais la question d'utiliser append)

donc btchat donne signe de vie...
:lol:

je zipperai l'ensemble après la promenade de chopin. (c'est mon toutou)

il s'agit du bluetoothchat des examples du SDK avec comme modifs:

a) changement du UUID pour utiliser le SPP

b) suppression de toute la partie server

c) ajout du saut de ligne en fin de commande

d) il faudra traiter la réponse pour n'afficher qu'à réception du ">"

priusfan · 14 Janv. 2011

j'ai mis le bébé avec ses couches sur mon ftp

server: priusfan.info
user: u39344557-andrius
mdp: sera transmis sur demande en mp

pour le moment, je l'envoie à parkerbol & guiness

axes de dev:
créer pour une session, un fichier sur sdcard avec un nom contenant date et heure.
logger chaque échange in / out précédé d'un timestamp à la milli seconde.

guinness · 15 Janv. 2011

First try

priusfan à dit:
d) il faudra traiter la réponse pour n'afficher qu'à réception du ">"

J'ai pris l'hypothèse que l'on pouvait utiliser la même instance de BluetoothChatService à la fois pour les réponses de commande et pour les PIDs passifs (c'est pas encore bien clair dans ma tête comment ça marche pour ne pas tout mélanger, mais bon.. D'ailleurs il faudra gérer une liste de handler si c'est le cas, et non pas un seul comme maintenant).

Du coup je n'ai pas utilisé la manière élégante de rester bloqué sur le stream en lecture, 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:
            	// First: read the message
                byte[] readBuf = (byte[]) msg.obj;
                // Then avoid multi-threading issues:
                // and check if we're done (i.e. we received '>'):
                synchronized(this) {
                    if (buffer == null) {
                    	// Start over:
                    	buffer = new StringBuffer();
                    }
                    // construct a string from the valid bytes in the buffer
                    String readMessage = new String(readBuf, 0, msg.arg1);
                    // Note: We don't handle the case where several '>' are received.
                    String[] result = readMessage.split(">",2);
                    buffer.append(result[0]);
                    // Check if our response contained '>':
                    if (readMessage.indexOf('>') >= 0) {
                    	// We found our end char, let's print the response:
                        mConversationArrayAdapter.add(mConnectedDeviceName+":  " + buffer.append(">").toString());
                        // Now let's deal with trailing chars after the '>':
                        if (result[1].length() > 0) {
                        	buffer = new StringBuffer();
                        	buffer.append(result[1]);
                        }
                        else buffer = null;
                    }
                    // else don't print anything just yet...
               	}
                break;
            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...

priusfan · 15 Janv. 2011

J'ai pris l'hypothèse que l'on pouvait utiliser la même instance de BluetoothChatService à la fois pour les réponses de commande et pour les PIDs passifs ....

tout à fait d'accord. le dialogue avec l'elm est du type talkiewalkie: un seul cause à la fois.
raison: on ne lui cause que lorsqu'il a répondu à la question précédente, sinon c'est un dialogue de ce type.

et quand on écoute, c'est soit dans l'attente d'une réponse à une commande,
soit en surveillant les trames passives, auquel cas il est nécessaire de traiter trame par trame : le séparateur etant le CRLF.

perso, je ne suis pas chaud d'utiliser les PIDs passifs: c'est assez galère de changer de mode et de mettre des filtres; et de toute façon, en ce qui concerne la P3, la seule info pertinente récupérable en passif est la contenance du réservoir...

gestion du multiple ">" : aucun intérêt et impossible si on respecte le principe du talkiewalkie

pas de bol, aujourd'hui, mon épouse monopolise la prius....

elm327 BT / Android

Administrateur

Participant hyperactif

Participant hyperactif

Participant hyperactif

Participant hyperactif

Participant hyperactif

darwiniste

Participant hyperactif

Participant hyperactif

darwiniste

darwiniste

Participant hyperactif

Participant hyperactif

darwiniste

Participant hyperactif

Participant hyperactif

Participant hyperactif

Participant hyperactif

darwiniste

Participant hyperactif

Participant hyperactif

darwiniste

darwiniste

Participant hyperactif

darwiniste