PaG148: Un nouveau modèle

Le 'PaG148' de chez Telefunken est un panoramique transistorisé conçu à la fin des années 60. Je disposais déjà du modèle PaG148-724/525 doté d'une entrée 525kH conçu pour le récepteur 'E724 KW' mais aussi utilisé sur les autres récepteurs disposant d'une FI de 525kHz dont la série E1500 dotée de l'option ad'hoc.

Un modèle PaG148-2 doté d'un FI de 10.7MHz vient de rejoindre le shack. Un premier test confirme que le panoramique fonctionne avec cependant un décalage notable du marqueur et une ondulation importante  de la ligne de référence. Un rapide contrôle visuel après extraction du coffret met en évidence une soudure sèche sur le condensateur de filtrage.

Une vérification plus complète des deux équipements devra être menée avec comparaison des deux modèles. A suivre donc ...

BC312: Réfection de l'alimentation et premier nettoyage

Le BC312-M est arrivé avec une alimentation dont le transformateur dont un enroulement était mal en point. Le coffret - superbe - a donc été conservé et bien nettoyé.

Il permet de loger deux alimentations à découpage: une 12V pour les filaments et une 24V qui attaque un convertisseur haute tension BA-177A. Le connecteur d'origine, qui provenait du BC312 a été remplacé par un connecteur Amphénol plus courant, l'original étant conservé au cas où un autre appareil de ce type atterrirait à la maison.

L'interrupteur Marche/Arrêt général est doublé de deux interrupteurs commandants la tension filament et la haute tension comme sur l'alimentation qui était fournie avec le BC312. Un indicateur permettant de surveiller la tension anodique à été installé.

Après peinture en noir, l'ensemble rend assez bien. Il reste maintenant à tester le BC312 qui, si l'alimentation filament ne pose pas problème, devra faire l'objet d'un contrôle des condensateurs de filtrage et de découplage.

Une première modification a été faite qui consiste à remplacer l'indicateur de niveau rajouté par le précédent propriétaire par un indicateur plus proche du style du récepteur et surtout plus discret. J'aurais pu remettre l'ensemble dans l'état d'origine avec son capot et son connecteur si particulier.

L'observateur averti découvrira que d'autres modifications ont été apportées sur cet appareil avec la condamnation de la position 'Off' sur le commutateur de la CAG, l'apparition d'une commande 'gain' à la place du fusible de rechange et d'une commande de réglage de l'indicateur avec une commande a la place l'interrupteur Emission/Réception pour laquelle il faudra trouver un bouton plus adapté.

Après un bon nettoyage de la face avant, ce BC312 de 1942 tropicalisé (MFP) apparaît bien plus agréable à voir. Il me faut regarder sur quoi portaient les modifications 850-1, 850-2, 850-3 et 850-6 mentionnées sur la face avant.

A suivre ...

A réparer: BC312 et Microtel 1200

Vendredi, un BC312 et un Microtel 1200 sont arrivés au shack. Un travail de rénovation est à prévoir pour ces deux équipements, l'un avec une alimentation à refaire, l'autre avec son oscillateur local à revoir.

Et dans le même temps, le travail sur le pylône MORS avance avec le nettoyage et la finition des deux derniers éléments. Une peinture verte a été choisie pour protéger le support.

Les autres éléments ont été assemblés et n'attendent plus que l'installation du dernier joint avant le test de mise sous pression.

AM437 : Version transistorisée

Une version inédite car transistorisée du module AM437AU destiné à la série des PRC8A, PRC9A et PRC10A avait rejoint mon stock de pièces de secours. Mon ami Jacques m'avait demandé d'ouvrir l'un des deux modules pour relever le schéma de ce module. C'est aujourd'hui chose faite avec une grande déception à la clef.

Ce module est en effet constitué de trois sous-ensembles noyés dans de la résine. Difficile d'en relever le schéma sauf à dissoudre cette résine où à trouver le 'datasheet' de ces modules CSF. Autant dire, chose impossible.

Ces modules ont un certain air de famille avec ceux équipant deux récepteurs HF non identifiés (dont un prototype) que je n'ai pas encore réussi à redémarrer mais dont je pense qu'ils étaient destinés à remplacer le récepteur du TRTG2A.

Ces modules intègrent très probablement les étages de fréquence intermédiaire ou FI. Je pense qu'il s'agit dans les deux cas d'une technologie modulaire spécifique développée par la CSF à la fin des années 60 mais qui semble ne pas avoir laissé de traces hors ces quelques prototypes.

Si un ancien de la CSF qui me lirait pouvait me donner des renseignements ...

OpenWebRx: Bascule sur OpenWebRx+

Une version étendue du remarquable logiciel OpenWebRx dite 'OpenWebRx+' est disponible qui offre diverses fonctionnalités utiles et de nombreux nouveaux décodeurs embarqués. Je viens de l'installer sur mes deux ensembles SDRPlay après l'avoir testée avec succès.

