mercredi 6 juillet 2016

SDRPlay: Premiers essais en panadapter

Commandé le samedi après moult hésitations, le récepteur SDRPlay est arrivé très rapidement mardi. Le taux de change de la Livre Sterling a en fait quelque peu aidé. Un premier test avant ouverture du boîtier a permis de s'assurer du bon fonctionnement. La réalisation s'avère être de très bonne facture hors le boîtier plastique et l'utilisation d'un quartz et non d'un TCXO. 

Deux erreurs qu'il me faudra rapidement corriger, la seule question ouverte étant celle du blindage avec trois options: blindage intérieur du boîtier avec de la bande cuivre normalement utilisée pour les blindages EMC, intégration du boîtier en l'état dans un coffret métallique ou intégration du PCB seul dans un boîtier blindé type 'Schubert' voire réalisé maison en époxy. Le cordon USB, non livré, s'est vu doté d'un plusieurs tores de ferrite.

En attendant, je n'ai pu résister à tester la configuration pour laquelle j'ai acheté ce récepteur, à savoir une utilisation en sortie de la FI 21.4Mhz de mon récepteur VHF/UHF. Le raccordement est rapidement effectué par le biais d'un atténuateur 10dB sur la liaison déjà existante vers la carte Wavecom. Quelques minutes après, le spectre de la bande FM peut-être exploré.

Le spectre en bande FM autour de 105.5Mhz (BW=2MHz)

Le module d'extension large bande 5MHz du TRC trouve ici parfaitement son emploi permettant une exploration pouvant couvrir la moitié de la bande maximale du SDRPlay. Quelques réglages sont nécessaires au regard des caractéristiques de la sortie FI à 0dB. Outre l'atténuateur, il est nécessaire de désactiver le LNA et de réduire le niveau de la CAG que l'on passe en mode manuel..

Le spectre en bande L autour de 1539.0Mhz (BW=2MHz)

Le résultat en bande L est totalement conforme à mon attente et devrait permettre le décodage des modulations à large bande que je ne pouvais obtenir au regard des filtres utilisés dans la chaîne de démodulation analogique du TRC298; du moins pour les modes non couverts par le décodeur Wavecom. Je ne désespère toutefois pas d'arriver à 'patcher' le firmware du TRC298 pour l'obliger à utiliser le filtre de 15kHz en BLU.

dimanche 3 juillet 2016

Inmarsat: Réflexions pour l'adaptation du récepteur

Le récepteur actuellement utilisé pour la réception Inmarsat m'offre deux possibilités pour le décodage: une sortie FI à 21.4MHz de largeur bande variable actuellement exploitée via la carte Wavecom W61PC, et une sortie audio exploitée par le logiciel JAERO, le démodulateur BLU étant alors utilisé.

L'ensemble fonctionne plutôt bien, le TRC298 étant parfaitement stable, mais je reste limité par deux problèmes.

Le premier problème provient du logiciel Wavecom pour la carte W61PC dont la version 7.1 n'intègre pas tous les modes attendus, la dernière version disponible - version 7.5 - pour cette carte, désormais obsolète, n'étant pas accessible auprès de la société Wavecom... J'envisage donc de connecter un récepteur SDR sur la sortie FI pour bénéficier des performances du récepteur jouant le rôle de tête HF. Ceci suppose de trouver un modèle à même de fonctionner en 21.4MHz mais aussi, et bien sûr, de monter suffisamment haut en fréquence pour recevoir aussi la bande L en direct. Mon choix s'est porté sur le SDRPlay que je viens de commander. 

Le second problème est lié à la bande passante de la chaîne de démodulation BLU du récepteur laquelle est limitée par un premier filtre à 7.5kHz puis par les filtres spécifiques de la carte BLU soit 4kHz pour les bandes supérieure et inférieure et 800Hz pour le mode A1.Si le décodage de la majorité des modes disponibles sur Inmarsat se suffit des 4kHz en sortie des filtres BLU, il n'en va pas de même avec certains modes aéronautiques qui nécessitent environ 12kHz de bande passante.
Trois solutions ont donc été étudiées pour résoudre le problème toutes trois basées sur la suppression du filtre en mode A1. La première - non encore testée - consiste à prendre l'entrée 21.4MHz de la carte BLU non sur la sortie filtrée de l'étage FI mais sur l'entrée large bande. La seconde solution consiste à inverser les filtres 7.5kHz et 15kHz en annotant l'inversion sur la panneau avant. La troisième solution, de loin la plus satisfaisante intellectuellement, serait de modifier le logiciel du TRC pour que celui sélectionne le filtre 15kHz en lieu et place du 7.5kHz. Dans tous les cas, il me faudra intervenir dans les modules du récepteur ce qui n'est pas une mince affaire au regard de son encombrement, de son poids et du fait qu'il est installé dans une armoire 19" difficile à déplacer.

La dernière solution a été explorée en priorité, hélas sans succès à ce jour. Je ne dispose en effet que de trop peu d'éléments pour bien comprendre la logique du logiciel de pilotage lequel est réparti sur deux cartes à bases de processeurs 6809. S'il est assez aisé de comprendre la logique de fonctionnement de chacune des cartes, et les espaces de décodage des périphériques, il est moins évident de déterminer l'emplacement où la modification devra être faite: sur la carte de gestion de l'affichage laquelle semble contrôler la configuration des filtres en fonction des modes choisis ou sur la carte de gestion du bus radio laquelle pilote directement la sélection des filtres.
Une première analyse du code de la carte de gestion du bus radio n'a pas permis de mettre en évidence une logique de fonctionnement permettant la modification attendue. L'analyse du code de la carte d'affichage est en cours qui permettra peut-être de déterminer les actions engagées sur la sélection du mode BLU via le clavier et par conséquent de modifier la consigne de sélection du filtre... A suivre.
On notera qu'une partie du décodage des périphériques de la carte de gestion du bus radio s'effectue via une PAL10L8.

Ne disposant pas de la première section du manuel de maintenance de niveau 4 lequel indique des adresses de décodage, il m'a fallu recourir à un Arduino et à un peu de code pour parcourir tout l'espace d'adressage de cette PAL et reconstituer le décodage.