Dans le cas présent, le TRX utilisé est un TS-590s qui possède deux connecteurs d’antennes que l’on peut commuter en envoyant une commande CAT de type « AN199; » pour Ant1 et « AN299; » pour Ant2.

L’idée est donc d’envoyer l’une ou l’autre de ces commandes alternativement, toutes les 2 minutes, juste avant que le cycle WSPR commence, suivant une table établie à l’avance, ce qui permet après dépouillement des données de savoir quelle antenne était en service.

L’enchainement du batch qui suit est très simple :

- Ouverture du port COM correspondant au TRX
- Pause d’une seconde (début de boucle)
- Si on est aux secondes 56, 57 ou 58, lecture de l’heure et extraction de la minute, sinon on retourne au début de la boucle d’attente
- En fonction de la minute, on commute soit Ant1, soit Ant2 pour le cycle qui va démarrer et on retourne au début de la boucle d’attente

La raison pour laquelle on envoie la cde CAT 3 fois de suite aux secondes 56, 57 et 58, est que le TS-590s est partagé entre plusieurs applications (avec des port COM virtuels), et que dans certains cas, il y a collision avec les envois CAT des autres applications (WSPR, et Win-Test). En envoyant la commande 3 fois de suite (méthode dite « bourrin »), on réduit les chances de collisions. Dans le cas d’une installation plus simple, un seul envoi serait suffisant.

Si on utilise un autre TRX qui possède 2 antennes commutables (TX et/ou RX), il suffit d’adapter la commande CAT à envoyer.

@ECHO OFF
REM Alternate TX Ant 1 and TX Ant 2, depending on the WSPR cycle
REM by sending a CAT command to the TS-590s 3 sec before
REM the WSPR cycle starts

REM (C) F6FVY - July 2019

REM xx00z, xx20z, xx40z : TX ant 1
REM xx02z, xx22z, xx42z : TX ant 2
REM xx04z, xx24z, xx44z : TX ant 1
REM xx06z, xx26z, xx46z : TX ant 2
REM xx08z, xx28z, xx48z : TX ant 1
REM xx10z, xx30z, xx50z : TX ant 2
REM xx12z, xx32z, xx52z : TX ant 1
REM xx14z, xx34z, xx54z : TX ant 2
REM xx16z, xx36z, xx56z : TX ant 1
REM xx18z, xx38z, xx58z : TX ant 2

REM COM port settings
mode COM9 BAUD=57600 PARITY=n DATA=8 STOP=1 >nul

:start
ECHO Waiting for time to switch TX antenna...
set ANT=

:loop
timeout /t 1 /nobreak > nul

REM Check if sec is 56, 57 or 58
REM So several CAT commands can be sent
REM in a row to prevent COM port congestion
REM or conflict with other apps

set SEC=%TIME:~6,2%
IF "%SEC%" LSS "56" GOTO loop
IF "%SEC%" GTR "58" GOTO loop

REM Check min mod 20 value

REM Note the "MIN=1%MIN% - 100"
REM trick to prevent "08" and "09"
REM to be considered as an
REM invalid octal ! WTF M$ !

set MIN=%TIME:~3,2%
set /a "MIN=1%MIN% - 100"
set /a "MOD20=%MIN% - ((%MIN%/20)*20)"

IF "%MOD20%" == "1" GOTO txant2
IF "%MOD20%" == "3" GOTO txant1
IF "%MOD20%" == "5" GOTO txant2
IF "%MOD20%" == "7" GOTO txant1
IF "%MOD20%" == "9" GOTO txant2
IF "%MOD20%" == "11" GOTO txant1
IF "%MOD20%" == "13" GOTO txant2
IF "%MOD20%" == "15" GOTO txant1
IF "%MOD20%" == "17" GOTO txant2
IF "%MOD20%" == "19" GOTO txant1
GOTO loop

REM To be safe, several commands are sent in a row
REM but display ant status once only

:txant2

set /p x="AN299;" <nul >\\.\COM9
IF "%ANT%" == "TX2" GOTO loop
ECHO TX ant 2 ON
set ANT=TX2
GOTO loop

:txant1

