Archives pour la catégorie Uncategorized

MTR2000 – UpDate – Retour à la vie

Laisser une réponse

Introduction :

J’ai eu le plaisir de me faire offrir des vieux relais normalement bon pour la ferraille. Ceci aurait été dommage de les voir partir au rebuts car les MTR2000 sont des machines extraordinaire. Certains ont été placé par exemple au Mont Alambre (43) pour le R5x, un autre est également à St Maximin (38) pour le R4 du ARA

Ces relais sont réalisés en fonte d’aluminium avec en prime 40W de PA et un système TRIC intégré. Certes, la consommation pourrait être optimisée mais le produit est « presque parfait ».

Je dis « presque » pour chambrer un peu car on parle de relais qui on été alimentés H24/J7 depuis 2004 ! soit 18 ans de bons et loyaux services. Ceci a laissé quelques traces et certaines machines ont finit par se bloquer.

Les blocages sont arrivés dans les derniers temps du réseau pour diverses raisons; reboot suite à des coupures électrique, plantage lors de la reprogrammation ou de la re-calibration des réseaux …etc .Sachant qu’il s’agissait de réseaux de sécurité, ceux-ci ont été remplacés.

Dans le lot, je me suis donc retrouvé avec deux relais VHF en version brique de calage pour ma bibliothèque de vieux MHz magasines ou de cartes QSL …

Description de la panne :

Ces deux relais présentaient le même problème ; il fallait les relancer une dizaine ou une vingtaine de fois car on se retrouvait sur la console avec le message BOOT : en insistant un peu plus on retrouvait le fameux Prompt : ]-o

Solution ?? :

Je dis bien ?? solution ?? En effet par hasard, fin 2021 après être tombé sur le blog de W9CR, j’ai retrouvé dessus une version firmware à jour pour les MTR2000 : https://wiki.w9cr.net/index.php/MTR_Repeater

Le remplacement et la reprogrammation de la Fprom me paraissait trop risqué.

Parti en guerre la fleur au bout du fusil, et surtout n’ayant rien a perdre, j’ai tenté la mise à jour du FW. A savoir que la partie Arduino m’était passé complètement à coté (ou n’avais pas encore été notée sur le site)…

Demandez-moi pas comment je m’y suis pris, mais en l’absence du bon Numéro de série pour correspondre à la clé du programme, j’ai forcé, j’ai by-passé, et finalement réussi à … … bloquer en mode RSS ONLY le super relais (plus de RF). Cependant après l’application de la mise à jour, finit les problèmes de Boot … Certes le relais n’était pas opérationnel mais il se lançais à tous les coups …. Je ne comprends pas trop mais sans doute que le fait de réécrire dans une autre partie de la mémoire, ou tout simplement d’upgrader, le relais démarrait à tous les coup .

Nous somme donc maintenant fin Décembre 2022, après être retombé sur le site de W9CR à la fin de l’été et surtout sur la partie de l’émulation du N° de série, j’ai finalement décidé de m’y remettre dessus hier soir… J’ai donc programmé l’Arduino, après quelques minutes le premier relais déjà upgradé avec la nouvelle version était de retour opérationnel ! Bien rodé au désoudage et installation du Nano, le seconds est passé comme une lettre à la poste …

Procédure (j’invente rien)

Ci-dessous je reprends donc la procédure tirée de W9CR, tirée elle-même de Chris DG2NGI 😉 : https://wiki.w9cr.net/images/6/65/Manual_to_change_Station_ID_of_Motorola_MTR2000_for_firmware_upgrade_via_RSS.pdf

Tout d’abord, il faut de quoi discuter avec le MTR2000 : https://wiki.w9cr.net/images/1/1d/Motorola_MTR2000_R03.02.01.zip

Puis le fameux Firmware verrouillé sur le ID 000008F11111C : https://wiki.w9cr.net/images/9/9a/MTR2000_Firmware_Package_R003.04.03.zip

Sans oublier la clé .cmp du ID 000008F11111C : https://wiki.w9cr.net/images/9/96/Mtr2000-OCR30403.CMP

Au cas où il y a le DUMP de la 28F800 contenant le programme (je ne connais pas la version FW) : https://wiki.w9cr.net/images/6/6e/28F800_image_for_MTR2000.bin

