Aller au contenu

Rechercher dans la communauté

Affichage des résultats pour « ENGINEERING ».

  • Rechercher par étiquettes

    Saisir les étiquettes en les séparant par une virgule.
  • Rechercher par auteur

Type du contenu


Forums

  • Utilisation du forum
    • La charte Automobile Propre
    • Comment poster son premier message ?
    • L'actualité du forum
  • La communauté Automobile Propre
    • Présentation des nouveaux membres
    • Rencontres et événements
    • Discussions générales
    • Le bar
  • Les forums de discussion
    • Voitures électriques
    • Voitures hybrides rechargeables
    • La recharge
    • Production et stockage électrique
    • Voitures hybrides
    • Utilitaires électriques
    • Voitures pile à combustible hydrogène
    • 2 roues électriques
    • Aides financières
    • Carburants alternatifs
    • Nouvelles mobilités
    • Quadricycles électriques
    • Rétrofit
  • Les véhicules par marques
    • Abarth
    • Aiways
    • Alfa Roméo
    • Audi
    • BMW
    • Bolloré
    • BYD
    • Chevrolet
    • Citroën
    • Cupra
    • Dacia
    • DS
    • Fiat
    • Fisker
    • Ford
    • Harley-Davidson
    • Honda
    • Hyundai
    • Jaguar
    • Jeep
    • Karma
    • KIA
    • Land Rover
    • Leapmotor
    • Lexus
    • Lucid
    • Mazda
    • Mercedes
    • MG
    • Mia
    • Microlino
    • Mini
    • Mitsubishi
    • Nio
    • Nissan
    • Opel
    • Peugeot
    • Polestar
    • Porsche
    • Renault
    • Rivian
    • Seat
    • Seres
    • Skoda
    • Smart
    • Sono Motors
    • Suzuki
    • Tesla
    • Toyota
    • Vinfast
    • Volkswagen
    • Volvo
    • Xpeng
    • Zeekr
    • Zero Motors

Calendriers

  • Calendrier
  • Calendrier de Leaf Café France
  • Calendrier de ACOZE

Rechercher les résultats dans…

Rechercher les résultats qui…


Date de création

  • Début

    Fin


Dernière mise à jour

  • Début

    Fin


Filtrer par nombre de…

Inscription

  • Début

    Fin


Groupe