Une image prête à l'emploi est disponible sur le site de LZ2SLL, image qui devra être mise à jour après installation bien sûr. Travaillant sur des adresses IP fixes, l'utilitaire 'nmcli' a été mis à contribution, celui-ci étant désormais actif par défaut sur la distribution 'BookWorm' ici proposée.

Les résultats sur un Raspberry Pi4 en 64bits sont très intéressants avec notamment une consommation CPU restant très raisonnable et une excellente gestion du SDRPlay, ici RSP1 et RSP1A. 

La configuration par défaut est parfaitement adaptée aux besoins radio-amateurs et facilement extensible par l'ajout de profils, comme ici.

J'envisage un passage sur un Raspberry Pi5, afin de gagner encore un peu en performances, après avoir validé la possibilité de l'alimenter via une alimentation linéaire comme pour les deux unités actuellement en fonction. Le Raspberry Pi5 nécessite en effet une alimentation USB-C sous 5V et 5A soit 2A de plus que ne l'autorise le mode standard. 

Il n'est désormais plus question de simplement raccorder un connecteur USB-C 'classique' mais il faut que l'alimentation soit à même de négocier pour répondre à la requête du Raspberry demandant explicitement à l'alimentation passer en mode forte puissance. Ceci nécessite un échange protocolaire qu'une alimentation linéaire classique ne sait pas faire. Je vais donc approvisionner et tester des connecteurs 'intelligents' assurant ce dialogue. 

A suivre ...

Météo: NetAtmo, Weewx, OCW et APRS

Après quelques mois d'utilisation, la station NetAtmo s'avère être bien pratique en particulier pour son anémomètre que j'ai pu installer sur le pignon du toit pour avoir une bonne idée du vent pouvant être subi par le pylône. Le seul vrai problème réside dans l'absence de toute API permettant de l'interroger localement. 

Souhaitant pouvoir enregistrer les données sur mon serveur et les publier sur le site 'aprs.fi' voire sur une gateway APRS à venir, il m'a fallu passer par une passerelle à même de requêter le serveur NetAtmo, disposant d'une base de données et d'interface vers un service à même de publier sur le site 'aprs.fi' mais aussi compatible avec FreeBSD. Après quelques recherches, le logiciel 'weewx' est apparu être le candidat idéal.

L'installation s'avère être très simple si l'on suit la documentation. Quelques modifications dans la configuration de l'installation ont été apportées afin d'être compatible avec la logique FreeBSD et l'utilisation du répertoire '/usr/local/etc' pour la configuration. L'installation du module 'netatmo.py' est requis en notant que celui-ci ne gère qu'un capteur complémentaire et uniquement en température. 

La gestion complète de la station nécessite plusieurs modifications dont l'ajout des tables ad'hoc dans la base de données, la configuration des paramètres présents dans 'weex.conf' et dans 'skin.conf'. Une lecture attentive du guide de customisation - https://www.weewx.com/docs/5.1/custom/introduction/  - est absolument requise pour éviter de modifier les mauvais paramètres. 

Il sera aussi nécessaire de modifier le code du driver NetAtmo dans le répertoire './weewx/bin/user' après l'installation de l'extension pour définir explicitement l'adresse de chacun des capteurs actifs (hors celui de la station). 

Par défaut, la recherche s'effectue sur la première adresse trouvée dans l'espace de nom 'NAModule4' qui correspond à tous les modules complémentaires (et oui, pourquoi faire compliqué ...):

  'extraTemp1': '*.NAModule4.Temperature',
  'extraHumid1':'*.NAModule4.Humidity',

Dans l'hypothèse d'une station disposant de modules complémentaires, cette configuration sera modifiée pour indiquer l'adresse de chaque module actif (ici masquée):

  'extraTemp1': '03:00:00:xx:xx:xx.NAModule4.Temperature',

  'extraHumid1':'03:00:00:xx:xx:xx.NAModule4.Humidity',

  'extraCo21':  '03:00:00:xx:xx:xx.NAModule4.CO2',

  'extraTemp2': '03:00:00:yy:yy:yy.NAModule4.Temperature',

  'extraHumid2':'03:00:00:yy:yy:yy.NAModule4.Humidity',

  'extraCo22':  '03:00:00:yy:yy:yy.NAModule4.CO2',

Ici, deux capteurs complémentaires sont déclarés par leur adresse 'MAC' qui tient lieu d'identifiant en notant l'ajout de la déclaration des capteurs de CO2 par ailleurs inscrits dans le schéma de la base de données. Après configuration des paramètres d'envoi des données sur le service OCW, les données apparaissent sur la carte APRS du site 'aprs.fi'.

Ma balise APRS a disparu du site car la passerelle APRS de la station F6KBS qui me relayait apparaît être inactive. Ce qui m’amènera à installer ma propre passerelle IP. En attendant les semaines à venir vont être bien occupées avec la suite de la remise en état du boitier de commande du FS5000, la reconstruction du MCR1 en 'kit', la reconstruction du pylône Mors et la mise à jour de mes récepteurs SDR autonomes avec la version OpenWebSdr Plus qui, si elle fonctionne bien, sera transférée sur un Raspberry Pi5.