Calcul du ckecksum utilisé

Bonjour à tous,

Je tente de recréer le protocole S-PCM de Graupner.

On a isolé les motifs suivants à partir d'une capture SPCM1024 Graupner réalisée à l'analyseur logique:

0x83, 0xFB, 0xC8, 0x03, 0xC1: 0xC1 étant le checksum des 4 bytes précédents
0xC4, 0x01, 0x88, 0x03, 0x1B: 0x1B étant le checksum des 4 bytes précédents
0xD3, 0xE1, 0xA7, 0x53, 0x53: 0x53 étant le checksum des 4 bytes précédents

Avec un ami, on essaie de trouver la méthode de calcule du checksum.

Pourriez vous nous aider à trouver la méthode utilisée?

Merci à vous tous,

Pierre

Bonsoir

Pourquoi planquer cette question au bar ? (peu fréquenté)

je la déplace dans la partie principale du Forum , elle y a toute sa place

Je n'ai pas la solution , juste une piste inspirée de cas particuliers :

Tentez une opération arithmétique ou logique simple sur les 4 octets de données (somme modulo 256 par exemple)

Peut être qu'en ajoutant le résultat de l'opération à la valeur de la somme de contrôle tu trouveras zéro

C'est souvent dans ce style , car le contrôle est simple et rapide à éxécuter, une simple combinaison arithémtique et/ou logique des 5 octets donne un résultat nul si OK

Merci pour le déplacement et l'idée

de rien , bien entendu l'idée avancée correspond à ce qui se fait de plus simple et date de l'époque ou c'était facilement codable en assembleur su micro 8 bits, la somme de contrôle est peut être plus complexe

Comment êtes vous sûr que c’est toute la trame?

Si j'ai bien compris, les quatre 1er byte correspondent aux 4 voies et c1 correspond au checksum des 4 voies et le code se répète ainsi régulièrement.
Je joins la doc spcm
JR_GraupnerSPCM (1).pdf (462.0 KB)

Si on croise la doc que tu donnes et les données que tu as relevés la première question qui vient à l'esprit c'est à quel niveau de la doc correspondent les données que tu as?

  1. lecture des pulse
  2. lecture de la trame logique
  3. autre.....

à la lecture de la doc c'est bien plus complexe que 4 octets suivis d'un checksum...

Bonjour à tous,

Merci de votre intérêt pour mon problème.
Je vais demander à mon collègue qui a réaliser le codeur SPCM et qui a besoin de connaître la méthode de calcul du crc de vous répondre.

Bonjour,

voici comment nous avons obtenu les 3 motifs qui pourraient permettre de déterminer l'algo de calcul du CRC8/Checksum:

S'aider visuellement des fichiers joints "JR_GraupnerSPCM(1).pdf" et "DecodageSpcmGraupner.pdf" afin de comprendre la démarche.

  1. La synchro est un niveau haut ou bas de 412.5µs, la polarité n'importe pas.

  2. Chaque front montant/descendant, est suivi d'un état haut ou bas toujours multiple de 165µs (sauf pour la synchro). Par exemple, si l'état dure 3x165=495µs, cela correspond aux 3 bits 100. Si l'état dure 5x165=825µs, cela correspond aux 5 bits 10000. Le premier bit après un front est toujours un 1 suivi d'un certain nombre de 0, sauf dans un cas particulier: le 1 juste après la synchro est ignoré.

  3. En groupant les bits obtenus par paquets de 8 bits, non obtenons des octets.

  4. Pour arriver à la trame "logique", il faut faire une conversion 8bits(octet)->5bits(quintet) en utilisant la Table 1 du document PDF. Une trame "logique" complète est composée de 32 quintets et est composée de 4 blocs de 8 quintets. Voir la structure en page 5 du PDF "JR_GraupnerSPCM(1).pdf":

  5. Chaque bloc de 8 quintets (8x5=40 bits) peuvent également se représenter comme 5 octets (5 x 8 = 40 bits aussi)

  6. Dans la doc, au chapitre Error Detection, il est écrit: Les 8 bits de poids faibles de chaque champ de contrôle (A, B, C, D) sont utilisés pour la détection d'erreur des 32 précédents bits respectifs. Nous en déduisons donc que le 5e octet de chaque bloc de 40 bits serait un CR8 ou un checksum portant sur les 4 premiers octets.

  7. Dans le PDF joint "DecodageSpcmGraupner.pdf", il y a une capture réalisée à l'analyseur logique sur laquelle les bits/octets/quintets/octets sont indiqués. On retrouve bien la valeur des voies RC (Ch2=509, Ch4=512, Ch6=512, Ch8=512, Ch1=847, Ch3=846). Les valeurs sont bien entre 0 et 1023, le neutre étant à 512. Ces valeurs sont donc cohérentes.
    Sur cette capture, les 3 premiers blocs de la trame (blocs de 40 bits) ont été décodés manuellement et transcodés sous forme d'une suite de 5 octets. Le 5e octet étant le CR8 ou checksum dont nous cherchons l'algorithme.
    Nous avons donc isolé 3 motifs:
    1er bloc: 0x83, 0xFB, 0xC8, 0x03, 0xC1: le 5e octet 0xC1 étant le crc/checksum des 4 bytes précédents
    2e bloc: 0xC4, 0x01, 0x88, 0x03, 0x1B: le 5e octet 0x1B étant le crc/checksum des 4 bytes précédents
    3e bloc: 0xD3, 0xE1, 0xA7, 0x53, 0x53: le 5e octet 0x53 étant le crc/checksum des 4 bytes précédents
    Voilà comment nous avons extrait les motifs afin de servir de vecteur de test pour tenter de déterminer l'algorithme de calcul de ce CR8 ou checksum.