Ensuite il faudra aussi un Arduino, sur le wiki, il est indiqué un Uno, mais j’ai fait la manip avec un Nano, il faut lui charger ce programme ainsi que mettre la librairie OneWire jointe, dans le compilateur : https://wiki.w9cr.net/images/3/35/MTR2000_DS4201_Emulator_Source_MTR2000-DS2401.zip

Pour la suite, il suffit de retirer le DS2401 (en la mettant bien de coté pour la ressouder) et de câbler notre Arduino à la place (Pin 8 sur Data du DS2401) voir la photo ci dessous. Perso je l’ai retiré à l’aide d’un pistolet à air chaud et pour alimenté l’Arduino j’ai pris les broches C19 GND et C20 +5V pour ne pas se trouver avec des potentiels différents. Attention après avoir enlevé la grille de protection, bien remettre les 2 vis du haut sur la carte fond de panier pour une bonne mise à la masse (ça risque de forcer un peu, mais ne pas hésiter)

On met le relais sous tension et on peut vérifier le Numéro de série 0000008F11111C soit par la console série 9600-8-N-1 avec les commande suivante après le prompt ]-o:

dorss
get bpn

Soit sinon via le logiciel RSS2000 dans la case Station ID

Ensuite il faut passer la la partie Service et lancer l’upgrade, choisissant le fichier FW où se trouvera également dans le même dossier le fichier .CMP

A la fin, le système déverrouille le software, vérifier alors que le relais est bien fonctionnel, le couper électriquement, supprimer le montage Arduino Nano et remettre le DS2401.

Redémarrer le système et vérifier que le Numéro de série original est bien revenu.

Bonne chance !!

Sébastien F4ASS/KI7QQO

KrakenSDR / KrakenRF : Utilisation d’un VPN pour l’interconnexion des stations sur DFagregator

Laisser une réponse

Le DF-Aggregator a été développé par ckoval7 et il est disponible ici : https://github.com/ckoval7/df-aggregator

Les informations générales du KrakenSDR se trouvent ici : https://github.com/krakenrf

Le but

Suite à la sortie du nouveau système KrakenSDR successeur du Kerberos , ceci a également été l’occasion d’avoir une importante update du logiciel ainsi que la mise à disposition du DF-Aggregator l’idée ici est de pouvoir donner la possibilité de mettre sur le même réseau les différents systèmes Kerberos/Kraken et un serveur unique: DF-Aggregator.

En effet, le serveur vas interroger les divers stations DF afin d’obtenir les informations sur la détection en cours (indicatif du site, indice trame, fréquence,coordonées GPS, angle, puissance, incertitude …). Ci-dessous la trame récupérée dans KrakenIP:8081/DOA_value.html pour la station F4ass-23 @ 430.075 

F4ASS-231665926474457430.07545.346994.64665705179.8337

OPEN VPN – Le serveur – installation

Pour faciliter l’usage et surtout, vu la présence d’un portail pfSense au QRA, j’ai donc opté pour le package OpenVPN disponible dans les extensions pfSense ; je ne vais pas détailler l’installation du serveur car elle est disponible par exemple ici : https://www.tech2tech.fr/openvpn-sur-pfsense-le-teletravail-facile-et-securise/

OPEN VPN – Le client – copie des fichiers

On va reprendre la procédure à partir du « Client Export » disponible dans le menu OpenVPN

Nous allons utiliser le « Bundled Configurations » en version « Archive » ; il suffit de le télécharger en local.

Pour se connecter au Pi4 il suffit de lancer la connexion au point d’accès « krakensdr » (mdp « krakensdr ») disponible en Wifi qui attribue en DHCP le sous réseau 192.168.50.0

Attention, il faut aussi que le PI4 soit relié au réseau Ethernet de la box !

Pour la suite il suffit d’utiliser « FileZilla » par exemple, afin de transférer les fichiers sur le PI4 qui est sensé être sur 192.168.50.5 .

Lancer la connexion :

Saisir l’identification user/pass : krakenrf /krakensdr et aller dans /home/krakenrf

Faire par exemple un glissé déposé du fichier .zip précédemment téléchargé dans le dossier ouvert.

krakenSDR – Installation du client sur le PI4

On commence par se connecter et vérifier que notre fichier est bien présent:

On tape ensuite la commande « unzip » suivie du fichier zip

Une fois extrait, on se sert de FileZilla pour renommer les fichiers (plus simple a traiter), Attention on renomme le .ovpn en .conf pour une utilisation avec OpenVPN.

