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

parkerbol à dit:
..
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) {
 ..
            		}
            		..
            	}
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 !
Cliquez pour agrandir...
Il y a un modulo dans l'affectation de i, donc il y a potentiellement plus d'un passage dans la boucle avec i==0, mais c'est vrai qu'un while aurait été plus logique qu'un for ici.

Bon sinon je vais essayer de regarder le code de bluetoothchat demain ou dimanche, on repart quand même de rien, c'est pour ça que je voulais regarder le code d'obdreader pour voir si on devait vraiment repartir from scratch...
Personne n'aurait décompilé le code de torque par hasard ? :-D

Pour le nombre de classes de obdreader, c'est juste une manière de ne pas dupliquer le code, mais il faut reconnaître qu'il y a des défauts: la liste des commandes est bcp trop touffue et chaque ligne est trop fine pour être cliquée dessus précisément.
 
guinness à dit:
I...
Personne n'aurait décompilé le code de torque par hasard ? :-D.
Cliquez pour agrandir...

si bien sur volkan l' a fait et moizossi,
mais c'est peu exploitable...
insiste auprés de volkan pour qu'il t'envoie son truc.
moi je pars maintenant pour la germanie...
 
Première étape

Bon alors j'ai avancé un peu (merci à Planétaire pour l'astuce du 2e push en mode accessoire, la batterie HT n'a pas perdu une barre malgré mes nombreux tests, en mode EV j'aurai pas tenu aussi longtemps), j'ai implémenté la séquence d'init recommandée par Priusfan ainsi qu'un menu "Test" avec la séquence de requêtes de Priusfan, avec les requêtes et les réponses loguées dans un fichier sur la SDcard, dans le répertoire PriusLog (chaque fichier est nommé par la date/heure de début de log).

