Welcome !


Bonjour à tous ,

Et bienvenue sur mon blog, j’y parle course à pied,
système linux et enfin radioamateur !

Bonne visite,
Kennavo,

Update your wordpress blog via CLI.

Recently, i try to update my blog via the web,
and it return « timeout » after few minutes.
So i move this task to CLI, more safer !

First, if you crash your last web setup,
Remove the lock into the php :

wp-admin/includes/class-core-upgrader.php

Simply comment this :

if ( ! $lock ) {
#return new WP_Error( 'locked', $this->strings['locked'] );
}

-> Setup is very easy, you have to install wp command, here i’m doing this into my /opt/ :

cd /opt/
wget -c http://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
ln -s /opt/wp-cli.phar /usr/local/bin/wp

Now i’m using this command :

-> Go to your blog root path and simply to :

root@crx-web01 html # cd /myultrasecurepath/bastien.barbe.pw/
root@crx-web01 html # sudo /usr/local/bin/wp core --allow-root update
Updating to version 5.4.2 (fr_FR)...
Téléchargement de la mise à jour depuis https://downloads.wordpress.org/release/fr_FR/wordpress-5.4.2.zip…
Décompression de la mise à jour...
Success: WordPress updated successfully.

 

Sources:
https://blog.microlinux.fr/wp-cli-update/

Guide de pilotage de votre station radioamateur à distance.

Version 1.0
Date : 25/04/2020
Update : 27/04/2020

Dans ce guide, je vous propose de mettre en place le pilotage de votre station radioamateur à distance avec des briques « open source ».

J’ai pu tester différents logiciels pour faire ce genre d’opération et au final j’ai retenu cette configuration que je vous propose ici, notez que ce guide évoluera dans le temps au fur à mesure de mes essais.

Dans le passé, j’ai déjà expérimenté une solution de « remote control » sous WINDOWS, pour ce faire vous pouvez utiliser : HAM RADIO DELUXE client/serveur et MUMBLE/MURMURE pour la VOIP mais aussi SKYPE, je ne décrit pas leur utilisation ici, c’est suffisamment simple et documenté sur Internet, par contre n’hésitez pas si vous avez besoin d’un coup de main pour la configuration.

D’expérience, je trouve plus simple le « remote control » avec LINUX, qu’avec WINDOWS. Je trouve que techniquement c’est plus stimulant surtout dans notre loisir qui consiste à expérimenter, de pouvoir regarder dans les codes sources, comprendre comment ça marche et maîtriser complètement notre système de contrôle distant.

Pour les utilisateurs donateurs du projet CRX-RADIO-CLOUD, je peux vous fournir un pack de connexion VPN avec un fichier ZIP contenant la configuration VPN cliente (fichier OVPN+certifcat & clé). Si vous êtes intéressé, me contacter par email :  f4eyq ( at ) crx.cloud. Pour disposer d’une latence maximale j’ai limité à 30 clients réparti sur 2 serveurs dédiés, sachant que je dispose ici de 2x  1GB de bande passante Internet chez OVH.

Sommaire :
Mes recommandations
1. Création d’une matrice de flux réseau
2. Configuration du serveur « REMOTE »
3. Configuration du client.
4. Configuration de votre box internet & tests.
5. Sécurité de votre installation.
6. Implémentation d’OPEN-VPN.
Notes.

Mes recommandations :

Logiciels :

Pas de VPN dans la mesure du possible : Un simple FIREWALL côté serveur est amplement suffisant (latence la plus basse). Attention pour les utilisateurs Français, il conviendra d’utiliser un VPN pour tous les flux car l’emploi direct du réseau INTERNET, n’est pas prévu par la réglementation actuelle.

Si vous souhaitez quand même en utiliser un, vous pouvez utiliser un système hybride à savoir : mettez toujours la VOIP sans VPN et le reste avec (surtout avec un filtrage IP sur la source en place).

Dans le cas ou votre station radio distante tourne avec un modem 4G par contre il faudra passer au VPN, car vous n’aurez pas d’adresse IP publique fixe (à moins d’utiliser un service type DynDNS mais ce n’est pas forcément très pratique et c’est devenu payant).

Ici je vous propose dans la partie 6 de ce guide, l’implémentation d’OPEN-VPN sur un serveur (en IP FIXE ou avec un DYNDNS) et aussi sur votre client WINDOWS ou LINUX.

Un FIREWALL sur votre serveur « remote station » : ici je vous conseil SHOREWALL (qui est un frontend pour IPTABLES), je détaillerai sa configuration ici dans le chapitre 5.

Matériels :

Si c’est pas déjà le cas : 
– Ajout de ferrites systématique sur vos alimentations USB, 12V, 5V.
– Ajout de transformateurs sur vos lignes sons si vous n’avez pas d’interface TRX/carte sons.
-> Si possible utilisez une alimentation et un HUB USB dédié devant votre RASPBERRY, c’est mieux que d’utiliser l’alimentation du RASBERRY pour tout faire.