set /p x="AN199;" <nul >\\.\COM9
IF "%ANT%" == "TX1" GOTO loop
ECHO TX ant 1 ON
set ANT=TX1
GOTO loop

Il ne reste donc plus qu’à lancer le batch, et constater que l’antenne est bien commutée automatiquement juste avant le début de chaque cycle WSPR.

Après quelques heures de fonctionnement, il n’y a plus qu’à récupérer les données sur wsprnet.org, ou wspr.rocks et les dépouiller pour pouvoir comparer les deux antennes.

73

Laurent – F6FVY

Tout d’abord, un grand merci à Jean-Pierre F10298 et SWL Benoit Tigeot pour leur aide et leur présence indéfectible, aussi bien pendant l’installation de notre stand, que pendant la durée de la manifestation.

Stand ARP (Jean-Pierre et Benoît)

Merci également à Hervé F5HRY/91, membre de l’ARP, qui n’a pas hésité à décaler son retour sur Paris lors de ce week-end prolongé afin de venir nous visiter et nous soutenir Dimanche après-midi.

Sachez que cette édition de la Maker Faire, que les organisateurs ont eu la bonne idée de coupler en partie à la Foire de Paris, a recensé plus de 35 000 visiteurs sur les deux jours (alors que 8 000 seulement s’étaient déplacés l’an dernier).

La Maker Faire Paris est désormais entrée dans la cour des grandes Maker Faire européennes, sans néanmoins encore atteindre la fréquentation celles de Bay Area (San Francisco) ou New York qui comptent chacune plus de 100 000 visiteurs par an.

Un visiteur un peu particulier…

Concernant plus précisément notre participation, les conditions d’installation ne permettaient pas vraiment de couvrir tous les aspects de notre hobby, et les restrictions liées à la sécurité des lieux n’autorisaient que l’érection d’aériens minimaux.

Nos antennes de réception minimalistes

Nous nous sommes donc limités à des démonstration de réception ADSB, et de modes numériques (RTTY, WSPR), sachant également que le bruit ambiant, aussi bien audio (notre stand était entouré de sirènes, de robots musiciens, d’un guitariste fils spirituel de Jimmy Hendricks, et d’un bricoleur aimant particulièrement jouer de son « canon à bonbons ») que HF (S9 + 30 de bruit lorsque les bobines Tesla situés à 50m de nous étaient en service) interdisait le calme que requiert la démo d’un QSO phonie par exemple…

Bobines Tesla

Robots band

Néanmoins, le flux incessant des visiteurs nous a permis de démontrer que notre hobby existait toujours (!), et qu’on pouvait s’y intéresser avec peu de moyens, ce qui est, grosso modo, le leitmotiv des « makers ».

Atelier de soudure

Comme en 2014, l’ARP a obtenu un ruban bleu (Editor’s Choice Blue Ribbon) qui récompense les exposants pour leur créativité, leur ingéniosité et l’innovation.

Ruban bleu décerné à l’ARP

Bref, un intense week-end prolongé, mais une participation qui sera probablement reconduite lors de l’édition 2016.

Étaient présents : Bernard F6BVP, Laurent F6FVY, Denis F4FBP, Marc F6DTB, Serge F6DZS, Ivan F4CKF, Irénée F6GAL, Alain F6BSV, Benoit Tigeot SWL, Jean-Marc F3JP, Jean-Pierre F10298, Michel F5GNZ, Michel F5MSO, Nicolas F1RAF. Michel F3KT/44 et Marie-Pierre F5DN/74 assistaient également à la présentation, par l’intermédiaire d’un connexion Mumble sur F6KVP-1.

Contenu de la conférence

Présentation générale du « parcours » OM de Bernard F6BVP

Montage de kits en ateliers ARP : récepteur SDR 40m (07/07/2007)

DV Dongle – AP DSTAR

Revue QST « spécial Raspberry Pi »

Raspberry Pi model B (512Mb)

• + carte SD 8 Go pour le système d’exploitation Linux
• + carte TNC Pi sur bus GPIO

Nouveau modèle B+ (sortie en juillet 2014)

• - pas de sortie RCA + carte micro SD + 4 ports USB + 40 GPIO
• + système RASPBIAN

Module caméra

