elm327 BT / Android

[guinness]

Je suis d'accord avec Priusfan: mettre de l'intelligence sur le fait de demander ou non un param en fonction d'autres critères risque d'alourdir le code si on veut avoir une couche "transport" séparée.
Mais on pourra toujours rajouter une méthode "sendOrNot(pid)" qui sera appelée par cette couche transport pour savoir s'il faut envoyer ou pas un pid, si on constate que c'est nécessaire pour gagner de la bande passante.

Je vais essayer de regarder tout ça dimanche.

 

[guinness]

Pour le fichier des commandes le State Of The Art maintenant ça serait de le faire en xml, ça fera une structure plus claire que ton tableau.

Pour la périodicité il faut qu'on réfléchisse un peu, ne devrait-on pas avoir une seule boucle périodique avec certaines commandes lancées seulement tous les n cycles (en remplacement ou en sus des commandes à fréquence plus basse?); sachant que si la séquence précédente n'est pas finie, il faudra choisir notre stratégie:

• on ne fait pas la nouvelle séquence,
• on place cette séquence dans une queue qui sera lue à la fin de la séquence en cours (éventuellement en traitant en priorité les séquences moins fréquentes?)
• autre...

Pour le xml, ça donnerait qqchose comme:

<sequence basePeriod="10">
<group frequency="1" name="A">
    <command value="atsh7e0" />
    <command value="2101"  />
    <command value="atsh7e2" />
    <command value="2101"  />
</group>
<group frequency=2 name="B">
    <command value="atsh7e2" />
    <command value="216162"  />
    ...
</group>
...

Ou alors on passe son temps à envoyer les commandes et on ne tient compte que des cycles (i.e. pas de repos pour l'interface)?

 

[Ageasson]

J'ai mis en passant le bec sur ce fil.....Trés technique.....
Qui pourrait m'indiquer la marche à suivre pour obtenit une bande non passante sur une couche transport..........?????

 

[priusfan]

salutations à notre barde . Etienne tu es bienvenu dans ce salon, mais je ne suis pas sur que tu y sois plus utile que l'ex embastillé, je parle de l' endimanché.
je t'en serre 5 et pense te revoir bientôt.

pour info, il est observateur bénévole.

@guinness : 120% d'accord, mais par manque de culture, je ne savais pas (et ne ne sais toujours pas) si la couche xml est opérationnelle et facile à exploiter...
de toute façon, il s'agit, en ce qui me concerne, d'approches....
fx

 

[guinness]

je vais regarder pour android, mais en java maintenant c'est très simple de créér des classes avec des tags qui permettent de charger directement un objet java grâce à un fichier xml (en plus ça marche dans les deux sens, c'est-à-dire qu'on peut aussi sauvegarder l'instance de cette classe en xml pour la relire plus tard).

Donc en gros il nous suffit juste de définir comment on veut stocker ces infos dans une classe, et la structure XML en découlera.

Salutations au barde aussi , qui n'est pas toujours compris par ceux qui lisent (et écrivent) un peu trop vite sur le forum.

 

[Less Polluter]

Ben ouais, de fois on se demande ce qu'il nous chante là ...

Euh ... bon ... ben levez pas les têtes de vos métiers. Je ne faisais que passer ... c'est par où les toilettes, hein ... sinon j'ai vu une machine à café donc vu que je suis debout je passe par là ... n'est-ce pas ... y a qu'à demander. Sucre saccharose, rhum, cognac, une bonne dose ... bon ben ... à +

 

[priusfan]

OBDLink

résultat des courses
ci-dessous résumé d'un test fait sur 15 cycles, idem post 132 de cette discussion:
[table="head;width=60%"]cmd|

mS​

|
AT SH 7E0|

61​

|
01 3C 3E|

88​

|
21 01 3C 49|

87​

|
AT SH 7E2|

52​

|
21 01 61 62 67 68|

94​

|
21 70 71 74 87 8A 98|

95​

|
AT SH 7C0|

53​

|
21 29|

99​

|
total|

630​

|
[/table]
conclusion : 2 fois + rapide que machin bleu

 

[guinness]

youpi

Super FX!
Ben écoute si tu ne m'as pas encore envoyé le dongle bleu, ne t'embête pas, je vais commander l'OBDLink chez ton fournisseur, il m'ont annoncé en recevoir d'ici la fin de la semaine.

De mon côté je n'ai pas produit de code ce week-end, mais j'ai quand même pris le temps de me replonger dans le code d'obdreader ainsi que dans la relecture complète de ce thread (je comprends mieux maintenant ).

Mon idée est de repartir "from scratch" en ne gardant juste que la partie d'affichage style terminal de btchat (et en ré-implémentant comme discuté précédemment la partie commandes/réponses).
J'irais peut-être piocher ici où là dans obdreader des bouts de code (pour la partie "settings" par exemple).
Une fois que tout ça aura avancé, on pourra passer à l'interprétation des résultats et enfin à la partie graphique d'affichage des données collectées en live (toute aide sera la bienvenue).

Par contre je vais être hyper pris par le boulot en ce moment donc faut pas s'attendre à qqchose de prêt dans le futur très proche.

 

