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…