Nouveau modèle A+ simplifié (sortie en novembre 2014) vendu $20 !

Site de Raspberry.org en français

Livres « the MagPi »

Sites :

• http://www.tropfacile.net en français dédié au RasPi
• http://www.raspfr.org/
• http://the-raspberry.com/
• http://ocw.mit.edu/index.htm MIT OPENCOURSEWARE, cours gratuit pour Python

Applications radioamateur innombrables

• Packet AX25 1200 bauds
• DX Spider
• APRS
• Xastir client APRS
• Caméra vidéo (Raspistill, mjpg streamer)
• Portail (igate) APRS
• VOIP (salon vocal numérique : Murmur, Mumble)
• Émetteur QRP SDR
• GPS et serveur de temps
• Serveurs : SK6AW.NET pour les spots DX ; F5LEN webcluster des spotters européens
• RADWAV SkyPi : émetteur 1W SDR

Site http://f6bvp.org/ (éditeur seamonkey)

• DIXPRS on Raspi
• Serveur vocal Mumble, disponible pour IOS et Androïd
• Vidéo mjpg-streamer

Le support de cette présentation est disponible, et téléchargeable ici.

Fin de la conférence à 21h15, avec remerciements au président Alain VATIN F6BSV pour l’accueil dans les locaux de F5KTR.

Vue générale d’un niveau de la Maker Faire (Photo F5RDS)

Malgré notre placement au sous-sol, des antennes précaires, et un changement de position de stand le samedi matin avant l’ouverture des portes, nous avons pu mettre en place différentes démonstrations :

• Récepteur HF Kenwood avec Mini-Whip sur les fréquences OM et météo, avec décodage des données au format RTTY sur ordinateur portable.
•  Transceiver VHF  utilisé notamment pour des démonstrations via le relais de Clamart (92)
•  Transceiver Icom 705 pour la HF
•  Clé RTL-SDR sur 1090 MHz et décodage de l’ADSB.
•  Petit émetteur-récepteur Pixie, et diverses cartes SDR, filtres, etc.
•  Montage réalisé durant le salon d’un keyer Arduino par Benoit le dimanche à partir du projet de K3NG .
•  Montage émetteur-récepteur CW 40m home-made par Olivier F5RDS connecté avec manip, et keyer maison.

Stand ARP. Benoit, Laurent F6FVY, Jean-Pierre F10298 (Photo F5RDS)

Nous avons également apprécié la visite Samedi d’Ivan F4CKF, et de Pierre-Louis F5NED du club F6KRK, qui n’ont pas hésité à mettre la main à la pâte pour nous aider à répondre aux  nombreuses sollicitations du public.

Environ 7000 personnes sont passées sur le salon durant ce week-end. Beaucoup de rencontres intéressantes avec d’autres Makers, et d’un public de tous les âges, mais majoritairement jeune, passionné, créatif, et avide de technique et d’expérimentation.

Atelier soudure (Photo F5RDS)

Il est clair que ces événements sont très importants pour la visibilité des radioamateurs. Beaucoup de visiteurs ont toujours une vision archaïque de notre hobby, et sont très curieux des évolutions, des nouvelles pratiques, ou des pratiques classiques toujours aussi impressionnantes d’un point de vue technologique. Il est important de montrer que les radioamateurs sont en fait les pionniers des Makers, et que l’essence même de cette activité est, comme le dit si bien le RR, « l’instruction individuelle, l’intercommunication et les études techniques, effectuées par des amateurs ».

De notre côté, au gré des déambulations dans les allées du salon, nous avons pu nouer des contacts avec de nombreux exposants, notamment régionaux,  élargissant ainsi nos carnets d’adresses de ressources techniques et scientifiques.

Machines de découpe laser et vinyl bientôt en libre-service (Photo F5RDS)

Enfin, nous devons remercier chaleureusement les organisateurs, Jean-Baptiste Le Clec’h du FabShop en particulier, pour son dévouement et l’énergie déployée afin de rendre parfaite cette première Maker Faire Paris. Nous avons déjà pris rendez-vous pour l’année prochaine !

F6KVP a obtenu un ruban bleu (Editor’s Choise Blue Ribbon) qui récompense les exposants pour leur créativité, leur ingéniosité et l’innovation.

