Bonjour Michel
… on va dire que ceux qui s’intéressent aux VLF ont de très grands jardins ;- )
Mais effectivement, la carte Red Pitaya m’a permis de recevoir SAQ sur 17 kHz, en utilisant mon doublet 40 m. Je pense que j’ai été sacrément chanceux.
Ceci dit, il faut préciser que les modifications de l’étage d’entrée sont quasiment nécessaires et sont loin d’être illusoires. C’est au moins 10 dB de dynamique en plus.
Quelques liens pour améliorer les choses :
http://rz1zr.ru/rpmod.htmlcelui qui m’a fournis le plus de renseignements
http://www.cqham.ru/forum/showthread.ph ... aya/page42la page la plus détaillée
http://forum.cq-nrw.de/viewtopic.php?t=34A noter que le changement de tension d’alimentation (dessous de la carte) est probablement le hack qui apporte le meilleur rapport performances/nombre de composants touchés (un déplacement de résistance 0 Ohm, ajout d’une capa de découplage, 10 dB de mieux)
Les autres modifs, notamment la suppression du lpf d’entrée, de l’ampli-buffer à gain unitaire, améliorent franchement la sensibilité et surtout rétablissent une impédance d’entrée basse, proche de 50 Ohms, ce qui n’est pas franchement le cas du montage d’origine, plus orienté instrumentation, donc à impédance d’entrée élevée.
Mais cette modif supprime au passage le filtre anti-aliasing. Si celui-ci n’est pas réintégré dans l’étage d’entrée (il l’est sur la série de pcb Alexiares « retrofit »), on a de fortes chances de recevoir les joyeusetés de toute la bande FM située dans la seconde zone de Nyquist.
Le transfo 9 :1 en entrée est un « pis-aller », mais il est obligatoire, précisément pour adapter l’impédance d’entrée (voir les sites russes)
L’utilisation d’un codec est, imho, une hérésie. Déjà, découper les spectres de réception en multiples des fréquences d’échantillonnage des cartes audio (96, 192, 384 kHz) est un lourd handicap, mais c’est un héritage d’OpenHPSDR, à l’époque de la carte Janus.
Envoyer cette « fenêtre » de 384 kHz pour chaque récepteur, la traiter via PowerSDR, puis la renvoyer via le câble Ethernet (donc ré-encapsulation) pour la faire traiter par un codec local, est à la fois une perte de temps au sens premier du terme, une inutile consommation de ressources, et surtout une inféodation du SDR en HDR (hardware defined radio… bref, un retour en arrière)
Apache a ajouté un codec sous la pression des pousseurs de boutons qui se sentaient incapables de gérer le mixer windows (mais avouons qu’à l’époque, les ordinateurs avaient des cartes son déplorables et les redirecteurs audio tel VAC étaient encore très instables)
Enfin, sur la Red Pitaya, l’ajout d’un codec bouffe les broches de sortie qui, sans cette verrue, peuvent piloter le front-end Alexiares en mode SPI.
J’ajouterais que la tendance est plutôt au traitement audio segmenté sur plusieurs récepteurs, réels ou virtuels, et que la solution hardware figée de l’unique codec interdit le traitement parallélisé de 2, 3 ou 7 flux différents (skimmers cw multibande, réception multimode en analogique ou modulations codées ou numériques etc). Donc, Virtual Audio, carte son d’ordinateur, élimination par le fer, le feu et l’épée de tout ce qui « fige » la configuration d’un SDR, à commencer par les codecs.
J’ajouterais accessoirement (mais alors vraiment accessoirement) que coller l’audio « sur » les entrailles du SDR ne va pas beaucoup faciliter la réception lorsque le transceiver est sous les combles et que l’opérateur est deux étages en dessous. Ou alors l’opérateur aime les souris et les araignées et leur prodigue de longues heures de trafic radio pour leur seul plaisir.
Si j’ai collé un SoC sur la red pitaya, c’était à seule fin de démonstration… dans 99% des cas, l’ordinateur local est éteint et c’est le portable I7 qui sert à recevoir. Plus efficace d’un point de vue transport (moins d’intégration, plus de puissance, plus d’autonomie, surtout vu la taille des ordinateurs portables modernes). Le « tout en un » n’est que la vision « icomisée » et « petit-yeasuhisée » de la radio, totalement inadaptée aux SDR imho.
Ce culte du codec sur un SDR est une tendance fortement poussée par les constructeurs de matériel radio. Plus il y a inféodation, plus il est facile de créer des « modes » et changer les références catalogue, afin d’entretenir le marché. Si les « big 3 » ne sont pas très chaud pour se lancer dans la course aux véritables SDR, ce n’est pas par incompétence, loin de là. Mais parce qu’une fois que l’on possède une radio logicielle, on la conserve 10 ou 20 ans.. l’évolution se fait par soft, et ça ne rapporte que des clopinettes aux vendeurs.
Mais revenons à notre Red Pitaya
Le plus simple est d’associer PowerSDR a VB Audio (français, gratuit en mono-canal)
https://www.vb-audio.com/Cable/Ou sa console de mixage Banana
Linux possède son proche cousin avec PulseAudio… il faut un peu tripoter les réglages (Merci LinHPSDR), mais raccorder un soft de démodulation à l’interface générique de réception n’est guère compliqué une fois que l’on a compris la logique.
Attention toutefois à l’indice de charge CPU. Il ne reflète en aucune manière la fluidité de réception. Une cpu à 30% peut très bien cacher de gros problèmes de latence et de gestion des interruptions liées à de mauvais drivers ou à un throtteling cpu mal réglé. Les dropout audio ne dépendent quasiment jamais de la charge cpu, mais des interruption générées par les traitements audio et vidéo. C’est franchement secondaire en traitement « voix », ça commence à poser des problèmes en mode « fuzzy » et encodés (cw, hellschreiber, tty, Tor, PSK, FT8 etc), ça fiche une sacrée pagaille en modes numériques (FreeDV, DMR et autres modulations complexes)
J’ai un vieux nanard (double cœur 64 bits 2,6 GHz, 16 Go de ram) qui tourne à merveille en travail classique, mais dont la gestion des interruptions audio m’interdit de jouer avec plus de 2 récepteurs, alors que j’ai à peine 25% de charge cpu.
J’espère n’avoir rien oublié
Marc