dimanche 3 mai 2015

GPS en balade

Un Raspberry Pi, une interface USB-série_TTL_3.3v_FTDI et un module GY-GPS6mv2 alimentés par un 'powerpack'.

Si on enregistre pendant un peu plus d'une demi-heure la position GPS sans le déplacer, la position rapportée varie :
Le GPS est posé sur un mur entre deux maisons. La vue est plus dégagée en est-ouest qu'en nord-sud. Le GPS semble, en effet avoir plus de mal à déterminer la latitude.

Dans un endroit plus dégagé :
La précision nord-sud est améliorée.

Le module donne toute une série de lignes NMEA toutes les secondes à 9600 bps (8N1). La latitude apparaît sous la forme DDMM.yyyyy et la longitude sous la forme DDDMM.xxxxx ('D' pour degré; 'M' pour minute; xxxxx & yyyyy sont des décimales de minutes). Ces coordonnées sont extraites des lignes GPGGA. La traduction en mètres est approximative : 40 000 km/360°; un offset est soustrait pour rendre la lecture plus aisée.

Si on s'intéresse à l'évolution de l'altitude, on obtient le graphe suivant :
On s'aperçoit également que les variations sont moins grandes lorsque la vue sur le ciel est plus dégagée.

La suite des mesures n'est pas la position réelle plus quelque chose d'aléatoire comme on aurait pu s'y attendre si les positions avaient été calculées indépendamment. On a affaire soit à une précision diabolique à la merci d'un phénomène physique continu non maîtrisé, soit, plus vraisemblablement, à un filtrage du genre xn+1 = αX + (1-α)xn (?).

Il faudrait regarder les autres informations (comme le HDOP), étudier l'évolution à plus long terme, essayer de déterminer la position moyenne par les moindres carrés, regarder si elle converge et si elle est stable dans le temps. Les graphes semblent déjà dire qu'il ne suffit pas de faire la moyenne sur cinq minutes pour avoir une meilleure précision. C'est plus complexe que cela...

Avec deux GPS

Une question que l'on pourrait se poser est de savoir si deux modules GPS posés l'un à côté de l'autre se baladent de la même manière... On s'approcherait d'un GPS différentiel à peu de frais. Cela serait plus ou moins le cas si les variations de la vitesse de propagation des signaux était dominante. Mais, il semble que non : les deux GPS se baladent indépendamment :
Une trace en vert, l'autre en rouge...

La différence entre les deux positions n'est pas meilleure que les positions individuelles.

À noter que l'on trouve pas mal de documentation sur ces modules :

dimanche 18 janvier 2015

AIS rtl_sdr frequency correction

La fréquence des quartz des clés TNT/USB bon marché varie d'une clé à l'autre. Cela semble poser problème pour certaines applications. Ce lien en discute pour gr-ais (de manière générale). Le paramètre 'e' de gr-ais permet de corriger la fréquence. Le gif animé (alternance de 3 secondes) suivant compare les spectres obtenus par gnuradio-companion avec deux clés différentes.
Spectres obtenus en quelques minutes dans le port des Yachts à Liège (seul SPN06 émet). ("<clic-droit> -> afficher l'image" permet de la voir en entier)

On peut voir un message dans le canal A dans chaque 'waterfall'. Les lignes vertes dans les spectres montre les maxima atteint au cours de quelques minutes. En principe, les messages sont transmis plus ou moins alternativement sur le canal A (161.975 MHz) et sur le canal B (162.025 MHz). Les messages sont courts (une trentaine de millisecondes), c'est pour cela qu'ils apparaissent sous la forme d'une simple ligne dans le 'waterfall'. La largeur d'un canal provient d'une modulation GMSK à 9600 bauds. La fréquence d'échantillonnage est de 249600 (9600*26) Hertz et le tuner est réglé sur 162 MHz; le spectre affiché couvre donc 162 MHz +/- 249.6/2 KHz (161.8752 - 162.1248 MHz). Le choix de 9600*26 est arbitraire; c'était pour avoir un nombre entier d'échantillons par bit (?).

