Un gang de HackRF fait un SDR à large bande

[Oleg Kutkov] a décidé de construire un SDR à large bande – pour la recherche et la surveillance des communications par satellite, vous savez, comme d’habitude. Il a opté pour une batterie de cartes HackRF – huit d’entre elles, en fait. Deux séparateurs RF 1 × 4 et un 1 × 2 et un LNA sur leur entrée RF combinée ont permis de bien démarrer le projet, et à partir de là, il n’a fait que se compliquer.

Les cartes HackRF peuvent être synchronisées avec une source d’horloge distincte, mais vous ne pouvez pas simplement tirer une seule ligne d’horloge vers toutes dans une configuration en étoile. Ainsi, il a construit une carte de distribution et d’amplification d’horloge, avec un retard de propagation de 4 ns à 1 PPS, et seulement 10 ns à 10 MHz. Ensuite, il a intégré cette carte à la configuration HackRF, en ajoutant un boîtier, en connectant un câble spécialement conçu à cet effet et en traitant les réflexions qui se sont produites.

Les cartes HackRF sont USB 2.0 et capables de générer un flux de données jusqu’à 320 Mo/s, et il n’y aurait aucun moyen viable d’agréger huit liens 2.0 en un seul. Pour résoudre ce problème, il a utilisé huit cartes PCI-E vers USB 3.0 distinctes, chacune avec un HackRF branché, toutes connectées à un PC alimenté par AMD Ryzen 9 via des risers PCI-E que nous voyons généralement utilisés à des fins minières. Pour lier le tout, il a créé un organigramme gnuradio et patché le bloc source osmocom pour activer les mécanismes de synchronisation d’horloge externe qu’il a décidé d’utiliser.

Chaque HackRF est connecté à sa propre carte USB PCIe.

À la fin, [Oleg] nous montre des résultats prometteurs – deux émetteurs-récepteurs DVB-S visibles sur l’affichage en cascade de la capture du spectre. Le travail n’est pas terminé ici, pour être clair – il s’est heurté à quelques barrages routiers. Le flowgraph gnuradio ne se prête pas bien au multi-threading, même sur une machine Ryzen 9, et [Oleg] s’est engagé à réécrire les mécanismes de capture en C ++ qui peuvent être bien alloués à des cœurs de processeur physiques séparés, ce à quoi gnuradio n’est apparemment pas très bon.

Plus important encore, le spectre capturé n’est pas continu, et [Oleg] se demande s’il peut être démodulé correctement. Il a dû recourir à des chevauchements de fréquences dus au suréchantillonnage, et il ne sait pas trop comment compenser cela. La stabilité globale de la fréquence est également remise en question. Cependant, à partir d’ici, il semble que la majeure partie du travail de construction d’un récepteur large bande soit terminée !

[Oleg] est généralement vu sur Twitter, a récemment fait de gros bricolages avec Starlink – alors que Kiev, la ville dans laquelle il se trouve actuellement, est sous le bombardement des forces armées russes. Nous ne pouvons que respecter et apprécier le dévouement. En janvier, nous avons couvert son travail sur un remplacement de modem Tesla LTE importé aux États-Unis pour résoudre les incompatibilités de la bande LTE en Ukraine, et son blog est un trésor d’expériences que nous n’avons pas encore correctement passées au peigne fin, de l’astrophysique et du travail par satellite à Réseaux RS485 et écriture de pilotes Linux.