Rédaction : Benoit Tigeot et Laurent F6FVY

Photos : Olivier F5RDS

Le balcon de F6FVY exposé ouest a été totalement réquisitionné pour permettre d’installer les antennes, à savoir une HB9CV 144/432 prêtée par Jean-Pierre F10298, et la station 10 GHz prêtée par Hervé F5HRY (8 W / Parabole 60 cm offset).

La plus grande distance parcourue a été F6APE/49 à 279 km qui a été contacté sur 2m et 3cm. F6KNB/33 a été entendu plusieurs fois, mais les conditions trop modestes n’ont pas permis le QSO.

J’ai réussi à contourner ce manque par une astuce ! J’ai tout simplement utilisé une application d’horloge autonome (DS Clock) , et l’ai paramétrée pour qu’elle n’affiche que les secondes, précédés du symbole deux-points, et en ajustant les propriétés et la position de sa fenêtre d’affichage pour qu’elle se fonde avec l’horloge existante. Voici les réglage que j’utilise (Windows 7 « standard »).

Dans un premier temps, ne pas bloquer la position de la fenêtre (Lock window position désactivé), et l’ajuster pour se coller juste après l’horloge Windows. Puis ré-afficher les options, et la bloquer.

L’illusion est visuellement parfaite.

Plutôt que de vouloir faire un programme monolithique qui gère tout, je me suis appuyé sur des solutions existantes pour le clavier et l’afficheur. Ce sera triggerhappy pour le clavier, et lcd4linux pour l’afficheur, qui sont des « daemons » qui tournent en tâche de fond.

Concernant le programme principal, il doit se connecter au DX-cluster, récupérer les infos, les mettre en forme pour l’afficheur, et selon les actions sur le clavier, « scroller » dans l’historique, faire afficher au LCD au choix les spots, les données WWV ou les données WCY. J’ai écarté les annonces pour l’instant. Comment écrire et développer ce process principal ? La première solution qui vient à l’esprit est le classique C (ou C++). Néanmoins, on est dans un environnement qui nécessitera de la cross-compilation, et le debugging risque alors d’être particulièrement lourd. En effet, il est pas possible d’installer d’environnement de développement directement sur le router (ses caractéristiques en terme de mémoire de masse et de RAM l’interdisent, sans parler de la vitesse d’éxecution des outils). Cette perspective ne m’enchante pas vraiment, surtout que je n’ai aucune expérience en matière de cross-developpement.

Par contre, le langage interprété Lua, très léger et très rapide, peut être installé sur le routeur sous forme de package, puisqu’il est utilisé par exemple pour l’interface web de paramétrage Luci (que je n’ai pas installé pour gagner de la place). Je connais déjà Lua pour l’avoir implémenté en tant que langage de script dans Win-Test et il conviendra parfaitement. Il faut juste lui adjoindre la bibliothèque de sockets (package LuaSocket) pour permettre la connexion au DX-cluster. Par contre, hélas, il n’est pas multi-thread nativement et il va falloir un peu jongler, notamment pour gérer le clavier sans trop de latence.

Pour les échanges entre le clavier et le script principal, j’utilise un fichier de type fifo, dans le répertoire /tmp qui est en fait en RAM. Ainsi, pas de latence, et pas d’usure du media ! Lorsque l’on appuie sur une touche, triggerhappy la détecte, et met un caractère (dépendant de la touche – cf le fichier de config de triggerhappy ci-dessous) dans le fifo, et lorsque le script va scruter le fifo, il va le récupérer et le traiter. La répétition automatique n’est gérée que pour les touches Up et Down, à savoir 8 et 2 sur le keypad.

root@OpenWrt:/etc/triggerhappy/triggers.d# cat dxticker.conf
KEY_KP1         1       echo "1" > /tmp/fifo
KEY_KP2         1       echo "2" > /tmp/fifo
KEY_KP2         2       echo "2" > /tmp/fifo
KEY_KP3         1       echo "3" > /tmp/fifo
KEY_KP4         1       echo "4" > /tmp/fifo
KEY_KP5         1       echo "5" > /tmp/fifo
KEY_KP6         1       echo "6" > /tmp/fifo
KEY_KP7         1       echo "7" > /tmp/fifo
KEY_KP8         1       echo "8" > /tmp/fifo
KEY_KP8         2       echo "8" > /tmp/fifo
KEY_KP9         1       echo "9" > /tmp/fifo
KEY_KP0         1       echo "0" > /tmp/fifo
KEY_KPENTER     1       echo "E" > /tmp/fifo
root@OpenWrt:/etc/triggerhappy/triggers.d#