Désolé d'avoir été aussi long, mais JR/Graupner n'ont pas fait dans la simplicité.
DecodageSpcmGraupner.pdf (1.0 MB)

BOnjour

x53 étant le crc/checksum des 4 bytes précédents

CRC ou Checksum, le précision est importante, le message initial n'envisageait pas l'hypothèse CRC .... qui ajoute un peu de piment....

Dans le document, dès que l'on entre dans le chapitre "Logical Frame" on parle en quintet pas en octets.
On lit

There are four 10-bit Control Fields. Each one controls the six quintets preceding it.

Donc pour le début de la trame, le champs de contrôle repéré A est composé de 2 quintets et il "contrôle" les 6 quintets qui le précèdent.
Du coup le mot de contrôle ne prend peut-être pas en compte des octets mais des quintets.

Pour le contrôle ils disent

The lower eight bits of every control field (A,B,C,D) is used for error detection in the respective preceding 32 bits

avez vous tenu compte du mapping entre valeur du Quintet et Octet correspondant dans la transcription donnée au premier post ?

Oui, les champs de contrôle A, B, C et D font bien 10 bits, mais d'après la doc, ils sont organisés comme suit:

bit9-bit8: Its two most significant bits, bits 9 & 8, control the meaning of the two auxiliary channel data fields preceding the control field
bit7-bit0: The lower eight bits of every control field (A,B,C,D) is used for error detection in the respective preceding 32 bits.

Nous interprétons donc la doc comme suit:
les champs de contrôle A, B, C et D "contrôlent" ce qui lui précède en:

  1. donnant la signification des 2 champs AUX (les 2 bits bit9-bit8)
  2. en associant aux 32 bits précédents (les 6 1er quintets + les 2 bits 9 et 8 du 1er quintet du champ de contrôle) un algo de contrôle sur le 8 bits qui serait un crc/checksum

Seuls les 8 bits de poids faibles sont utilisés pour l'error detection (donc un octet et pas un ni deux quintets).
Les 32 bits précédents peuvent donc être vus comme des 4 octets (incluant les bit9 et bit8 du champ de contrôle).
Même si il s'agit de quintets, on peut les grouper en octets, cela facilite les manipulations, typiquement pour un calcul de CRC/checksum.
8 quintets, ça fait 40 bits et 5 octets, ça fait toujours 40 bits (sans que les bits aient changés), ce n'est qu'une question de groupement/organisation.
Actuellement, nous ne savons pas si ces derniers 8 bits de droite représentent un CRC ou un checksum, ou peut⁻être même, une autre manipulation savante?

Voilà pour notre interprétation.

et pour le mapping de la table 1 ?

vous dites avoir décodé
0x83, 0xFB, 0xC8, 0x03, 0xC1
mais était-ce le contenu de la trame physique
10000 01111 11101 11100 10000 00000 11110 00001
et vous n'êtes pas passé à la la trame logique ?

