In short (English): a DIY controller for the Yaesu G-2800DXC rotator, built around an Arduino Nano, two relays and a K3NG-based firmware that speaks the GS-232A protocol over USB. A separate supply for the relays and a star ground cut the azimuth reading error from 5–10° to 2–4°, and a 6-point calibration keeps the stops within 2° of the rotator’s needle. Firmware, eight Python scripts and a GUI with a world map are on GitHub (GPL-3.0). Full write-up in French below.
Piloter son rotor depuis le PC, c’est un vrai plaisir en exploitation : on clique sur une carte, l’antenne se met en route, et le log suit. Pour mon rotor Yaesu G-2800DXC, j’ai voulu un contrôleur simple, bon marché et entièrement maîtrisé : un Arduino Nano, deux relais, quelques composants, et un firmware basé sur le célèbre K3NG qui parle le protocole GS-232A. Voici l’idée, la conception, les mesures et les fichiers pour le refaire chez toi.
L’idée : un rotor piloté par le PC, sans boîtier du commerce
Le G-2800DXC est un rotor robuste et très répandu chez les radioamateurs. Sa commande d’origine est parfaite à la station, mais je voulais pouvoir l’intégrer à mon logiciel de station (StationMaster) et à n’importe quel programme qui comprend le GS-232A. Le cahier des charges tenait en quelques lignes :
- commande de l’azimut par USB, au protocole GS-232A ;
- lecture de la position réelle de l’antenne ;
- sécurités : pas d’inversion brutale, limites, délai maximal de rotation ;
- montage durable, démontable, facile à dépanner.
Le matériel
- 1 × Arduino Nano (clone CH340), monté sur supports femelles ;
- 2 × relais SRD-05VDC-SL-C, commandés chacun par un transistor 2N2222 ;
- 1 × résistance de 10 kΩ et 1 × condensateur de 100 nF pour filtrer la mesure d’azimut ;
- 1 petit chargeur 5 V (type téléphone) dédié aux bobines des relais ;
- 1 plaque à pastilles (34 × 26 trous) et des borniers à vis pour le câble du rotor.
Le câblage du rotor
Seuls quatre conducteurs du câble sont utilisés ; le vert et le jaune restent libres.
| Fil | Rôle | Raccordement |
|---|---|---|
| Brun | Masse | Contacts des relais et GND du Nano |
| Rouge | R / CW : l’azimut monte | Relais 1 (RL1), commandé par D2 |
| Noir | L / CCW : l’azimut descend | Relais 2 (RL2), commandé par D3 |
| Orange | Tension d’azimut | Entrée A0, via 10 kΩ + 100 nF |
| Vert, jaune | — | Non branchés |
Attention aux couleurs ! Elles ne sont pas un standard : sur mon câble, j’ai dû croiser le noir et le rouge par rapport à ce que j’avais prévu au départ pour que « monte » fasse réellement monter l’azimut. Le tableau ci-dessus est la version corrigée, celle qui marche. Chez toi, la logique sera peut-être différente : contrôle toujours le sens avec un tout petit déplacement avant de lancer un grand tour, et garde la commande S (stop) sous la main.
La conception : deux alimentations, une masse en étoile
C’est le point qui fait toute la différence en pratique. Le Nano reste branché à l’USB du PC, mais les bobines des relais ont leur propre 5 V, fourni par un chargeur de téléphone. Seules les masses sont communes : le + du chargeur ne touche jamais le 5 V du Nano. Résultat : les appels de courant des relais ne viennent plus perturber l’alimentation du microcontrôleur.
Les masses sont tirées en étoile : un fil A (brun vers GND du Nano) réservé à l’entrée A0 et à son condensateur de 100 nF, et un fil B pour le retour des transistors. La mesure d’azimut garde ainsi une référence propre, sans être polluée par le courant des relais.
Ce que ça change, chiffres à l’appui
Au début, les relais et le Nano partageaient le même 5 V. À chaque démarrage du moteur, la tension s’effondrait un peu et la lecture d’azimut dérivait avec elle. J’ai suivi la tension du Nano, avant et après la séparation :
| Mesure | Alimentation commune | Alimentation séparée + masse en étoile |
|---|---|---|
| Chute du 5 V au multimètre pendant la rotation | 3,0 % (4,68 → 4,54 V) | 1,6 à 2,4 % (4,53 → 4,45 V le 23/10) |
Chute lue par la référence interne (commande \B) | environ 3 % | 0,8 à 1,1 % |
| Erreur de lecture de l’azimut en rotation | 5 à 10° | 2 à 4° |
| Pics de lecture d’environ 0,2 s | présents | disparus |
| Stabilité de A0 au repos | — | 1 point ADC d’écart sur 20 lectures |
Au multimètre, avec la masse prise sur la broche 6 de l’ICSP, les trois points de mesure concordent : au repos, l’ICSP affiche 4,53 V ; pendant la rotation, on lit 4,45 V sur l’ICSP, 4,46 V sur la broche +5V du Nano et 4,46 V sur REF, soit une baisse d’environ 1,6 %. La référence interne (commande \B) donne environ 4,48 V en rotation (BG = 251), stable sur trois essais : l’écart de 0,02 à 0,03 V correspond à un ou deux pas de \B, dans la précision du multimètre. Le relevé de la veille, au même point, avait donné 4,44 V (−2,4 %), d’où la fourchette du tableau. Une réserve sur la comparaison : la mesure « avant » date d’un autre Nano et son point de mesure exact n’est pas noté ; lis-la comme un ordre de grandeur. Le résultat qui compte : pour un budget de quelques euros (un vieux chargeur), l’erreur de lecture est divisée par deux ou trois, et les pics parasites ont disparu.
Le firmware : K3NG adapté, protocole GS-232A
Le cœur du projet est rotor_k3ng_ON5AM.ino, une adaptation du firmware K3NG qui parle le GS-232A à 9600 bauds. Il apporte plusieurs sécurités qui rendent l’ensemble agréable et rassurant à l’usage :
- verrouillage CW/CCW (gauche/droite) : les deux relais ne peuvent jamais être actifs ensemble ;
- pause d’1 seconde à chaque inversion de sens, pour ménager le moteur ;
- limite logicielle de 0 à 360° ;
- timeout de 300 s sur une rotation ;
- filtrage anti-pics sur la lecture d’azimut et détection de blocage ;
- étalonnage sur 6 points ;
- commandes
\Ret\Bpour le diagnostic.
Le téléversement se fait avec avrdude à 57600 bauds, et le port série est identifié de façon stable par son chemin /dev/serial/by-id/… sous Linux, ce qui évite les surprises quand on débranche et rebranche le Nano. Le code complet est sur GitHub (lien en fin d’article).
Les fichiers du projet : 1 firmware et 8 scripts Python
Le dépôt contient le firmware rotor_k3ng_ON5AM.ino et huit scripts Python dans le dossier scripts/, plus un petit outil, tools/gen_world_map.py, qui génère le fond de carte à partir de Natural Earth. Voici le rôle de chaque script :
rotor_control.pyest l’interface de pilotage : carte du monde, azimut, indicatif, boutons de commande (détails plus bas) ;test_comm.pyteste la communication : bannière, puis 15 lectures de l’azimut ;relay_test.pyteste les relais R, L, A et S, ainsi que le verrouillage (le relais CW retombe avant que CCW colle) ;calib_read.pyrelève un point d’étalonnage : 20 lectures brutes de A0 plus l’azimut ;pas_rotor.pyfait un petit pas réel, R puis L, avec la pause d’inversion, et coupe tout si l’azimut s’écarte de plus de 20° ;goto_test.pyessaie l’ordreMet suit l’azimut jusqu’à l’arrêt ; l’option--stopvérifie queSl’annule ;m_test.pyfait le même essai en détail : durée, vitesse et phases (rotation, puis impulsions) ;b_rotation.pylance une rotation de N secondes en lisant\Btoutes les demi-secondes, pour contrôler le 5 V en charge ;Sest toujours envoyé à la fin.
Le plan de pose sur plaque a été généré et vérifié par script (script non publié) : la liste des connexions a été contrôlée contre le schéma avant de sortir le fer à souder.
Les mesures et l’étalonnage
Le contrôleur tourne très bien. Voici ce que disent les mesures, après la séparation des alimentations (voir plus haut) et un nouvel étalonnage.
Étalonnage de l’azimut
Avant le nouvel étalonnage, l’écart pouvait atteindre +16° vers 360° par rapport à l’aiguille de la commande d’origine. Après un étalonnage sur 6 points téléversé dans le Nano, les ordres M 90, M 180, M 270 et M 360 s’arrêtent à 0 ou −2° de l’aiguille : largement suffisant pour une antenne directive.
Voici la table téléversée dans le Nano (CAL_ADC = {17, 198, 389, 587, 777, 840} et CAL_DEG = {0, 90, 180, 270, 360, 390}), relevée avec 20 lectures de A0 par point :
| Azimut réel (aiguille) | ADC moyen | Point de la table | Azimut affiché |
|---|---|---|---|
| butée (≈ 1°) | 16,8 | 17 → 0° | 0° |
| 90° | 198,0 | 198 → 90° | 90° |
| 180° | 389,0 | 389 → 180° | 180° |
| 270° | 587,0 | 587 → 270° | 270° |
| 360° | 777,1 | 777 → 360° | 360° |
| 390° (graduation « 30 ») | 839,5 | 840 → 390° | 390° |
Aux points d’étalonnage, l’affichage égale évidemment l’aiguille : c’est la construction de la table. À la butée, j’ai choisi 0° plutôt que 1° pour que la limite logicielle refuse un nouveau mouvement vers la gauche. Le vrai contrôle se fait aux arrêts d’un ordre M : Nano / aiguille donnent 358° / environ 358°, 268° / 270°, 180° / 180° et 90° / 90°.
Vitesse de rotation et timeout
Yaesu annonce 50 à 120 s pour un tour complet sur le G-2800DXC. En commande externe, j’ai mesuré 2,45°/s sur 90° (36,7 s), contre environ 4,5°/s depuis la face avant : le rotor est donc nettement plus lent piloté par le contrôleur. La course complète de 0 à 360° prend de 150 à 180 s.
Autre observation : une zone plus lente, vers 1,8°/s, entre 235° et 206°. Je n’en connais pas la cause pour l’instant (mécanique, câble, vent ? je n’ai pas tranché). Cela n’affecte pas la précision, seulement la durée du déplacement. La broche 3 (vitesse) n’est pas branchée : la raccorder reste une amélioration possible pour régler la vitesse depuis le PC.
Ces temps expliquent le choix du timeout de 300 s dans le firmware : il laisse une marge d’environ deux fois la course complète mesurée, tout en coupant les relais si le rotor se bloque.
Les points de contrôle avant la première mise sous tension
- sens du Nano sur ses supports ;
- brochage des 2N2222 (EBC ou CBE selon le fabricant) ;
- position des broches des relais SRD ;
- aucune liaison entre le + du chargeur et le 5 V du Nano ;
- continuité des 31 fils du guide de câblage, avant de brancher quoi que ce soit ;
- sens de rotation vérifié par un petit déplacement, puisque les couleurs du câble ne sont pas un standard.
Le tableau de commande
L’interface rotor_control.py affiche une carte du monde centrée sur la station. Tu tapes un indicatif (l’appli retrouve sa position via QRZ) ou tu cliques directement sur la carte : une ligne rouge montre la direction de la cible, et un pointillé vert indique le cap réel de l’antenne, lu sur le Nano. Les boutons GO, CCW, CW et STOP lancent ou arrêtent le mouvement ; l’antenne ne bouge que sur un clic explicite.
Exemple : je tape F1EIA, la ligne rouge se trace sur la carte et le cap affiché est 219,2°. Un clic sur GO et l’antenne part vers la cible, pendant que le pointillé vert la rattrape.
Quelques détails pratiques : la fenêtre est redimensionnable, F11 passe en plein écran, et la commande S est envoyée à la fermeture pour ne jamais laisser le rotor en mouvement. Le réglage (port série, identifiants) se fait dans rotor_config.ini, qui reste hors du dépôt Git pour ne rien publier de personnel.
Et les autres rotors Yaesu ? Comparatif et adaptation du montage
Yaesu propose toute une famille de rotors, du modèle d’entrée de gamme au géant pour grandes antennes HF. Le G-2800DXC se situe tout en haut de la série azimut ; voici comment il se place par rapport à ses cousins, d’après les fiches techniques officielles et les revendeurs.
| Modèle | Usage conseillé | Rotation | Temps pour 360° | Charge au vent | Charge verticale |
|---|---|---|---|---|---|
| G-450C | Léger à moyen : VHF/UHF, petit tribande HF | 450° | 63 s (50 Hz) | 1 m² | 100 kg (300 kg en intermittent) |
| G-1000DXC | Lourd : grandes antennes, montage en tour | 450° | 40 à 100 s (variable) | 0,75 m² × 0,6 m sur mât ; 2,2 m² en tour | 200 kg en continu (800 kg en instantané) |
| G-2800DXC | Très lourd : montage en tour, grands réseaux d’antennes | 450° | 50 à 120 s (variable) | 3 m² | 300 kg (1 200 kg en intermittent) |
| G-5500 | Satellites : azimut + élévation | 450° en azimut, 180° en élévation | 58 s en azimut | Moyennes et grandes antennes directives | Voir le manuel |
Le G-2800DXC offre le meilleur couple du lot, avec un système à engrenages planétaires qui améliore le freinage avec les grands réseaux d’antennes. Il est conçu pour être monté à l’intérieur d’une tour, et sa vitesse variable permet des démarrages et des arrêts en douceur.
Compatibilité avec le protocole GS-232
Côté pilotage par ordinateur, Yaesu propose son interface GS-232B pour les séries DXA/DXC (G-800DXA, G-1000DXA/DXC, G-2800DXA/DXC) et pour le G-5500. Des alternatives commerciales existent aussi, comme les interfaces USB RTC-200 et ERC-DUO, qui parlent le même protocole. Le contrôleur décrit dans cet article propose la même « langue » (GS-232A) pour une fraction du prix : de quoi réutiliser tous les logiciels de pilotage de rotor existants.
Mon montage est-il adaptable à un autre modèle ?
Sur la prise de commande externe des rotors Yaesu (hors G-5500), on retrouve simplement les signaux des boutons « gauche », « droite » et, selon les modèles, « libération du frein », plus la tension analogique de direction et la masse. C’est exactement ce que fait mon contrôleur : deux relais qui simulent les boutons, et une lecture de la tension d’azimut sur A0. Le principe est donc prometteur pour les autres rotors de la série DXA/DXC, avec des adaptations à prévoir :
- frein : les modèles qui ont une libération du frein demanderont un troisième relais ;
- vitesse : la broche de commande de vitesse peut être pilotée (c’est la piste d’amélioration évoquée plus haut) ;
- étalonnage : la plage de tension d’azimut diffère d’un modèle à l’autre, d’où l’intérêt de l’étalonnage sur 6 points ;
- G-5500 : c’est un rotor à deux axes, avec une électronique différente ; il faudrait ajouter un second axe côté firmware et matériel (le K3NG sait le faire).
Je n’ai testé que le G-2800DXC : si tu essaies avec un autre modèle, vérifie le brochage dans son manuel avant de souder, et raconte-moi ce que ça donne !
Sources
- Yaesu UK : fiche du G-2800DXC
- Yaesu UK : fiche du G-450C
- RigPix : fiche du G-1000DXC
- Yaesu : manuel du G-5500
- WiMo : interface RTC-200 (signaux de la prise de commande externe)
- Passion Radio : interface GS-232B et modèles compatibles
Les fichiers sur GitHub
Le firmware, les huit scripts Python et la documentation sont disponibles sur GitHub, sous licence GPL-3.0 : github.com/albertM-hub/rotor-g2800DXC. Tu peux les télécharger, les adapter à ton rotor et, si tu améliores quelque chose, je serai ravi de le voir.
Tu as construit ton propre contrôleur, ou tu hésites encore ? Dis-moi en commentaire comment ça se passe chez toi : les retours d’expérience sont toujours précieux. 73 de ON5AM !
Licencié Harec depuis 1990, après une pause de quelques années, j'ai renouvelé mon intérêt pour la radio, je suis particulièrement actif en HF, appréciant le FT8, les contest et la chasse au Dx. Passionné d'informatique, je suis convaincu que le monde des radioamateurs doit évoluer avec les avancées technologiques, notamment avec l'émergence de l'IA dans nos shack.