[parkerbol]

J'ai crée un googlegroup. Envoyez moi vos mails par MP si vous voulez en faire parti.

Pouvez vous valider ou amender cela svp ? L'adresse sera le googlegroup.

J'ai aussi peu de temps parce que gros gros projet en ce moment, mais j'aimerai vraiment participer à la fête modestement mais sur la même base notamment le dev de guinness en cours.
Mon frère sera dispo en support (j'ai le code de sa dernière interface qui est très très sympa).

 

[priusfan]

ok pour le googlegroup

dans ce projet, j'apporte une connaissance des infos extractibles du CAN, et une bonne partie de l'algo pour les calculs.

fais nous rêver en nous montrant des photos des réalisations de ton frangin.

 

[guinness]

Bon, je n'ai encore rien commencé, mais je vais partir d'un projet vierge en créant les classes pour faire les différents traitement dont on parle et quand j'aurai qqchose qui tourne (au mini la possibilité de faire des cmdes/réponses à la main, au mieux un bouton pour lancer des commandes de surveillance en boucle avec log dans fichier), j'importerai dans le googlegroup.

Patience, ça ne sera pas pour tout de suite je crains

 

[parkerbol]

Je recommande d'utiliser CheckStyle http://eclipse-cs.sourceforge.net/getting_started.html qui analyse le code lors d'une build, c'est pénible au début mais comme ça tout le monde aura un code propre et bien commenté.
Je vais donc créer le repository puisqu'il n'y a pas eu d'objection par rapport à ma dernière capture d'écran.

@Priusfan,
L'ancienne interface du widget WHOOT de mon frère, y a encore une refonte en cours :

Bon j'y vais ma femme m'appelle

 

[guinness]

a marche pas

C'est toujours vivant ce projet check-style?
Je demande car quand je configure eclipse pour utiliser le site http://eclipse-cs.sf.net/update/ il me dit

No repository found at http://eclipse-cs.sf.net/update/

Dans la série plug-in y a FindBug qui est pas mal non plus.

 

[parkerbol]

Ben oui, ça fonctionne encore, je l'ai installé au bureau hier !
Je vais regarder findbug mais l'esprit est différent je pense de CheckStyle.

ADD : dans le sens qualitatif. Je viens de voir findbugs. Le défaut de checkstyle, c'est qu'il a beaucoup à désactiver avant de commencer et les désactivations de certains ne sont pas celles des autres dans le sens travail collaboratif depuis le net.
On peut toujours centraliser les règles sur sonar mais faut que je vois avec mon collègue qui bosse dessus ces derniers temps, comment on fait exactement.
Un petit résumé en français : http://martinsson-johan.blogspot.com/2010/01/sonar-eclipse-pmd-checkstyle-findbugs.html

 

[priusfan]

checkstyle s'installe correctement.

m'a l'air délicat à paramétrer: lignes limitées à 80 car par défaut...
la joyeuse époque des cartes perforées est quand même révolue ...

@suivre

 

[guinness]

flash news...

Alors pour checkstyle mon problème était que Eclipse était configuré pour accéder à Internet depuis mon proxy du boulot (ce qui ne marche pas chez moi); en désactivant le proxy j'ai pu l'installer mais j'ai très vite été découragé par la somme de toutes les remarques qu'il me faisait et je l'ai désactivé au bout de 30 secondes). Quand on aura un plus petit ensemble de règles communes à respecter je veux bien ré-essayer mais là j'avoue que ça me saoulait .

J'ai pas mal avancé, mais le résultat est assez complexe à cause de la gestion du multithreading, l'avantage par rapport à obdreader c'est que c'est mon code donc au moins on a quelqu'un sous la main qui le maîtrise .
Alors voici une description de l'archi actuelle, voici les classes (même si je n'ai pas vraiment codé en Object-Oriented) en précisant aussi quelles threads y accèdent:

• Deux classes graphiques (inspirées de btchat) pour l'instant: HsdConsoleActivity avec le look de console pour les commandes/réponses manuelles, et DeviceListActivity pour la recherche des devices bt. Il nous manque la fenêtre graphique qui affichera les données en temps réel, je suis une bille en graphisme donc j'ai besoin d'aide sur ce point.
• CoreEngine (un singleton), cette classe est créée par l'Activity principale (pour l'instant la Console, mais à terme la fenêtre graphique à la Torque), cette classe est la partie logique du code que j'ai voulu sortir du code graphique (même si ça complique un peu pour les interactions vers l'utilisateur).
• CommandResponseObject, une sorte de struct qui contient la commande à envoyer et la réponse reçue (avec la durée entre émission/réception), j'ai fait deux sous-classes InitCommand et BackgroundCommand (pour distinguer les commandes d'Init de celles qui tournent en boucle de celles lancées à la main dans la console).
• Pour finir les 3 classes-singleton qui tournent chacune dans une Thread dédiée, la première est CanInterface qui ne fait que lire les commandes une à une puis attend la réponse (terminée par '>') et place cette réponse dans une Liste avant de lire la commande suivante (en fait elle utilise une 2e thread pour la gestion de la commande/réponse comme ça je peux surveiller que ça ne prend pas plus de 400ms sinon j'abort).
• CommandScheduler, c'est la classe qui place les commandes une à une dans la Queue lue par CanInterface, pour l'instant les commandes sont dans le code, j'ai pas encore codé la lecture XML (car les tags @Xml ne marchent pas sur android). Il y a la notion de périodicité, i.e. on peut ne lancer certaines commandes que tous les n cycles (et j'ai aussi rajouté le fait que si un "AT SH" part en timeout, alors on redémarre le cycle au début).
• Enfin celle qui intéresse PriusFan: ResponseHandler, qui dépile les réponses reçues de CanInterface. La méthode decodeResponses ne demande qu'à être codée pour interpréter les réponses! Pour l'instant je ne fais qu'écrire dans un fichiers les commandes/réponses (avec la durée avant réponse complète).