EDIT: je vois sur votre dessin que vous avez le contraire, d'un octet vous retirez le quintet. à la lecture de la doc ça semble logique en effet

le doc que vous avez posté semble être le résultat des travaux dont fancyfly (Michel Kuenemann sans doute) avec Shaul Eizikovich parle dans ce blog

avez vous essayé de les contacter par ce forum ?

le secret du CRC a l'air bien gardé

Certainement pas.
Réfléchis, un checksum tout bête (une simple somme modulo 256 par exemple) ne donnera pas le même résultat si tu additionnes les quintets ou les octets.

Je les ai contacté tous les deux en premier avant de poster ici.
Shaul Eizikovich qui est le créateur de SmartPropoPlus nous a répondu qu'il n'a pas eu besoin de décoder le checksum car il n'avait besoin que de la valeur des canaux en provenance de la radio.
Nous, on fait le contraire, on veux créer un vrai signal S-PCM qui puisse être reconnu par le récepteur Graupner.

Extrait du PDF DecodageSpcmGraupner.pdf:


On est parti d'une capture (à l'analyseur logique) de la vraie trame physique (signal de modulation d'un émetteur SPCM Graupner).
La trame physique, c'est le signal D0 ci-dessus qui transporte le train binaire.
Le codage est le suivant: après chaque transition, on a un 1 suivi d'un certain nombre de 0

Le premier 1, juste après l'impulsion de synchro, est ignoré: c'est à partir de là qu'il faut commencer à compter les groupes de 8 bits (octets)
Quand on a 8 bits, on a un octet. :slight_smile: Ex: Octet0, Octet1, etc...
A partir de la Table 1, connaissant l'octet sur la ligne, on en déduit le quintet (de 00000 à 11111): c'est cette étape qui permet d'arriver à la trame logique à partir de la trame physique.
Une fois qu'on a 32 quintets, on a la trame logique entière. Mais dès qu'on a 8 quintets, on a le premier des 4 blocs qui compose la trame.

Les 8 premiers quintets sont: (40 bits)
`10000 01111 11101 11100 10000 00000 11110 00001

`En "collant" ces quintets, on obtient: (les mêmes 40 bits)

1000001111111011110010000000001111000001

En les groupant en paquets de 8, on obtient: (les mêmes 40 bits)
10000011 11111011 11001000 00000011 11000001 0x83 0xFB 0xC8 0x03 0XC1
On retrouve donc nos 8 bits de droite (0xC1) qui représente le crc/checksum des 32 bits précédents qui sont 0xB3, 0xFB, 0xC8, 0x03.
Ces 5 octets (0xB3, 0xFB, 0xC8, 0x03 et 0xC1) représentent donc bien (le premier bloc de) la trame logique.

Oui, c'est bien le doc de Shaul Eizikovich. Mais, lui, il voulait simplement récupérer les voies RC d'un signal PCM injecté dans la carte son d'un PC pour jouer au simulateur d'avion depuis un émetteur RC physique. Son projet s'appelle SmartPropoPlus. C'est lui, plus les personnes qu'il cite dans le PDF JR_GraupnerSPCM(1).pdf qui ont fait le reverse engineering du protocole. Mais lui, il n'avait pas besoin de connaître l'algo du crc/checksum car la liaison étant courte, il y a avit très peu de rique d'erreur. Par contre, nous, nous devons impérativement positionner correctement ce champ parce que c'est pour créer le modulateur PCM d'émission pour notre projet opensource d'émetteur RC (OpenAVRc) pour pouvoir utiliser un réécepteur RC Graupner, qui lui, va vérifier l'intégrité des trames reçues.

Nous avons évidemment contacté Shaul, mais comme on s'en doutait, il nous a répondu qu'il ignorait tout simplement ce champ car dans son cas d'usage il peut s'en passer.

@fdufnews:

[quote]Certainement pas.
Réfléchis, un checksum tout bête (une simple somme modulo 256 par exemple) ne donnera pas le même résultat si tu additionnes les quintets ou les octets.[/quote]
Entièrement d'accord, mais, le résultat est sur 8 bits et est une opération sur les 32 bits précédents. On ne sait pas si l'opération est faite sur des octets, des quartets, mais on est quasi sûr que ce n'est pas fait sur des quintets: 32 bits n'est pas modulo 5.