Vous utilisez un navigateur techniquement dépassé et avec des failles potientielles. Il se peut que notre site ansi que d'autres aient des problèmes d'affichage par sa faute. Vous devriez le mettre à jour ou utiliser un navigateur alternatif.
Le NAC ne vérifie la configuration BSI que dans le cas d'une caméra 130°, même désactivé dans le BSI si c'est une 180° configurée dans le NAC ça s'affiche en passant la marche arrière (de ce que j'ai pu tester en réel)
Techniquement il n'y a pas besoin d'activer quoi que ce soit pour le Visiopark 2 dans le BSI à partir du moment où le NAC est bien configuré et le boitier alimenté (je n'ai jamais essayé donc à ne pas prendre pour argent comptant)
Today I tried to test reversing camera in cousins Proace.
I activated In 2105 last three options (this works in my 308 to change 130 to 180 version view), in 2106 nothing was selected.
For test i tried old 130 camera.
I tried to swap signal lines but without any effect.
This car doesn't have AAS and with diagbox 7.49 and 7.58 i wasn't able to activate camera in BSI but as far as i understand its not needed in case of 180 camera programed in NAC.
Thanks
edit.
I try to test it with commands provided on github but nothing was shown on car screen.
22D405 Visible satellites
2FD6000300 Black screen
2FD66003 Camera display control
2FD6700330 180° Camera display control - Standard view
2FD6700340 180° Camera display control - Zoom view
2FD6700350 180° Camera display control - Lateral view
Probably because the issue is not the soft but the NAC itself ignoring settings ? This update never intended to solve your issue (probably linked to calibration rather than telecoding zone)
Hi everyone, and thanks @VLud for sharing all that informations coming, I guess, from lot of work.
Does anyone knows if this calibration method will work on SMEG+ devices too?
Thank you.
Is there another way to do that on SMEG+? I know I am off topic here, but I couldn't find a specific thread.
Maybe if you could give me some tips in PM I will be really gratefull!
Quel est la différence avec les deux fichiers de calibration 308_T9-9693028980.cal et 308_T9-9693019180.cal ?
A part dire que le second concerne une 308 avec Denon, le premier contient un sacré bloc en plus et malgré la doc sur les trames, j'ai du mal à identifier les zones ciblées dans le "content"
Probably because the issue is not the soft but the NAC itself ignoring settings ? This update never intended to solve your issue (probably linked to calibration rather than telecoding zone)
Maybe, but I can change almost everything except 212A and it upsets me
Please tell me where and what I need to see to make it work. Your picture gives me confidence in the possibility of solving my question
Maybe, but I can change almost everything except 212A and it upsets me
Please tell me where and what I need to see to make it work. Your picture gives me confidence in the possibility of solving my question
Today i was changing settings in my 308 where 130° and 180° camera settings are working to understand better what can be wrong in Proace, and I have seen today (not only today but today it was most problematic) many times "Log file is not accessible (probably locked by another process)" what was irritating when you try to change same setting few times.
It is appearing with different operations, connecting to nac, read parameters, save parameter, even when its finishing 60seconds after nac reboot.
For sure log file wasn't opened. App location was not locked for writing (desktop, download, dedicated folder on C: )
From my observations it looks like its better when I wait few seconds (around 5) after each operation. Is it possible that root cause could be slow connection to your server Vlud? I am not sure how often it is sending log to you.
Bonjour, merci pour votre boulot, c'est enorme. J'ai quelques questions, désolé si elle sont en doublon je n'ai pas eu le courage de lire les 23 pages :
si je comprends bien, on ne peut pas utiliser les obd vers usb qu'on peut trouver sur aliexpress et envoyer les commande sur la connexion COM car ils n'ont pas la connexion au bus constructeur ?
est-ce que vous auriez realisé la meme chose sur un SMEG+ de 308 II de 2015 pour par exemple activer le theme GT rouge ?
Les OBD génériques utilisent les PIN communs à tous les constructeurs pour faire de la recherche de panne / effacement de défauts et donc pas le CAN-BUS Diagnostic qui sert à la configuration / calibration / recherche de panne avancée des ECU
Non, ça prend du temps et le SMEG est déjà dépassé depuis un moment
Can somebody confirm that RCC A2 is capable to work with reversing camera?
I checked on My Peugeot 308 with NAC and after disabling camera parameter in BSI and AAS panoramic camera is still working.
In Toyota Proace with RCC A2 I was not able to make camera working and i don't know why.
We found that pins 16 and 17 are going to this yellow connector (pin 9 and 10) and we use it to connect camera signal.
I start to doubt if RCC can support reversing camera.
Je regarde un peu les outils proposés et je voulais savoir pourquoi la source du programme windows n'est pas disponible sur github ?
Aussi, si jamais on passe par l'outil de diagnostic servicebox, comment est-ce qu'on peut faire pour sniffer ? peut etre que certains qui son sur d'ancienne version comme le smeg+ pourraient partager avec vous les trames.
Aussi, si jamais on passe par l'outil de diagnostic servicebox, comment est-ce qu'on peut faire pour sniffer ? peut etre que certains qui son sur d'ancienne version comme le smeg+ pourraient partager avec vous les trames.
Il faut que tu sniff quand tu utilises DiagBox, ServiceBox, c'est juste pour les references des pieces et les procedures de montage/demontage (et SEDRE les schemas electriques).
Si tu as de quoi faire, tu peux sniff en te connectant quelquepart sur le bus CONF (si t'as une voiture en AEE2004) ou INFO/DIV (si tu as une voiture en AEE2010) avec une interface CAN classique (soit un truc a la CANAble, ou en mode ghetto avec un arduino+module mcp2515, le premier se trouve autour de 10-15eur sur aliexpress, l'autre se trouve autour de 1.5eur (arduino nano) + 2.5eur (module CAN), toujours sur aliexpress).
Si tu fais ca, c'est tres vivement conseille d'apprendre le fonctionnement d'UDS (vu que le diag peugeot se base sur UDS), pour pouvoir comprendre ce qui se passe sur le bus CAN.
Si tu as des competences en reverse engineering, pour t'aider, tu peux essayer de dump le firmware et l'analyser (ou recuperer une MaJ, souvent chiffree ceci dit, et voir si tu as moyen d'y recuperer les binaires), ces systemes sont souvent soit du RTOS (vxworks, freertos, qnx...) soit du linux (souvent minimaliste, mais les RCC/NAC sont une usine a gaz qui embarquent systemd et wayland donc voir ce qui s'y trouve). De memoire le SMEG est un systeme embarque base sur vxworks, donc des connaissances de ce truc sont pas mal recommande. sinon les outils habituel (cutter/radare2, ghidra, hopper, IDA, etc) evidemment + des connnaissances sur les languages assembleurs des cpus utilises la dedans sont utile
Si tout ca semble etre du charabia, c'est probablement plus simple de commencer par apprendre UDS, avec un peu de logique ca se "demystifie" rapidement, et de jouer avec diagbox si tu en as un, voir ce qu'il existe (et si tu te sens confiant, envoyer des ordres en changeant certains trucs pour voir si ca reagit, et comment, mais sur une voiture, le fuzzing est pas forcement recommande)
Ok, merci pour ta reponse. Par contre je ne sais pas ce qu'est le bus CONF et meme si ca m'aiguille dans mes recherches ca ne me dit pas concretement comment doit etre realisée la procedure. Apres l'idee aurait ete de, meme sans connaitre le fonctionnement du protocole, pouvoir recuperer les trames envoyées par le diagbox et les partager. Pour peut etre plus tard les decoder. Mais au moins enregistrer la session pour pouvoir la reproduire.
Pour ce qui est des sources je pense que c'est le principe de l'open source. Certains en feront une utilisation commerciale mais au moins la communauté peut en profiter, participer a l'amelioration, et sait que ce qui a ete commercialisé peut etre fait de maniere gratuite et ouverte. De toute maniere, ceux qui sont capable d'industrialiser le concept sont aussi capables de trouver des gens capables de faire le meme travail de reverse.
En tout cas merci pour l'enumertation des concepts impliqués. Ca aide a savoir ou se documenter.
j'en profite pour poser une autre question. Est-ce qu'il est possible de recuperer les données de distance renvoyée par les radar du vehicule en se connectant sur le bus CAN en diagnostique ? ou est-ce que ces données sont disponibles uniquement sur le bus constructeur du CAN ? Et est-ce que quelqu'un sait ou recuperer ces données exactement ?
Ok, merci pour ta reponse. Par contre je ne sais pas ce qu'est le bus CONF et meme si ca m'aiguille dans mes recherches ca ne me dit pas concretement comment doit etre realisée la procedure. Apres l'idee aurait ete de, meme sans connaitre le fonctionnement du protocole, pouvoir recuperer les trames envoyées par le diagbox et les partager. Pour peut etre plus tard les decoder. Mais au moins enregistrer la session pour pouvoir la reproduire.
Pour ce qui est des sources je pense que c'est le principe de l'open source. Certains en feront une utilisation commerciale mais au moins la communauté peut en profiter, participer a l'amelioration, et sait que ce qui a ete commercialisé peut etre fait de maniere gratuite et ouverte. De toute maniere, ceux qui sont capable d'industrialiser le concept sont aussi capables de trouver des gens capables de faire le meme travail de reverse.
En tout cas merci pour l'enumertation des concepts impliqués. Ca aide a savoir ou se documenter.
Le bus CONF est celui qui historiquement contient la radio/la radio-navigation, le combine, l'ecran multifonctions.... sur l'AEE2010 (donc le "template" pour l'electronique a partir de 2010), ca a ete decoupe en deux, CONF et INFO/DIV (parceque y'avait trop de trucs sur le CONF a force de rajouter des options). Si tu as SEDRE ou une RTA, tu as une explication des differents bus CAN PSA dedans
Y'a pas vraiment de "procedure" pour le reverse engineering, tu fais "ce qui doit etre fait" pour comprendre le bousin et faire ce que tu veux avec (le modifier, le comprendre/documenter, le reproduire...), si y'avait une procedure standard du "howto reverse engineer ECUs", le boulot de certains serait pas mal facilite
Capturer et partager les trames CAN sans les comprendre peut etre interessant, mais contre-productif et dangeureux: il peut y avoir des infos que tu veux pas dedans (comme ton code pin, derivable des demandes de deverouillage, et ton VIN, par exemple), et c'est tres peu probable que quelqu'un (sauf s'il est interesse pour faire la meme chose que toi sur ton modele, dans ce cas, il a deja surement des captures de sa propre voiture) s'amuse a passer du temps sur un truc qu'il n'a pas et qui l'interesse pas (y'a deja enormement de boulot sur le reste des ECUs dans une voiture )
Pour la blague sur "l'utilisation commerciale", quoi que ca veuille dire ici, et l'avis du taulier sur l'opensource, je te laisse lire le reste du topic, disons qu'on va dire qu'il est tres tres contre le fait que des gens fassent une "utilisation commerciale" de son boulot, et qu'il veux surtout pas aider "ces gens la"
(meme si ca change rien, ceux qui veulent le vendre savent logiquement deja faire du reverse engineering, donc recuperer les infos est trivial, quasiment tout autant que refaire le travail de reverse engineering d'origine, effectivement, sans compter l'immense doigt d'aller poster un exe obfusque sur github, plateforme dediee... a l'opensource)
j'en profite pour poser une autre question. Est-ce qu'il est possible de recuperer les données de distance renvoyée par les radar du vehicule en se connectant sur le bus CAN en diagnostique ? ou est-ce que ces données sont disponibles uniquement sur le bus constructeur du CAN ? Et est-ce que quelqu'un sait ou recuperer ces données exactement ?
Les donnees brutes, non, en general, un minimum de processing est fait dessus par l'ECU, sinon, oui, les capteurs envoient les donnees qui semblent interessantes sur le bus CAN (pas forcement le CONF ceci dit, cf ce que dit SEDRE sur les capteurs qui t'interessent, souvent CAR ou I/S). Il n'y a pas "reelement" de "CAN Diagnostique" chez PSA: les 2 pins standard sont connecte au I/S (ou y'a l'ECU moteur, c'est lui qui gere les demandes EOBD), et les 2 pins custom, "DiagOnCan" ou se trouvent les autres bus (CAR, CONF...), j'ai pas encore des masses etudie celui la (je me suis connecte directement sur les bus en question), mais normalement DiagBox communique directement avec chaque ECU en utilisant UDS + lis certaines donnees "normalement" (eg. hors UDS) sur le CAN, il y a aussi une indication du "mux" sur le BSI, pour l'instant je suppose que y'a un moyen d'activer, si c'est pas deja par defaut, un forwarding "brut" des trames CAN, avec le BSI qui redirige la ou il faut selon les IDs des trames en question.
Je n'ai pas parlé de procédure pour le reverse engineering en général mais de procedure pour sniffer les trames avec une diagbox. Concretement je ne sais toujours pas ce qu'il faut faire. J'ai deja eu a faire du reverse dans d'autres domaines et je sais ce que ca represente.
Sinon je ne parle pas de partager les trames CAN sans les comprendre mais pouvoir dans un premier temps enregistrer une session brut dans le but de la decrypter ensuite. Seulement apres ca la partager.
Pour ce qui est de ma question sur les radar c'etait avant tout pour savoir si on peut obtenir ces valeurs avec un dongle CAN vers usb simple qu'on peut trouver pour quelques euros sur aliexpress ou si on devait passer par un arduino connecté aux pin 3 et 8 comme fait ici.
A noter que je me suis surtout inscrit ici pour repondre aux fausses accusations, je ne compte pas rester ici (je travaille sur mes projets sur gitlab, github et sur un chan dedie d'un discord publique)
Pour la blague sur "l'utilisation commerciale", quoi que ca veuille dire ici, et l'avis du taulier sur l'opensource, je te laisse lire le reste du topic, disons qu'on va dire qu'il est tres tres contre le fait que des gens fassent une "utilisation commerciale" de son boulot, et qu'il veux surtout pas aider "ces gens la"
(meme si ca change rien, ceux qui veulent le vendre savent logiquement deja faire du reverse engineering, donc recuperer les infos est trivial, quasiment tout autant que refaire le travail de reverse engineering d'origine, effectivement, sans compter l'immense doigt d'aller poster un exe obfusque sur github, plateforme dediee... a l'opensource)
C'est quand même plus drôle de revenir à la moindre occasion de faire du bashing, tu ne pouvais pas te contenter de répondre au reste puisque de toute manière cette question ne t'était pas adressée ?
Le fait que tu sois autiste n'excuse pas tout, si tu es incapable de respecter les autres et leur idées ne vient pas sur le forum.
Pur choix personnel. Tu as tous les outils à ta disposition pour refaire le logiciel si tu en as envie (liste des paramètres, algorithme seed/key, commandes UDS, etc) mais ça ne va pas être très utile pour un SMEG de toute façon.
D'après tes questions j'ai surtout l'impression que tu veux qu'on te fasse ton projet (où est cette information, sur quel réseau, etc), je n'ai pas les réponses à toutes tes questions car je n'ai pas travaillé sur ton projet.
Il faut un minimum d'investissement personnel (temps et argent), dès que tu auras compris les mécanismes ce sera simple.
Ce site utilise des "témoins de connexion" (cookies) conformes aux textes de l'Union Européenne. Continuer à naviguer sur nos pages vaut acceptation de notre règlement en la matière.
donc voir ce qui s'y trouve). De memoire le SMEG est un systeme embarque base sur vxworks, donc des connaissances de ce truc sont pas mal recommande. sinon les outils habituel (cutter/radare2, ghidra, hopper, IDA, etc) evidemment + des connnaissances sur les languages assembleurs des cpus utilises la dedans sont utile 
)