IMPORTANT: J'ai l'impression que des fois on ne reçoit pas de '>' après une commande; pour l'instant le seul moyen de débloquer est d'envoyer à la main qqchose comme "at i" pour débloquer la situation (la réponse à "ati" se fait alors passer pour la réponse non reçue).
J'ai désactivé les interactions avec l'interface graphique quand on envoie les commandes en batch (Je préviens juste avec un "Please Wait" suivi d'un "Done"), car j'ai remarqué que ça ralentissait dans les logs. Donc si vous ne voyez pas de "Done" arriver après qq secondes, il faut faire une commande manuelle (on remplacera ça par un timeout plus tard).

Voici un exemple de fichier obtenu:
Code: 
16:06:38:142 Sent: AT SH 7E0
16:06:38:384 Received: OK

16:06:38:391 Sent: 01 3C
16:06:38:461 Received: 03 703 7F 01 12 

16:06:38:464 Sent: 01 3E
16:06:38:708 Received: NO DATA

16:06:38:716 Sent: 21 01
16:06:38:840 Received: 7E8 00 00 00 00 2E 80 2B 
7E8 23 FF 8E 95 00 00 00 00 2E 80 2B 
 00 00 00 00 2E 80 2B 
7E8 23 FF 8E 9

16:06:38:851 Sent: 21 3C
16:06:38:860 Received: 

16:06:38:868 Sent: 21 49
16:06:38:894 Received: 7E8 03 7F 21 12 
STOPPED

16:06:38:898 Sent: AT SH 7E2
16:06:38:943 Received: 3 7F 14 11 
STOPPED

16:06:38:946 Sent: 21 01
16:06:39:022 Received: EE8 10 1B 61 01 00 00 00 00 
7E8 21 11 00 00 00 00 2E 80 2B 
7E8 00 00 00 00 2E 80 2B 
7E8 23 FF 8E 9C A8 A2 2E 14 

16:06:39:030 Sent: 21 61
16:06:39:096 Received:  61 60 61 60 00 00 00 01 

16:06:39:098 Sent: 21 62
16:06:39:172 Received: 

16:06:39:180 Sent: 21 67
16:06:39:185 Received: 

16:06:39:190 Sent: 21 68
16:06:39:231 Received: TTOPPED

16:06:39:236 Sent: 21 70
16:06:39:354 Received: 7E8 03 7F 21 12 

16:06:39:357 Sent: 21 71
16:06:39:441 Received: 7E8 03 7F 21 12 

16:06:39:447 Sent: 21 74
16:06:39:577 Received: 7E8 03 7F 21 12 

16:06:39:585 Sent: 21 87
16:06:39:656 Received: 7E8 03 7F 21 12 

16:06:39:664 Sent: 21 8A
16:06:39:762 Received: EE8 03 7F 21 12 

16:06:39:764 Sent: 21 98
16:06:39:852 Received: 7E8 03 7F 21 12 

16:06:39:860 Sent: AT SH 7C0
16:06:39:905 Received: KK

16:06:39:912 Sent: 21 29
16:06:40:053 Received: 7C8 03 61 29 39

J'ai aussi testé l'ajout de menu (je débute en dev d'application Android) pour activer/désactiver les bips de ceinture ou de marche arrière (attention j'ai pas vraiment testé, d'ailleurs la commande (07c0 3bac00 j'ai aussi essayé c0 au lieu de 00 à la fin) pour remettre le bip à répétition de la marche arrière n'a pas l'air de marcher.

Bref mes devs en cours sont sur le ftp de priusfan (dans le répertoire guinness), je ne pense pas avoir le temps d'avancer plus loin avant la fin de semaine prochaine, mais si d'autres veulent commencer à modifier le code, ça serait peut-être pas mal qu'on monte un svn qqpart...
 
Oui je milite aussi pour cela, car ça fait des devs dans tous les coins. A vous de décider entre git ou googlecode.
 
parkerbol nous expliquera comment utiliser un tel environnement (qui est évidement indispensable)...

en ce qui concerne guinness, bravo , c'est un bon départ pour enchainer demandes & réponses.
je constate que ton appli est tunisienne (elle révèle pas mal de corruption :-D ).
le transfert n'est pas fiable...
j'avais constaté cela également avec une de mes interfaces.
solution dialoguer avec l'elm à sa vitesse native de 115k.
je cite un extrait de cette page
concrètement , tenter recette suivante
Comment améliorer la rapidité de l'interface ?

La plupart des interfaces ELM sont configurées pour dialoguer avec l'ordinateur à une vitesse de 38400 baud. Sachez que cette vitesse est un paramètre interne de l'interface qui peut très bien être modifié. L'augmentation de cette vitesse de communication aura pour effet d'augmenter la réactivité de votre interface (de 10 à 20%), ce qui est très utile lorsque l'on souhaite surveiller des variations rapides (tel que l'évolution des valeurs des capteurs dans le mode graphique de notre logiciel).
Pour "re-paramétrer" votre interface pour fonctionner à 115200 baud suivez la procédure suivante :

    • Connectez vous à votre véhicule à l'aide de notre logiciel
    • Servez vous de l'onglet console pour tapez les commandes décrites dans le tableau suivant:
    • Tapez : AT PP 0C SV 23
    • L'interface répondra : OK
    • Tapez : AT PP 0C ON
    • L'interface répondra : OK
    • Les nouveaux paramètres seront pris en compte après éteint/allumé l'interface (débranchement/branchement du véhicule)

Attention : ce paramètre est sauvegardé et votre interface fonctionnera à 115200 baud à chaque redémarrage. Assurez vous que les programmes informatiques que vous utilisez habituellement avec votre interface supportent cette vitesse de communication
Cliquez pour agrandir...
ps : je viens de tester l'apk de guinness, mes résultats ne sont guère + brillant , alors qu'avec la même séquence, même interface , même voiture, mon appli en vb donnait des résultats de bonne qualité....

de toute façon, il faudra mettre en place un watchdog: si pas de réponse dans un délai de 0,4 seconde, on relance le cycle.

avec la base de guinness, je tenterai peut-être des expérimentations cette semaine
 
argh

Euh, j'ai tapé les commandes ci-dessus et je ne parviens plus à me connecter à l'interface 😢

En plus après réflexion il me semble que je parlais déjà à 115k puisque cette case était cochée dans les paramètres de EOBDFacile...

Du coup pour les autres qui ont la même interface que moi attendez de voir si je parviens à résoudre le problème avant d'essayer à votre tour...
 