Pour l’afficheur, j’utilise là aussi un autre fichier intermédiaire en RAM (/tmp/lcd.txt) qui va être écrit par le script Lua, et relu régulièrement par lcd4linux qui va envoyer les 4 premières lignes sur l’afficheur. Le problème n’est pas là. Ce qui pose un GROS problème, c’est que le driver lcd4linux pour le circuit HD44780 sur bus I2C est basé sur une assignation des broches du PCF 8574 totalement différente, et notamment pour les 4 bits de données, de celle de l’interface I2C de l’afficheur !

Et là, ça se corse ! Je dois modifier le driver en question du package lcd4linux, le recompiler, et réinstaller le package sur le routeur. Et bien entendu, il faut recommencer la manip à chaque essai… J’installe donc une Debian Wheezy dans une machine virtuelle de VirtualBox, et « en avant les pelles et les pioches ». Je vous passe tous les détails de la manip, mais il me faut quelques (longues) soirées pour arriver à mes fins ! J’obtiens aussi l’assistance d’un Bordelais dont le pseudo est Squonk, trouvé sur le forum OpenWRT, à l’origine du rétro-engineering du WR703N, qui me sort de plusieurs impasses. De voir enfin quelque chose s’afficher sur le LCD en question a été une grande satisfaction Mais j’ai beaucoup appris, et c’est là l’essentiel.

Le script principal Lua d’environ 500 lignes se résume donc à :

1. Initialisation
2. Lancement de la connexion au cluster
3. Récupération des infos (spot, wwv, etc.)
4. Remise en forme pour que les infos essentielles tiennent sur les 20 colonnes du LCD
5. Ajout dans l’historique et mise à jour de l’affichage
6. Traitement du clavier
7. Et on boucle sur la récup des données (point 3).

Le script est aussi prévu pour se reconnecter en cas de rupture du lien Wi-Fi ou autre.

Je le fais démarrer au boot du routeur, après toutes les inits, rendant ainsi le dispositif totalement autonome.

L’ensemble est alimenté par un chargeur USB de téléphone et sa (très) faible consommation me permet de le laisser tourner toute la journée si je veux. La charge CPU n’excède pas quelques pourcents, et il reste environ 1/4 de la RAM dispo avec un historique possible de 100 spots.

Le seul inconvénient est la latence de l’afficheur LCD en lui-même rend le scrolling un peu chaotique si l’on veut faire défiler un long historique, mais il n’y a pas grand chose à y faire, sauf à utiliser un autre afficheur de type TFT ou OLED par exemple.

Je vais maintenant certainement améliorer un peu le programme pour pouvoir  inclure également les annonces (ça ne coûte pas cher).

Il existe probablement bien d’autres applications et de fonctions liées à notre activité que ce routeur peut assurer à moindre coût. Si vous en menez une à son terme, n’hésitez pas à nous en faire part dans les commentaires.

Avant tout, la première étape consiste à installer OpenWRT sur le routeur, et le configurer pour qu’il accède à votre réseau Wi-Fi. De nombreux tutoriaux existent sur le sujet, et également des vidéos (même en français). Pour se familiariser avec cette distribution, il est également possible de l’installer dans une machine virtuelle dans sa version x86. Avant de se lancer, il est bon de s’imprégner du sujet et la lecture du Wiki d’OpenWRT s’avère indispensable, notamment en cas de volonté de mise à jour ultérieure, ou pour tout réinstaller (sans perdre les fichiers de config. si possible) si ça se passe mal.

Port série

La toute première modification hardware effectuée est d’installer un connecteur 3 broches (TxD, RxD, GND) au pas de 2.54 pour sortir un port série (qui sera au niveau 3v3). Ce port sera utilisé en cas d’urgence si le firmware installé se trouvait corrompu et bloquait entièrement la connectivité réseau. On est jamais trop prudent. Il s’est avéré que je n’en ai pas eu besoin, mais bon…