Comme je n'ai pas encore reçu ma nouvelle interface BT+USB, j'ai fait des tests en simulant les réponses (et des timeout!) dans CanInterface, ça m'a permis de bien dégrossir les premiers bugs.
Si ça vous intéresse je peux fournir un apk (puis les sources) sur le ftp de priusfan (=> Edit: c'est fait) en attendant de voir comment on met en place une solution de gestion de version...

 

[parkerbol]

Ok. Je vais configurer les règles checkstyle un peu plus tard.

Normalement tu as reçu le mail concernant la solution sur laquelle tu as travaillée afin de la publier.
pour résumer :
svn checkout https://hsdcanmonitor.googlecode.com/svn/trunk/ hsdcanmonitor --username guinness
je n'ai pas créé de branche spécifique pour le moment.

J'ai hâte de lire le code , le mien ne me satisfait pas pour le moment. J'ai mis mon frère en support, je vais essayer de travailler sur la partie graphisme dès que possible et après les 1ers essais.

 

[guinness]

projet open source démarré

Ca y est, le code est committé dans le projet code.google.com !
J'ai créé un sous répertoire android-bt au cas où on se met à hoster des devs pour autre chose que bluetooth et android.
Le projet s'importe tel quel dans eclipse.
Pour info personnellement j'utilise tortoise svn (sous windows ) comme client svn.

 

[parkerbol]

ok . pareil au boulot on a longtemps hésité entre tortoise et pushok. pushok n'est pas le favori des développeurs.

ajout : néanmoins j'ai testé subclipse http://subclipse.tigris.org/update

 

[priusfan]

Je regrette de ne pas avoir envoye mon truc bleu à guinness

Bravo pour l avancement.
De mon coté, je passe le we loin de la maison et sans ordinateur...

 

[priusfan]

je viens de rentrer de granville (où le temps était magnifique).

1ère chose, j'ai récupéré le dev de guinness et avant de chercher à comprendre, je colle l'apk dans mon htc et je teste l'appli dans la prius.

c'est facile à utiliser, c'est stable et cela consomme peu de cpu,
par contre, il y a truc qui chagrine le pseudo elm327 , il considère systématiquement qu'on l'a stoppé à chaque trame.

voir le fichier de log joint.
@suivre

ps extrait de la doc elm327:

Several new error messages have been added. ..... and the new response “STOPPED” which is sent if a user interrupts a search. This latter message may help in some of the more troubling cases where a user is finding that the ELM327 is returning to the prompt for some unknown reason. If there was an interrupt detected, the ELM327 will now report it, by stating that it was “STOPPED”..

 

[guinness]

bizarre, bizarre...

N'ayant pas la possibilité de tester pour l'instant, je ne peux pas vérifier ce qui peut provoquer ces "STOPPED", il faudrait débugguer en vérifiant quand est appelé _out.write()...
L'autre idée serait qu'il ne faut envoyer qu'un seul des \n\r et pas les deux?

Sinon pour l'optimisation il reste des points à améliorer mais on verra à l'usage quand on aura une activité graphique qui marche.

Puisqu'on en parle, j'ai créé une classe HsdGraphicActivity qui ne fait rien mais qui contient déjà un peu de code. Si quelqu'un veut jouer avec les layout sur android, c'est avec le fichier main.xml qu'il faut jouer.

Voilà, la suite quand j'aurai mon dongle, j'ai relancé le vendeur car il m'avait annoncé en ravoir en stock la semaine dernière...

 

[priusfan]

\n\r pas \r\n


ok cela marche beaucoup beaucoup mieux en mettant \n\r

cela se passe par ici: (j'ai laissé le commentaire original)

    public byte[] getCommandToSend() {
        // Add \r\n to all commands before sending:
        return (_command + "\n\r").getBytes();
    }

j'ai testé avec \n tout seul sans succès....

et voila la preuve.

ps: pour la phase de mise au point un timestamp plus complet est souhaitable de façon à connaitre le temps d'un cycle complet

 

[parkerbol]

effectivement on lit la différence sur la log.
je n'ai pas encore tester sur la prius bien que l'apk soit déjà sur le téléphone.
le temps que ma femme me la prête !

 

[planétaire]

Tu as un fichier de paramètres fait pour la Prius 2 ?

Attention les demandes aux Ecu sont différentes de celles des P3+Auris.