Génération de code pour DSP sur USRP.

Salut les brigolos!

Je suis sur un problème assez poilu en ce moment, je fait du traitement de signal pour démoduler des trames ADS-B venant d'avions en plein vol avec un USRP (radio digitale dans le genre bien balèze)
Seulement j'utilise matlab/simulink et doit porter tout le fatras (qui fonctionne très bien) en code C/C++ pour déployer le système sur un micro-ordinateur type raspberry-pi
Heureusement il y a un générateur de code pour matlab
Mais pas de bol, le code généré ne compile pas et est truffé d'erreurs.

Alors voici une petite question: avez-vous déja bossé avec du code généré par un soft? Et dans ce cas là, en cas de bug, comment est-ce qu'on décide par ou attaquer le problème? On débuggue le code C généré ? Ou alors on reformule et nettoie le code de base?
Je suis complètement nouveau au procédé alors c'est pas encore tout à fait clair pour moi...

Et tant que j'y suis, je vais avoir l'USRP sous la main pendant les 2 prochains mois alors je suis en quète de bonnes idées de trucs à tester
Pour faire simple, l'engin fait la taille d'une carte de crédit et coute 600 balles.
Capable de générer et receptionner (full duplex) des signaux entre 70 et 6000MHz sur une bande de 56MHz :3
Il n'y a pas beaucoup de puissance sur le canal de transmission, par contre le récepteur est ultra-sensible
Mais une petite idée me trotte dans la tête, c'est à base de https://en.wikipedia.org/wiki/Rolling_code et de me clefs de voiture, curieux de savoir la difficulté d'un tel bazar.

Toi tu m'intéresses avec l'ADS-B :D T'as vu la conf de la defcon ou c'est pour totalement autre chose ?

Code généré = gros caca en général...

Sans connaitre le but final c'est dur de donner des conseils étant donné qu'il y a peut-être une meilleure solution au pb.

Oui, j'ai vu cette conf ^^, a vrai dire l'année suivante il y a eu une réponse à DEFCON d'un ingé qualifié dans le domaine et il disait tout simplement que les conséquences décrites par le hacker étaient sur-évaluées, les avions utilisent des systèmes de fusion de données qui permettent de rejeter les erreurs avec une efficacité monstrueuse. Au final le pilote a toujours la main.
J'ai pas vraiment envie de m'attarder sur de l'émission, même si je vais en parler dans le rapport que je rends avec le projet, c'est que c'est sacrément illégal ^^'.
Mais si quelqu'un de plus fou que moi veut s'y attarder, la modulation est hyper simple, c'est juste de la PPM (pulse position modulation) avec un codage winchester (un front sur deux est codant), le tout à une vitesse de 2MHz.

Mais je ne fait que du décodage de l'ads-b, je démodule, détecte l'arrivée des trains de données, en décode le contenu et stocke le tout dans un fichier
Mais j'ai bien l'impression que mon code a du mal avec la gestion des fichiers, va falloir que je revoie cela.
Je me doute bien que le code généré c'est pas de la grosse qualité, mais je n'ai plus le temps de recoder tout le système.

C'était juste une question généraliste sur le code généré et les méthodes pour l'utiliser: C'est un truc que je n'ai jamais fait donc je suis un peu en train d'avancer à tâtons

Chez Boeing peut-être mais chez Airbus j'ai comme un doute...

Yep, l'émission est totalement interdite.

Donc du coup pourquoi tu ne fais pas comme le mec de la conf en prenant un soft de SDR pour faire la démod ?

Les actions des pilotes désactivent toujours le pilote auto
Aussi, la gestion d'évitement des collisions se fait à plusieurs niveaux avec des alarmes plusieurs minutes avant la collision probable
Enfin, habituellement ce sont les controlleurs aériens qui s'occupent de faire faire des corrections: les radars primaires et les plans de vols sont les premières choses utilisées pour éviter les collisions au dessus des zones continentales.

C'est parceque je suis encore en milieu universitaire que j'utilise Matlab, sinon je sait bien que les packages comme air-modes- sur gnu radio sont bien le job
Et puis on me demande de connecter le récepteur à une base de donnée pour y stocker des données sélectionnées.
C'est un projet un peu velu...

Justement, ils comptent virer les radars primaires (entre autres) car trop coûteux et "inutiles" une fois l'ADS-B généralisé...

Le truc c'est surtout que c'est un protocole sans authentification ni chiffrement ce qui veut dire que tu peux à peu près tout faire depuis ton salon... genre générer un ou deux millions d'avions fictifs par exemple, comment tu crois que les contrôleurs réagiraient à un tel problème ? la réponse: ils ne pourraient pas faire grand chose... Le truc c'est que les failles sont quasiment infinies, c'est pas juste un pb qui concerne les collisions d'un avion.

Oui ben dans ce cas c'est un peu toi qui a choisi la méthode compliquée (ce qui est relativement stupide quand un outil adapté et fonctionnant correctement existe déjà...) et vu que je connais Matlab seulement de nom (et de réputation: une usine à gaz) je ne risque pas de pouvoir aider malheureusement. T'as regardé si y'a un forum dédié ?

Non, le radar primaire ne sera jamais supprimé car il est la seule manière de faire de la détection d'engin qui refuse de cooperer.
Les radars secondaires peuvent peut etre etre supprimés car ils sont basés sur les transpondeurs et nécessitent la coopération des avions. Avec un ADS-B appliqué sur tous les avions et un réseau solide ce sont les radars secondaires qui peuvent etre supprimés.

Le protocole est non crypté en effet mais les controleurs ont encore accès aux bases de données de plans de vol ainsi qu'aux radars primaires et secondaires.
Autant, les primaires n'offrent pas une solution de repli à grande échelle
Les secondaires tant qu'ils sont là offrent une meilleure sécurité