Il s’agit donc juste d’installer un mini-connecteur DIL 3 broches à l’emplacement d’une LED qui n’est pas câblée, couper les pistes de la LED absente, et gratter le vernis épargne pour souder la broche de masse. Puis relier par du fil à wrapper ces broches aux points tests nommés TP_IN et TP_OUT sur la sérigraphie en bas à droite côté composants. Une fois la soudure effectuée sur ces test-points, je conseille fortement de les noyer sous une goutte de colle à chaud pour éviter de les arracher par une mauvaise manip.

Préparation de l’emplacement du connecteur série

Connecteur en place

Soudure des fils à wrapper sur TP_IN et TP_OUT

Routage des fils vers le connecteur

Pour vérifier que tout fonctionne, il suffit de rebooter le routeur (ON/OFF) en ayant connecté ce port série via, par exemple, un adaptateur USB / Série 3v3 à PuTTY en 115200 8N1.

Ecran de boot sur liaison série

Hub USB

En faisant quelques essais préliminaires avec OpenWRT sur le WR703N, il apparait un premier souci : Le clavier numérique USB n’est pas reconnu en tant que tel par le système. En fait, le port USB 2.0 ne reconnait directement que les périphériques High Speed, mais il ne sait pas gérer les périphériques Low Speed comme les claviers ou les souris. Le seul moyen est donc d’utiliser un hub USB 2.0 High Speed qui va assurer la transition entre ces protocoles. Avoir un élément supplémentaire ne m’enchante guère, mais à la lecture de plusieurs sites, il est possible d’intégrer un tel hub dans le routeur. Ce sera ma première modification sérieuse.

J’ai fini par trouver un hub USB qui convient pour quelques euros, et l’ai dépouillé totalement pour l’intégrer dans le boitier. Il suffit de démonter le connecteur USB, sortir 4 fils pour aller vers le hub et réinstaller un connecteur USB femelle à la place de l’ancien avec des broches droites, reliées au hub. J’ai même ainsi à ma disposition 3 ports USB supplémentaires disponibles si besoin.

Hub sans son boitier

Entrée du hub reliée au WR703N

Réinstallation d’un connecteur USB sur une sortie du hub, désormais intégré au routeur

Par expérience, sachez qu’il existe de nombreux modèles de hubs qui utilisent tous le même boitier plastique noir et des connecteurs « en araignée ». Certains ne sont pas High Speed, mais seulement Full Speed, et ne conviennent donc pas à cette utilisation. Certains vendeurs changent aussi de fournisseur, sans prévenir, et sans véritablement contrôler les caractéristiques du produit. On pourra s’assurer de la vitesse effective du hub par la commande « lsusb -vt » sous OpenWRT (ne pas oublier d’installer les packages adéquats), ou par exemple avec l’utilitaire UsbTreeView sous Windows.

root@OpenWrt:~# lsusb -vt
 /:  Bus 01.Port 1: Dev 1,, Driver=ehci-platform/1p, 480M
     |__ Port 1: Dev 2, If 0,, Driver=hub/4p, 480M
         |__ Port 1: Dev 3, If 0, Interface Device, Driver=usbhid, 1.5M
root@OpenWrt:~#

Le clavier est alors reconnu comme HID dans dmesg :

root@OpenWrt:/# dmesg | grep usb
 [    4.670000] usbcore: registered new interface driver usbfs
 [    4.680000] usbcore: registered new interface driver hub
 [    4.680000] usbcore: registered new device driver usb
 [    5.080000] usb 1-1: new high-speed USB device number 2 using ehci-platform
 [    5.510000] usb 1-1.1: new low-speed USB device number 3 using ehci-platform
 [    9.050000] input: HID 1710:8812 as /devices/platform/ehci-platform/usb1/1-1/1-1.1/1-1.1:1.0/input/input0
 [    9.060000] hid-generic 0003:1710:8812.0001: input,hidraw0: USB HID v1.10 Keyboard [HID 1710:8812] on usb-ehci-platform-1.1/input0
 [    9.070000] usbcore: registered new interface driver usbhid
 [    9.070000] usbhid: USB HID core driver