eobd facile procède à une série de tests pour tenter successivement différentes vitesses.
par ailleurs, il y a 2 vitesses :
a) celle du port comm (interface vers monde extérieur, pour laquelle on ne peut rien).
b) celle entre l elm327 et son interface de comm

cela m'est arrivé aussi d'avoir une interface coincée, la bleue, j'ai dû plusieurs fois la démarrer à la manivelle dans windows.

si suite à données corrompues lors du paramétrage, l'elm est vraiment coincé, il est théoriquement possible de le remettre en version de base en mettant à la masse la pin6 de l'elm327.
mais compte tenu de la manière dont le boitier et collé (et il n'y a pas de bouton de reset) je ne vois pas d'autre solution que de retester avec l'outil sous windows et si toujours pas de résultat, demander échange à la boutique.

par ailleurs, j'envisage de modifier btchat pour coller la boucle de lecture derrière l'écriture (et bien sur la partie logging).
 
Moi aussi j'avais déjà eu qq difficultés au début, c'est pourquoi je ne perds pas encore espoir.

Pour accélérer les cycles lecture/écriture, le code original de btchat n'est pas en effet adapté, il est fait pour un mode autre que le talkie-walkie (avec plusieurs personnes qui parlent en même temps).
 
Bon alors j'ai pas encore résolu mon problème (je garde la possibilité de mettre un jumper entre deux pins, mais en dernier recours et faisant bien attention).
Par contre j'ai trouvé un moyen de tester des Baud Rate sans tomber sur mon problème:
Code: 
AT BRD 23
(pour tester 115k)
ça ne répond OK que si tout va bien sinon ça retourne au baud rate précédent.
Une fois qu'on a déterminé le meilleurs BR qui va bien, alors on peut le setter de manière permanente avec AT PP.
 
Question pratique pour l'affichage sur Android

Je suis en cours d'apprentissage pour faire la/les fonctions affichage sur Android et j'avance, je le crois.

Est-ce les fonctions affichages qui doivent faire des requêtes à ODBII?
ou
Est-ce les fonctions ODBII qui doivent faire les requêtes d'affichage?

Cela change la structure des fonctions. Cette décision est assez structurante sur la suite des développements pour mon point de vue.
 
bonjour,
mon approche:

  1. un service lance, de manière périodique, des requêtes ( en fonction du modèle de véhicule); la fréquence des requêtes n'est pas la même suivant l'info demandée, par exemple les températures et le niveau du réservoir peuvent n'être demandés que toutes les 2 ou 3 minutes.
  2. traite les réponses, càd décrypte les données brutes et calcule les données "consolidées",
  3. fournit à une autre tache des résultats pour traitement, càd logging & affichage.
variante: les données consolidées sont calculées dans l'étape 3 pour alléger étape 2.


ces résultats sont, d'une part des données brutes (quand même converties en SI), d'autre part des données calculées (en bleu).
[table="head;width=60%"]Var|desc|
SOC|State of Charge %|
HVL|Batt Voltage|
Amp|Batt Amp|
Batt_KW|Batt kW|
Dis_Max|Discharge Max (kW)|
Cha_Max|Charge Max (kW)|
Batt_ref_tmp|Batt resfresh Temp (°C)|
batt_TB1|Batt Tmp1|
batt_TB2|Batt Tmp2|
batt_TB3|Batt Tmp3|
HVH|HighVoltage|
Cnv_Temp|°C|
ICE_kW||
ICE_Temp|°C|
Ice_Rpm||
ICE_Torque|NM|
Cool_Temp|°C|
MG2_kW||
MG2_Temp|°C|
MG2_RPM||
MG2_Torque|NM|
Invt_Temp_MG2|°C|
MG1_kW||
MG1_Temp|°C|
MG1_RPM||
MG1_Torque|NM|
Invt_Temp_MG1|°C|
Inj_muL||
FF_mLS|FuelFlow mL/S|
FF_LH|FuelFlow (calc) L/H|
Cons_kM_L||
Cons_L_100||
CalcLoad|%|
VehLoad|%|
MAF|G/S|
MAP|kPa|
Air_Intake_Temp|°C|
Acc_Pedal|%|
Atm_Press|kPa|
Ext_Temp|°C|
Aux_Batt|V|
Speed|kM/H|
Distance|kM|
[/table]

j'attends vos commentaires..
FX
 
Volkan à dit:
Je suis en cours d'apprentissage pour faire la/les fonctions affichage sur Android et j'avance, je le crois.

Est-ce les fonctions affichages qui doivent faire des requêtes à ODBII?
ou
Est-ce les fonctions ODBII qui doivent faire les requêtes d'affichage?

Cela change la structure des fonctions. Cette décision est assez structurante sur la suite des développements pour mon point de vue.
Cliquez pour agrandir...

Il est plutôt recommandé de faire un modèle dit pattern type MVC - Modèle-Vue-Contrôleur.
Ce qui veut dire que l'affichage est dé-corrélé de la partie traitement et heureusement sinon le code sera illisible.
Le single thread model est aussi pénalisant, en cas de plantage dans le traitement, l'UI (ou IHM) plante.
Je recommande la lecture de http://dl.google.com/googleio/2010/android-android-ui-design-patterns.pdf
 
priusfan à dit:
j'attends vos commentaires..
FX
Cliquez pour agrandir...

Excellent, on va pouvoir créer une class par requête et une par traitement, je vois plus clair maintenant.
Tu peux compléter le tableau en mettant à côté le nom type SocCommande, puis SocTraitement (ou en anglais).
Je suis en train d'installer mon nouveau pc à la maison, l'ancien a crashé irrémédiablement ! J'avais oublié comme c'était long de tout réinstaller :evil:
 
Après courte réflexion je pense qu'il faut mini 3 threads:
1 pour les requêtes/réponses sans interprétation, la seule thread qui a le droit de parler à L'ELM comme ça on respecte le mode talkie-walkie.
1 pour faire les calculs et préparer les données en deux catégories, la première qui ne contient que les dernières info reçues (pour l'UI) pour une valeur données (ICE RPM, Coolant Temp, etc.), la seconde qui garde tout l'historique pour les logs.
Le troisème thread gère l'UI.

Faut que je regarde ce qui serait le plus efficace en terme de synchronisation car la synchro entre threads est coûteuse, je me replonge dans le Collection Framework et je reviens vous voir :-D
 
attention: les requêtes et les variables récupérées sont d'une certaine manière dissociées.
je m'explique : une requête peut fournir un wagon de réponses;
exemple pour la P2, on ne demande pas spécifiquement la vitesse de MG2, mais on lance la requète 21 c3 à 7e2 et on récupère ceci:
 

Pièces jointes

contenu de l'interface eobdfacile.

facile à ouvrir après avoir décollé autocollant bleu et enlevé 4 vis.
l'intérieur semble très propre.
le coeur du truc n'est pas un elm327 mais un clone à base PIC.
le module BT ressemble beaucoup à cela .
le débit limité à 38k est regrettable car ce module permet beaucoup +....
 
Est-ce que la limite ne pourrait venir du fait qu'on passe de l'ELM à RS232 puis qu'on utilise un module RS232 vers BT. Auquel cas la limitation viendrait de la partie RS232 (qui a besoin de gros voltage swings pour aller au dela de 38k baud)?

En tout cas moi je vais tenter de câber moi-même mon dongle à la voiture en branchant le pin 6 du dongle sur le 14 afin de forcer un démarrage avec la valeur d'usine pour la vitesse.

PS: Merci pour le mp, ils m'avaient effectivement répondu aussi, mais sans être aussi clair sur le fait qu'il ne faut pas faire la manip AT PP 0C sur le modèle BT (j'espère qu'il vont mettre un warning BT sur leur site à cet endroit).
 
latence du BT,
une explication dans cette discussion
je n'ai pas retrouvé quel produit développe le dénommé jfitzpat, mais manifestement, il en connait un rayon...
 
Alors, pour en revenir à nos devs, voici l'état actuel de mes réflexions:
Une première thread qui ne s'occupe que d'envoyer/recevoir les requêtes/réponses à l'ELM BT, sans interpréter les réponses.
A l'émission on garde un timestamp d'envoi de la requête et on prend un autre timestamp à la fin de la réception. On stocke l'ensemble dans une classe E (requête+timestamp, réponse+timestamp) qu'on ajoute dans une ConcurrentLinkedQueue<E>.
Une deuxième thread se charge de vider la queue FIFO pour interpréter les réponses qu'on peut ensuite placer:
  • dans une nouvelle queue pour le logging (ou alors on lance la commande pour logger dans un BufferedOutPutStream directement),
  • et dans une ConcurrentHashMap<K,V> ou K est un type de valeur (ICE RPM, Coolant temp, etc.) et V est la dernière valeur décodée.
Une troisième thread d'UI ne fait que lire à son rythme (de préférence plus lent que l'écriture, sinon autant lui envoyer des évènements à chaque écriture) les différentes valeurs qui l'intéressent dans ce ConcurrentHashMap.

Si on trouve que ça ne va pas assez vite pour l'UI, alors on peut lire la ConcurrentLinkedQueue à l'envers (grâce par ex. à Collections.asLifoQueue) pour l'UI (afin d'avoir les dernière valeurs en priorité), et laisser une autre thread moins prioritaire traiter les requêtes/réponses dans l'ordre pour le logging.
 