Pour la suite on va lancer l’installation de Open-VPN sur notre PI4 avec la commande : 

sudo apt-get install openvpn

Ensuite il faut copier les fichier vers notre fichier client openvpn fraîchement installé

sudo cp kerberos1*.* /etc/openvpn/client/

On écrit ensuite le mot de passe (pas très sécure) dans un fichier nommé pass.txt avec à l’intérieur le User et le Password sur deux lignes par exemple :

toto
vDs5#%G96*!

Éditer le fichier .conf et le modifier comme suite :

dev tun
persist-tun
persist-key
data-ciphers AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305:AES-256-CBC
data-ciphers-fallback AES-256-CBC
auth SHA256
tls-client
client
resolv-retry infinite
remote toto.fr 1194 udp4
verify-x509-name "OpenVpnServCert" name
auth-user-pass /etc/openvpn/client/pass.txt
pkcs12 /etc/openvpn/client/kerberos1.p12
tls-auth /etc/openvpn/client/kerberos1.-tls.key 1
remote-cert-tls server
explicit-exit-notify

Pour tester il faut avant tout connecter le PI4 krakensdr sur l’Acess-Point de votre téléphone ou de votre Clé 4G en le configurant SSID et WPA en « KrakenAndroid » pour bien arriver par l’extérieur (voir le site de KrakenRF pour la procédure), penser a débrancher le câble réseau, et ensuite taper :

sudo systemctl start openvpn-client@kerberos1

vérifier qu’il n’y ai pas d’erreur et lancer éventuellement :

sudo systemctl status openvpn-client@kerberos1

On regarde maintenant sur l’interface d’accueil si notre pfSense remonte bien le VPN comme étant connecté ; on remarque ici l’adresse IP donné par l’opérateur de téléphonie mobile pour la connexion ainsi que l’adresse virtuel

Il vous reste juste à tester le ping sur l’IP de votre interface pfSense et si ca fonctionne, pour que le VPN se reconnecte automatiquement à chaque démarrage taper :

sudo systemctl enable openvpn-client@kerberos1

Sébastien F4ASS/KI7QQO

Autocalibration externe Kerberos SDR sur Kraken SDR software

Laisser une réponse

Bonjour, dans cet article nous allons voir comment mettre en place l’autocalibration sur les ancien Kerberos, en effet Corey Koval dont le pseudo est ckoval7 https://github.com/ckoval7 a développé sur l’ancien système la possibilité d’effectuer une calibration automatique par modification du code. La bonne nouvelle est que maintenant cette fonctionnalité est sensé avoir été poussée dans la dernière version du KrakenSDR. Je dis sensé car j’ai noté un petit soucis sur les Pin de commandes

Les informations sont ici : https://www.tindie.com/products/lakeshorelabs/set-of-4-spdt-rf-switches-with-50-ohm-load/

Pour ma part j’ai utilisé des relais coaxiaux acheté à l’occasion d’un salon radio-amateur pour augmenté l’immunité RF mais dont vous verrez ci dessous un schéma de principe :

https://user-images.githubusercontent.com/56490178/195976924-1bf3beb1-8460-46e9-ae00-26011c0863ed.png

Modifications du logiciel de KrakenRF

Pour les tests je vous conseille d’utiliser pour l’instant la version du 18-08-2022 car celle d’octobre me donne des comportements bizarres avec le DF-Aggragator !

Pour mon utilisation à l’origine nous avions un /calibration sur la pin 16 (GPIO23) et un calibration sur la pin 18 (GPIO24); ce que j’ai constaté c’est que la GPIO23 fonctionnait mais que la GPIO24 ne bougeais pas. En effet pour commander mes relais j’ai besoin d’un +3.3v quand je dois mettre les relais sur charge (ponctuel); à l’heur de l’économie d’énergie ceci se justifie aussi ;-).

L’idée est donc de modifier le code pour avoir sur la GPIO24 un repos à 0v et un 3.3v quand il faut calibrer .

Après s’être connecté en SSH, nous allons donc aller retrouver le fichier rtl_daq.c , ci dessous l’emplacement :

Capture d’écran 2022-10-13 203235

Éditer le fichier en sudo et vers les 3/4 du fichier retrouver la ligne : gpioWrite(24, 0); et la remplacer par gpioWrite(24, 1);