root@OpenWrt:/#

Sortie I2C

Arrive alors la modification la plus délicate : Utiliser deux broches GPIO de l’AR7240 comme interface I2C. Il s’agit de dessouder 2 résistances CMS 0402 (lunettes / loupe / microscope indispensable) de pull-down R15 et R17 situés à gauche du SoC côté composants, et souder 2 fils à wrapper à la place. Comme pour la sortie série, la goutte de colle à chaud après l’opération est conseillée. Ces sorties sont au niveau 2v7 et il est donc indispensable d’utiliser un circuit d’adaptation si l’on veut commander un périphérique I2C 5v. J’ai également récupéré du 2v5 sur un point test nommé TP_2V5 côté cuivre, vers le centre, pour faciliter le câblage de cet adaptateur, que j’ai choisi d’installer côté LCD. Donc, sortent sur un connecteur HE10 (un peu surdimensionné) : GND, SDA (br 29), SCL (br 7), 2v5 et 5v.

Soudure de 2 fils à wrapper sur les 2 GPIO servant à l’I2C

Fil à wrapper sur le point test 2v5

Sécurisation des soudures par une goutte de colle à chaud

Ajout d’un connecteur HE10 pour l’I2C

Pour disposer d’un port I2C avec ces 2 broches, il faut installer les packages kmod-i2c-gpio-custom, kmod-i2c-core et i2c-tools (optionnel mais pratique pour tester). Puis installer les modules i2c-dev (insmod i2c-dev) et i2c-gpio-custom en précisant les paramètres adéquats (insmod i2c-gpio-custom bus0=0,29,7). Si tout va bien, dmesg doit contenir ces 2 lignes :

root@OpenWrt:/# dmesg | grep i2c
 [    8.940000] i2c /dev entries driver
 [    8.960000] i2c-gpio i2c-gpio.0: using pins 29 (SDA) and 7 (SCL)
root@OpenWrt:/#

L’adaptateur I2C 5v consiste pour chaque ligne SDA et SCL en une résistance de pull-up de chaque « côté » (2v5 et 5v) et un N-FET pour assurer la transition. Pour ma part, j’ai « cannibalisé » un adaptateur déjà câblé, qui était prévu pour adapter du 5v à du 3v3, en retirant ce qui gênait, à savoir le régulateur 3v3 et une diode.

Schéma de l’adaptateur I2C 2v5 / 5v

Adaptateur I2C avant modification

Adaptateur I2C après modification

Afficheur LCD

Concernant l’afficheur, mon choix s’est porté sur un modèle à 4 lignes de 20 caractères, rétro-éclairé, avec interface I2C (5v) déjà connectée. Le circuit qui pilote le LCD est un classique HD44780, extrêmement répandu dans tous ces modules. Il est câblé en mode data 4-bits avec le PCF 8574 (I2C I/O expander) sur l’interface I2C, qui comporte 8 sorties. Les 4 autres sorties correspondent au 3 signaux de commande RS, R/W et EN, et à la commande du rétroéclairage (backlight).

Afficheur LCD 4 lignes x 20 caractères

Interface I2C fournie et installée sur l’afficheur

Une fois l’adaptateur I2C 5v/3v3 connecté sur l’afficheur LCD via l’interface I2C, et sur le routeur, il faut tester si le PCF8574 est vu sur le bus I2C, avec i2cdetect :

root@OpenWrt:~# i2cdetect 0
WARNING! This program can confuse your I2C bus, cause data loss and worse!
 I will probe file /dev/i2c-0.
 I will probe address range 0x03-0x77.
 Continue? [Y/n] Y
 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
 00:          -- -- -- -- -- -- -- -- -- -- -- -- --
 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
 20: -- -- -- -- -- -- -- 27 -- -- -- -- -- -- -- --
 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
 70: -- -- -- -- -- -- -- --
 root@OpenWrt:~#

Il est bien vu par le système, et i2cdetect indique même son adresse 0×27 (39).

Les éléments extérieurs fonctionnent donc, et sont vus par OpenWRT : Le clavier (numérique), et l’afficheur LCD via l’interface I2C.