@guinness
soyons radins: la notion de timestamp, on n'en a pas pas vraiment besoin, car cela ne changera pas grand chose dans les calculs résultant d' intégrations.
en effet, on reste dans des délais de l'ordre du 1/10ème de seconde.
 
guinness à dit:
...
Une première thread qui ne s'occupe que d'envoyer/recevoir les requêtes/réponses à l'ELM BT, sans interpréter les réponses.
A l'émission on garde un timestamp d'envoi de la requête et on prend un autre timestamp à la fin de la réception. On stocke l'ensemble dans une classe E (requête+timestamp, réponse+timestamp) qu'on ajoute dans une ConcurrentLinkedQueue<E>.....
Cliquez pour agrandir...
d'accord avec l'approche du découpage en thread, je suggère toutefois une petite mise en forme lors de la réception,
je propose que l'on transmette qqc structuré comme ceci:
commande (du type 7E2 21 C3)
suivi de la réponse sous forme d' un array qui ne contient que les octets de data significatifs, soit sous forme de couples hexa tels qu'on les reçoit, soit sous forme de byte (de toutes façons, c'est comme cela qu'on les utilisera)..
cette simple mise en forme ne devrait pas être trop pénalisante, et en tout cas on peut chiffrer son impact en temps.
 
optimisation?