Voir aussi

jeudi 13 novembre 2014

FGM-3

Continuant sur la lancée d'Aurora detector, j'ai fait l'acquisition d'un petit magnétomètre 'fluxgate' FGM-3 (pour environ 40 euros tout compris)...
Un premier essais avec une pile. À noter que sur la photo, la terre du 'logic analyser' est dessinée... C'est aussi une mauvaise idée d'utiliser des piles sans régulateur; la tension varie et la période du signal dérive... Avec une batterie 12 volts et un régulateur 78L05, cela fonctionne beaucoup mieux. Le constructeur recommande d'utiliser un 78L05 en cascade avec un 78L09.

Le bidule, grand comme une pile AA, comporte 4 broches (mais je n'en utilise que 3). Il suffit de l'alimenter en 5 volts et un signal rectangulaire dont la période dépend du champ magnétique sort sur une troisième broche. La documentation annonce une période relativement linéaire entre 8 µS et 20 µS dans le champ magnétique terrestre (-.5 gauss à +.5 gauss) suivant l'orientation du capteur.
Forme du signal quand le capteur est orienté est-ouest (Pulseview avec sigrok dans le clone Saleae à 24 MHz)

Plusieurs options existent pour mesurer cette période. On peut mesurer la fréquence en comptant le nombre de cycles pendant une période donnée, par exemple, une seconde. Elle varie donc entre 125 KHz et 50 KHz. C'est l'option choisie ici avec un Arduino (pendant 5 secondes). On peut aussi mesurer la période si on dispose d'un compteur suffisamment rapide... Après, c'est une question de compromis entre la finesse de la mesure et le temps d'acquisition. Comme je disposais d'un clone Saleae, j'ai décidé de mesurer le temps pris par un certain nombre de cycles.
Enregistrement brut du 12 novembre 2014. NanoTesla à partir du nombres de ticks à 4 MHz pour 25000 flancs descendants. Les barres verticales correspondent à des entrées/sorties de voitures dans le passage latéral. Il y a un certain bruit de fond et une perturbation entre 13 et 22 heures. Pourquoi est-ce aussi stable et à quoi est due cette perturbation? Il va falloir faire des mesures durant plusieurs jours pour essayer de le comprendre. L'idéal serait de disposer d'une mesure officielle pas trop éloignée pour pouvoir comparer.

De telles mesures sont disponibles sur le site Intermagnet (sous forme graphique et sous forme chiffrée). Les mesures les plus proches sont probablement celles de Dourbes (~100 km, code 'DOU'). Cela varie, de fait, continuellement et les données sont filtrées. La manière dont sont prises les données est documentée. Il est à noter que les courbes disponibles sont généralement non corrélées et que mes mesures en génèrent peut-être une autre encore...

En rapprochant la génération du 5 Volts du FGM-3 et en le faisant de la manière recommandée (avec un 78L09 suivi d'un 78L05 et 3 condensateurs) les zones de stabilités ont tendance à disparaître. Cela donne, après filtrage, quelque chose comme :
...Ce qui ne correspond pas vraiment à ce qu'ils ont mesuré à Dourbes.... Et, ce qui chipote aussi, c'est que l'amplitude est plus grande ici. Y aurait-il une erreur dans la formule de conversion ticks->Tesla?

Une manière d'évacuer ce doute est de mettre le FGM-3 dans un champ connu (ou, plus exactement, faire varier le champ de manière connue). Un bon moyen pour le faire est de mettre le détecteur au centre de bobines de Helmoltz... Aussitôt dit, aussitôt fait.
Deux fois dix tours sur un morceau de bouteille en plastique de 2 litres (R = ~0.05 m), une source de 5 Volts avec une résistance de ~ 2.5 KOhm (ce qui donne un courant de 2 mA) est sensé me donner un champ de 360 nT... Alors que la déviation d'une boussole est imperceptible (la modification du champ est inférieure au % du champ terrestre), la variation est clairement visible sur un graphe.
Le 'stuut' c'est que ma formule de conversion donne une variation de 40 nT... Ha-là-là... (alors que j'aurais voulu diviser la mesure par 10, voilà maintenant que je dois la multiplier par 10; ça ne s'arrange pas, il va falloir revoir les calculs...; Il faudrait aussi faire un essai à l'extérieur, en pleine nature, loin des perturbations potentielles)

Des mesures 'scientifiques' en temps réel sont disponibles sur http://InterMagnet.org ([données] et la documentation dans [publications]). À suivre...

vendredi 26 septembre 2014

Aurora detector

En cours de rédaction...

En cherchant sur Internet 'Aurora detector', on tombe en premier sur le 'Pop-bottle detector' proposé par l'AuroraWatch UK de l'université de Lancaster; aussi connu sous le nom de 'jam-jar magnetometer'. Un aimant pendu à un fil dans une bouteille ou un pot de confiture se déplace au gré des fluctuations du champ magnétique ambiant. Les aurores étant liées aux perturbations du champ magnétique terrestre par le vent solaire, on essaye de détecter celles-ci au moyen de ce magnétomètre 'maison'. Ces perturbations étant faibles en Belgique, il convient d'amplifier le 'signal' pour en faciliter la mesure. Traditionnellement, on colle un petit miroir sur l'aimant, on l'éclaire par une source plus ou moins ponctuelle et on s'intéresse au 'spot' lumineux réfléchi sur un mur (un dixième de degré de rotation se traduit par un déplacement du spot de près d'un centimètre et demi à quatre mètres (4*tg(2*.1)=1.01396 (à vérifier...)). Le dispositif a la réputation d'être très sensible malgré sa simplicité : avec un fort aimant et un fin fil, on détecte le mouvement de voitures à plusieurs dizaines de mètres.

C'est amusant mais ce n'est pas très pratique. Il faudrait encore détecter les mouvement du spot lumineux pour l'enregistrer, générer une alarme, que sais-je encore... On trouve maintenant de petits magnétomètres dans les téléphones portables, les boussoles électroniques, les GPS,... On peut même acheter des kits comprenant le HMC5883L pour un peu plus d'un euro sur eBay (GY-271). Il s'interface facilement avec un Arduino ou un Raspberry Pi, les trois petits magnétomètres X-Y-Z fournissent leurs mesures sur 12 bits sur un bus i²c. Rien n'est plus simple à interfacer : 4 fils, quelques lignes de code et nous voilà avec un magnétomètres mesurant jusqu'à 8 gauss avec une résolution de 2 milligauss. Est-ce suffisant pour 'détecter les aurores'? Pas sûr. Le champ magnétique terrestre fait 500 mG... (il faudrait tester sans l'aimant et trouver des références expliquant que les perturbations peuvent atteindre 10% (où?))

Par contre, un truc amusant, c'est de placer ce détecteur dans le champ de l'aimant pendu au fil dans le bocal... L'idée, c'est que l'aimant va prendre sa place dans le champ ambiant tout en générant un champ beaucoup plus puissant et donc plus facile à mesurer. En fait, on s'intéresse à la variation du champ suite au déplacement infime de l'aimant (et on espère que ces variations seront facilement mesurables)...

Avec des aimants de disque dur, cela donne quelque chose comme :
Si on s'intéresse au spectre du signal avec GNU Octave (plotspec.m),
on trouve une oscillation de 4-5 secondes. Cela doit correspondre à l'oscillation naturelle de l'aimant au bout du fil. Sa période dépend du moment d'inertie de l'aimant et des forces de rappel qu'exercent le fil et l'interaction des champs magnétiques. Si on zoome sur le graphique, on observe bien les oscillations.
Dans ce cas-ci, je prends (environ) deux mesures par seconde. La fréquence d'échantillonnage n'est pas exactement 2 Hz parce que l'interrogation boucle dans un script qui relance chaque fois le programme... Pour l'instant, ce n'est pas très important, c'est donc 'bon assez'. À noter que cette technique de mesure a certaines conséquences : on ne mesure pas le champs instantané, on ne risque pas de louper une brève perturbation pour autant qu'elle ait un effet sur le pendule qui réagit comme une balançoire : on peut pousser dans le sens du mouvement ou à contre-temps. Ensuite, on a tout le temps pour prendre la mesure, le bidule oscille autour du champ non perturbé (-> balance de pharmacien; on n'attend pas que l'oscillation s'arrête, on la centre (?)).

