Afficher un message
Vieux 17/10/2023, 21h08  
Yamh
Débutant T-E
 
Avatar de Yamh
 
Date d'inscription: juillet 2023
Localisation: Cournon d'Auvergne
Âge: 34
Messages: 68
Thanks: 32
Thanked 142 Times in 37 Posts
Pouvoir de réputation: 4
Yamh will become famous soon enoughYamh will become famous soon enough
Par défaut

Bonsoir,

J'ai reçu le boitier Vgate vLinker FS USB et j'ai réussi à envoyer tous les paramètres en créant une Macro et en l'envoyant avec le mode Macro de Pyren3, sa rapidité à débloqué le problème.
Par contre, j'ai toujours la même erreur avec DDT4ALL et Pyren3 en mode DDT, même en configurant la vitesse de port du Vgate à 1Mbps.

J'apporte des nouvelles après avoir été en relation avec Shrlnm (membre du projet Pyren), l'origine du problème n'est pas vraiment matériel, mais plutôt logiciel.

Résumé et éclaircissement du problème :
Le calculateur de l'autoradio attend le téléversement d'un paramètre en moins de 5 secondes approximativement, donc si le téléversement dure plus de 5 secondes pour un même paramètre il y a un refresh et le calculateur renvoie une erreur --> Service Not Supported In Active Session(7F2E7F)

C'est ce qui se passe lorsque je téléverse les longues chaines de caractères Hexadécimal concernant les paramètres :
- DataWrite.Phone_acoustic_parameters 1
- DataWrite.Phone_acoustic_parameters 2
- DataWrite.Accoustic_Common
- DataWrite.Accoustic_Driver
- DataWrite.Accoustic_Whole_car

Le téléversement d'une longue chaine de caractères ne se fait pas en une seule fois, elle est découpée en plusieurs trames.
Pour chacune de ces trames existe un temps de latence RTT (Round-trip delay time) correspondant à l'allez/retour de l'information, ce temps de latence est adapté par le logiciel de programmation (DDT4ALL, Pyren3, Pyren DDT mode...etc...)
Il faut donc raccourcir au mieux ce temps de latence pour envoyer l'intégralité des trames en moins de 5 secondes.

Dans mon cas le temps de latence RTT d'une trame est d'environ 125ms, ce qui est énorme.
L'écriture du paramètre "Phone_acoustic_parameters 1" nécessite l'envoi de 116 trames !
116 x 0,125 = 14,5 secondes pour envoyer ce paramètre, on est loin des 5 secondes maximum !

Je n'ai donc pas encore trouvé le moyen d'effectuer le téléversement avec DDT4ALL ainsi qu'avec le mode DDT de Pyren3.


-----------------------------------------------

Pour les ELM327 PIC18F25K80 il est tout de même possible d'envoyer de très longues chaines de caractères moyennant une petite modification.
Shrlnm a trouvé une solution en m'indiquant de modifier un fichier dans le répertoire de Pyren3, cela ne fonctionne qu'avec la fonction Macro de Pyren3 :
Citation:
Envoyé par Shrlnm

--

you may try to edit the line 1666 in mod_elm.py

from
Code:
min_tout = min( 300, 2*self.response_time*1000, 4700.//len(raw_command)-16)
to
Code:
min_tout = min( 300, 2*self.response_time*1000, 4000.//len(raw_command)-16)
or
Code:
min_tout = min( 300, self.response_time*1000, 4700.//len(raw_command)-16)
---


Or Then you may edit the next line 1667

from
Code:
if min_tout<4:
to
Code:
if min_tout<100:
But it is not universal fix, it is only for your case

C'est la modification de la ligne 1667 qui a résolue le problème.
il faut bien cocher l'option CFC dans le Menu de Pyren3 pour les ELM327 PIC18F25K80.
J'ai réussi à téléverser tous les paramètres de cette manière avec un ELM327 PIC18F25K80.
Ne pas oublier de remettre la ligne 1667 à l'origine une fois qu'on a plus besoin de téléverser d'énormes chaines de caractères

---

Je vous tiendrai au courant s'il existe un moyen de contourner le soucis avec DDT4ALL ou le mode DDT de Pyren3
Yamh est déconnecté   Réponse avec citation