je vous fais partager un échange avec les gens de eobdfacile;
il s'agit de 3 mails en ordre chrono.
la partie à tester est en bas...
je m'y colle ce soir, pour valider sur p3
Bonsoir Fx,

Je viens de relire plus attentivement les résultats de vos tests (à la première lecture je devais être omnibulé par les images lol)
J'ai une bonne nouvelle pour vous, je pense que la sequence peut être réduite de 50% (1.5sec pour le tout)
Plusieurs conseils
Envoyer 013C au lieu de 01 3C (et hop un espace de gagner)
Désactiver les epaces (ATS0), celle ci vous l'aviez déjà trouvé
et surtout utilisez le multi-PID (faisable en bus CAN), ça permet de doubler "fictivement" la vitesse de récupération

J'avais une remarque concernant l'open source, c'est juste mon point de vue. Vous êtes des développeurs Français, nous le sommes aussi... Je voulais vous faire part de nos début dans l'OBD, nous étions comme vous, le logiciel n'était pas en open source, mais il était complètement gratuit, nous souhaitions gagner de l'argent grâce à la publicité et aux dons. On a abandonné l'idée rapidement lorsque certain vendeurs spécialiste de l'OBD (qui ne savent même pas à quoi ressemble une trame CAN), on inclus dans leur pack notre logiciel 100% gratuit sans notre accord. Moralité si vous ne faites pas d'argent, d'autre ne ce gèneront pas.. Optez plutôt pour le gratuit en gardant les sources pour vous!

Pour revenir au technique, les données que vous souhaitez, sont est-elle accessible en "broadcast" CAN sur le bus moteur?? SI tel est le cas, vous devriez résoudre votre problème de vitesse plus vite que prévu...
Ci dessous un exemple sur une Ford, à gauche un timestamp en seconde et à droite la trame CAN
L'information de vitesse véhicule est disponible 30 fois par seconde... x-)