La multilateration(MLAT) peut aussi etre utilisée pour améliorer l'ADS-B et ca augmente nettement les besoins technologiques pour le spoofer. Mais c'est une solution qui nécessite plusieurs récepteurs.

Après, en ce moment tu peut avoir du wifi haut débit dans presque tous les avions long-courier et les jets privés qui sortent des chaines d'assemblage. Je pense pas qu'il faudra attendre longtemps avant que les avions n'échangent en crypté via satellite et via les réseaux au sol.

Au final un avion moderne c'est un systeme qui a une quantité massive de capteurs redondants avec pour couronner le tout un pilote redondant. Le protocole ADS-B a été crée exprès pour etre cheap et pouvoir etre installé sur tous les aeronefs (la documentation autorise même les véhicules au sol ou les obstacles comme les grues, ballons, immeubles, ... à etre marqués). Lorsque un système d'avionique utilise l'ADS-B il évalue lui-même la fiabilité de l'info en recoupant avec les autres systèmes. Si le système a sa capacité diminuée il va même aller alerter le pilote et peut se désactiver. C'est la même chose pour les signaux GPS, tu peut avoir une évaluation de la précision en temps réel.

Donc si un petit malin fait apparaitre un avion (ou 200) dans la proximité d'un autre, la première chose que les pilotes vont faire c'est checker leurs systèmes. Les premières alertes tombent toujours quelques minutes avant le danger. Ca laisse le temps de demander confirmation aux ATC de la zone qui ont a disposition les radars primaires, transpondeurs et autres.

Voila la réponse à defcon dont je parlais
https://www.youtube.com/watch?v=Uy3nXXZgqmg

Pour ce qui est des forums dédiés... Il n'y a presque rien

Il parlait clairement des radars primaires mais il faudrait que je revois la conf pour voir la source de l'info (un papier officiel probablement).

Le pb n'est pas technologique, il est dans la spec du protocole. Si elle dit qu'il n'est pas chiffré alors il ne sera pas chiffré puisqu'il est implémenté selon la spec... Et le plus gros pb est surtout qu'il n'y a pas d'authentification donc n'importe qui peut se faire passer pour n'importe qui.

Antot a écrit:

Au final un avion moderne c'est un systeme qui a une quantité massive de capteurs redondants avec pour couronner le tout un pilote redondant. Le protocole ADS-B a été crée exprès pour etre cheap et pouvoir etre installé sur tous les aeronefs (la documentation autorise même les véhicules au sol ou les obstacles comme les grues, ballons, immeubles, ... à etre marqués). Lorsque un système d'avionique utilise l'ADS-B il évalue lui-même la fiabilité de l'info en recoupant avec les autres systèmes. Si le système a sa capacité diminuée il va même aller alerter le pilote et peut se désactiver. C'est la même chose pour les signaux GPS, tu peut avoir une évaluation de la précision en temps réel.

Ca me semble légèrement optimiste et perso en matière de sécurité je préfère être pessimiste parce que sinon la loi de Murphy se charge de te rappeler la réalité vite fait bien fait en général...

Ok, je regarderais ça dès que j'ai le temps

Matlab n'a pas de forum ? et t'as essayé stackoverflow ?

Les radars primaires ne seront jamais retiré, si ils le sont ce serait une très très grave erreur.
Je pense que tu confond avec les radars secondaires, ADS-B en est une sorte d'amélioration, automatique et indépendante.

Quand tu aura eu le temps de voir la vidéo que je t'ai envoyé, tu verra bien pourquoi ce n'est pas un problème que ces protocoles ne soient pas cryptés.
C'est parce qu'ils ne sont pas utilisés comme outils de décisions directement par les ATC et les vols commerciaux. ADS-C (C pour "contract") est une alternative payante qui utilise des canaux cryptés et sont utilisés par les opérateurs pour les besoin opérationnels (maintenance, administration, ...)

Il faut retenir qu'il y a deux ADS-B différents. ADS-B In et Out. ADS-B out va bientôt etre obligatoire pour un très grand nombre d'avions. En gros, ceux équipés vont tout simplement émettre leur propres info sans se soucier de quoi que ce soit d'autre.
Au contraire, l'ADS-B In est nettement moins fréquemment équipé et ne sera pas obligatoire pour un grand nombre d'engins. Par exemple, j'ai pu faire de la voltige il y a quelques mois, l'avion dans lequel j'était était équipé en ADS-B out de manière native (équipement embarqué qui est inclus avec la certification de l'avion -> il ne vole pas sans). Il y avais aussi un ADS-B In qui n'était pas dans la certification et était juste un tout petit appareil attaché avec du velcro au dessus du panneau(c'est trop cher pour acheter du matos certifié et de refaire passer la certif, alors que l'attacher de manière non fixe ne change pas la certif de l'avion ^^) Le machin était une interface minime qui affichait avec une info d'azimuth approximative les avions en approche.

Dans l'industrie aéronautique c'est pas ce qui manque les précautions, Murphy lui-même était ingénieur dans l'aerospatiale

Matlab a un forum qui est presque illisible, je crains de ne pas avoir de réponse la dessus, tout comme stackoverflow. Je vais certainement me contenter de la ML de Ettus-Research car elle semble peuplée d'une belle bande de nerds qui sera certainement amusé et interessé par ce genre de trucs que personne n'a trop essayé

Edit: pas mal ce machin
http://aviation.stackexchange.com/questions/15786/how-can-ads-b-replace-primary-radar-when-flightradar24-using-ads-b-is-so-inacc