Si on analyse le résultat global, sur ces 10 premières heures, je ne détecte pas vraiment d'aurores mais beaucoup de perturbations locales : fortes, des passages de voitures vers/de l'arrière de l'immeuble pendant les heures de bureaux et moyennes, les véhicules qui passent dans la rue; cela se calme en soirée; c'est encore plus calme pendant la nuit et reprend le matin. À noter que ces voitures passent d'ouest en est dans la rue et (principalement) du nord au sud le matin et du sud au nord à 17 heures dans le passage latéral (où les camions, bus,... ne peuvent pas passer).

On note quand même une tendance à la baisse. Mais, on ne peut pas vraiment savoir si c'est le fil qui s'allonge sous la fatigue, une modification de l'hygrométrie, de la température ou un autre phénomène. Il faut aussi noter que le bidule est sur la table du salon au milieu de la pièce et que les pas sur le plancher laissent probablement également leur empreinte. On note également que l'oscillation est amortie mais c'est très lent, il est très rare qu'elle s'amortisse suffisamment pour noyer le signal dans le bruit du capteur avant qu'une nouvelle perturbation du champ ne vienne remettre l'aimant en mouvement. Il faut encore apprendre à connaître, apprivoiser le dispositif...

D'où l'intérêt de lancer une plus longue campagne de mesure...
Elle court pendant une semaine et un jour (du 23 septembre à 15:37 jusqu'au 30 septembre mi-journée + un jour sans bocal). La présence de l'aimant dans le bocal amplifie bien le signal (XYZ devient quasi plat quand on retire le bocal, il n'y a pas une simple modification de la direction; à noter que les autres directions saturaient avec l'aimant). On observe les entrées/sorties de voitures dans le passage latéral (une vingtaine (?) de voitures chaque fois). Le reste, c'est du trafic dans la rue (il faudrait que je me procure un horaire des bus...). Notez que le 27 est un samedi et qu'il n'y a pas d'entrées massives vers les bureaux dans le passage latéral. Mais, ce que l'on observe aussi, c'est une variation de grande ampleur. En fait, pour le moment, SpaceWeather montre des aurores. Le NOAA NOAA's Space Weather Prediction Center affiche
Le graphe ne redescend pas, cela semble dû au vieillissement de quelque chose qui se laisse aller (?)... (Entre-temps, je pourrais vérifier que la fréquence d'oscillation est restée constante, ce qui aurait tendance à indiquer que ce n'est pas lié au fil mais c'est vrai qu'un changement dans l'intensité du champ va aussi provoquer une modification de la fréquence...).

Quand la nuit est calme, on peut observer l'amortissement des oscillations. Cela met vraiment très longtemps. Après une perturbation à 03h17 le 28/09, on peut toujours percevoir les oscillations 40 minutes plus tard (?) (sans que l'on puisse percevoir d'autres perturbations).
En fait, c'est la méthode utilisée lors des premières études du magnétisme terrestre à la fin du XVIII-ième siècle. Notamment par Robert de Lamanon lors de l'expédition de La Pérouse. La force du champ magnétique dépend de la latitude. Cela se traduit par des oscillations plus lentes à l'Équateur qu'aux latitudes plus élevées. Y-a-t-il bien un lien entre la déviation et l'apparition d'aurores? Il semble que oui. Par exemple, lors de l'aurore du 21 octobre 2001, en Belgique, on peut observer une déviation à l'observatoire de Chambon-la-Forêt et à Wingst (pas de mesures à Dourbes (plus proche) à cette époque). Ces déviations sont rares, très rares, exceptionnelles à nos latitudes, d'ordinaire, c'est le calme plat.

En empilant un tas de petits cylindres au néodium et en le pendant à une fibre extraite d'un lacet, on peut observer l'inclinaison magnétique. L'inertie du bareau étant plus importante, la période d'oscillation augmente quand on l'allonge.

À suivre...

Parmi les trucs à regarder de près, la géométrie de l'aimant, le type et la longueur du fil, la position du capteur pour maximiser la dynamique en fonction du mouvement (mais sans saturer). À noter que si on plonge l'aimant dans un bain d'huile, l'amortissement des oscillations est radical mais la sensibilité disparaît également. Évaluer (par calcul quand j'aurai un aimant plus orthodoxe) le moment d'inertie et les forces de rappel (par mesure des périodes avec des barreaux similaires (aimanté et non aimanté).

Bref, plein de trucs intéressants à faire pour quelques euros... ;-)

lundi 15 septembre 2014

Filtrons avec Octave

Chipotons un peu avec GNU Octave (MATLAB)... Je m'étais intéressé, il y a quelques mois à la détection des signaux faisant basculer les compteurs électriques bihoraires au moyen d'un simple fil sur le connecteur microphone d'un PC. Je vais utiliser un bout de fichier pour faire du 'traitement de signal' (filtrage numérique).
$ echo 'date "+%g%m%d.%H%M%S"' > now; chmod +x now
$ arecord -f S16_LE -t raw -r 25000 > 25000.`./now`
$ dd if=25000.131204.064758 of=sample.raw bs=1000 count=5 skip=1
$ sox -r 25000 -e signed -b 16 -c 1 sample.raw sample.wav
Et dans Octave,
x = wavread('sample.wav');
y = x - mean(x);   # remove the DC component
plot(y)
print -dpng 'bzzz_50Hz.png'
donne
et
plotspec(y, 1/25000)
print -dpng '50Hz_spectrum.png'
donne
On voit (ou pourrait voir en zoomant avec le bouton de gauche de la souris) que la composante principale du spectre se trouve à +/- 50 Hz mais que l'on trouve des harmoniques avec une magnitude atteignant 10% de la composante principale. Ce n'est probablement pas la bonne manière de faire (?) mais le but est ici de jouer avec les fonctions de filtrage de MATLAB/GNU Octave. Par exemple, éliminons les harmoniques avec un FIR :
b = fir1(120, 0.0035);
z=filter(b, 1, y);
clf;
plotspec(z, 1/25000);
print -dpng 'spectrum_50Hz_filtered_FIR_120_0.0035.png'
donne
La réponse fréquentielle du filtre nous est donnée par :
clf;
freqz(b, 1, 512, 'half', 25000);
print -dpng 'filter_FIR_120_0.0035.png'
Essayons d'isoler l'harmonique à 250 Hz en concevant un FIR avec remez() (firpm() dans MATLAB. On spécifie la réponse fréquentielle approximative que l'on désire au moyen de deux vecteurs (fréquences/réponses) :
f = [0 0.03 0.04 1];
a = [0 1    0    0];
w = [1 1];
b = remez (120, f, a, w);
clf;
freqz(b, 1,512,'half',25000);
print -dpng 'remez.120_0-1-0-0_0-.03-.04-1_freq.png'
z=filter(b, 1, y);
clf;
plot(z);
hold on;
plot(y, 'r');
print -dpng 'remez.120_0-1-0-0_0-.03-.04-1_result.png'
donne
et
Le filtre n'est pas très sélectif mais le 250 Hz ressort bien (en bleu).


...En cours de rédaction / y-a un truc qui cloche...
Le 0.0035 passé à 'fir1()' est à comparer avec 50/(25000/2) ('fréquence normalisée'), on coupe un peu dans le 50Hz, cela aurait dû être supérieur à 0.004 (50/12500) (?). La pente du filtre n'est pas extraordinaire, on est à -10 dB à 250 Hz...

dimanche 20 juillet 2014

AIS

Dans le cadre des expérimentations rtl-sdr (radio logicielle avec clé TNT/DAB à moins de dix euros), une petite captation avec ais_rx.py sous Linux sur le terril Saint-Gilles à Cointe derrière le stade du Standard.  On a une belle vue sur la vallée de la Meuse vers Huy; au loin, on aperçoit les tours de refroidissement de la centrale nucléaire de Tihange.
Un quart d'heure de captation (sous lubuntu) a permis de recevoir environ 900 messages AIS de péniches entre Kinkempois et Amay.
En vert, la captation par un programme encore expérimental moins sensible mais beaucoup plus léger que ais_rx.py qui est basé sur GNU-Radio.  Il est possible d'envoyer les lignes NMEA dans OpenCPN.  On obtient alors quelque chose comme :
Mais, bien sûr, ce serait mieux avec une carte en fond...  Ici, c'était juste pour tester la cross-compilation vers XP (avec Mingw) et l'interface tcp avec OpenCPN.  On notera la présence de l'écluse d'Ivoz-Ramet au milieu de l'écran (?).

Plus tard, ailleurs...

En utilisant les cartes de OpenNauticalChart et en utilisant OpenCPN avec naive_ais, en mars, on obtient :

Il faut noter que la version de naive_ais manque terriblement de sensibilité à cette époque et ne capte qu'une partie des messages. La carte monte un agrégat de deux campagnes de captation. Une sur un terril qui n'avait réussi qu'à capter un bateau et l'autre, dans le port même (un peu trop près du bateau pompe-à-essence) qui ne les capte pas tous non plus...

Voir aussi



lundi 28 avril 2014

ADS-B sur piles

Liège-Bastogne-Liège 2014, le jour idéal pour tester dump1090 sur un Rasberry Pi (avec touchscreen) sur piles sur les hauteurs de Liège... Le but est de capter les messages ADS-B envoyés par les hélicoptères de la courses. L'équipement est simple : un pack de 6 piles rechargeables NiMH (ALDI/Top Craft), un petit convertisseur DC-DC pour ramener la tension à 5 volts, un Raspberry Pi, son touchscreen Tontec (MZTX-PI-EXT) et une petite clé USB TNT équipé du chip Realtek RTL2832U permettant le RTL-SDR avec son antenne d'origine (ou une de ses sœurs.


Dump1090 fonctionne dès le départ sur le Raspberry Pi.  Le problème était de rendre celui-ci portable pour aller capter les avions sur les hauteurs...  Pour cela, deux aspects : l'alimentation et le contrôle.  Pour le contrôle, l'idéal est un touchscreen.  Il y en avait un pas cher mais il n'était pas sûr que cela fonctionne.  Si l'affichage semblait ne poser aucun problème grâce à un article de ce blog , la partie 'touch' a nécessité quelques recherches et développements... Mais, donc, cela a fini par fonctionner.  Pour l'alimentation, le pack de six piles et le convertisseur DC-DC offre la solution idéale pour peu que l'on se contente d'une autonomie de quelques heures; le RPi et le touchscreen consomment 0.5A sous 5 volts (sans le dongle TNT).  Le convertisseur permet 2 A et les piles ont une capacité de 2.3 Ah.

Restait juste à développer une petite application graphique pour lancer l'acquisition, la stopper et éteindre le Pi...  Le plus simple est d'écrire quelques lignes en Tcl/Tk faisant appel à des scripts shell.


Bien sûr, ce serait mieux d'avoir une interface montrant les avions, etc...  Mais pour l'acquisition, c'est le plus facile.  Avec une Raspbian, il suffit d'ajouter une ligne à /etc/xdg/lxsession/LXDE/autostart du genre '@wish /home/pi/menu.tcl'.  Un script de quelques lignes :

#!/bin/sh
# the next line restarts using wish \
exec wish "$0" ${1+"$@"}

button .quit -text "Quit!" -command { exit }
button .rec -text "Record" -command { exec /home/pi/rec.sh & }
button .stop -text "Stop" -command { exec /home/pi/stop.sh & }
button .shutdown -text "Shutdown" -command { exec /home/pi/shutdown.sh & }

pack .rec .stop .quit .shutdown
Et le tour est joué. Les scripts contiennent des lignes comme : '/home/pi/bin/dump1090 > dump1090.`/usr/local/bin/now`' (now est 'date "+%g%m%d.%H%M%S"' et permet de suffixer le fichier avec le jour et l'heure); 'pkill dump1090' et 'sudo shutdown -h now'. La captation d'environ une heure entre 14 et 16h30 donne le résultat suivant :
Où l'on peut voir les coordonnées envoyées par les aéronefs : en abscisse, la longitude, en ordonnée, la latitude.  Pour donner une idée, Maline est en 51/4.5, Cologne 54/7, Orléans 48/2 et Bâle 47.5/7.6.  La captation était en 50.6/5.6 avec une bonne vue vers le sud (et moins bonne vers le nord où l'hôpital de la Citadelle masque la vue).

Si on trace la distance à l'aéronef (projeté au sol) calculée à partir des coordonnées géographiques contenues dans certains messages (grâce à la formule trouvée ici), cela donne le graphique suivant :

Les ruptures sont dues au fait qu'il s'agit d'un assemblage de plusieurs captations mais on voit clairement les avions s'approcher puis s'éloigner.  En général, plus les traces sont proches, plus elles sont continues mais certaines traces étonnamment lointaines sont aussi visibles.

Si on s'intéresse à l'altitude des aéronefs, on obtient le graphique suivant :
On observe de nombreux vols à altitude constantes mais aussi des montées et des descentes.  Le plus haut, à 44925 pieds est un jet privé, M-JANP, parti de Londres vers la Turquie, les plus bas sont les hélicoptères de la courses.  À nouveau, il y a des coupures dues à l'assemblage.

Pour la petite histoire, les hélicoptères captés étaient OO-HCZ, OO-HCW et OO-HCP. Mais j'ai aussi capté OO-SEX, le Cessna des parachutistes de Spa; OO-URS et OO-VPD, un petit bi-moteur et près de 300 avions de lignes.  Sur un peu plus d'une heure, entre 14h30 et 16h30, le système a capté 726 713 messages (! peut-être à vérifier, cela fait 200 messages à la seconde !).

Je peux isoler un profil de vol particulier.  Par exemple, pour OO-SEX, cela donne :
Il semble larguer les parachutistes à 2800 pieds (et comme le terrain est à un peu plus de 400 mètres d'altitude, cela fait environ 500 mètres au dessus du sol (?)).  Le cafouillage vers la fin provient probablement d'une perte de communication due à une altitude trop basse et on reprend avec la montée de la rotation suivante (?).  En fait, les mesures ont été prises sans repères temporels (le dump1090 original ne donne pas le temps de la captation du message et le Raspberry Pi n'a pas d'horloge temps-réel à la base; ceci peut être réglé avec un module RTC i2c avec un composant DS1307 (howto (.pdf)) mais il n'était pas branché (et donc, pas lu...)).

Identifications captées : AAF515, AAR501, ABW715, ADH818, AEE601, AEE624, AEE625, AFL2455, AFL2458, AFL2463, AFR1053, AFR112, AFR1147, AFR1211, AFR128, AFR146F, AFR1535, AFR1607, AFR1623, AFR1645, AFR1822, AFR1844, AFR1851, AFR1889, AFR1953, AFR253, AFR389E, AFR508, AFR562, AFR936F, ASR342, AUF171, AUI128, AWE711, AZA88Z, AZA97U, BAF610, BAH7, BAW147, BAW2676, BAW277, BAW347, BAW35, BAW45T, BAW53ZG, BAW547, BAW563, BAW632, BAW64G, BAW679, BAW703, BAW905U, BAW910N, BAW952M, BCS723, BEL2GP, BEL3PR, BEL5HR, BEL5VC, BEL716, BEL7PC, BEL7TX, BER2860, BER527N, BER797Q, BMR16GB, BMR45JR, BMR46CN, BMS123, BOX413, BRU866, CFE41G, CFG8TD, CTN4456, CYP347, DAL245, DAL475, DKGSA, DLH25E, DLH2CH, DLH2F, DLH2MF, DLH2NL, DLH2RX, DLH37E, DLH53T, DLH66A, DLH7TP, DLH8WH, DLH96E, EIN358, EIN359, EIN44T, EIN55N, ETD021, ETH3717, EXS92WX, EZS13EY, EZS82FX, EZS93FY, EZY11JX, EZY1972, EZY1975, EZY2085, EZY2134, EZY263F, EZY31RU, EZY46MN, EZY49VU, EZY5116, EZY51KE, EZY57EV, EZY58UH, EZY62WU, EZY64KC, EZY65XL, EZY67LT, EZY74GK, EZY75HC, EZY83EB, EZY85JM, EZY8832, EZY88PX, EZY8909, FALCN01, FBR14DI, FGVLD, FHY7884, FPO191X, GBYNE, GMI1142, GWI55M, GWI65B, GWI73E, HKY91, HOP3575, HVN16, IBS3731, ICV518, IRL258V, ISF60EU, JAF12Y, JAF29V, JAF3YG, JAF83W, JAF9BJ, JEF11, KAY56, KLM13T, KLM1415, KLM1602, KLM1987, KLM19P, KLM67Z, KLM79K, LAN704, LCO1505, LGL4603, LGL742, LGL7WD, LGL95E, LNX83GP, MJANP, MON1376, MON486G, MON5409, MON812, MON908, MSR725, MSR784, MSX521, MTINK, N3BR, N900HG, NAX2497, NAX5181, NAX92Y, NJE6MA, OMA134, OOHCP, OOHCW, OOHCZ, OOSEX, OOURS, OOVPD, OYMMM, PAL720, PGT502, PGT521, PGT522, PHAML, PHEDM, PRI244, PRI2704, QTR004, QTR040, QTR194, RJA111, ROT383, ROT384, ROT392, RRR2305, RYR10DL, RYR10UB, RYR16NB, RYR18DR, RYR1939, RYR26KZ, RYR30XE, RYR36VT, RYR39RT, RYR4014, RYR40JB, RYR40MX, RYR44BZ, RYR46QZ, RYR54HG, RYR582, RYR70JU, RYR70NW, RYR70SN, RYR754, RYR755, RYR793, RYR87BT, RYR87RK, RYR88QC, RYR973, RYR98EG, SAS559, SNM572, SUS9152, SWR319, SWR31N, SWR324, SWR35T, SWR64, TAP561, TAP686, TAP757W, TAP787B, TCW7922, TCW814E, TCX1588, TCX1628, TCX2549, TCX3425, TFL523, THA931, THY1819, THY1939, THY1966, THY7LT, TOM053, TOM23C, TOM393, TOM3FC, TOM435, TOM4JG, TOM843, TRA1739, TRA347T, TRA512N, TRA6348, TRA653P, TUI6PC, TVS13J, TWI583, UAE205, UAL964, VIR652W, VJS617, VLG1265, VLG1876, VLG6206, VLG8355, VPBDB, VPBZL, VPCYY, VQBFN, VQBHO, WZZ3TF, WZZ7UG, WZZ959.

Voir aussi