402.465111 < 36080000000000000043
402.465887 < 0807270175250133C0
402.466506 < 09080701D70407BD1772
402.467583 < 2107FFFE3CA44000C0
402.467760 < 4B08335E33773358336D
=========================================================================================================
Le 27 janvier 2011 08:01, <fxmoya@lelong.com> a écrit :

Bonjour,
merci pour les conseils,
si ce que vous entendez par multi-PID, est le fait de ne pas s'adresser sélectivement à une ECU, on l'a testé ,cela ne nous amène guère de gain de temps (au contraire) et complique pas mal le décodage dans le cas de réponses multitrames de 2 ECU (où tout est un peu mélangé).

en ce qui concerne le broadcast, on le connaît assez bien puisque l'on a commencé par là avec des dev en C puis en VB tournant sur eeePc avec les interfaces suivantes (toutes en USB) :
canusb http://www.lawicel.com/
elm327 http://www.obd-2.de/kabelec.html
tactrix openport http://www.tactrix.com/index.php?pa...category_id=6&option=com_virtuemart&Itemid=53
mongoose mfc http://www.drewtech.com/products/mongoose.html

en ce qui concerne les prius, il y a environ 1500 trames par secondes...
cela nécessite un elm paramétré à 500kbps faute de quoi on se chope instantanément un buffer overflow
ou alors il faut passer son temps à jouer avec des filtres et des masques et on ne sera pas à l'écoute par exemple au moment où la trame donnant le niveau de carburant passe.
l'info vitesse est diffusée environ 110 fois par seconde...
par ailleurs, les infos spécifiques du système hybride ne sont pas broadcastées.

donc pour les dev sous android, le bluetooth par son faible débit et sa latence, nous impose une approche très différente
l'alternative sera de tester le wifi qui permettra probablement une meilleure réactivité.
François-Xavier MOYA

=========================================================================================================
Bonjour,
Non, je parle de "multi-PID", pas de multi-ECU... Mais c'est peu être un terme que j'emploi abusivement, c'est comme ça qu'on appelle le fait de demander plusieurs PIDs dans une seule requête.
Je vous donne un exemple qui j'en suis sur vous montrera l'intérêt en terme de gain de vitesse
par exemple sur le mode 1 vous demandez les PIDs 3C et 3E en deux fois
mais vous pourriez envoyez
> 013C3E
et obtenir une réponse du type
< 41 3C dx dx dx 3E dx dx
Vous allez presque diviser le temps par 2. je vous laisse investiger pls en détail par vous même.
Si vous avez des question n'hésitez pas
Cordialement,
L'équipe d'OutilsOBDFacile,
Cliquez pour agrandir...
 
La piste peut être intéressante puisqu'uelle cherche à réduire le temps de traitement entre question et réponse qui est le premier frein (en gros 8 pid par seconde). Le débit du port com vient après. Mais je teste pas avant samedi, je passe le contrôle technique de ma P2 samedi.
 
Merci pour les échanges, dans la série augmenter la vitesse il y a aussi ce produit qui n'est pas donné mais qui a plusieurs avantages:
  • on peut se connecter en USB si le BT ne marche plus (j'en connais un qui aurait aimé avoir cette option :-D),
  • on peut mettre à jour le firmware,
  • il supporte les 115 Kbaud en bluetooth !

PS: Ca y est j'ai moi aussi ouvert mon dongle et recâblé le pin 14 (low) vers le pin 6 (high) de la carte, ce qui devrait inhiber l'utilisation du PP 0C et me permettre de le désactiver avant de remonter le boitier.
Au passage j'ai vu que les pin 4 et 5 sont soudés (chassis ground et signal ground), je n'ai pas trouvé si cela pouvait avoir une influence sur la qualité du signal reçu de la prius (j'ai vu que certain véhicules n'avaient même pas de chassis ground d'où la soudure j'imagine)...
 
attention casse cou!!

si tu mets en court circuit les pins 6 & 14 de la prise diag, tu court circuites le bus CAN.

c'est la pin 6 du PIC qu'il faut traiter.

passe moi un coup de fil en urgence.
 
Identifiez-vous ou inscrivez-vous pour participer.
Pages vues depuis le 20 Oct 2005: 316,288,736
Retour
Haut Bas