Commencez par les tests sur votre réseau LAN puis par INTERNET & tenez compte de la latence de votre ligne et de votre matériel, réduisez/augmenter le débit et la qualité du son si besoin, la vitesse du port série (espace entre chaque byte envoyé et aussi vitesse de récupération des infos ( via pooling avec FLDIGIT ) je détaille tout cela dans ce guide.

Côté client :

– Disposant d’un petit PC DELL avec 1G de RAM, j’y installe une UBUNTU 18 que je met ensuite à jour, puis j’y installe LUNBUTU, une version allégée idéale ici sur mon mini PC que j’utilise pour le contrôle de la station à distance.

Si vous voulez utiliser des logiciels de mode numérique avec votre station distance, je vous conseil côté client un PC Windows ou LINUX mais avec plus de 1G de RAM car après tests ici avec JACK (outil pour créer des câbles virtuels sous LINUX ) il s’avère qu’il faut +de 1G de RAM pour que cela tourne correctement surtout si ensuite vous lancez WSJT ou tout autre logiciel de modes numériques.

Enfin soyez vigilent sur la qualité de votre micro-casque, surtout sur une station distante, l’idéal est de disposer d’un PTT.

Côté serveur : 

– Pour mes essais je prend un RASPBERRY-PI-1 disposant de 512Mo de RAM avec processeur ARMv6 ce qui suffit amplement ici, si vous disposez d’un RASPBERRY plus puissant tant mieux, la latence n’en sera que meilleure.

– Notez que j’utilise un RAMDISK pour les LOGS afin de ne pas fatiguer la carte mémoire, et que les périphériques USB sont branchés
sur un petit HUB USB alimenté sur une alimentation 5V dédiée, dans le but ici de ne pas solliciter de trop le RASPBERRY.

– Concernant la carte son, ici on utilise une carte son USB, de ce côté là vous avez l’embarra du choix, ici une carte à 10€ fonctionne très bien, mais comme pour le RASPBERRY, si vous avez mieux tant mieux pour vous.

1. Création d’une matrice de flux réseau :

Le contrôle distant vous impose ici de connaitre les ports réseaux que l’on va configurer sur notre RASBERRY
puis sur notre BOX INTERNET, ici je vous conseil  :

– Pour les gens en 4G ou les grands voyageurs, notez que ici vous n’aurez pas de ports réseau à ouvrir, il vous faudra installer un client OPEN-VPN sur le RASBERRY, disposer d’un provider VPN et vous connecter sur votre passerelle au démarrage du serveur RASPBERRY. De là votre client qui pilote votre station radio devra lui aussi disposer d’un client VPN configuré sur le même réseau, les accès se feront au travers le VPN.

Pour les gens en IP fixent avec une BOX INTERNET classique des 2 côtés c’est mon cas, vous avez rien à faire avec une configuration VPN, c’est pas la peine, sauf si vous chercher une solution qui marchera quand vous êtes en voyages, pour cela il vous faudra obligatoirement un VPN ou un accès SSH direct (avec tunnels).

Voici une matrice que vous devez remplir avec les ports de votre choix, notez bien les valeurs,
car il faudra configurer tout cela sur votre BOX internet :

– Choix d’un port SSH non standard ( pas de port 22 car les méchants hackers viendrons vous embêter sinon ),
choisissez une valeur entre 2200 et 2600 par exemple.

– Choix d’un port VOIP : choisissez une valeur entre 3000 et 3999 par exemple.

– Choix de 2 ports, contrôle du port COM : choisissez une valeur entre 4000 et 4999 par exemple et d’une  autre  valeur entre 5000 et 5999 par exemple, si vous disposez d’un rotor et d’autres équipements sur le port série ajouter autant de ligne que vous n’en avez besoin.

Ici je rempli avec ceci :

Port côté serveur radio Port visible côté Internet  Description
22 2235 (TCP) Accès SSH distant
3105 3105 (UDP) Accès VOIP.
4207 4207 (TCP) Accès CRX-COM/Websocket.
5209 5209 (TCP) Accès FLRIG

Mon serveur RASPBERRY aura l’adresse IP :    192.168.1.25    ( ici avec une FREEBOX ).


2. Configuration du serveur « REMOTE » 

Ici j’ai un RASPBERRY sous la main, donc j’ai fait avec, bien sur vous pouvez utiliser n’importe quel PC LINUX que vous souhaitez dédié à l’application « Serveur REMOTE ». Je pense que le hardware RPI est le plus adapté et le meilleur marché pour ce type d’application.

Installation de l’OS ici RASBIAN :

Ici je commence par graver l’image ISO de RASBIAN avec le logiciel WINDOWS WIN32DISKIMAGER sur ma carte SD,
je ne saurai vous recommander une carte SD type SAMSUNG, c’est vendu avec adaptateur mini SD vers SD,
ici j’ai 32Gb ce qui est largement suffisant.

Je vous propose d’installer côté serveur :

– SCREEN ( pour ce qui ne connaissent pas, cela vous permet de lancer vos logiciels dans une console avec un écran par application ).
– CRX-COM ( ici pour le pilotage du poste via port série depuis votre navigateur WEB ).
– PYTHON / COM/TCP ( permet de partager votre port série par le réseau, complémentaire à CRX-COM ).
– PAROLE ( permet de partager l’audio sur le réseau ).
– SEREN ( comme PAROLE il permet de partager l’audio, mais on peut se connecter à plusieurs sur un flux audio ).

Ici on démarre qu’en mode console pas la peine de charger un serveur graphique
qui sert à rien ici, pour ce faire :

Lancez cette commande sur le RASBERRY :

root@f4eyq-raspberrypi1 opt # raspi-config

Dans boot options (3) choisissez « B1 Desktop / Cli » puis : « B1 Console ».
Redémarrez l’ensemble.

Côté réseau :

Ici je créé 2 fichiers texte dans le dossier /etc/network/interfaces.d/ et je met à jour le fichier wpa_supplicant.conf pour la partie WIFI,
Notez que l’interface filaire ne nous sert qu’en cas de ou le WIFI sera HS ou pour des fins de configuration/dépannage.

Voici ma configuration, vous pouvez l’adapter à votre configuration réseau :
( ici j’utilise l’ethernet uniquement en cas de secours si j’ai pas d’écran sous la main ).

root@f4eyq-raspberrypi1 opt # cat /etc/network/interfaces.d/eth0

auto eth0
allow-hotplug eth0
iface eth0 inet static
metric 150
address 192.168.2.100
netmask 255.255.255.0

root@f4eyq-raspberrypi1 opt # cat /etc/network/interfaces.d/wlan0

allow-hotplug wlan0
auto wlan0
allow-hotplug wlan0
iface wlan0 inet dhcp
metric 100
pre-down route del default gw 192.168.1.1
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

root@f4eyq-raspberrypi1 opt # cat /etc/wpa_supplicant/wpa_supplicant.conf

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=FR
network={
scan_ssid=0
ssid="nomdevotrewifi"
id_str="wireless"
psk="votremotdepassewifi"
}


Côté HARDWARE :

Avant de continuer vous devez brancher vos câbles USB sur le RASPBERRY, interface CAT system et autres cartes sons USB si c’est pas déjà fait.
Voici une série de commandes qui vous seront utiles pour mieux connaître la partie HARDWARE : 

root@f4eyq-raspberrypi1 ~ # lsusb
Bus 001 Device 007: ID 0d8c:000c C-Media Electronics, Inc. Audio Adapter
Bus 001 Device 006: ID 148f:2573 Ralink Technology, Corp. RT2501/RT2573 Wireless Adapter
Bus 001 Device 005: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 001 Device 004: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

On y voit :
– Ma carte son USB « C-Media »
– Ma carte WIFI longue portée « Ralink Technology, Corp. RT2501/RT2573 Wireless Adapter »
– Mon interface YAESU USB/série : « Prolific Technology, Inc. PL2303 Serial Port »

Côté cartes sons on peut voir que le RASPBERRY en a une intégrée que l’on ne vas pas utiliser ici :

root@f4eyq-raspberrypi1 ~ # aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: ALSA [bcm2835 ALSA], device 0: bcm2835 ALSA [bcm2835 ALSA]
Subdevices: 7/7
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
Subdevice #4: subdevice #4
Subdevice #5: subdevice #5
Subdevice #6: subdevice #6
card 0: ALSA [bcm2835 ALSA], device 1: bcm2835 IEC958/HDMI [bcm2835 IEC958/HDMI]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: ALSA [bcm2835 ALSA], device 2: bcm2835 IEC958/HDMI1 [bcm2835 IEC958/HDMI1]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: Device [C-Media USB Audio Device], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0

Notez bien que la carte son USB est :  CARD 1 et DEVICE 0    c’est important pour la suite. 
card 1
: Device [C-Media USB Audio Device], device 0: USB Audio [USB Audio]

Notez que ma carte son USB est définie par défaut via cette configuration :

root@f4eyq-raspberrypi1 ~ # cat /etc/modprobe.d/alsa-base.conf
options snd-usb-audio index=-2

Pensez à désactiver le « loopback audio » c’est à dire la copie du sons du haut-parleur vers le micro pour cela,
Lancer alsamixer, choisissez votre micro (via fleches) puis appuyez sur la touche « m » pour faire disparaître le symbole « m » :

Sinon … le son du micro sera renvoyé sur le haut parleur,
je vous laisse apprécié le bazard si vous ne désactiver pas cela !

Côté logiciels serveur :  ( PAROLE/SEREN/CRX-COM/PY-SERIAL ) :

Ici je vous ai préparé ma liste de ce qui est installé sur le RASPBERRY installed-software.log
via :

root@f4eyq-raspberrypi1 ~ # dpkg --get-selections > /opt/installed-software.log

Vous pouvez l’importer directement ma liste et l’installer :

root@f4eyq-raspberrypi1 ~ # aptitude install dselect
root@f4eyq-raspberrypi1 ~ # dpkg --set-selections < /opt/installed-software.log
root@f4eyq-raspberrypi1 ~ # dselect

Ou par groupe :

# apt-get -y install shorewall net-tools screen git cmake build-essential libusb-1.0-0.dev libltdl-dev libusb-1.0-0 libhamlib-utils libsamplerate0 libsamplerate0-dev libsigx-2.0-dev libsigc++-1.2-dev libpopt-dev tcl8.5-dev libspeex-dev libasound2-dev alsa-utils libgcrypt20-dev libpopt-dev libfltk1.3-dev libpng++-dev portaudio19-dev libpulse-dev libportaudiocpp0 libsndfile1-dev
# apt install python-pip
# pip install pyserial

Et pour CRX-COM la documentation d’installation avec RASPBERRY est ici, si besoin : https://project.crx.cloud/crx-com-rasb-ft817

Ici je récupère et installe tout dans /opt/ en root pour ne pas perdre de temps, les droits & la sécurité ça sera au chapitre 5 sécurité.

# mkdir -p /opt/parole/
# mkdir -p /opt/seren/
# mkdir -p /opt/fldigi/
# mkdir -p /opt/cat2tcp/
# mkdir -p /opt/crx-com/app/

# wget http://holdenc.altervista.org/parole/downloads/parole-010beta4.tgz -O /opt/parole/parole-010beta4.tgz
# wget http://holdenc.altervista.org/seren/downloads/seren-0.0.21.tar.gz -O /opt/seren/seren-0.0.21.tar.gz
# wget https://project.crx.cloud/d/CRX-COM-njs-lastest.tgz -O /opt/crx-com/CRX-COM-njs-lastest.tgz
# wget https://github.com/pyserial/pyserial/blob/master/examples/tcp_serial_redirect.py -O /opt/cat2tcp/tcp_serial_redirect.py

Ensuite on décompresse et installons le tout :

# cd /opt/parole/
# tar xvf parole-010beta4.tgz
# cd /opt/parole/parole-010beta4/
# make
# make install
# ldconfig
# ln -s /opt/parole/parole-010beta4/parole /bin/parole

# cd /opt/seren/
# tar xvf seren-0.0.21.tar.gz
# /opt/seren/seren-0.0.21/
# ./configure
# make
# make install
# ldconfig

Ici j’ai donc installé SEREN et PAROLE ici :

root@f4eyq-raspberrypi1 seren-0.0.21 # whereis seren
seren: /usr/local/bin/seren
root@f4eyq-raspberrypi1 seren-0.0.21 # whereis parole
parole: /bin/parole

Ensuite pour CRX-COM :  ( adapter le paquet NODEJS suivant votre matériel RASPBERRY ), ici j’ai ceci :

root@raspberrypi ~ # uname -m
armv6l

Du coup j’installe cette version :

# cd /opt/crx-com/
# wget https://nodejs.org/dist/v10.15.3/node-v10.15.3-linux-armv6l.tar.gz /opt/crx-com/node-v10.15.3-linux-armv6l.tar.gz
# tar -xzf node-v10.15.3-linux-armv6l.tar.gz
# cd node-v10.15.3-linux-armv6l
# sudo cp -R * /usr/local/
# cd /opt/crx-com/app/
# wget https://project.crx.cloud/d/CRX-COM-njs-lastest.tgz -O /opt/crx-com/app/CRX-COM-njs-lastest.tgz
# tar -xzf CRX-COM-njs-lastest.tgz
# npm i

# vim /opt/crx-com/app/config.ini ( on y met ceci )

DISPLAY_DEBUG_NET=1
DISPLAY_DEBUG_COM=1
SILENT_MODE=0
LISTEN_PORT=4207

Voilà une fois tout installé, je vais créer des scripts shell, voici les miens,
vous pouvez les modifier suivant votre configuration.

Gestion du port série : ( en écoute ici sur : tcp 4207 & tcp 5209 )

/opt/run_crxcom.sh

#!/bin/bash
cd /opt/crx-com/app/
node bin.js

/opt/run_netcom.sh

#!/bin/bash
/opt/cat2tcp/tcp_serial_redirect.py -P 5209 --develop --bytesize=8 --parity=N --stopbits=2 /dev/ttyUSB0 38400

Gestion de la VOIP :  ( en écoute ici sur udp 3105 )

/opt/run_voip_parole.sh

#!/bin/bash
/bin/parole -a -l -d plughw:1,0 -b 128000 -p 3105

/opt/run_voip_seren.sh

#!/bin/bash
/usr/local/bin/seren -S -a -n f4eyq-1 -d plughw:1,0 -C 0 -b 128000 -p 3105


Notez bien que :

– On ne pourra lancer qu’un seul script de gestion de port série et VOIP à la fois, tout dépend du contexte,
Ici cela me permet rapidement de basculer d’une configuration à une autre.

Pour accélérer le lancement des 2 solutions, je vous propose mon fichier .screenrc,
qui va lorsque vous allez appeler screen configurer vos écrans et applications :

/root/.screenrc

hardstatus alwayslastline
hardstatus string '%{= kG}[%{G}%H%? %1`%?%{g}][%= %{= kw}%-w%{+b yk} %n*%t%?(%u)%? %{-}%+w %=%{g}][%{B}%m/%d %{W}%C%A%{g}]'
defscrollback 5000
startup_message off
attrcolor b ".I"
termcapinfo xterm 'Co#256:AB=\E[48;5;%dm:AF=\E[38;5;%dm'
defbce on
sessionname "f4eyq-remote-pi"
shell -/bin/bash
screen -t voip 1 /opt/run_voip_parole.bash
screen -t cat 2 /opt/run_netcom.sh
screen -t cmd 3

Pour SCREEN, vous pourez lancer vos logiciels au démarrage du serveur, via une connexion SSH puis simplement en tapant  :

# screen

Cela va vous lancer screen avec les options qu’on a mise dans le .screenrc vous pouvez de là,
Naviguer dans les fenêtres du screen ( ici 3 ) via :   CTRL + a   puis la touche   «  (3)

De là vous pouvez passer d’une fenêtre à l’autre, vous pouvez voir que la VOIP et lancé dans la une ,
le CAT system dans la 2 et dans la 3 j’ai mis un bash disponible pour vos commandes.

Si besoin vous pouvez créer de nouvelles fenetres dans le screen avec :
CTRL + a  puis la touche c

Notez que si vous fermez votre connexion SSH, screen sera toujours lancé avec vos logiciels, et que pour retrouver votre screen,
Vous pourrez le faire via :

# screen -r

Voilà avec ces outils vous avez une solution serveur fonctionnelle, notez aussi que vous pouvez installer un soft de contrôle côté serveur pour ce faire il vous faudra installer HAMLIB aussi sur le RASPBERRY.

Avant de passer à la configuration cliente, on va donc lancer notre serveur ( commande screen ),
Et vérifier que nos programmes sont en écoutes :

root@f4eyq-raspberrypi1 ~ # netstat -plantu
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:5900            0.0.0.0:*               LISTEN      363/Xtightvnc
tcp        0      0 0.0.0.0:6000            0.0.0.0:*               LISTEN      363/Xtightvnc
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      571/sshd
tcp        0      0 0.0.0.0:5209            0.0.0.0:*               LISTEN      1128/python
tcp        0      0 192.168.1.25:22         192.168.1.33:6496       ESTABLISHED 931/sshd: root@nott
tcp        0    400 192.168.1.25:22         192.168.1.33:6513       ESTABLISHED 964/sshd: root@pts/
tcp6       0      0 :::22                   :::*                    LISTEN      571/sshd
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           286/avahi-daemon: r
udp        0      0 0.0.0.0:3105            0.0.0.0:*                           1131/parole
udp        0      0 0.0.0.0:41511           0.0.0.0:*                           286/avahi-daemon: r
udp        0      0 0.0.0.0:68              0.0.0.0:*                           328/dhcpcd
udp6       0      0 :::5353                 :::*                                286/avahi-daemon: r
udp6       0      0 :::44797                :::*                                286/avahi-daemon: r


3. Configuration du client. 

Partie VOIP : 

Pour cette partie, on va comme pour le serveur installer PAROLE et SEREN pour la VOIP, se référer plus haut pour ces opérations.
Ensuite on va créer 2 scripts SHELL qu’on lancera pour activer notre VOIP.

Voici pour exemple mes scripts que vous pouvez adapter à votre configuration :

# cat start_voip_parole.sh

parole -c 192.168.1.25 -p 3105 -b 128000

 

# cat start_voip_seren.sh

seren -t 1 -S -n f4eyq-remote -c 192.168.1.25 -p 3105 -C 0 -b 128000

Sur mon client, je n’ai qu’une carte son, donc pas la peine de la spécifier aux clients VOIP.

Partie CAT :

Ici on pourra faire le pilotage soit via CRX-COM, soit via FLRIG, le principe est simple :
– Envoyer des commandes CAT au TRX via un réseau TCP.

Ici vous pouvez installer via les paquets ou les sources, ici sur UNBUTU j’ai préféré les sources pour flrig, car le paquet de flrig pour UBUNTU comporte un bug à l’affichage des fréquences, cela me permet donc d’avoir la dernière version disponible :

Setup HAMLIB :   ( prendre la dernière version ici :  https://github.com/Hamlib/Hamlib/releases/  )

# mkdir /opt/hamlib/
# cd /opt/hamlib/
# wget https://github.com/Hamlib/Hamlib/releases/download/3.3/hamlib-3.3.tar.gz
# tar xzf hamlib-3.3.tar.gz
# cd hamlib-3.3
# ./configure && make && sudo make install
# ldconfig

Setup FLRIG : ( prendre la dernière version ici : http://www.w1hkj.com/files/flrig/ )

# mkdir -p /opt/flrig/
# cd /opt/flrig/
# aptitude install libfltk1.3-dev
# wget http://www.w1hkj.com/files/flrig/flrig-1.3.50.tar.gz -O /opt/fldigi/flrig-1.3.50.tar.gz
# tar xzf flrig-1.3.50.tar.gz
# cd flrig-1.3.50
# ./configure
# make
# make install

Lancez « flrig », et configurez la partie « TCP » et RIG,
voici ma configuration comme exemple :

Comme vous pouvez le voir j’ai mis 300ms dans le poll interval à vous d’ajuster ce paramètre,
pour une latence minimale (de 100 à 1sec).

J’ai mis 30sec pour le byte interval.

Ensuite dans TCP/IP je renseigne simplement l’IP/ le port du RASPBERRY,
Et dans le ping j’ai renseigné 100 / Retry 5 sec , Applowed drops: 5.


Si vous souhaitez faire des modes numériques, vous pouvez aussi installer FLDIGI, et aussi qjackctl pour la partie câbles audio,
il vous faudra utiliser un câble virtuel pour : relier la sortie son VOIP sur l’entrée son du logiciel radio et idem avec un autre câble,
pour relier le micro de la VOIP à la sortie son du logiciel, je décrirai cela dans un article séparé.

Notez qu’il existe sur la toile des scripts automatisés pour installer FLRIG/FLDIGI, qu’il existe aussi des paquets DEBIAN/UBUNTU,
mais encore une fois il est mieux d’avoir la maîtrise sur ce que l’on installe c’est bien mieux à vous de voir.

Pour CRX-COM, dans le cas ou je n’utilise pas FLRIG voici ma configuration, notez que j’utilise le port TCP 4207 ici,
l’IP WIFI est 192.168.1.25 : ( vous pouvez aussi renseignez l’IP via le VPN/l’IP publique ici suivant votre configuration).

(!) Pensez bien à accepter l’alerte de sécurité sur l’URL HTTPS avant de charger la configuration,
ici :    https://192.168.1.25:4207/

Notez que j’ai tester CRX-COM avec OPEN-VPN et que cela fonctionne bien,
voir partie 6 pour OPEN-VPN si vous devez implémenter un VPN en plus.

4. Configuration de votre box internet & tests :

Ici le serveur sera visible via 4 ports ( avec FIREWALL pour limiter tous les accès à une IP distante ) :
– 1 port pour le contrôle distant : SSH.
– 1 port pour la VOIP.
– 1 port pour le port série via Python.
– 1 port pour le port séria via CRX-COM.

Pour ceux qui utilise OPEN-VPN, dans ce cas, faite passez tous vos ports via le VPN et la VOIP en dehors. Notez que si vous voulez expérimenter vous pouvez aussi faire passer la VOIP par le VPN mais gare à la latence (ping > 300ms).

Reportez vous à la matrice de flux que vous avez définie dans l’étape 1.

Tests :

Ici l’idée c’est de ajuster l’encodage audio et la fréquence de récupération des données CAT suivant :
– Votre débit réseau et celui de votre serveur.
– La latence entre vous et votre serveur. 

Pour ce faire, je vous conseil, un talki VHF, mettre votre station de base sur la fréquence du talki et passer en émission.
Ajuster les scripts que l’on a créé lors de l’installation pour avoir un minimum de latence audio/cat.

Vous pouvez aussi activer le son du micro ( via la commande alsamixer sur le RASPBERRY ), brancher un HP externe sur votre RASPBERRY,
puis comparé le son du HP côté RASPBERRY avec celui de votre client VOIP.

Pour avoir la latence la plus faible, ici je descend à environ 300-500 ms.
Ici vous pouvez ajuster la valeur -b (bitrate) dans les scripts VOIP :

– Ici j’ai mis :  128000
– Vous pouvez ajuster celle ci à minima à 8000 côté client et côté serveur ( on passe alors de 16kb/sec à environ 2kb/sec ).

Si comme moi le CPU de votre RASPBERRY n’est pas une F1 ! , vous pouvez aussi ajuster le -C à 0 sinon vous pouvez le configurer à 3 voir 5 (cela va agir sur la qualité d’encodage OPUS).


5. Sécurité de votre installation : 

Côté matériel :
– Onduleur / parafoudre. ( si possible ).
– Pouvoir brancher/débrancher le poste à distance (via un relais/sortie GPIO du RASPBERRY).
– Certain on même pensé à cela pour les antennes : https://vimeo.com/133917999
– Prévoir un timeout sur l’émission (en cas de coupure réseau) – solution à réfléchir, je suis preneur de vos pistes.

Côté logiciels : 
2 choses à faire ici à minima :
– Essayer au maximum de ne pas tout faire en root, lancer si possible les logiciels avec un utilisateur lambda côté serveur.
– Mettre en place un FIREWALL IPTABLES ici je passe par SHOREWALL un petit outil qui nous génère les règles IPTABLES à la volée.

Voici ma configuration, qui peut vous inspirer je pense :

root@f4eyq-raspberrypi1 shorewall # cat /etc/default/shorewall

startup=1

root@f4eyq-raspberrypi1 shorewall # cat zones

#ZONE TYPE
zfw firewall
zlan2eth ipv4
zlan2wlan ipv4

root@f4eyq-raspberrypi1 shorewall # cat interfaces

#ZONE INTERFACE
zlan2eth eth0
zlan2wlan wlan0

root@f4eyq-raspberrypi1 shorewall # cat policy

#SOURCE DEST POLICY LOG LEVEL
zfw all ACCEPT
zlan2eth all DROP $LOG
zlan2wlan all DROP $LOG
all all REJECT $LOG

Définissez vos IP d’administration / de remote ici par exemple ici : ( vous remplacerez IPADMINSECOURS, IPPUB1.XXX et IPADMIN1 par vos IP )

root@f4eyq-raspberrypi1 shorewall # cat params

LOG=info
MGMT_WLAN=IPADMIN1,IPADMIN2,IPPUB1.XXX
MGMT_ETH=IPADMINSECOURS

root@f4eyq-raspberrypi1 shorewall # cat rules

#ACTION SOURCE DEST PROTO DPORT SPORT ORIGDEST RATE
?SECTION ALL
?SECTION ESTABLISHED
?SECTION RELATED
?SECTION INVALID
?SECTION UNTRACKED
?SECTION NEW

ACCEPT zlan2eth:$MGMT_ETH $FW tcp 22
ACCEPT zlan2wlan:$MGMT_WLAN $FW tcp 22

ACCEPT zlan2wlan:$MGMT_WLAN $FW udp 3105
ACCEPT zlan2wlan:$MGMT_WLAN $FW tcp 4207
ACCEPT zlan2wlan:$MGMT_WLAN $FW tcp 5209

ACCEPT $FW zlan2eth all
ACCEPT $FW zlan2wlan all

Ping(ACCEPT) zlan2eth $FW
Ping(ACCEPT) zlan2wlan $FW

Maintenant qu’on a défini notre politique, on va relancer SHOREWALL, on ne devrait pas avoir d’erreur :

root@f4eyq-raspberrypi1 shorewall # /etc/init.d/shorewall restart
[ ok ] Restarting shorewall (via systemctl): shorewall.service.

En cas de pépin, on peut lister les détails des logs par :

root@f4eyq-raspberrypi1 shorewall # journalctl -xe

Gardez toujours une connexion SSH en plus quand vous configurez votre FIREWALL ( pour ne pas vous couper la branche ! ).
Enfin testez via un  scan de port que tout va bien :   nmap -P0 [ADRESSE IP]   pour voir si votre politique de sécurité est OK,
Puis faite un accès SSH depuis une de vos IP d’administration si tout va bien, votre FIREWALL est fonctionnel.

Une fois tout OK, on met SHOREWALL au démarrage du PI et on redémarre le serveur :

root@f4eyq-raspberrypi1 shorewall # systemctl enable shorewall
Synchronizing state of shorewall.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable shorewall
Created symlink /etc/systemd/system/basic.target.wants/shorewall.service → /lib/systemd/system/shorewall.service.


6. Implémentation d’OPEN-VPN : 

Notez que ici je met à disposition un pack VPN pour les membres VIP du CRX-CLOUD.

Si vous voulez avoir votre propre serveur suivez l’étape « Implémentation OPENVPN côté serveur »,
sinon contacter moi pour obtenir votre pack client.

Ici je vous propose de voir comment implémenter la partie OPEN-VPN côté client et pour les plus motivés/experts d’entre vous côté serveur,
voici le récapitulatif :

[RASPBERRY-PI:Client OPENVPN] ————-[INTERNET] [ SERVEUR OPEN-VPN ] [INTERNET] ————- [ PC-CLIENT : Client OPENVPN ]

Implémentation OPENVPN sur le client :

La configuration OPENVPN et presque similaire à WINDOWS et LINUX.

Pour WINDOWS, voici ma configuration, celle-ci se trouve ici :
C:\Users\{utilisateur}\OpenVPN\config\   elle doit être avec l’extension « .ovpn » :

client
dev tun
proto tcp
remote monserveurvpn 8443
resolv-retry infiniteµ
nobind
persist-key
persist-tun
remote-cert-tls server
ca ca.crt
cert f4eyq-laptop1.crt
key-direction 1
key f4eyq-laptop1.key
tls-auth ta.key 1
cipher AES-256-CBC
auth SHA256
#comp-lzo
verb 0

Celle-ci utilise ces fichiers de « chiffrements » en provenance de ma PKI :

ca.crt
f4eyq-laptop1.crt
f4eyq-laptop1.key
ta.key

Pour LINUX, voici ma configuration sur le RASPBERRY :

client
dev tun
proto tcp
remote monserveurvpn 8443
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
ca ca.crt
cert f4eyq-raspberrypi.crt
key-direction 1
key f4eyq-raspberrypi.key
tls-auth ta.key 1
cipher AES-256-CBC
auth SHA256
verb 0


Implémentation OPENVPN côté serveur :

Cette étape n’est à suivre que si vous souhaitez avoir votre propre serveur VPN (il vous faudra un serveur dédié sur Internet au mieux ou au pire votre connexion ADSL/FIBRE mais avec une adresse IP fixe).

Là cela se corse un peu niveau technique, car vous allez devoir utiliser une PKI pour générer les clés et certificats des clients VPN.
Ici j’utilise que l’OS DEBIAN, mais cela fonctionne sur tout serveur LINUX.

Configuration de votre « PKI » :

Je commence par installer EASY-RSA, c’est un ensemble d’outil pour gérer une PKI LINUX, celle-ci est souvent utilisée avec OPEN-VPN.

cd /opt/
git clone https://github.com/OpenVPN/easy-rsa.git
cd /opt/easyrsa/easyrsa3/
cp vars.example vars

Dans le fichier vars, je vais modifier ceci :

export KEY_COUNTRY="FR"
export KEY_PROVINCE="IDF"
export KEY_CITY="VilleDeMonServeur"
export KEY_ORG="monVpn"
export KEY_EMAIL="admin@mondomaine.fr"
export KEY_OU="myOu"

Ensuite je vais définir la durée de vie des certificats que je génère : (ici 1 an pour les clients et la clé du serveur PKI l’AC elle vivra 5 ans).

set_var EASYRSA_CA_EXPIRE 1825
set_var EASYRSA_CERT_EXPIRE 365

Ensuite je commence par initialiser ma PKI :

# ./easyrsa init-pki

Puis l’AC qui me servira à signer et générer les certificats clients :

# ./easyrsa build-ca nopass

Maintenant je peut générer le certificat de mon serveur VPN :

# ./easyrsa gen-req monserveurvpn nopass
# ./easyrsa sign-req server monserveurvpn

Cela va générer 2 fichiers :

=> /opt/easyrsa/easyrsa3/pki/issued/monserveurvpn.crt
=> /opt/easyrsa/easyrsa3/pki/private/monserveurvpn.key

Maintenant je génère les clés de sécurité utilisé côté clients/serveur :

# ./easyrsa gen-dh
# openvpn --genkey --secret ta.key

Cela générer 2 fichiers :

=> /opt/easyrsa/easyrsa3/ta.key
=> /opt/easyrsa/easyrsa3/pki/dh.pem


Configuration du service OPEN-VPN cible : 

Maintenant que j’ai généré tous mes fichiers de chiffrement, je peux attaquer la configuration du service OPEN-VPN,
Ici par sécurité on peut utiliser une VM dédiée pour la PKI ou tout faire sur le même serveur à vous de voir :

Je déploie ici mes fichiers de ma PKI vers mon service OPEN-VPN :

cp /opt/easyrsa/easyrsa3/ta.key /etc/openvpn/server/ta.key
cp /opt/easyrsa/easyrsa3/pki/ca.crt /etc/openvpn/server/ca.crt
cp /opt/easyrsa/easyrsa3/pki/issued/monserveurvpn.crt /etc/openvpn/server/server.crt
cp /opt/easyrsa/easyrsa3/pki/private/monserveurvpn.key /etc/openvpn/server/server.key
cp /opt/easyrsa/easyrsa3/pki/dh.pem /etc/openvpn/server/dh2048.pem

Et enfin sa configuration cible, je ne rentre pas dans les détails techniques, si vous avez besoin une documentation est fournie en ligne sur le site OPEN-VPN :

port 8443
proto tcp
dev tun
ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/server.crt
key /etc/openvpn/server/server.key
dh /etc/openvpn/server/dh2048.pem
topology subnet
server 10.77.0.0 255.255.0.0
ifconfig-pool-persist ipp.txt
client-config-dir /etc/openvpn/ccd
ccd-exclusive
client-to-client
duplicate-cn
keepalive 10 120
tls-auth /etc/openvpn/server/ta.key 0
auth SHA256
cipher AES-256-CBC
persist-key
persist-tun
status openvpn-status.log
verb 5

Ici j’utilise un fichier par client dans le sous-dossier « ccd » :
Mais c’est optionnel si vous définissez votre pool d’IPs clientes.

Exemple :

# cat /etc/openvpn/ccd/f4eyq-raspberrypi
ifconfig-push 10.77.0.25 255.255.255.0

Voilà j’espère que ce guide vous aura aidé dans la réalisation de votre « remote station config open source ».
N’hésitez pas à me contacter si vous avez des remarques/idées sur le sujet ( f4eyq ( at ) crx.cloud ).

73 à tous !

Notes :
OS RASBIAN :  https://www.raspberrypi.org/downloads/raspbian/
WIN32DISKIMAGER : https://sourceforge.net/projects/win32diskimager/

Softs VOIP testés sous LINUX :
PAROLE :          http://holdenc.altervista.org/parole/index.html
SEREN :            http://holdenc.altervista.org/seren/index.html
IC706 :               https://github.com/csete/ic706-remote/blob/master/src/audio_server.c
MUMBLE/MURMURE.

Contrôle distant :
CRX-COM :      https://project.crx.cloud/crx-com-rasb-ft817

Firewall :
SHOREWALL :  https://shorewall.org

Solution VPN :   https://openvpn.net

Solution Windows testée :
Windows : MUMBLE/MURMURE/SKYPE + HAM Radio Deluxe client/serveur,
Et VIRTUAL AUDIO CABLE pour les modes digitaux en VOIP.

Articles relatifs :
Welcome

Remote ham radio operation through a Raspberry Pi

New-FLDIGI Install Script for Raspberry Pi (Latest Version – 3.23.13)

Matériels :
Férites : https://fr.aliexpress.com/  ( cherchez ferite, vous y trouverez votre bonheur ).

CAT-SYSTEM en WIFI.

Bonjour à tous,

J’ai déjà eu l’occasion auparavant de décrire le fonctionnement de CRX-COM avec un RASBERRY ici, aussi voici un exemple de configuration, pour piloter votre poste émetteur/récepteur depuis le réseau WIFI chez vous, avec un petit RASBERRY, une clé WIFI et une interface USB/COM.

1. Configuration système du RASBERRY 

Ici le RASBERRY est branché occasionnellement avec un cable réseau, le reste du temps il est en WIFI,
voyons faire comment faire une configuration de base pour cela :

On configure le fichier  /etc/dhcpcd.conf  avec ceci :

interface eth0
metric 150
static ip_address=192.168.2.100/24
static routers=192.168.2.1
static domain_name_servers=8.8.8.8 192.168.2.1

interface wlan0
metric 100
inform 192.168.1.11
static routers=192.168.1.1
static domain_name_servers=8.8.8.8 192.168.1.1

Et notre fichier /etc/network/interfaces avec cette configuration à adapter bien sur suivant votre réseau :

auto eth0
allow-hotplug eth0
iface eth0 inet static
metric 150
post-up route add default gw 192.168.2.1 metric 150
pre-down route del default gw 192.168.2.1
address 192.168.2.100
netmask 255.255.255.0

allow-hotplug wlan0
auto wlan0
allow-hotplug wlan0
iface wlan0 inet dhcp
metric 100
pre-down route del default gw 192.168.1.1
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

Ensuite la configuration du réseau WIFI avec ceci :

root@raspberrypif4eyq ~ # cat /etc/wpa_supplicant/wpa_supplicant.conf
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=fr
network={
scan_ssid=0
ssid="monsuperwifi"
id_str="wireless"
psk="votre clé wifi"
}

#application de la nouvelle conf:
root@raspberrypif4eyq ~ # wpa_cli -i wlan0 reconfigure

Puis configuration du système de fichier, ici pour ne pas crammer la carte mémoire du RASB trop vite, je met les logs en RAM :

root@raspberrypif4eyq opt # cd /opt/
root@raspberrypif4eyq opt # git clone https://github.com/azlux/log2ram.git
root@raspberrypif4eyq log2ram # ./install.sh
Created symlink /etc/systemd/system/sysinit.target.wants/log2ram.service → /etc/systemd/system/log2ram.service.
##### Reboot to activate log2ram #####
##### edit /etc/log2ram.conf to configure options ####

Ensuite on redémarre le tout.

2. Configuration NODEJS et CRX-COM 

Maintenant passons à l’installation de CRX-COM :
=> Pour installer NODEJS, il suffit de suivre ce que j’ai noté ici : https://project.crx.cloud/crx-com-rasb-ft817

Ensuite pour CRX-COM, on télécharge la dernière version, puis on décompresse et installe le tout :
Toujours dans le /opt/ :

mkdir /opt/crx-com/
wget https://project.crx.cloud/d/CRX-COM-njs-lastest.tgz
tar xvzf CRX-COM-njs-lastest.tgz
npm i

Quelques minutes plus tard notre RASBERRY est prêt, je peux donc lancer le programme, notez que j’utilise la commande screen, pour pouvoir lançer celui en tache de fond (et quitter le SSH si je veux), tout en pouvant revenir quand je veux et visualiser la console du programme :

screen
cd /opt/crx-com/
node bin.js

Si je reviens, pour ceux qui ne connaissent pas screen, il faut taper cette commande pour recharger le screen :

screen -r

Voici ma configuration côté CRX :

La seule chose spécifique est que je renseigne l’adresse IP du RASB sur mon LAN,
Notez aussi que le port   /dev/ttyUSB0 est visible comme si il était en local.

73 à tous et bon courage pour ce confinement !

PS:
Page du projet : https://project.crx.cloud/crx-com
Configuration RASBERRY : https://project.crx.cloud/crx-com-rasb-ft817

Iota Contest 2019 – TM5S

RSGB IOTA Contest 2019 – TM5S
Compte rendu : F4EYQ

Après pas mal de réflexion, nous avons décidé cette année de poser les antennes sur l’Ile de Sein.
Pour commencer ce compte rendu je souhaite commencer par citer un proverbe africain « Si tu veux aller vite, vas-y-seul mais si tu veux aller loin, alors il faut y aller ensemble ».

Merci tout d’abord aux OM de F5KKD pour m’avoir proposé leur aide à Fabien F4GYM pour sa collaboration et bien sûr à l’équipe de F6KOP & le DXCLIPERTON pour leur soutien, à mon amis Didier habitant & peintre sur l’Ile de Sein pour son aide.

Pour mon 8ème IOTA CONTEST, je dois dire que nous avons traversé pas mal de difficultés pour réaliser à monter une équipe surtout sur le plan « humain ».

Au final nous avons quand même réussi à 2 opérateurs & avec l’aide de mon père à monter cette expédition. C’est probablement la première fois que je n’ai fait que très peu de chose côté logistique même si j’avais préparé en amont un plan d’action, c’est Fabien qui s’en est occupé et avec l’aide de pas mal d’OM que je tiens aussi à remercier au passage.

Nous avons chargé le matériel à Audierne comme à l’accoutumé pour aller sur l’Ile, cette année pas de SPIDERBEAM comme avant mais uniquement des ¼ d’ondes, qui ont final on bien rempli leur rôle (et aussi fait pas mal de discussion sur les réseaux sociaux quant à la taille des radians), côté ADN l’antenne est configurée en « portable/expédition » et non en mode concourt, de toute façon cela nous importe peu vu que le dégagement Nord/Nord Est n’est pas bon ( avec des maisons et des bateaux autour ) nous chercherons pour la prochaine fois de meilleurs performances, le résultat côté Antennes est déjà très QRO.

Le bivouac s’organise avec le montage des antennes 80/40/20m mais au moment de brancher le 220v nous nous rendons compte qu’EDF n’a pas activé compteur initialement prévu !

Action / réaction nous allons monter une succession de rallonge pour récupérer du courant depuis le hangar de Didier. Cela nous permet enfin de démarrer, après 1H de bataille avec WINTEST nous prenons le départ de ce concourt des îles 2019 avec un peu de retard.

Cela ne nous empêche pas de rattraper le temps perdu car nous nous en rendons compte en distribuant les numéros / report radio / numéro de IOTA.

Nous nous décidons à faire des sessions de 2H en journée & 3H la nuit ce qui est au final très suffisant pour 2 opérateurs, Seul petit bémol c’est le manque d’un perroquet pour lancer les QSO mais bon cela donne un petit côté SPORT qui n’est pas désagréable.

Le soir est plutôt sympa et nous permet de faire pas mal de DX, Après une nuit assez difficile la partie 0AM-6AM est probablement la plus dure pour les opérateurs.

Nous prenons la suite pour la dernière ligne droite, J’ai la chance de faire la dernière heure qui va je dois dire très vite en terme de QSO.

Et voilà 550 c’est déjà fini, nous regroupons tout le matériel et le lendemain soir nous rentrons sur Audierne, avec une belle tempête en prime … : )

End ! see you on next IOTA CONTEST,
TM5S 2019.

tm5s

Grand Raid du Golf du Morbihan 2019

Même si c’est dur, même si parfois on abandonne,
on y retourne, vous vous demandez pourquoi ?
et bien voici une partie de la réponse 😉

Après 6 mois de préparation et 2450km parcouru cette année place au bilan, j’ai pris le départ de ce Grand Raid avec un sac un peu trop lourd (5.8kg) une méteo (33-34° au départ) un peu trop chaude (le départ a été décalé d’une heure du fait de la chaleur) et … des chaussettes un peu trop serrées !Sur cette édition du GR, c’était ma première fois dans le sens anti-horaire, je l’avais déjà fait 2 fois dans le sens horaires ( avec un maximum de 130 km )  d’une année sur l’autre cela peut changer. Cette année nous avons eu la partie très technique en premier ( avec un énorme escalier au     50 ème km ou je peux vous dire que tout le monde râle ! s’en suit des escaliers et des alternances de sentiers côtier / petites côté et route, pour en fin de nuit finir par de grosse portions de sentiers dans une brume épaisse.

Et là soulagement le lever de soleil, je peux vous dire qu’on en prend plein les yeux et ça fait du bien, ensuite c’est principalement que du sentiers jusqu’au bateau qui nous amène de  l’autre côté du Golf.Ici, je ne regrette pas un seul instant de ma préparation n’y de ma course même si j’ai abandonné un peu avant le 110 ème kilomètre, j’ai quand même pris du plaisir sur la première partie de course. Mentalement j’ai tout donné, mais j’ai fait des erreurs qui m’on stoppé à un moment « charnière » de la course à savoir le passage au 100 ème, j’ai forcé jusqu’au 110 mais je n’ai pas pu aller plus loin.

J’ai noté cette fois ci tout ce qui m’a posé problème pour ne pas reproduire ces erreurs, la plus importante ayant été la préparation que j’ai axé sur le double de temps ( + de 20 semaines au lieu de 12 ) et d’après ce que m’a indiqué un amis « pro » sur le sujet, j’aurai du partir sur un système pyramidal sur 12 semaines là j’ai fait l’inverse j’ai enchaîné des semaines à 100/130km et trop de distance mais pas assez de volume au final j’aurai pu arriver sur la course beaucoup plus « frais ». 
 

Côté sac, il était environ 1kg trop lourd par rapport aux autres personnes, j’ai porté des chaussettes de « contention » et .. j’ai eu le malheur de les retirer à mi course pour les changer … du coup mes pieds sont devenu très enflés, normalement j’aurai porter ce type de chaussette sur une distance maximum d’un marathon …

Pour la prochaine, cela sera donc pas de changement de chaussettes, ni de douche au 100  ème, juste une toilette de chat 🙂 et surtout pas de chaussettes de contention, par contre la contention sera sur les mollets (je validerai d’ailleurs cela l’année prochaine sur le 80km et un peu avant sur le marathon).

Bon point positif avec un sac un peu plus lourd, je n’ai pas du tout souffert côté hydratation, je n’ai jamais manqué d’eau et il m’a resté en permanence à l’arrivée des ravitaillements environ 300 à 600 ml, j’avais une poche à eau salomon dans le dos de 1.5L + 2 bidons de vélo de 650ml   ( c’est cela que je retirerai prochaine fois, je remplacerai par une flasque de 650ml ) , côté nourriture j’avais 2x 3800kcal et bien j’ai mangé les 3800 premières kcal jusqu’au 100 ème sans problème je pense qu’hormis les pieds cela m’a permis de mieux encaisser la course (pour la prochaine je pense que je passerai à 3000~3400 max), j’ai vu certains se passer des bidons et être en manque d’eau donc côté eau c’était plus bien.

Enfin dernière erreur qui m’a été je pense fatale, la première nuit, j’ai trop « bombardé » dans certains sentiers, il faisait plus frais et j’avais de bonne sensations passé le 40 ème et je pense que les chaussettes de contentions combiné à la dizaine de racine que j’ai cogné mon abîmé les pieds mais sans me faire de douleurs sur le coup, probablement à cause de l’adrénaline.

J’aurai simplement ralenti là dedans, j’aurai gagné de précieux km pour la suite en terme de fraîcheur, j’inclurai d’ailleurs cela dans ma prochaine préparation sur le travail « mental » je pense que c’es la clé ici à savoir la patience dans l’effort.

Côté sommeil , j’ai dormi 10 min la première nuit + 30 min environ au niveau du 100 ème kilomètre, pour la prochaine fois je ferais 20+20 puis 10 min sur la fin si besoin.
 
Au final c’est une belle leçon car la difficulté du GR c’est justement que plus on avance moins … il y a de difficulté ( cela semble aussi interminable entre 2 ravitaillements ). Mentalement j’ai tout donné, j’ai arrêté quand la douleur aux 2 pieds s’est propagé aux genoux pour ne pas abîmer mon corps et me dégoutter de l’ultra marathon.

Pour la suite, je repart sur une préparation marathon pour en courir un d’ici fin de l’année 1er trimestre l’année prochaine (pour étalonner mes performances pour 2021 à savoir < ou > à 3″h30 sur marathon : inf. ou sup. à 30h sur le GR).

Je serai en 2020 je serai sur le petit format du Golf à savoir le raid de 87 km histoire de me faire plaisir et reprendre confiance sur du plus court et dans 2 ans donc 2021, je remet le couvert avec une 4 ème participation au grand raid, je l’aurai un jour ! je l’aurai 😉

Voilà maintenant place à la récupération, pour 3 semaines à rien faire (côté sportif), si ce n’est quelques footings d’ici 2 semaines sur le GR34 voir si je sais toujours courir !  Merci pour vos encouragements, et merci à mes proches pour leur soutien dans toute la préparation.
 
Kennavo, 

Aller au vélo au boulot, pourquoi ?

C’est une vaste question, tout d’abord la chose la plus importante, on ne choisi pas le moyen de transport en premier,

on regarde quel est la DISTANCE entre son domicile & son travail, puis ses capacités physiques.

Pour nos amis automobiliste la distance est synonyme de carburants, de taxe ou de batterie pour les autres.

A vélo, faut pas se tromper, 30 bornes c’est je pense le maximum pour le vélo, vous allez voir pourquoi …

Ici j’ai de la chance sur Nantes d’avoir toujours été à moins de 10km, soit aller/retour 20km par jour.

Du coup une fois qu’on pense être capable de le faire, il reste un facteur important,

La transpiration !!! et oui, arriver au boulot en mode « transpi » c’est pas agréable pour les collèges.

Du coup ici j’opte pour ne pas « bombarder » sur la route, ainsi je roule tranquillement, pas question de courir le tour de France juste avant une réunion.

Force de ce constat j’ai vu arriver les vélos électriques & trottinettes et là çà a commencer par du gros n’importe quoi,

Personnellement je pense que ces personnes devraient être exclues de la loi proposée pour les vélos.

Sauf si bien sur ils se mettent à respecter ceux qui , n’ont pas de propulsion autres que leurs jambes … mais ceci et un autre débat.

Ici j’ai fait le choix du vélo depuis mes 15 ans, je n’ai plus jamais arrêté sauf pendant un passage de 7 ans sur la région parisienne mais c’est plus par la force des choses que j’ai du faire cette pause comme tous les parisiens qui n’ont pas le choix d’ailleurs.

Il y a peu, j’ai entendu l’arrivée d’une loi pour proposer aux entreprises d’indemniser leurs employés

Alors du coup, vu qu’ici je n’ai jamais rien demandé à personne pour faire du vélo ( vu que j’aime cela et que c’est mon choix )

je me suis dis la chose suivante :

Quand tu pédales comme un con dans le froid l’hiver et que les collègues eux sont en mode « sofa/clim/moteur ou transport commun »,

tu te fais chier pour rien, mais avec une carotte ( genre la prime d’indemnisation ) ça serait mieux pour toi ?

A bon ! en fait pas du tout ! Cela change absolument rien.

Du coup que faire de ces indemnités (plafonnées à 400€/ans si j’ai bien compris) ? Et bien figurer vous qu’un vélo cela s’entretient, ici j’ai un budget d’environ 10 euros par mois

pour cela ( j’y inclus une révision DECATHLON une fois par an car je roule beaucoup et c’est plus pour être en sécurité ).

Au final, les automobilistes dont je ne fait pas parti ( puisque je ne roule qu’à vélo ) diront :

Des indemnités pour cela ? Haha, si tu savais combien je paye de crédit voiture voiture, ou de carte SNCF/RATP etc …. et sans compter mon assurance …

Je répondrai à cela : Je roule à vélo c’est mon choix, vous roulez avec 4 roues/une vignette/un moteur, du carburant, une vignette, des emmerdes … c’est le votre !

J’attend avec impatience la suite des débats, mais je ne me fait pas d’illusions, le président a annoncer l’obligation, de verser les indemnités qui sera passé sous ordonance, du coup je rigole doucement car :

Compter les kilomètres tous les jours à vélo ?

Je veux bien j’ai un GPS aucun soucis,

mais si je roule à vélo, Je roule à vélo pour ma santé à la différence de tous ces gens liées à leurs véhicules motorisés 😉

Alors oui, je prendrai tous les jours 2 chemins, peut être 3 suivant les jours,

Mais jamais personne ne me dictera de prendre le chemin plus cours ( cf texte de loi), le mesurer au GPS,

pour 33.3333€ par mois 😉

#VELO #BOULOT #DODO

Control your radio transceiver from your web browser

About 5 years ago, i’ve create a small php script to control my YAESU FT817 via APACHE server and a LINUX box,
since this moment, i have work on my « cloud » for HAM radio « www.crx.cloud » and I thought about how to have the most powerfull system and on the cloud.

During this time, i’ve test various project a DLL for IE/Firefox for serial COM port operation with Javascript,
also a Google Chrome application and extension to do this job.

In parallel I discovered NODEJS and also the WEBSOCKETS with Socket.IO, suddenly I left on this concept:

– A NODEJS application that fulfills the role of WEBSOCKETS server and also allows to control the serial port.

– On the other a client, in the browser using JAVASCRIPT and WEBSOCKETS to connect to the server via his WEB BROWSER.

 

 

Thus the user launches the server in the background on the PC he wants. Then it connects to it from any browser (CHROME / FIREFOX or OPERA).

On the protocol side, each radio equipment manufacturer uses its own system except for some of the groups, so I had to deal with that, so I grouped:

– yaesu1 / icom1

– kenwood1 / elecraft1 / yaesu2

Why that ? simply because the method of writing and reading the serial port is not the same.

On one side are hexadecimal values ​​for ICOM / YAESU and on the other character strings for YAESU2 / KENWOOD1.

Finally in terms of protocol ICOM uses identifiers for each of their equipment, against the procole remains the same,
so even if the code is more complicated to use their protocol, it’s quite simple in the end to control. YAESU side,
it’s not the same thing because there are 2 different protocols.

Funny thing also at YAESU protocol V1 the radio returns frequency and mode in the same frame … so I had to adapt my code
so that it works in all situations, so JAVASCRIPT side I had to use the Promise class here allows to control the execution
of an asynchronous task before launching another example:

– My client JS asks the server: What is the frequency?

– He must wait before asking what is the mode,

Otherwise the remote NODEJS server will not be able to execute commands on the serial port and may overlap with them.

This is where the JS Promise class comes into play.

Then I created a class javascript by constructor to generate the commands, the most complicated being that
for ICOM because of the calculations and the changes of bases to operate (with binary shift for example).

Note that for the moment the system is not perfect because on the part NODEJS I still have books of reading specific to each
manufacturer in the long term I would like to do these operations also on the client side JS / WEBSOCKET and not side NodeJS.

Finally for the moment, the project is in « beta » because I do not have hardware kenwood1 / yaesu2
so I advance the code thanks to feedback from users.

If you want to see what this gives:

Server CRX-COM (NODEJS):
https://git.crx.cloud/f4eyq/crx-com

Client part (JS Web browser) CRX-CLOUD:
https://git.crx.cloud/crx-php/crx-cloud-ham/tree/master/app-php/crxComClient
https://git.crx.cloud/crx-php/crx-cloud-ham/tree/master/app-js/crxComClient

I also posted a little documentation to explain all this here:
https://project.crx.cloud/crx-com

And a diagram is available here:
https://project.crx.cloud/crx-com-schema

73  to   all

Prévoir la propagation d’ondes HF avec le machine learning.

Depuis juin 2017, je travaille sur un projet de prédiction de propagation des ondes HF pour les radioamateurs, disposant d’une base de données conséquente contenant des « dxspots » radioamateurs (un dxspot étant un contact radioamateur établi sur une fréquence donnée, celui ci est partagé sur un réseau mondial appelé dxcluster auquel tous les radioamateurs ont accès) et des infos de propagations NOAA (National Oceanic and athmospheric administration), j’ai mis au point une application de prévision  » CRX Météo radio » basée sur du machine learning, l’idée est assez proche de ce que l’on trouve en finance pour faire de prévision d’ailleurs j’ai pu lire un exemple développé avec cette librairie fait pour analyser des données financières.
Lire la suite « Prévoir la propagation d’ondes HF avec le machine learning. »