Traducteur CCD-CAN

Le protocole CCD (Chrysler Collision Detection) de Chrysler est un protocole de communication propriétaire utilisé par les véhicules Chrysler pour communiquer entre divers modules électroniques et unités de commande dans la voiture. Il s'agit d'une évolution de l'ancien protocole Chrysler Collision Detection Bus (CCDB). Le protocole CCD est un protocole de communication série à deux fils qui utilise une paire de fils torsadés pour transmettre des données entre les modules. Il fonctionne à une vitesse de 9600 bits par seconde (débit en bauds) et utilise une structure de communication maître-esclave, où un module sert de maître et les autres modules sont des esclaves. Le protocole CCD utilise un système de communication basé sur les messages, où chaque message se compose d'un en-tête, d'une charge utile de données et d'une somme de contrôle. L'en-tête contient des informations sur le type de message, le module de destination et la longueur de la charge utile des données. La charge utile de données contient les données réelles transmises, telles que les relevés de capteur ou les signaux de commande. L'un des principaux avantages du protocole CCD est sa capacité à détecter et à signaler les défauts et les erreurs dans le système de communication. Chaque module surveille en permanence le bus de communication, et s'il détecte une erreur, il signalera l'erreur au module maître. Cela permet un diagnostic et une réparation plus rapides des défauts du système. Le protocole CCD est utilisé dans une large gamme de véhicules Chrysler, y compris les voitures, les camions et les VUS. Il est utilisé pour contrôler divers systèmes du véhicule, y compris le moteur, la transmission, les freins, le système d'airbag et d'autres modules de commande électroniques.

Chrysler CCD et CANBUS (Controller Area Network Bus) sont tous deux des protocoles de communication utilisés dans les véhicules pour permettre la communication entre différentes unités de commande électroniques (ECU) dans le véhicule. Cependant, il existe des différences essentielles entre les deux protocoles.

Vitesse : CANBUS est un protocole de communication plus rapide que Chrysler CCD. CANBUS peut transmettre des données à des vitesses allant jusqu'à 1 Mbps, tandis que Chrysler CCD fonctionne à une vitesse de 9600 bits par seconde.

Structure des messages : CANBUS utilise une structure de communication basée sur les messages, où chaque message se compose d'un identifiant, d'une charge utile de données et d'autres bits de contrôle. En revanche, Chrysler CCD utilise une structure de communication maître-esclave avec un en-tête, une charge utile de données et une somme de contrôle.

Tolérance aux pannes : CANBUS est conçu avec la tolérance aux pannes à l'esprit, ce qui signifie qu'il peut continuer à fonctionner même si un ou plusieurs nœuds du réseau tombent en panne. D'autre part, Chrysler CCD est moins tolérant aux pannes et peut rencontrer des erreurs de communication si un module du bus tombe en panne.

Flexibilité : CANBUS est un protocole plus flexible, car il permet diverses configurations et topologies. Il prend également en charge plusieurs types de messages et une large gamme de débits de données. Chrysler CCD est un protocole propriétaire conçu spécifiquement pour les véhicules Chrysler et n'est pas aussi flexible.

Adoption : CANBUS est un protocole de communication plus largement adopté par différents constructeurs automobiles et applications, tandis que Chrysler CCD n'est utilisé que par les véhicules Chrysler.

En résumé, alors que Chrysler CCD et CANBUS sont des protocoles de communication utilisés dans les véhicules, CANBUS est un protocole plus rapide, plus flexible et plus tolérant aux pannes qui est plus largement adopté par différents constructeurs automobiles et applications.

Le traducteur se compose de trois composants principaux, le module contrôleur/émetteur-récepteur CAN, l'émetteur-récepteur CCD et un microcontrôleur basé sur Arduino Mega 2560. Le contrôleur CAN est le module canbus MCP2515 disponible auprès de divers vendeurs, généralement équipé d'un émetteur-récepteur TJA1050 intégré. L'émetteur-récepteur CCD peut être trouvé sous la forme d'une puce originale (CDP68HC68S1E) ou sous la forme d'une carte entièrement repensée de Daniel Laszlo disponible ici . L'Arduino Mega 2560 est disponible auprès de nombreuses sources sous la forme d'une carte de développement pleine grandeur ou d'une version à petit facteur de forme. L'utilisation d'un méga 2560 est nécessaire en raison des limitations de la bibliothèque CCD ne prenant en charge que le processeur 2560.

Le tachymètre peut afficher jusqu'à ~ 8500 tr/min avant de revenir à zéro, et l'incrémentation du compteur kilométrique n'est pas liée au compteur de vitesse, c'est un octet de données séparé envoyé par le PCM. Le décodage du tachymètre, du speedo, du carburant et de la tension de la batterie a été compris dans le passé, mais la pression d'huile et la température du liquide de refroidissement étaient un peu difficiles à déchiffrer. Je ne sais pas dans quelles unités ils sont censés être transmis, mais j'ai pu représenter graphiquement mes entrées par rapport aux valeurs de la jauge et proposer une fonction absurde pour les convertir respectivement en psi et ° F, avec une précision acceptable.

Une pensée que j'ai eue et qui a également été suggérée par John Sharkey ( @johnsharkey ) était de remapper certaines des jauges sur un autre canal de données, comme augmenter l'affichage de la jauge de batterie, ou peut-être l'affichage de la jauge de pression d'huile AFR. Ce serait aussi simple que de changer certaines adresses et de mettre à l'échelle dans le programme de traduction et d'ajouter une superposition au groupe d'instruments. Le seul obstacle que je vois en ce moment, c'est que ces petites jauges réagissent plus lentement aux changements d'entrée que le tachymètre ou le speedo. Je ne suis pas sûr qu'il y ait un moyen de contourner cela autre que de creuser dans les circuits du groupe d'instruments lui-même, mais cela mérite une réflexion plus approfondie.

Je ne suis pas la première personne à déchiffrer le code CCD. Un certain nombre de personnes ont travaillé sur le décodage de ce protocole pour leurs propres raisons, mais les informations sont rares et les projets sont souvent laissés inachevés et oubliés. Daniel Laszlo a été une formidable source de matériel et d'informations, et des informations sur ses projets peuvent être trouvées ici . Si vous souhaitez devenir un contributeur du projet, n'hésitez pas à m'envoyer un e-mail à AnthonyR@marstech.co .