Capture d’écran 2022-10-13 203520

Pour la suite faire un make

Capture d’écran 2022-10-13 203841

dans l’interface du KrakenSDR développer le Basic DAQ Configuration (ou vous aviez déjà du choisir le Preconfigured DAQ Files en kerberos_default)

Changer le temps de Recalibration Interval à 10mn et passer en Periodic tracking

On reboot et ça devrait être bon !

LE RÉSEAU RÉGION ARA (Auvergne Rhône Alpes)

2 réponses

L’historique et la configuration de base

La plupart des relais analogique interconnectés utilisent le programme SVXLINK développé par SM0SVX (https://www.svxlink.org/).

A l’heure actuelle, sur le territoire, nous connaissons presque tous la version Spotnik basée sur ce programme qui fait fonctionner actuellement le réseau RRF (Réseau des Répéteurs Francophone), qui se veut avant tout, un réseau mondial Francophone avec presque 200 relais.

L’image .IMG de la SD du logiciel est disponible au téléchargement pour les plateformes ARM type Pi-Zero, Orange Pi, etc… Le téléchargement des versions sont disponibles ici : ftp://rrf.f5nlg.ovh/

Suite à plusieurs demandes restées infructueuses auprès d’un « OM », nous avons crée sur l’idée de F4EED et grâce surtout à F4HOF un serveur qui se voulais plus régional http://ara.ham42.net. Ainsi qu’un serveur de communication d’urgence disponible ici : http://dashboard.fr-emcom.com/

Pour des raisons identiques il avait également été l’occasion de crée un serveur dédié, hébergé en Guadeloupe avec l’aide FG8OJ et réalisé lors d’un déplacement pour participer à l’exercice Tsunami Caribe Wave 2019 https://radioamateur.gp/relais

Ici, on ne vas pas réinventer la procédure d’installation disponible sur les sites du RRF, on vas principalement se concentrer sur : « comment adapter » ce système pour qu’il se connecte au ARA et/ou FrEmCom

L’adaptation

Connexion au spotnik

On commence par se connecter en SSH avec son logiciel favoris (putty par exemple pour les utilisateurs de Windows)

Ou comme ci dessous depuis le Bash d’un Ubuntu avec la commande ssh root@IpDeVotreSpotnik puis on saisi le mot de passe par défaut (si vous ne l’avez pas encore changé !) qui est spotnik

Mise en place des fichiers audio ARA et EmCom

Généralement les fichiers audio se trouvent tous dans le même répertoire, il faut effectuer le téléchargement depuis le dossier /home avec la commande git clone https://github.com/F4ASS/reseau_ARA/ . Puis il faut ensuite taper cd reseau_ARA/ puis mv *.wav /usr/share/svxlink/sounds/fr_FR/RRF/ pour déplacer les deux fichiers .Wav dans le bon endroit.

Création des scripts

L’ensemble des fichiers de configuration des salons (ou conférences) se trouvent dans /etc/spotnik/ on tape donc cd /etc/spotnik/

Pour commencer sachant que plusieurs versions existent, pour éviter de tout casser on vas repartir de l’existant, c’est à dire, utiliser une copie du fichier nommé « restart.rrf », depuis le répertoire courant, on peut vérifier sa présence avec la commande ls qui liste les fichiers. Il suffit ensuite de copier le fichier de configuration avec la commande cp restart.rrf restart.ara ensuite, on édite le fichier par exemple avec nano à l’aide de la commande nano restart.ara. On remplace toutes les noms rrf par ara, puis on remplace les paramètres de connexions (on peut aussi faire pareil pour le fichier FrEmCom en remplaçant pas frm).

Pour le réseau ARA (rrf=>ara)
« HOST=ara-r.fr »
« AUTH_KEY=hN8pB4jU »
« PORT=5310 »

Pour le réseau FrEmCom (rrf=>frm)
« HOST=ara-r.fr »
« AUTH_KEY=KvPXN3kF »
« PORT=5320 »

# DTMF 96 RRF #
devient
# DTMF 272 ARA #

echo "rrf" > /etc/spotnik/network
devient
echo "ara" > /etc/spotnik/network

ln -s /usr/share/svxlink/sounds/fr_FR/RRF/Srrf.wav /usr/share/svxlink/sounds/fr_FR/PropagationMonitor/name.wav
devient
ln -s /usr/share/svxlink/sounds/fr_FR/RRF/Sara.wav /usr/share/svxlink/sounds/fr_FR/PropagationMonitor/name.wav

rm -f /etc/spotnik/svxlink.rrf
devient
rm -f /etc/spotnik/svxlink.ara

cat /etc/spotnik/svxlink.cfg >/etc/spotnik/svxlink.rrf
devient
cat /etc/spotnik/svxlink.cfg >/etc/spotnik/svxlink.ara

echo "HOST=rrf2.f5nlg.ovh" >>/etc/spotnik/svxlink.rrf
devient
echo "HOST=ara-r.fr" >>/etc/spotnik/svxlink.ara

echo "AUTH_KEY=Magnifique123456789!" >>/etc/spotnik/svxlink.rrf
devient
echo "AUTH_KEY=hN8pB4jU" >>/etc/spotnik/svxlink.ara

echo "PORT=5300" >>/etc/spotnik/svxlink.rrf
devient
echo "PORT=5310" >>/etc/spotnik/svxlink.ara

svxlink --daemon --logfile=/tmp/svxlink.log --pidfile=/var/run/svxlink.pid --runasuser=root --config=/etc/spotnik/svxlink.rrf
devient
svxlink --daemon --logfile=/tmp/svxlink.log --pidfile=/var/run/svxlink.pid --runasuser=root --config=/etc/spotnik/svxlink.ara

Modification du Logic.tcl

Pour gérer les commandes de changement de conférence il est utile de rajouter les codes DTMF pour que le relais puisse exécuter le fichier restart correspondant.

Ce fichier se trouve dans /usr/share/svxlink/events.d/local/

Il suffit d’ajouter les conférences correspondantes en dessous des salons prédéfinit. (vous pouvez copier-coller les lignes d’un salon précédent)

On fait pointer les commandes sur le(s) fichier(s) précédemment(s) crée(s).

Ajout du code de retour automatique de FG8OJ

Bertrand, FG8OJ a développé un script python pour gérer le retour automatique sur un réseau de replie au choix après la « non utilisation » du réseau en local (pas d’ouverture du relais) pendant une temporisation prédéfinie.

Le code est disponible sur le site Git de Bertrand https://github.com/fg8oj/svxlink il se compose d’un fichier dont je vais partager ci dessous le code adapté au « ara » à écrire dans le dossier /etc/spotnik/ grâce à la commande nano modedef.py et bien sure, bien penser à rendre ce fichier exécutable avec la commande chmod +x modedef.py

#!usr/bin/env python
# -*– coding: UTF-8 ––
# Script FG8OJ pour Spotnik
# Relance après inactivité radio vers un groupe par défault
# Cron a ajouter :
# //* * * * * python /etc/spotnik/modedef.py > /dev/null 2>&1
# Configuration :
default= »ara » # appel du fichier restart /etc/spotnik/restart.XXX
timeout=30 # durée en minute avant le rebasculement sur le salon par défault
import datetime
import os
log = open(« /etc/spotnik/network », »rt »)
reseau=log.readline().strip()
if (reseau == default):
exit()
log2 = open(« /tmp/svxlink.log », « rt »)
delay=9999999
for x in log2:
if ( (x.find(« The squelch is OPEN »)>-1)or(x.find(« Activating link »)>-1) ):
dti=x.find(« : « )
dt=x[:dti]
dt= datetime.datetime.strptime(dt, »%a %b %d %H:%M:%S %Y »)
dt=datetime.datetime.now() – dt
if (delay>dt.total_seconds()):
delay=int(dt.total_seconds())
print(delay)
if (delay==9999999):
exit()
if (delay>(timeout*60)):
print(« restart « + str(delay))
os.system(« /etc/spotnik/restart. » + str(default))
log.close()

Modification du Cron

Il existe des taches RRFRaptor, afin de désactiver cette fonction handicapante pour notre utilisation, il faut donc désactiver la tache Cron. Il vous faut alors éditer le fichier avec la commande nano /etc/crontab et supprimer ou commenter avec un # les 3 lignes en rapport avec le RaptorRRF:

Pour la suite on vas configurer l’éditeur pour utiliser nano en tant qu’éditeur de tache Cron de l’utilisateur root avec la commande export EDITOR=nano puis en éditer les Cron locales avec crontab -e et ajouter le lignes ci dessous (elles sont déjà contenue dans le fichier modedef.py)

Pour valider, il faut relancer le système avec la commande reboot

Exécution manuel

Pour lancer manuellement la conférence ARA il faut aller dans /etc/spotnik/ et exécuter le script avec la commande ./restart.ara

Idem, pour lancer la conférence FrEmCom pour le salon de l’urgence il faut exécuter la commande ./restart.frm

Gestion du lancement FrEmCom le jeudi soir pour le QSO de l’urgence

Éditer les Cron locales avec crontab -e et remplacer le précédent script comme celui-ci

## SCRIPT de FG8OJ avec ajout gestion FrEmCom le jeudi soir
* * * * 0 python /etc/spotnik/modedef.py > /dev/null 2>&1
* * * * 1 python /etc/spotnik/modedef.py > /dev/null 2>&1
* * * * 2 python /etc/spotnik/modedef.py > /dev/null 2>&1
* * * * 3 python /etc/spotnik/modedef.py > /dev/null 2>&1
### Pour le jeudi
* 0 * * 4 python /etc/spotnik/modedef.py > /dev/null 2>&1
* 1 * * 4 python /etc/spotnik/modedef.py > /dev/null 2>&1
* 2 * * 4 python /etc/spotnik/modedef.py > /dev/null 2>&1
* 3 * * 4 python /etc/spotnik/modedef.py > /dev/null 2>&1
* 4 * * 4 python /etc/spotnik/modedef.py > /dev/null 2>&1
* 5 * * 4 python /etc/spotnik/modedef.py > /dev/null 2>&1
* 6 * * 4 python /etc/spotnik/modedef.py > /dev/null 2>&1
* 7 * * 4 python /etc/spotnik/modedef.py > /dev/null 2>&1
* 8 * * 4 python /etc/spotnik/modedef.py > /dev/null 2>&1
* 9 * * 4 python /etc/spotnik/modedef.py > /dev/null 2>&1
* 10 * * 4 python /etc/spotnik/modedef.py > /dev/null 2>&1
* 11 * * 4 python /etc/spotnik/modedef.py > /dev/null 2>&1
* 12 * * 4 python /etc/spotnik/modedef.py > /dev/null 2>&1
* 13 * * 4 python /etc/spotnik/modedef.py > /dev/null 2>&1
* 14 * * 4 python /etc/spotnik/modedef.py > /dev/null 2>&1
* 15 * * 4 python /etc/spotnik/modedef.py > /dev/null 2>&1
* 16 * * 4 python /etc/spotnik/modedef.py > /dev/null 2>&1
* 17 * * 4 python /etc/spotnik/modedef.py > /dev/null 2>&1
* 18 * * 4 python /etc/spotnik/modedef.py > /dev/null 2>&1
* 19 * * 4 python /etc/spotnik/modedef.py > /dev/null 2>&1
# Pour lancer le FrEmCom à 19h55
55 19 * * 4 python /etc/spotnik/modedeffrm.py > /dev/null 2>&1
* 20 * * 4 python /etc/spotnik/modedeffrm.py > /dev/null 2>&1
#Pour le retour sur ARA
46 20 * * 4 python /etc/spotnik/modedef.py > /dev/null 2>&1
* 21 * * 4 python /etc/spotnik/modedef.py > /dev/null 2>&1
* 22 * * 4 python /etc/spotnik/modedef.py > /dev/null 2>&1
* 23 * * 4 python /etc/spotnik/modedef.py > /dev/null 2>&1
### Pour les autres jours
* * * * 5 python /etc/spotnik/modedef.py > /dev/null 2>&1
* * * * 6 python /etc/spotnik/modedef.py > /dev/null 2>&1

A bientôt sur le réseau ARA (272) ou FrEmCom (112)

Sébastien F4ASS / KI7QQO

Transpondeur Tri-Bandes avec voie SVXLink

2 réponses

Transp2

Fonctionnalités attendues de ce système:

  • Une voie VHF 50.5375 Mhz Simplex FM CTCSS 123Hz
  • Une voie VHF 145.2125 MHz Simplex FM CTCSS 123Hz
  • Une voie UHF 431.275 MHz Simplex FM CTCSS 123Hz
  • Une voie VoIp basé sur une logique SVXLink en mode simplex

Pour des raisons fonctionnels évidentes (manque de GPIO sur l’OrangePiZero et stabilité/autonomie du système) la principale partie de logique a été déportée sur un Arduino Nano V3 qui possède de nombreuses entrée sortie ainsi qu’un simple programme avec des boucles très basique (et plein d’autres avantages)

Bien-sûre, ceci nous oblige a utiliser le SVXlink comme une voie radio supplémentaire

Choix des composants:

1- Pour le traitement analogique pour la plupart de mes montages, depuis déjà pas mal de temps, je fais appel à un composant magique le 4066 , il s’agit d’un commutateur de signal utilisable pour commuter de l’audio.
La documentation est disponible ici : http://www.ti.com/lit/gpn/cd4066b

2- Pour la gestion de la logique, comme expliqué ci-dessus nous utilisons un Arduino NanoV3

3 – Pour la partie interconnexion VoIp nous sommes partis sur la base de l’image SPOTNIK réalisée par l’équipe de F5NLG disponible ici https://f5nlg.wordpress.com/ . Sachant que nous possédons un serveur local (ARA : Auvergne Rhône Alpes) et par soucis de limiter les temps d’émission inutiles, nous avons mis par défaut une interconnexion avec le réseau ARA. Nous gardons également l’ensemble des réseaux disponibles par défaut sur la distribution de F5NLG, donc, entre autre le réseau RRF.

4- La radio utilisée pour le 50MHz est sur une base de Talco CS40 dont nous avons dépouillé l’ensemble de la partie logique présente sur la partie inférieur du poste. L’avantage de l’utilisation de l’Arduino Nano V3 est également que celui-ci nous donne la possibilités de réaliser la programmation de la PLL du Talco (et donc de commuter la programmation à chaque changement d’état ; TX ou RX)

5- Les deux radio utilisées pour les deux autres voies sont des Motorola GM950 et CM340 dont l’avantage est de posséder des E/S Flat pour maintenir la compatibilité des Pré/Dé-amphase, ainsi que des signalisations et commande d’émission.

Schéma de la carte logique à base d’Arduino

Le programme arduino

Rendez-vous sur le Github @F4ASS https://github.com/F4ASS/Transpondeur-Tribande

Note : cette version du document est amenée à évoluer

Derniers travaux sur le Site du Guisay

2 réponses

28-03-2016

Bonsoir,

Je me lance donc pour un premier article sur wordpress afin de faire découvrir et de partager mes retours d’expérience sur ma passion : la radio.

Pour me faire un petit peu la main sur ce nouveau « joujou », nous allons commencer par un court article sur la maintenance du site du Guisay de Saint-Étienne réalisé les 12 et 19 Mars 2016.

On peut commencer par remercier les participants de l’expédition (et celui qui était au chaud chez lui 😉  ) : F4EED F5GFE F4GIX F4HOF F4HGW

Le préparatifs à la maison 😉  :

  • Re-calibrage de la partie émission du relais 6m
  • Mise à jour de la logique du relais 6m (à base d’Arduino)
  • Chargement de deux, trois panneaux qui ont généreusement été offerts par mon Pro

Voici donc la liste des travaux dernièrement réalisés sur site :

  • Contrôle des antennes d’émission 50 Mhz
  • Remise en place du relais précédemment entretenu
  • Mise en place d’un nouveau panneau 5Ghz à la cime du pylône
  • Re-configuration du bullet 5Ghz UBIQUITY
  • Calibrage de la liaison HamNet pour le DSTAR avec F4HOF
  • Ajout d’un Filtre Band-Pass à 51.350Mhz (-1,1dB)
  • Vérification du couplage entre le relais DMR Motorola et le DSTAR (détails dans un prochain article)

Performances observées :

  • Relais 6M (50Mhz)
    • Sensibilité -105 dBm (attention nous avons observé beaucoup de perturbations)
    • Puissance d’émission : 10Watt (40dBm)
  • Relais Dstar
    • Puissance d’émission 15W (41.7dBm)
    • Perte dans le couplage 3.2dB
  • Relais DMR
    • Puissance d’émission 15W (41.7dBm)
    • Perte dans le couplage 3.2dB

Voici donc la fin de ce petit article …

Bientôt d’autres articles, qui seront plus élaborés …

F4ASS, Sébastien

Ci Dessous quelques photos :

 

 

Petite vue des Cavités VM réalisé lors de l’installation du relais en 2013

cavités VM