Vgate est un fabricant chinois. J'utilise l'interface pour ddt4all et Pyren.
https://www.vgatemall.com/products-detail/i-19/

Belle trouvaille Merci, j'ai cherché un peu, quelques précisions :

Impossible de trouver un Datasheet pour le Chip MIC3322 qui équipe le Vgate Vlink FS.
OBDLink SX (Chip : STN1130) --> DataSheet
Clone ELM327 (Chip :PIC18F25K80) --> DataSheet

Mon problème étant d'envoyer de longues trames d'informations en une seule fois.
Donc en comparant les 3 sondes (Clone ELM327 PIC18F25K80, OBDLink SX STN1130, Vgate Vlink FS MIC3322) et en faisant confiance aux spécifications marketing de Vgate comme je ne trouve pas de DataSheet.

RAM (Buffer) :
Clone ELM327 PIC18F25K80 : 3.648 Kb RAM
OBDLink SX STN1130 : 8Kb
Vgate Vlink FS MIC3322 : 8Kb

OBD request byte up to :
Clone ELM327 PIC18F25K80 : 1kB (?pas sûr?)
OBDLink SX STN1130 : 2Kb
Vgate Vlink FS MIC3322 : 4Kb

MIC332X/342XMultiprotocol OBD to UART InterpreterDatasheet

JINXUSOLU OBD-II converter and bluetooth chips comparison table

---------- Post added at 19h09 ---------- Previous post was at 19h06 ----------

http://www.jinxusolu.com/filedownload/104470

http://www.jinxusolu.com/filedownload/104472

Vous êtes au top! Merci pour la documentation :yo:
J'ai commandé le Vgate vLinker FS USB ce matin, il devrait arriver Mardi.

De plus, il est compatible avec toutes les instructions ST et VT.

En attendant, je me suis penché sur Pyren3, après une réinstallation complète mon ELM clone communique bien avec Pyren3.
Cet outil est génial !

Et bien le problème est exactement le même qu'avec DDT4ALL, même en activant le mode CFC qui rend le transfert bien plus rapide (6 secondes tout de même)...
J'ai d'abord essayé avec le mode DDT --> Service Not Supported In Active Session
Puis j'ai carrément créé une Macro et le constat est le même --> Service Not Supported In Active Session

J'espère donc avoir plus de chance de réussite avec le Vgate Vlinker FS.

Pièce jointe 101401
Pièce jointe 101402

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 :

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

Salam,

J'ai déjà rencontré ton soucis sur autoradio reset software ou même écran r-link.

Voici une solution qui passe bien via Renolink avec la sonde SX et aussi avec le ddt4all prévoir des adaptations.

Utiliser un adaptateur can-m car la radio elle fait partie du can multimédia et le SX n'est pas capable de commuter les pins.

Ensuite mettre le +apc puis allumer la radio qui renvoie un message d'erreur
au renolink > scan > audio puis start
tu devrais trouver le bon script pour ta radio
Il faut remplir l'ensemble des paramètres correctement twitter, haut-parleur, Equipement premium sur l'audio etc
Une foi cela fait dans l'onglet reset faire un reset hard et non software !!!!!

Quand la radio sera correctement configuré elle va démarrer correctement après un hard reset

Merci pour ton partage d'expériences

J'ai pu le reprogrammer avec le mode Macro de Pyren3.

Le problème venait de la gestion du RTT des trames CAN dans le logiciel DDT4ALL qui ne me permettait pas d'envoyer 116 trames d'informations Hexadécimal en moins de 5 secondes.(14,5 secondes d'envoi alors que l'autoradio R-Plug&Radio+ refresh sa ligne CAN toutes les 5 secondes).

Avec le mode Macro de Pyren3 pas de soucis, l'envoi des 116 trames est presque instantané.