A propos de moi

  1. Bonjour à tous et meilleurs voeux pour cette nouvelle année. Plusieurs techniques existent pour accéder à ce mode engineering mais qui changent selon les dernières mises à jour de nos autos. Celle du Niro EV datant du 06-11-23 ne permet plus d'utiliser ces techniques. Je n'ai pas encore trouvé l'astuce à ce jour, mais j'ouvre ce fil pour partagé l'info dès qu'elle sera disponible. @+ Bruce
  2. Apparemment, en plus d'apporter les feux matriciels aux Model 3/Y/S/X, la 2024.8.3 apporte une autre fonction : Si vous prévoyez un voyage en voiture, vous pouvez choisir l’option One-Time Charge. Cette option s’affiche lorsque vous augmentez la limite de charge des voitures au-delà de la recommandation de conduite quotidienne. Par la suite, votre véhicule reviendra automatiquement à votre limite de charge de conduite quotidienne précédente. En gros notre limite de charge est à 80%, on la règle à 100% en prévision d'un voyage. La limite revient ensuite automatiquement à 80%. Et effectivement il m'est déjà arrivé plusieurs fois d'oublier de la baisser suite à un voyage. Concernant les feux matriciels dans la 2024.8, l'information est officielle et vient de Lars Moravy qui est "Vice President of Vehicle Engineering" chez Tesla :
  3. Oui j'avais vu quelques vidéo. Mais ca reste le domaine de l'a peu prêt et des théories. EV ils sont sympa, mais ca part souvent dans du rétro engineering bizarre. Ca le mérite d'exiter c'est sur, mais vaut mieux aller essayer soit même
  4. LauGo

    Mode ingénieur

    Bonjour, La procédure avec les niveaux de volume 7-3-1 ne semble plus fonctionner ! Avez-vous connaissance d’une nouvelle procédure pour entrer en Engineering mode ? Merci.
  5. 1) ne plus utiliser la thermique pour des longs trajets c'est déjà un grand bien. Si c'est ce que tu comptais faire alors je t'invite à prendre une 4motion pour faire rouler la moins possible la thermique. Le surcout chez VAG de la 4motion étant très faible comparé à une ID4 propulsion (vu que le braquage te satisfera). Par contre, au risque de me répéter, quand je lis montagne froid humide je t'invite à prendre des pneus hivers ou 4 saisons (avec le 4motion et 4 saisons ça te suffira pour faire tes 100m si la pente n'est pas >25%) ! 2) non le permanent c'est un raisonnement de thermique avec des ponts etc... en électrique l'antipatinage étant ultra plus réactif le moteur avant n'est activé qu'en besoin de forte puissance (optimisation conso) ou manque de motricité arrière. De la même manière (et aussi grâce au couple moteur finement réglable) les moteur électriques sont plus réactifs qu'un moteur thermique en raison de l'absence d'inertie mécanique d'un moteur à combustion. Bon ça sonne encore un peu comme Engineering Explained mais tu verras à l'usage que c'est que du bonheur ! Bref si tu n'es pas pur pur montagnard alors le 4motion+4 saisons peut être pour toi une excellente solution.
  6. Comme ses voitures se vendent de moins en moins on risque de faire une erreur dans la réponse et plus le temps avance plus la réponse à ta question sera difficile. Toutefois il y a des créneaux qui ne sont pas bien encore couvert par l’offre électrique, car tout les modèles électriques sont loin d’être encore tous efficients. Voir l’article ci-dessous. Technique mais très intéressant. https://insideevs.com/features/705034/engineering-explained-ev-efficiency/ Mais la bonne questions est peut-être de savoir quelles sont les voitures électriques qui se vendent et se vendront cette années et pourquoi? On n’avance pas avec un rétroviseur devant les yeux. Et surtout comme le dit JM Jancovici pour ses Voeux 2024 sur RTL, l’important c’est l’action. Et bien voila solution pour bien recharger sa voiture électrique vu de Belgique. Je dirais voilà pourquoi les motivations d’achats de voitures électriques vont se décupler et ne pas se résumer à une guerre thermique électrique déjà derrière nous en 2024. Cette guerre là est déjà dépassée et reconnu comme perdu comme là fait remarquer un membre de la discussion. Alors regardons devant nous et agissons.
  7. Vu ICI Je ne sais pas à quoi sa sert mais vaut mieux éviter d'y toucher....
  8. bonjour voilà ce qu'au moins 1 personne a pu faire avec une version A1 dont la doc ne faisait aucune référence au protocole Modbus: Github_1 travail à partir de cette discu Github_2 donc il faut passer du temps avec un peu de matos pour faire ce qui est couramment appelé du 'reverse engineering' pour la version A2 qui est vendu depuis nov23, qui elle fait référence à Modbus, rien encore de visible sur www. et j'ai pas eu encore le courage de suivre trame envoyée sur liaison série mais en tout cas, si vous cherchez une wb qui fait du délestage dynamique rien qu'en branchant des fils sans vous triturer les méninges, passez votre chemin, wb Lidl n'est pas faite pour vous. pour les autres, un peu de travail vous attend, car le service Lidl allemand ou français contacté ne sait que renvoyer les infos sur les params de com classique en automatisme a plus PS: vient de voir ce post Norauto et suite à ça ai visité le site et cherchez une borne triphasée et suis tombé sur plan et vous mets comparaison plan wb Lidl vs Norauto ; ça semble être le sosie avec différence vers câble VE!! au final, c'est le même revendeur CMC holding en Allemagne qui revend les produits donc Norauto vend donc des bornes monophasée avec délestage dynamique (avec TIC ou Tore courant) de même conception que Lidl (mais sans délestage TIC) mais ça existe pas en tri dommage
  9. Entre l'article de France3 ("Un de ses proches, avec lequel la vétérinaire a un contentieux pour des questions d'argent, aurait pris le contrôle du véhicule puis tenté de le voler. Christine Dousset-Lazier a porté plainte mais se pose encore des questions : "Si cette personne a réussi à le pirater, peut-être qu'il y a un problème. Soit-disant, ce logiciel est invincible." ") et le reportage sur TF1 où la dame explique que du coup elle a racheté une Highland... C'est juste du Social Engineering où le proche connaissait son mail, a fait passer le compte Tesla chez lui... mais "c'est la faute de l'informatique" et "elle s'est fait pirater sa Tesla"... soupir....
  10. Merci pour vos retours, ça me rassure ...en même temps qu'à ce me désole, engineering pourri effectivement ! Faites signe si vous arrivez a améliorer la situation, sinon je m'en tiendrai a l'hydrophobe...
  11. Merci pour la version 60, je n'y avais pas fait attention. Quant à la démultiplication oui il y a une coquille dans l'excellent (par ailleurs) article d'Andydavid sur le Enyaq 85, que j'ai noté en commentaire, mais en gros : - rapport d'allonge du rotor : x1,3 - rapport d'augmentation de Vitesse maximale (Autobahn) : 180/160 = 1,125 Donc c'est sûr et certain que la démultiplication a été raccourcie sinon la Vmax aurait été de 160 x 1,3 = 208km/h (modulo la simplification due à l'aérodynamique qui est au carré de la vitesse, mais qui a elle seule ne suffirait pas à rabaisser la Vmax à 180km/h. Et si on prend en compte l'aérodynamique sans changement de couple du rotor, la Vmax aurait été portée à 188,4 km/h). #Bref : démultiplication raccourcie dans une proportion non connue Quant à l'amélioration de l'accélération je ne m'avancerai pas à l'aveugle pour dire ce qui est majoritaire (couple ou réducteur), car en tant que client on s'en fout un peu (de la raison principale, pas des performances accrues^^). Mais on pourrait poser la question à Engineering Explained
  12. Bonjour Je me permet de reporter ce message sur le Forum ZS. Car les systèmes du ZS 2 et de la nouvelle MG5 sont les mêmes. j’ai vu sur pas mal de vidéo sur l’ancienne MG5 et ZS avec l’ancien système multimédia qu’il y avait un mode « engineering » en faisant une manipulation dans l’onglet « système » des paramètres. Ce mode permet d’activer des options comme la Clim Automatique par exemple. bref… j’aurais aimé savoir comment accéder à ce mode avec notre MG5 2022 ou ZS 2 ? Quelqu’un serait au courant de la manipulation ? Ou peut-être sur le ZS 2 car les deux véhicules tournent sous le même système ? merci à vous ?
  13. Guillaule59

    Engineering Mode

    Bonjour j’ai vu sur pas mal de vidéo sur l’ancienne MG5 et du ZS avec l’ancien système multimédia qu’il y avait un mode « engineering » en faisant une manipulation dans l’onglet « système » des paramètres. Ce mode permet d’activer des options comme la Clim Automatique par exemple. bref… j’aurais aimé savoir comment accéder à ce mode avec notre MG5 2022 ? Quelqu’un serait au courant de la manipulation ? Ou peut-être sur le ZS 2 car les deux véhicules tournent sous le même système ? merci à vous ? 😊
  14. Encore un bel exemple de « over-engineering », où le système de clé main-libre ne fonctionne pas la plupart du temps. Et en plus on ne peut changer la pile de la fameuse clé galet. Donc une fois que la pile est morte, il faut racheter une clé, au prix de 300 €. Il faudrait bien expliquer tout cela aux clients, et surtout leur laisser le choix du type de la seconde clé (classique ou galet). Encore une belle expérience client.
  15. c'est pas faux. Mais c'est parce que Tesla n'est pas une boite automobile. Elle applique des concepts très différents issus du software engineering. Oui tout ce qu'il font est rationnel. Après ca veut pas dire que c'est une garantie de succes ni protégé contre les erreurs d'analyse (on pourrait cité le yoke, même si t'aime pas les exemples) je te rejoins qu'ici on a pas le début d'une explication, sauf que le mode rampage n'est pas necessaire techniquement. On peut juste ergoter.
  16. C'est peut-être une piste pour l'évolution de la Highland, non ? Ci-dessus la TM3 Lowland. Je n'ai pas encore trouvé de vue de Starship de la Highand, mais ça ne saurait tarder. Je parie un caramel mou qu'elle sera plus arrondie à l'AV. Il faut déjà le rappeler; la Highland fait 2,5 cm que la Lowland. Et de mémoire, en terme de cX, plus c'est long, plus c'est bon ! De plus les 2,5 cm de plus de la Highland sont sur le porte à faux AV. Déjà, c'est flagrant de profil et ça devrait conduire un arrondi plus prononcé en vue de dessus : Autres détails : Le béquet AR est plus prononcé en longueur sur la Highland. Le dessous de la Highland semble un peu plus lisse, vu d'avant. Il est probable que le carénage a été soigné. Il faudra attendre une vue de Boring Company de la Highland vs Lowland pour en juger. Et comme tu le soulignes, l'aéro interne, qu'on oublie souvent. C'est ce que j'avais lu également, mais j'avais posté un lien où Jason de Engineering Explained nous explique que le diffuseur peut participer à la réduction de la trainée en plus de la portance (cf. la section "diffuser" à 9'25" dans la vidéo que j'avais postée) : Certes il s'agit de la Lucid AIr et on n'est pas du tout dans ce cas là pour le petit diffuseur TM3 Highland, mais je ne peux continuer à m'empêcher de penser que le diffuseur de la Highland a un rôle fonctionnel, même léger (peut-être en conjonction avec un dessous muni de légers bossages longitudinaux ?), et pas simplement esthétique : c'est pas le genre de la maison Tesla de mettre des pièces plus compliquées et plus chères pour des prunes !
  17. Labougie

    Menu secret MG4 ;)

    aucune idée si c'est fonctionnel toujours avec prudence https://www.mgevs.com/threads/thank-me-later-engineering-menu.13931/ labougie
  18. cyberoni

    Kia Update

    Sur mon Eniro la version était un Android 4.0. Je peux vérifier mais je pense que sur le EV6 c'est pareil. Suffit d'aller dans le mode engineering et de chercher C'est grâce à ça que l'on pouvait avoir ABRP directement d'installé sur le Eniro au début, jusqu'à ce qu'il bloque le truc. Suffisait juste de télécharger l'APK via l'explorer internet du véhicule et de l'installer. Si j'ai le temps je regarderai sur mon EV6 ce soir et prendrai une photo. Pour le proc par contre je n'en n'ai aucune idée concernant la puissance. Petite photo du mode engineering du Eniro.
  19. Bonjour, Il y a quelques mois, par curiosité et par envie, j'ai souhaité avoir plus d'informations sur la batterie de ma voiture, et les données provenant de TeslaMate via Tesla ne me convenait pas : des informations manquantes ou agrégées et parfois même extrapolées. A la fin je ne savais même plus si ce que je voyais en face de moi était une donnée mesurée ou calculé. Bref, je me suis mis en quête de trouver un lecteur OBD sur le net pour avoir plus d'informations et surtout des résultats de mesures. Sur le net, ce n'est ce qui manque, il y a plein de solutions, dont le plus célèbre Scan My Tesla. Mais ça ne me convenait toujours pas pour plusieurs raisons: - la première c'est que je ne sais si les données affichées sont calculées ou lu directement sur le bus (par exemple le SOC ? calculé par SMT ou lu sur le bus ?) - la seconde c'est la précision de la valeur qui n'est pas donné, par exemple le nominal full pack est donné en kWh, très bien, mais à combien de kWh prés ? sur le bus on ne passe que de petites valeurs de 8 octets max, alors certaines sont multipliées ou divisées par un coefficient qui définie la précision de la valeur. - la 3eme c'est que je ne voulais pas que l'OBD écrive sur le BUS sans que je le sache. En effet pour avoir des informations sur le bus il y a deux méthodes : soit on attend qu'une donnée soit produite par son producteur, soit on envoie une trame de demande du style "au fait, c'est quoi la valeur de tel machin maintenant ?" et le producteur répond sur le bus (a tout le monde). Evidement je ne voulais pas ça, car je ne voulais donner aucun moyen pour Tesla de détecter cet OBS. Donc juste de l'écoute, un sniffeur. - enfin c'est que je voulais la capacité de persister ces trames provenant du bus et de pouvoir dépouiller les données a tête reposée, sur mon pc, à la maison confort oblige - la cerise sur le gâteau : être en mesure de superposer des données provenant du bus CAN avec des données de TeslaMate, sur le même graphique ! Bref, au final, par curiosité et par envie, j'ai souhaité réaliser mon propre sniffeur de bus CAN pour ma model 3 en me disant que j'allais apprendre pleins de choses sympa, eh bien oui c'est le cas, et j'aimerai vous les partager, pour les curieux comme moi Peut-être que parmi vous il y en a qui aimerait se lancer dans cette aventure sans oser, ou tout simplement des curieux de voir comment ça se passe Alors évidement j'ai une idée de ce que j'aimerai avoir comme information et du projet que j'aimerai faire, mais je ne dit pas tout pour l'instant, j'en garde pour plus tard Pour le lecteur de bus CAN, j'ai choisi un lecteur pas cher, mais avec un lecteur de carte SD (histoire de pouvoir mettre les trames lu par le bus dessus) et j'ai bien vérifié les critères : ainsi qu'une carte SD avec une grande capacité et une classe 10 afin d'améliorer sa rapidité d'écriture (mais qui n'a servi a rien non plus car une carte de trop grande capacité n'était pas pris en charge par mon arduino ...) J'ai donc choisi : - OBD-II CAN Bus Basic Dev Kit (ref : 1030007) a 17$ et 5$ de frais de port auprès de Longan. Cette version n'existe plus mais il y en a d'autres https://www.longan-labs.cc/can-bus/obd-ii.html - Un cable en Y pour connecter cette OBD à la voiture. https://www.amazon.fr/dp/B09MQSPFWP/ref=pe_27091421_487052621_TE_item - Une carte SD HC 16Go V10. J'ai plus la référence mais c'est celle là en version 16Go : https://www.amazon.fr/Philips-FM32MP45D-jusquà-microSDHC-Adaptateur/dp/B0B3GHFV7H/ref=sr_1_2?__mk_fr_FR=ÅMÅŽÕÑ&crid=3OZWYP7NQJV08&keywords=sd+philips+16gb+v10&qid=1683300483&s=automotive&sprefix=sd+philips+16+gb+v10%2Cautomotive%2C124&sr=1-2-catcorr Quelques remarques sur ce matériel : - j'ai choisi un OBD 2 avec une vitesse de bus allant jusqu'à 1Mbit/s. Mais ça n'a servi a rien, vu que la vitesse du bus de nos modèles 3 est de 500 Kbits/sec. Je l'ai découvert en faisant mes essais et sur https://www.racelogic.co.uk/_downloads/vbox/Vehicles/Other/Docs/Tesla-Model 3.pdf - j'ai lu quelque part, j'ai oublié la référence, que la vitesse du bus (1Mb/s, 500kb/s, 250Kb/s etc dépendait de la longueur du bus en mètre, et de mémoire c'était 40 mètres max pour faire du 1Mb/s, ce qui je pense explique pourquoi Tesla utilise une bande passante de 500kb/s ? je ne sais pas, 40 mètres c'est long et cours en même temps. Bref, j'avais lu également que dans les voitures c'est souvent du 500kb/s qui est utilisé - J'ai dû changer de carte SD, j'avais pris une 64Go initialement, mais j'ai appris plus tard que la librairie pour écrire/lire sur les cartes SD avec un arduino était limité a une certaine capacité... Bref, j'ai pris une 16Go et formatter correctement c'est bon. - La prise en Y est difficile a installer je trouve, l'espacement entre les deux fiches a connecter à la voiture sont trop rapprochées ce qui fait que c'est difficile de tout bourrer dedans comme dans des videos comme celle-ci : Pour l'installation de Arduino IDE, il faut suivre le tuto sur le site du vendeur de l'OBD : https://docs.longan-labs.cc/1030003/ J'ai eu plusieurs déboires avant d'arriver à uploader un programme dessus et qu'il tourne, mais le fabriquant répond rapidement par mail, c'est toujours appréciable Le problème était surtout que les numéro de PIN m'était inconnu, et qu'il faille pour ma part appuyer sur le bouton reset de la carte, brancher le cable usb au pc, attendre 2 sec, relaché, et enfin uploader dessus. Sinon il y a un erreur de port COM visiblement sur ARduino IDE 😕 Après quelques essais, j'ai commencé à écrire un programme pour se connecter au BUS CAN et écrire les données sur carte SD. Grosso modo, ça a l'air simple mais en fait il m'a fallu pas mal de temps de mise au point Pour tuer le suspense, voici mon programme dans son intégralité, c'est fou comme il est cours, mais j'en ait fait des aller-retours avec ma voiture : #include <SPI.h> #include <SD.h> #include <mcp_can.h> #define SPI_CS_PIN 9 #define CAN0_INT 2 MCP_CAN CAN0(SPI_CS_PIN); long unsigned int id; unsigned char len = 0; unsigned char rxBuf[8]; /* SD card Settings */ char fileName[20]; File dataFile; // Time (4), id(3), len(1), data(max 8 ) = 4+3+1+8 = 16 bytes byte capsule[16]; uint32_t flushTime = 0; void setup(){ pinMode(12, OUTPUT); // OPEN THE POWER SUPPLY digitalWrite(12, HIGH); // init sd card if (!SD.begin(5)) { return; } // find next log file name for (uint8_t i = 1; i < 10000; i++){ sprintf(fileName, "DATA%d.log", i); if (SD.exists(fileName) == false){ break; } } // create new log file & append header dataFile = SD.open(fileName, FILE_WRITE); boolean canInit = false; while (!canInit) { // 500KBPS : https://www.racelogic.co.uk/_downloads/vbox/Vehicles/Other/Docs/Tesla-Model 3.pdf // does not work : 20MHz nor 1MBPS if (CAN0.begin(MCP_ANY, CAN_500KBPS, MCP_16MHZ) == CAN_OK) { canInit = true; } else { dataFile.println("MCP2515 can not be Initialized"); dataFile.flush(); delay(1000); } } // listen bus only CAN0.setMode(MCP_LISTENONLY); dataFile.println("data format : Time (4 bytes), id (3 bytes), data len (1 bytes), data (0-8 bytes)"); dataFile.flush(); } void loop() { while(CAN_OK == CAN0.readMsgBuf(&id, &len, rxBuf)) { uint32_t now = millis(); // time capsule[0] = (byte)((now >> 24) & 0xFF); capsule[1] = (byte)((now >> 16) & 0xFF); capsule[2] = (byte)((now >> 8 )& 0xFF); capsule[3] = (byte)(now & 0xFF); // tesla use only 11 bits, max id see : 0x07FF (2047) capsule[4] = (byte)((id >> 16) & 0xFF); capsule[5] = (byte)((id >> 8 ) & 0xFF); capsule[6] = (byte)(id & 0xFF); // data capsule[7] = len; for (int i=0; i<len; i++) { capsule[8 + i] = rxBuf; } // send to internal buffer dataFile.write(capsule, 8 + len); // write on sd card every 10 sec max if (now - flushTime > 10000) { dataFile.flush(); flushTime = now; } } } Plusieurs remarques sur ce programme : - N'ayant pas d'horloge, il n'y a pas de notion de date. on connais juste le temps en milli secondes depuis le démarrage du programme, donc les fichiers sont simplement nommé DATA1.LOG, DATA2.LOG, etc. A noter que la librairie SD limite la casse les noms de fichiers : donc tout est écrit en majuscule - J'ai essayé avec une fréquence de BUs de 500KBPS : je n'ai reçu aucune trame -> marche pas - J'ai essayé avec une fréquence de la puce a 20MHz : je n'ai reçu aucune trame -> marche pas - J'ai essayé avec une fréquence de la puce a 8MHz (dans le doute...) : je n'ai reçu aucune trame -> marche pas - Si j'appelle pas la méthode flush() sur le fichier, alors l'écriture ne se fait pas et mon fichier n'a que l'entête de début de fichier, c'est pourquoi toutes les 10secondes je force un flush(). Mais en contre partie, ça veut dire que je vais être aveugle toutes les 10 secondes aux trames passant sur le BUS, vu que pendant ce temps, le programme écrit sur la carte SD. (il n'y a pas de multi thread). Sauf qu'en réalité ce sera pas exactement le cas, j'expliquerai pourquoi plus tard - J'avais idée d'utiliser plutôt les interruptions (comme ici : https://www.locoduino.org/spip.php?article148), mais j'ai pas concrétisé cette idée, j'expliquerai plus tard pourquoi - J'ai voulu avoir le temps précis à la milliseconde pour chaque message - Pas de conversion en chaine de caractères, tout est stocker en binaire pour éviter de perte du temps et risquer de perdre des messages - J'ai réduit a 3 bytes la place nécessaire pour stocker l'identifiant du message après avoir fait des tests et vu que Tesla n'utilisait finalement que 11bits Une fois les données collectés sur ma carte SD, transféré sur mon pc, j'ai créé le programme qui lit ces trames Grosso modo, c'est assez simple, en java ça fait ça : final FileInputStream fileInputStream = new FileInputStream("../MyObd2/data/DATA4.LOG"); final DataInputStream d = new DataInputStream(new BufferedInputStream(fileInputStream, 1000000)); final String dataFormat = d.readLine(); // data format : Time (4 bytes), id (3 bytes), data len (1 bytes), data (0-8 bytes) while (d.available() > 0) { int now = d.readInt(); final int messageId = (d.readByte() << 16 & 0x00FF0000) | (d.readByte() << 8 & 0x0000FF00) | (d.readByte() & 0x000000FF); final byte len = d.readByte(); final byte[] data = d.readNBytes(len); ... } Facile hein Au passage, je sniffe environ 1300 messages à la secondes, l'identifiant max que j'ai vu c'est 2047 Avant de passer au décodage des messages, j'en ai profité pour déterminer si j'arrivais a sniffer tout les messages ou si des messages était perdu entre temps. Alors comment faire ? comment savoir qu'on a pas reçu un message ? pas facile hein vu qu'on l'a pas reçu ... Pour savoir, dans un premier temps j'ai juste compter le nombre de fois que je passe dans ma loop de mon programme arduino et je compte le nombre de messages que j'ai stocké sur ma carte SD. Résultat : bonne nouvelle, il passait quasiment 2 fois plus souvent dans ma loop que du nombre de message. Rassurant. ça veut dire que 50% du temps il regarde s'il y a un nouveau message (dans un des deux buffers en interne à la librairie) et il n'y a pas de nouveau message. Alors il attend. Oui sauf que il est possible que 3 messages arrivent très vite les uns derrière les autres et dans ce cas il y a des pertes non ? Pour savoir si c'est le cas, j'ai utilisé une autre méthode : je me suis dit qu'il devait y avoir des messages périodiques, c'est à dire des messages qui sont émis tout les temps de temps, et donc ce serait facile de savoir si j'en perd un : il y aurait un trou dans le graphique ! Bon ben du coup j'ai un graphique a créer... alors c'est parti : J'ai installé un InfluxDB (un apt-get install sur un serveur qui trainait dans le coin) et j'ai fais quelques lignes pour créer une database avec ces messages : InfluxDB influxDB = InfluxDBFactory.connect("http://houston:8086"); // influxDB.deleteDatabase("myobd"); // influxDB.createDatabase("myobd"); // influxDB.createRetentionPolicy("defaultPolicy", "myobd", "300000000d", 1, true); influxDB.setDatabase("myobd"); influxDB.setRetentionPolicy("defaultPolicy"); Puis envoie : Point point = Point.measurement("message") .time(startTime + now, TimeUnit.MILLISECONDS) .addField("messageId", messageId) .tag("index", String.valueOf(messagesCount)) .build(); influxDB.write(point); A noter que j'ai rajouté artificiellement une date de démarrage, vu que mon arduino n'a pas d'horloge. J'ai mis une startTime qui semblait correspondre a peu prés au moment ou le programme a dû commencer à s'exécuter (on est pas à la seconde prés ici) Une fois toutes les valeurs mises dedans, au passage j'en profite pour dire que j'ai dû rajouter un "tag" lors de la création du point ci-dessus, parce que influxDB ne permet pas d'écrire plusieurs points ayant la même date. Pas de chance.... alors j'ai trouvé cette astuce (perfectible bien sûr) pour écrire plusieurs points avec la même date... astuce vu sur un forum Aprés j'ai rajouté un graph dans le grafana de mon TeslaMate : On peux voir qu'il y a des endroits de creux, j'imagine que c'est à ces moments que l'écriture sur la carte est faite (il y a un buffer de 512 octects) j'ai pas vérifié la corrélation par contre. Si je zoom, on voit bien le trou : ... de 2ms ! pas si énorme que ça en fin de compte, mais il y a une perte tout de même. Maintenant, trouvons un message qui se répète, et pas n'importe lequel ! il faut un message qui ait une fréquence rapide, et qui a un id (en ordonné sur le graphique) très bas, car les messages avec des id bas préempte les messages avec des ids plus grand. (donc les messages important ont un id bas) Par contre, comme le bus i2c, le bus CAN est un bus sans perte ! c'est à dire que si deux écrivains écrivent leurs trame en même temps, alors celui avec le plus faible ID va écraser l'autre (une mise à la masse, donc un 0, remportera un bit 1 qui serait émit au même moment) et donc c'est le message avec l'id le plus faible qui va passer. Le second écrivain verra qu'il n'arrive pas écrire son message et donc tentera de l'émettre à nouveau juste après). Donc si je trouve un message émit régulièrement, il peux être éventuellement décalé, mais il doit y avoir un point ! Et voici mon choix, le 306 : il est émis toutes les 10 ms, tout de même ! Bon clairement il y a des trous Si j'ajoute ceux qui sont prioritaire par rapport à lui : C'est bizarre cette histoire, parce que si un message est préempté, il devrait être décalé, mais c'est pas le cas ici, il y a un vide, et pas un décalage Et si c'est l'écriture sur carte SD qui aveugle les nouveaux messages, il ne devrait pas avoir de points verts dans certains trou jaune, ce qui est pourtant le cas Et puis l'écriture sur carte SD, je pense que c'est plus les pause de 2 ms régulièrements Mais alors ou sont passé les 306 manquants ? Sont-ils au moins émis ? Pour tester, j'ai fais un autre petit programme, mais au lieu d'écrire sur carte chaque message, j'ai décidé de uniquement me focaliser sur les 306, de les compter un à un, jusqu'à recevoir 1000 messages et mesure le temps qu'il faut que je les reçoivent.A raison de 10 ms entre deux messages, ça fait donc 10 secondes. et j'écris sur carte SD uniquement ce delta de temps while(CAN_OK == CAN0.readMsgBuf(&id, &len, rxBuf)) { // track 10 ms signal, meaning 1000 messages received in 10000ms if (id == 306) { if (count306 == 0) { count306StartTime = millis(); } count306++; if (count306 == 1000) { // 10 sec ? dataFile.print("count 1000 messages 306 in "); uint32_t now = millis(); dataFile.print(now - count306StartTime); dataFile.println(" ms"); dataFile.flush(); count306 = 0; } } } } Résultat : data format : Time (4 bytes), id (3 bytes), data len (1 bytes), data (0-8 bytes). No Filter, 500 KBPS, 16 MHz count 1000 messages 306 in 12653 ms count 1000 messages 306 in 12105 ms count 1000 messages 306 in 12834 ms count 1000 messages 306 in 16305 ms count 1000 messages 306 in 11813 ms count 1000 messages 306 in 11374 ms ça c'est surprenant ! il me faut une durée variable de temps pour compter jusqu'à 10000. C'est pas normal et puis clairement il y a des pertes de paquets, pour le 1er cas, 12653ms, je m'attendais à avoir 1265 messages, mais j'en ai reçu que 1000, soit une perte de 26.5% tout de même ! Mais comment expliquer cette perte ? Clairement ce n'est pas ma carte SD vu qu'elle n'est pas sollicitée entre deux mesures Et comme le programme fait des loop à vide, c'est sans doute pas le cpu du microcontrôleur non plus Finalement, c'est peut-être qu'il n'a pas été émis, mais ce serait bizzare Ou qu'il y a des erreurs sur le bus Ou que le mécanisme de ré-emission ne marche pas mais ce serait bizzare Bref, je n'ai pas la réponse, tout du moins pour l'instant (désolé) Pour ma part, si je loupe quelques message ce n'est pas grave dans le cas d'usage Passons au gros morceau sympa, le décodage des messages Bon alors clairement, ici c'est le bordel ! (désolé pour les âmes sensibles) Tesla ne fournit pas de documentations sur ces messages, donc c'est uniquement du reverse engineering que l'on trouve. ça veut dire : tous les messages sont loin d'être décodé (sur les 300 types de messages j'ai pu en décoder que 108) et selon les mise à jour logiciels ça peut remettre en cause les décodages précédents. Bref un gros boulot très technique et très compliqué, dont la référence a connaitre est ce forum : https://www.teslaownersonline.com/threads/diagnostic-port-and-data-access.7502/page-106 ou plein de personnes plus motivé que jamais essayent de décortiquer le machin avec en tête Josh Wardell. Bravo a cette équipe. Exemple de reverse engineering qu'ils ont fait : ça vaut le coup d'aller voir Bref, sur son Git Hub, Josh a compilé un .dbc qui explique tous les messages qu'ils ont découvert : https://github.com/joshwardell/model3dbc/blob/master/Model3CAN.dbc Malheureusement il n'est pas à jour, mais il y a tout de même un bon paquet de message qui reste encore bon dedans Oui mais c'est quoi un dbc et comment ça se lit ? Alors là, ça va faire mal ! Je me suis arraché pas mal de cheveux là-dessus, oui parce qu'il y a 50% des sites qui disent n'importe quoi (j'exagère un peu) Par exemple, dans ce fichier on trouve ça : BO_ 12 ID00CUI_status: 8 VehicleBus SG_ UI_audioActive : 1|1@1+ (1,0) [0|1] "" Receiver SG_ UI_autopilotTrial : 12|2@1+ (1,0) [0|3] "" Receiver SG_ UI_bluetoothActive : 2|1@1+ (1,0) [0|1] "" Receiver source : https://www.csselectronics.com/pages/can-dbc-file-database-intro Le BO indique comment décoder un message, le 12 c'est à dire avec l'id 12, le nom du message ID00CUI_status, qui comprend 8 bytes Dans ce message il y a plusieurs informations dedans, que l'on appel des signaux, chaque ligne qui commence par SG définit un signal Par exemple le premier veut dire que le nom du signal est UI_audioActive, qui commence au bit1 et à 1bit en little endian de longueur 1 de scale et 0 d'offset d'une valeur min de 0 et de max 1 et l'unité n'existe pas ça a l'air simple comme ça, mais le problème c'est le StartBit qui pose problème et le sens de lecture. Franchement beaucoup de site se plante quand il s'agit de l'expliquer, et d'ailleurs même le document de référence pour le décodage des fichiers dbc se trompe entre @0 et @1 : 0=little endian, 1=big endian http://mcu.so/Microcontroller/Automotive/DBC_File_Format_Documentation.pdf Endianness: 0 = big endian (most significant byte first), 1 = little endian (least significant byte first) (Note: the DBC format documentation is wrong on this) https://docs.openvehicles.com/en/latest/components/vehicle_dbc/docs/dbc-primer.html / Bref, en deux mots : @1 ça veut dire little endian, et contrairement a ce qu'on peut lire partout, le startBit se lit en dents de scie et pas de gauche à doite comme le prétendent certains site Autrement dit, le signal : SG_ Exemple : 5|12@1+ (42,23) [52|96] "Km" se décode comme ça : on lit a partir du bit 5, c'est à dire la valeur "l" (évidement c'est des 0 et des 1 qu'il y a dedans et pas des lettres, j'ai mis des lettres parceque je trouve que c'est plus facile a comprendre) et on lit ensuite le bit 6, qui est à GAUCHE du bit 5, puis le bit 7, puis le bit 8 à l'autre bout, puis le 9 etc. Bref, à la fin on lit la valeur : abcdefghijkl Que l'on convertit ensuite en décimal et que l'on appelle rawValue pour avoir la valeur physique il faut alors faire rawValue * scale + offset pour obtenir la valeur en Km Evidement il faut que cette valeur soit inclus entre [52 et 96] inclus, sinon la valeur n'est pas bonne -> a rejeter Pour ma part, j'ai fais ce code là en Java : class BitReader { final byte[] data; final int dataCount; BitReader(byte[] data, int dataCount) { this.data = data; this.dataCount = dataCount; } boolean readBit(int index) { final int dataIndex = index / 8; final int bitIndex = index % 8; if (dataIndex >= dataCount) { throw new IllegalStateException("buffer overflow"); } final byte dataByte = this.data[dataIndex]; // signed switch (bitIndex) { case 0: return (dataByte & 0b0000_0001) != 0; case 1: return (dataByte & 0b0000_0010) != 0; case 2: return (dataByte & 0b0000_0100) != 0; case 3: return (dataByte & 0b0000_1000) != 0; case 4: return (dataByte & 0b0001_0000) != 0; case 5: return (dataByte & 0b0010_0000) != 0; case 6: return (dataByte & 0b0100_0000) != 0; case 7: return (dataByte & 0b1000_0000) != 0; } throw new IllegalStateException("bitIndex shall not be > 7"); } long readBits(int startBit, int bitLen) { long res = 0; for (int i = 0; i < bitLen; i++) { int currentBitIndex = startBit + i; final boolean bitValue = readBit(currentBitIndex); if (bitValue) { res |= 1L << i; } } return res; } public OptionalDouble readDouble(int startBit, int bitLen, boolean signed, double scale, double offset, double min, double max) { if (startBit + bitLen > dataCount * 8) { return OptionalDouble.empty(); } long rawValue = readBits(startBit, bitLen); if (signed) { long msbMask = 1L << (bitLen - 1); rawValue = (rawValue ^ msbMask) - msbMask; } double physicalValue = (rawValue * scale) + offset; if ((min <= physicalValue && physicalValue <= max) || (max == min && min == 0)) { return OptionalDouble.of(physicalValue); } else { return OptionalDouble.empty(); } } } record Message(long messageId, String messageName, int bytesCounts, List<Signal> signals) { } record Signal(String signalId, int startBit, int bitLen, boolean signed, double scale, double offset, double min, double max, String unit, boolean multiplexedKey, OptionalInt multiplexedValue, Map<Integer, String> format) { } Bon, maintenant qu'on sait comment décoder, il faut lire le fichier dbc, le parser, puis décoder les messages et les envoyé dans la base de donnée inluxDB... Alors j'ai fais un parseur de fichier dbc public class BcdReader { public Map<Integer, Message> read(File file) throws IOException { Map<Integer, Message> messages = new HashMap<>(); Message currentMessage = null; for (String line : Files.readAllLines(file.toPath())) { // BO_ 12 ID00CUI_status: 8 VehicleBus if (line.startsWith("BO_")) { final String[] words = line.split(" "); int messageId = Integer.parseInt(words[1]); final String messageName = words[2].replace(":", ""); int bytesCounts = Integer.parseInt(words[3]); currentMessage = new Message(messageId, messageName, bytesCounts, new ArrayList<>()); messages.put(messageId, currentMessage); } // SG_ UI_cellReceiverPower : 24|8@1+ (1,-128) [-128|127] "dB" Receiver // SG_ UI_audioActive : 1|1@1+ (1,0) [0|1] "" Receiver // SG_ UI_autopilotControlIndex M : 0|3@1+ (1,0) [0|7] "" Receiver // SG_ UI_apmv3Branch m1 : 40|3@1+ (1,0) [0|5] "" Receiver if (line.startsWith(" SG_")) { final String[] words = line.trim().split(" "); String signalId = words[1]; boolean multiplexedKey = false; OptionalInt multiplexedValue = OptionalInt.empty(); int readIndex = 3; if (words[2].equals("M")) { multiplexedKey = true; readIndex++; } if (words[2].startsWith("m")) { multiplexedValue = OptionalInt.of(Integer.parseInt(words[2].replace("m", ""))); readIndex++; } final int startBit = Integer.parseInt(words[readIndex].split("\\|")[0]); final int bitLen = Integer.parseInt(words[readIndex].split("\\|")[1].split("@")[0]); final boolean signed = words[readIndex].endsWith("+"); readIndex++; final double scale = Double.parseDouble(words[readIndex].split(",")[0].replace("(", "")); final double offset = Double.parseDouble(words[readIndex].split(",")[1].replace(")", "")); readIndex++; double min = Double.parseDouble(words[readIndex].split("\\|")[0].replace("[", "")); double max = Double.parseDouble(words[readIndex].split("\\|")[1].replace("]", "")); readIndex++; final String unit = words[readIndex].replace("\"", ""); Signal signal = new Signal(signalId, startBit, bitLen, signed, scale, offset, min, max, unit, multiplexedKey, multiplexedValue, new HashMap<>()); currentMessage.signals().add(signal); } // VAL_ 777 DAS_leftVeh2Type 4 "BICYCLE" 2 "CAR" 3 "MOTORCYCLE" 5 "PEDESTRIAN" 1 "TRUCK" 0 "UNKNOWN" ; if (line.startsWith("VAL_")) { final String[] words = line.trim().split(" "); final int messageId = Integer.parseInt(words[1]); final String signalId = words[2]; Signal foundSignal = null; final Message message = messages.get(messageId); for (Signal signal : message.signals()) { if (signal.signalId().equals(signalId)) { foundSignal = signal; break; } } final String[] words2 = line.substring(line.indexOf(signalId) + signalId.length()).split("\""); for (int i = 0; i < words2.length - 1; i = i + 2) { final int key = Integer.parseInt(words2[i].trim()); final String value = words2[i + 1].replaceAll("\"", "").trim(); foundSignal.format().put(key, value); } } } return messages; } } Bref, on met tout ça dans influDB, et on obtient quelque chose comme ça pour un trajet : A noter que la bonne manière de décoder le message 850 concernant les informations du BMS, c'est maintenant de la manière suivante : BO_ 850 ID352BMS_energyStatus: 8 VehicleBus SG_ BMS_energyStatusMultiplexer M : 0|2@1+ (1,0) [0|3] "" VehicleBus SG_ BMS_nominalFullPackEnergy m0 : 16|16@1+ (0.02,0) [0|1310.7] "kWh" VehicleBus SG_ BMS_nominalEnergyRemaining m0 : 32|16@1+ (0.02,0) [0|1310.7] "kWh" VehicleBus SG_ BMS_idealEnergyRemaining m0 : 48|16@1+ (0.02,0) [0|1310.7] "kWh" VehicleBus SG_ BMS_fullChargeComplete m1 : 15|1@1+ (1,0) [0|1] "" VehicleBus SG_ BMS_energyBuffer m1 : 16|16@1+ (0.01,0) [0|655.35] "kWh" VehicleBus SG_ BMS_expectedEnergyRemaining m1 : 32|16@1+ (0.02,0) [0|1310.7] "kWh" VehicleBus SG_ BMS_energyToChargeComplete m1 : 48|16@1+ (0.02,0) [0|1310.7] "kWh" VehicleBus (Encore merci au topic de Josh) Et pour le décodage des tensions des cellules, c'est pas encore clair, mais le gars de SMT a posté sur le forum cet algo (que j'ai traduit en java) : if (messageId == 1025) { int cell = 0; double v = 0; for (int i = 0; i < 3; i++) { v = ((data[i*2+3]<<8) + data[i*2+2])/10000.0; if (v < 0) { double c = (( data[0])*3+i+1); System.err.println("cell id "+c + " value : " + v + " volt "); } } } Et j'ai l'impression que c'est mieux que celui de Josh, à savoir : BO_ 1025 ID401BrickVoltages: 8 VehicleBus SG_ MultiplexSelector M : 0|8@1+ (1,0) [0|0] "" Receiver SG_ StatusFlags : 8|8@1+ (1,0) [0|0] "" Receiver SG_ Brick0 m0 : 16|16@1+ (0.0001,0) [0|0] "V" Receiver SG_ Brick1 m0 : 32|16@1+ (0.0001,0) [0|0] "V" Receiver SG_ Brick2 m0 : 48|16@1+ (0.0001,0) [0|0] "V" Receiver SG_ Brick3 m1 : 16|16@1+ (0.0001,0) [0|0] "V" Receiver SG_ Brick4 m1 : 32|16@1+ (0.0001,0) [0|0] "V" Receiver SG_ Brick5 m1 : 48|16@1+ (0.0001,0) [0|0] "V" Receiver SG_ Brick6 m2 : 16|16@1+ (0.0001,0) [0|0] "V" Receiver SG_ Brick7 m2 : 32|16@1+ (0.0001,0) [0|0] "V" Receiver SG_ Brick8 m2 : 48|16@1+ (0.0001,0) [0|0] "V" Receiver SG_ Brick9 m3 : 16|16@1+ (0.0001,0) [0|0] "V" Receiver SG_ Brick10 m3 : 32|16@1+ (0.0001,0) [0|0] "V" Receiver SG_ Brick11 m3 : 48|16@1+ (0.0001,0) [0|0] "V" Receiver SG_ Brick12 m4 : 16|16@1+ (0.0001,0) [0|0] "V" Receiver SG_ Brick13 m4 : 32|16@1+ (0.0001,0) [0|0] "V" Receiver SG_ Brick14 m4 : 48|16@1+ (0.0001,0) [0|0] "V" Receiver SG_ Brick15 m5 : 16|16@1+ (0.0001,0) [0|0] "V" Receiver Bref, je poursuis mes investigations, je voulais faire un post, histoire que j'oublie pas tout, et que si certaines personnes ont autant galéré que moi, qu'ils puissent savoir comment j'ai fais. Si vous avez des questions n'hésitez pas je vous répondrez volontiers, Je mettrai peut-être mon code sur github à l'occasion, et je ferai sans doute un post plus tard pour l'exploitation des données, j'ai déjà des infos croustillantes, mais je mettrait ça sans doute dans le topic associé. A voir... Annexe : quelques liens utile en vrac' : https://github.com/DieselDuz42/Arduino-CAN-bus-SD-logger/blob/master/canbus-logger.ino https://raw.githubusercontent.com/DieselDuz42/Arduino-CAN-bus-SD-logger/master/Example Logs/35516-042417.TXT https://github.com/DieselDuz42/Arduino-CAN-bus-SD-logger forum https://forum.arduino.cc/t/can-bus-traffic-logger/222157 https://github.com/akpc806a/CAN_Logger/tree/master/Firmware/IAR // can logger with buffer: https://github.com/akpc806a/CAN_Logger/blob/master/Firmware/ChibiStudio/CAN-Logger/main.c // can avec interruption https://www.locoduino.org/spip.php?article148 dbc data base https://github.com/joshwardell/model3dbc/blob/master/Model3CAN.dbc https://docs.google.com/spreadsheets/d/1ijvNE4lU9Xoruvcg5AhUNLKr7xYyHcxa8YSkTxAERUw/edit#gid=0 https://github.com/nmullaney/candash/blob/main/android/app/src/main/java/app/candash/cluster/CANSignalHelper.kt#L128 dbc sheet https://docs.openvehicles.com/en/latest/components/vehicle_dbc/docs/dbc-primer.html https://www.csselectronics.com/pages/can-dbc-file-database-intro https://www.scanmytesla.com/ https://www.longan-labs.cc/1030003.html http://docs.longan-labs.cc/1030003/#arduino-ide-setup-for-v2-rp2040-version https://www.longan-labs.cc/1030002.html https://www.longan-labs.cc/blog/post/can-bus-products-selection-guide/ https://github.com/Longan-Labs
  20. @BAM Salut, Je suis réservé sur les explications de Carlinkit. Le gros problème, c'est que Carlinkit tu as de nombreux vendeurs, mais le seul officiel c'est "carlinkit.com". De chez Carlinkit j'ai plusieurs produits, j'ai les CPC200 qui sont des proxy pour faire du Carplay sans fil, j'ai la V3, le Mini et la V5. Il y a une constante sur ces produits, ils ont des BUGS qui sont liés à plusieurs problèmes: 1- Tu as une latence entre un déclencheur et la répercussion sur l'iPhone. C'est beaucoup plus facile de le percevoir en audio, exemple, 2s de délai entre le moment où tu changes une chanson et elle se change sur l'iPhone. 2- Ils ont une mauvaise gestion de la mise en veille du IONIQ 5. Quand tu arrêtes ton véhicule, le signal "carplay" se ferme quand le système de divertissement s'arrête sur le véhicule, sauf que le port reste alimenté pendant 45 minutes, résultat, leur boitier reste actif, et cause des petits couacs, comme le fait que l'iPhone veut basculer l'audio dessus. Y compris quand le IONIQ 5 se met à jour pour transmettre des données aux serveurs de Hyundai, l'alimentation sur le port Carplay est rallumée et le boitier se rallume et croit qu'il est connecté à un équipement Carplay et si l'iPhone est à proximité, la communication bascule dessus... Le support avait essayé de me servir un problème de "voltage" pour m'expliquer des coupures de signal. Mais l'iPhone est très sensible et ne coupe par comme le boitier de Carlinkit. Après plusieurs échanges, ils ont admis que le problème venait d'une surchauffe du boitier qui provoque d'abord des saccades et des décalages de la navigation si tu as Waze par exemple de lancé, un décalage de qq secondes. Ensuite, l'écran perd sa réactivité... puis tout plante... La chauffe, est d'après ce que j'avais eu comme explication liée à la qualité d'informations que le IONIQ 5 remonte sur le port Carplay, car il va délivrer de nombreuses informations et en veut autant. Exemple, tu lances le GPS du IONIQ 5, puis tu lances une navigation avec Waze, le GPS intégré du IONIQ 5 se coupe, car il attend désormais les données de cartographie par Carplay, et dans ces situations, le boitier de Carlinkit chauffe et selon le contexte plante. J'ai aussi des TBOX chez Carlinkit qui sont des Android (13 maintenant sur la Plus en version 168). Ils sont beaucoup plus stables, car ils ne traitent pas les informations de GPS du IONIQ 5, il récupère quelques données, comme par exemple la luminosité pour basculer en sombre/jour automatiquement. Mais avec lui, si tu mets un itinéraire sur le GPS du IONIQ 5 et tu en mets un sur Waze, les 2 fonctionnent sans se couper mutuellement, car il ne traite plus les informations OEM du GPS du IONIQ 5. Dans les 2 cas, ça reste du reverse engineering du protocole Carplay, et ils tentent de se faire passer pour un iPhone 11, avec une version d'iOS 12.4. Donc tu as des BUGS quand ton iPhone tourne par exemple en version 16 d'iOS, car il y a des incohérences avec les fonctionnalités attendues par iOS 16 en Carplay et ce que transmet le boitier proxy de chez Carlinkit. Que ce soit chez Carlinkit, Ottocast, Exploter... c'est toujours le même procédé, donc des bugs similaires, et une latence audio / action. Tu as des développeurs EU qui ont sortis un boitie AAWireless pour Android Auto sans fil. Avec des développeurs qui maitrisent leur sujet et gèrent par exemple sur les IONIQ 5 par mise à jour la coupure de Carplay alors que l'alimentation reste active... Ils ont débuté le support en BETA de Carplay, et avec eux on est certain qu'ils vont faire une intégration très propre ! https://www.aawireless.io/carplay Pour Carlinkit, tu peux réduire les BUGS tant sur la TBOX que la CPC200 (le proxy), en achetant un câble en Y. Il faut supprimer du Y la tension électrique du câble arrivant du port Carplay. Donc il n'y aura plus d'alimentation possible, pour cela, tu peux par exemple arracher la patte VCC => Voici le sujet d'origine avec la solution, que j'ai pu mettre en oeuvre dans mon IONIQ 5. Maintenant, dès que je mets le contact, alors l'alimentation est envoyée et la TBOX ou la CPC démarre, et elle a nettement moins de BUG, car quand elle démarre, le système de divertissement a démarré, alors qu'avant elle pouvait démarré alors que j'ouvrais à peine les portes. Ce qui générait des bugs, exemple Waze planté, car le système de divertissement n'était pas disponible. Quand j'appuie sur le bouton de contact pour arrêter la voiture, le courant est coupé sur le port immédiatement.
  21. C'est une BMW série 7, abandonné en 2009 : https://fr.wikipedia.org/wiki/BMW_Hydrogen_7 L'un des (nombreux) inconvénients était le fait que le réservoir se vide de lui même en seulement 9 jours si il est a moitié sans l'utiliser à cause de son échauffement qui doit être évacué pour ne pas monter en pression (maxi 17h entre les utilisations pour ne pas perdre de carburant) 😂 Mais comme toujours, d'un point de vue ingénierie, c'est fou d'avoir réussi à faire un système pareil. C'est en ça que l'usage sur une voiture de course comme Toyota au dessus ne présente pas ce problème et devient un peu plus "viable" comme usage. Et c'était il y a seulement 6 mois : https://global.toyota/en/newsroom/corporate/39234866.html Pour rester chez "Engineering Explained", il avait aussi fait une présentation de ce modèle il y a quelques temps :
  22. Si je parle de stockage en hydrogène liquide, c'est pas une blague, Toyota l'a fait pour des voiture en compétition sur 24h, avec un moteur à combustion (et pas une pile à combustible). https://www.h2-mobile.fr/actus/toyota-gr-corolla-hydrogene-liquide-plein-nouveautes/ "Engineering Explained" en a fait une vidéo (en anglais) super intéressante expliquant la technologie utilisée, en quoi cela parait une bonne idée pour un usage en course, et les challenges techniques qu'il y a derrière.
  23. En tant que forumeur , je souscrit aux mises en garde de @tben Toute modification du comportement d'un ordinateur induit des effets de bords. Je dis bien ordinateur, et non voiture. cat je considère ma tesla comme un ordinateur à 4 roues et deux moteurs. Le dev d'une IA est assez complexe pour que des apprentis sorciers ne viennent pas foutre la grouille en interprétant un snapshot comme un état de fait inamovible ! Et c'est ce que fait un sexy bouton, développé sur la base d'une version obsolète du soft Tesla ! (oui, obsolète, le temps du retro engineering et de l'interprétation des résultats, les softeux tesla ont fait évolué le soft) Jouer à l'apprenti sorcier avec un engin de cette puissance , c'est risqué !!!
  24. Encore une super-vidéo de Engineering Explained sur la physique du pneu et à la fin sur l'explication de la note européenne :
  25. Il faudrait surtout connaitre la logique plutôt que faire de reverse engineering pour comprendre La voiture a peut-être une bonne raison d'hurler dans ce cas, mais on ne sait pas pourquoi.


×
×
  • Créer...
Automobile Propre

Automobile Propre est un site d'information communautaire qui est dédié à tout ce qui concerne l'automobile et l'environnement. Les thématiques les plus populaires de notre blog auto sont la voiture électrique et les hybrides, mais nous abordons également la voiture GNV / GPL, les auto à l'hydrogène, les apects politiques et environnementaux liés à l'automobile. Les internautes sont invités à réagir aux articles du blog dans les commentaires, mais également dans les différents forums qui sont mis à leur dispositon. Le plus populaire d'entre eux est certainement le forum voiture électrique qui centralise les discussions relatives à l'arrivée de ces nouveaux véhicules. Un lexique centralise les définitions des principaux mots techniques utilisés sur le blog, tandis qu'une base de données des voitures (commercialisées ou non) recense les voitures électriques et hybrides.