Projet ADS-B: Vérification des CRC

J'ai implémenté le calcul des codes de contrôle transmis dans les champs AP ou PI des trames DF11 et DF17 pour lesquelles les polynômes générateurs sont disponibles dans la littérature, en particulier dans les documents publiés par Eurocontrol.

Après quelques minutes d'acquisition, les compteurs embarqués dans le code permettent d'avoir une bonne idée de la qualité de la réception:

Heure	Framing error	Received	CRC OK	DF17
19:06TU	890	983	328	124
19:10TU	3664	3802	1371	515
19:12TU	5994	6132	2318	823
19:14TU	9219	9563	3655	1286
19:20TU	16350	17474	6779	2428

On en retiendra que:
- 50% des trames ne passent pas le test du décodage Manchester,
- 66% des trames ont un code contrôle erroné (Cf  Note de fin de page).

Et ceci de manière assez constante, le réglage du seuil de détection ne semblant pas influencer outre-mesure le taux d'erreur sur les CRC. Sur les trames courtes, l'erreur apparaît être dans les derniers bits du champ du contrôle comme on peut le voir ci-dessous sur la copie d'écran de mon application de validation:


Il s'agit probablement d'un nouveau problème d'échantillonnage - le code a été modifié depuis la première optimisation - problème qu'il va falloir confirmer en déclenchant au bon moment l'analyseur logique. Cela demande du temps et l'instrumentation du code. J'attaquerai donc cette validation après finalisé les développements.
La version 0.3 du code assure:
- l'acquisition de toutes les trames ADS-B
- la vérification des CRC des trames DF11 et DF17
- la retransmission sur une liaison série à 115200bds
   - de toutes les trames, ou uniquement des trames DF17
   - de toutes les trames, ou uniquement de celles ayant un CRC correct
- la gestion du contrôle de flux de la liaison série en XON/XOFF
- le maintien de 5 compteurs d'état:
   - Nombre d'erreurs de framing
   - Nombre de trames reçues
   - Nombre de trames CRC OK
   - Nombre de trames DF17
   - Nombre de trames perdues durant un XOFF
- la retransmission sur demande de ces compteurs.

Nota: La relecture d'une spécification de l'ICAO me laisse à penser que j'ai mal interprété le paragraphe consacré à la génération des champs AP ou PI. J'ai ainsi considéré à tort que les informations CL et IC étaient systématiquement positionnées à 0 dans toutes les réponses. Il apparait que cela n'est vrai que dans le cas d'une réponse à certaines requêtes spécifiques. Dans tous les autres cas, les informations CL et IC sont acquises dans la requête et réintégrées dans le calcul de la valeur de contrôle.
N'ayant pas la connaissance de ces valeurs, il apparaît impossible de vérifier l'intégrité des trames reçues. Cependant, la faible taille de ces deux champs (3bits et 4bits) au regard de celle de la somme de contrôle (24bits) doit permettre d'effectuer malgré un filtrage intéressant en rejetant des trames à coup sûr erronées. Il suffit pour cela de calculer la somme exclusive de la valeur reçue avec celle calculée, et de rejeter toutes les trames pour lesquelles le résultat sera supérieur à la valeur maximale pouvant être encodée par ces deux champs, soit 7F (ou 127 en décimal) et non pas simplement égal à 0 comme je l'ai implémenté. Cette erreur explique le constat précédent portant sur le fait que les bits erronés se situent en fin du champs de contrôle le reste de la trame étant cohérent.