Il va falloir maintenant passer au software pour mettre tout cela en musique !

Suite et fin dans la troisième partie…

Depuis quelques temps, j’avais idée de concevoir un dispositif permettant de surveiller d’un œil le DX-Cluster F6KVP-3. Je ne voulais pas mobiliser une partie d’écran de mon ordinateur pour cela, voire même pouvoir le faire sans ordinateur du tout. Une sorte d’appareil autonome qui se connecterait en Wi-Fi au cluster et affiche les spots les uns après les autres (avec possibilité de scrollback etc.).

Dans l’idée de base, l’engin devait être donc constitué d’un module Wi-Fi, d’une unité de traitement du flux cluster, un affichage (pas vraiment défini à ce niveau de réflexion, mais probablement un afficheur LCD à lignes ou un petit TFT), et quelques touches de commande (voire un clavier numérique).

Synoptique du projet DX Ticker

Bien entendu, s’offrait à moi la possibilité d’utiliser un smartphone ou une tablette, mais – 1 -  je n’ai pas ça en stock en rab’ (surtout dédié à cet usage), – 2 – je trouve cela un peu luxueux pour une telle utilisation et – 3 – surtout, ça n’offre aucun intérêt : Installer une appli et la démarrer, on ne fait rien, on n’apprend rien, et ça fonctionne du premier coup : tout ce que j’abhorre dans le « néo-radioamateurisme » !

Cette idée rapidement écartée, que me reste-t-il ?

• Raspberry Pi + dongle Wi-Fi + afficheur LCD + keypad USB : C’est jouable, mais encore une fois, je trouve cette solution trop luxueuse pour une telle fonctionnalité. Tant au niveau puissance de calcul, largement sous-utilisée, que coût – je chiffre l’ensemble à une cinquantaine / soixantaine d’euros.
• Arduino (ou assimilé) + module Wi-Fi + afficheur LCD + touches (pas question d’utiliser un keypad USB – trop galère avec l’Arduino). C’est plus dans les cordes au niveau puissance / usage mais j’ai du mal à trouver un module Wi-Fi à un prix raisonnable. Rien à moins de 20 ou 30 Euros. On doit pouvoir faire mieux…

Le routeur TL-WR703N

La solution que je vais finalement adopter m’apparait justement en recherchant sur Internet un module Wi-Fi à coût raisonnable. Il s’agit du TP-Link TL-WR703N. C’est un petit routeur Chinois (moins de 6 cm x 6 cm) pour clé 3G vendu aux alentours de 15 Euros, frais de port inclus (tant pis pour Arnaud M.). Il est équipé d’un port Ethernet 10/100, d’un port USB 2.0 High Speed et intègre une connexion Wi-Fi 802.11n 150 Mbps. L’ensemble tourne avec un SoC (System on Chip) Atheros AR7240 (MIPS) à 400 MHz, une ROM Flash de 2 MB, et 16 MB de RAM. Sa petite taille, son coût, et sa connectivité l’ont rendu très populaire auprès de la communauté OpenWRT qui s’est empressée de porter leur distribution sur ce routeur. De plus, et c’est aussi cela qui m’intéresse, on peut le bidouiller « relativement facilement » pour y ajouter un port série (3v3) – qui sera salvateur en cas de « brickage » – et surtout sortir 2 GPIO (2v7) qui pourront être utilisées comme port I2C, permettant ainsi d’adjoindre mon afficheur LCD.

Routeur TL-WR703N

Routeur TL-WR703N ouvert

En résumé, dans ce routeur, sont concentrés le module Wi-Fi, l’unité de traitement du flux cluster (sous un Linux épuré), la gestion USB de mon keypad et la connectivité I2C pour l’afficheur LCD. Tout ça pour 15 Euros ? Vendu ! Il n’y a plus qu’à…

Je vais maintenant décrire les différentes étapes pour parvenir à mes fins, sans trop de détails (notamment sur le software) qui sortent totalement de la vocation « radioamateur » de ce blog. Je reste bien sûr à la disposition des lecteurs qui voudraient plus de précisions, notamment par l’intermédiaire des commentaires ou en privé.

Suite dans la seconde partie…