OpenX6X00 v0.3.7 : plans de bandes et Winlink

La dernière version du micrologiciel communautaire enrichit les Xiegu X6100 et X6200 avec des plans de bandes adaptés aux régions, un flux de travail Winlink plus lisible et un modem Mercury expérimental. Elle montre aussi tout ce que des logiciels exécutés directement dans une radio définie par logiciel moderne peuvent transformer.

Pendant longtemps, un émetteur-récepteur HF se définissait surtout par sa façade et le micrologiciel fourni par son fabricant. OpenX6X00 change cette perspective pour les Xiegu X6100 et X6200. Sa version 0.3.7 ajoute les plans de bandes des différentes régions de l’IARU, des restrictions liées aux classes de licence américaines, une interface Winlink remaniée et le modem Mercury expérimental. Ces nouveautés s’ajoutent aux applications de modes numériques, à la journalisation, au contrôle par navigateur et à d’autres logiciels qui fonctionnent directement sur la radio.

Cette évolution a une portée pratique. Un ordinateur portable peut ajouter des modes numériques et des fonctions réseau à presque n’importe quel émetteur-récepteur, mais il faut alors transporter un écran supplémentaire, des câbles et un autre appareil à alimenter et à dépanner. OpenX6X00 intègre nombre de ces fonctions dans l’environnement informatique déjà présent dans la radio. Il ne s’agit donc pas seulement d’une nouvelle interface : le logiciel permet de réunir l’exploitation radio, la journalisation et certaines fonctions réseau au sein d’un même système.

La version 0.3.7 marque une étape dans cette évolution. Elle n’ajoute pas de nouvel étage RF et ne modifie pas le micrologiciel de bande de base qui contrôle les fonctions fondamentales de l’émetteur-récepteur. Elle enrichit plutôt la façon dont la partie Linux de la radio interprète les règles d’exploitation, présente les communications numériques et protège ses interfaces web. Ces changements illustrent aussi les exigences auxquelles doit répondre un projet de micrologiciel ouvert : les nouvelles fonctions doivent s’intégrer à deux radios apparentées, tenir compte des différences entre les plans d’exploitation nationaux et rester sûres lorsque des services sont accessibles depuis un réseau local ou à distance.

D’une interface de remplacement à une plateforme logicielle

OpenX6X00 fonctionne sur la partie Linux des X6100 et X6200, depuis une carte microSD. Les radios conservent un micrologiciel de bande de base distinct pour des fonctions telles que le DSP, la RF, la gestion de la puissance et le manipulateur. OpenX6X00 communique avec cette partie, mais ne la remplace pas. Cette séparation permet au projet de faire évoluer l’interface et les applications tout en s’appuyant sur le micrologiciel existant pour les fonctions fondamentales de l’émetteur-récepteur.

Cette distinction est importante, car l’expression « micrologiciel ouvert » peut laisser entendre que toutes les parties d’une radio ont été remplacées ou sont librement modifiables. Ici, le projet contrôle une couche logicielle importante, mais la bande de base reste un composant distinct fourni par Xiegu. Le système d’exploitation, les applications, l’interface de contrôle et les outils web peuvent évoluer indépendamment du micrologiciel qui gère le matériel radio. En pratique, une fonction disponible dans OpenX6X00 peut néanmoins dépendre de ce que la bande de base sous-jacente permet.

L’histoire du projet aide également à comprendre son périmètre. OpenX6X00 est un fork de la dernière version ouverte du micrologiciel de la X6100, après la fermeture du projet d’origine. Les responsables indiquent avoir supprimé les services qui communiquaient avec l’extérieur et poursuivi le développement de manière ouverte. Le système inclut désormais notamment un panneau de commande dans le navigateur, l’affichage du DX cluster, des fonctions de journalisation, des applications pour les activités en extérieur et plusieurs modes numériques. La nouvelle version enrichit cet environnement logiciel au lieu de traiter chaque fonction comme un accessoire séparé.

L’ordinateur intégré modifie la configuration d’une station portable. Lorsqu’une application de mode numérique fonctionne sur la radio, il n’est parfois plus nécessaire de connecter un ordinateur pour décoder ou transmettre dans les modes pris en charge. Si un journal de trafic ou des outils d’activation sont également disponibles sur la même plateforme, certaines opérations peuvent se faire sans passer d’un appareil à un autre. Le contrôle par navigateur offre une autre possibilité : un téléphone, une tablette ou un ordinateur connecté au réseau local peut piloter la radio depuis une interface web. Ensemble, ces fonctions rendent l’émetteur-récepteur moins dépendant d’un ordinateur externe pour de nombreuses tâches numériques et connectées.

Cette intégration a toutefois ses limites. Les commandes physiques, l’écran, les circuits audio et les capacités de la bande de base déterminent toujours ce que le logiciel peut faire. Une application Linux peut proposer un nouveau flux de travail, mais elle ne peut pas supprimer les contraintes du matériel ni garantir un comportement identique sur les deux modèles. La distinction entre la couche applicative et la bande de base est particulièrement utile lorsqu’on compare les fonctions, qu’on cherche l’origine d’un problème ou qu’on envisage une mise à jour. Une plateforme logicielle plus riche élargit les usages de la radio, mais sa conception matérielle continue d’en fixer les limites.

Des plans de bandes adaptés à la région

La nouveauté la plus visible de la version 0.3.7 est probablement l’extension des plans de bandes. Les versions précédentes n’affichaient que le plan de la région 1 de l’IARU dans la bande de visualisation. La nouvelle version prend aussi en charge les régions 2 et 3, ainsi que les plans américains correspondant aux classes de licence Extra, Advanced, General et Technician. L’affichage devient ainsi plus pertinent pour les radioamateurs dont les allocations diffèrent de celles du plan initialement pris en charge.

Un plan de bandes ne se résume pas à des libellés affichés à l’écran. Il aide les opérateurs à savoir où différents types d’émissions sont appropriés ou autorisés et guide leurs choix lorsqu’ils changent de fréquence. Le nouveau système peut afficher le plan sélectionné dans la bande de visualisation, y compris dans le panneau du navigateur. Il influence également certaines fonctions de l’interface, comme le choix du mode à partir du plan de bandes et l’indication des segments CW. Dans les plans américains associés à une classe de licence, les portions qui ne sont pas accessibles à l’opérateur sont affichées en gris, avec une indication « out » lorsqu’elle s’applique.

La sélection automatique utilise les informations de localisation disponibles pour choisir une région IARU. Elle utilise d’abord une position GPS, puis le locator Maidenhead configuré et enfin le pays associé à l’indicatif. Si aucune de ces informations n’est disponible, la radio conserve la région sélectionnée précédemment. Cet ordre convient à une radio portable susceptible d’être utilisée à différents endroits, tout en prévoyant une solution de repli pour les opérateurs qui ne disposent ni du GPS ni d’un locator configuré.

La sélection automatique ne choisit volontairement pas de plan américain associé à une classe de licence. Savoir que la radio se trouve aux États-Unis ne permet pas au logiciel de déterminer les privilèges de son opérateur. Un plan régional ne suffit pas à distinguer ces autorisations : les radioamateurs américains doivent donc sélectionner eux-mêmes le pays et leur classe de licence. C’est un choix raisonnable : l’automatisation peut simplifier la configuration lorsque les informations nécessaires sont disponibles, mais elle ne doit pas deviner une donnée réglementaire qu’elle ne peut pas connaître.

Dans certains cas, le plan régional modifie également la liste des bandes de la radio. Dans les régions 2 et 3, les entrées 160 m, 80 m, SSB sur 40 m et 6 m peuvent adopter les limites de la région lors du premier démarrage après la mise à jour, à condition que l’opérateur n’ait pas déjà modifié ces entrées. En région 1, les limites existantes ne sont pas déplacées par cette modification. Cette différence compte, car les plages fixes adaptées à une région ne correspondent pas nécessairement aux allocations ou aux pratiques d’exploitation d’une autre.

Pour un opérateur portable, cette nouveauté peut éviter de petites incohérences d’interface qui ont pourtant des conséquences concrètes. Une radio emportée au-delà d’une frontière, configurée pour une autre région ou utilisée selon un plan national différent devrait afficher des informations adaptées à cette situation. L’affichage ne remplace pas la connaissance de la réglementation applicable et une seule option ne peut pas couvrir toutes les variantes nationales. Il rend toutefois le contexte d’exploitation sélectionné plus visible et aide à aligner l’affichage des fréquences sur ce contexte.

Le projet indique avoir testé l’affichage et les entrées de la liste des bandes sur une version PC et sur une X6100 de test, pour les régions 2 et 3 ainsi que les classes américaines General et Technician. Cela apporte un élément utile sur le fonctionnement de l’interface, mais ne constitue ni une certification réglementaire officielle ni une vérification exhaustive de toutes les combinaisons possibles de régions et de licences. D’après les notes de version, la sélection automatique à partir d’une position GPS n’a pas été testée sur une radio. Il faut garder ces réserves à l’esprit : les fonctions de sélection régionale sont pratiques, mais il revient toujours à l’opérateur de choisir les autorisations correctes et de les respecter.

Winlink se rapproche d’un fonctionnement directement sur la radio

Winlink est l’un des éléments les plus importants de cette mise à jour, car il relie la radio amateur à la messagerie électronique et aux messages stockés puis retransmis par des réseaux radio. En HF, il peut être utile lorsque l’accès classique à Internet est indisponible ou lorsqu’un opérateur veut transmettre des messages par l’intermédiaire d’une passerelle radio. Le flux Winlink d’OpenX6X00 utilise ARDOP, un protocole numérique conçu pour la communication de données par radio. La nouvelle version vise surtout à rendre le processus de connexion plus lisible et les problèmes plus faciles à diagnostiquer.

L’interface mise à jour ajoute une carte « Before you connect » qui montre comment Winlink va utiliser la radio. Une carte de connexion explique pourquoi une tentative a échoué et quelles actions pourraient être utiles ensuite. Le logiciel ne se contente donc plus d’afficher un bouton de connexion : il cherche à rendre compréhensibles les conditions de l’action et les raisons d’un échec. Lors du dépannage d’une connexion HF, ces informations peuvent être plus utiles qu’un simple message d’erreur, surtout lorsque la configuration de la radio, celle du modem et la disponibilité de la passerelle influencent toutes le résultat.

Le comportement de la bande passante ARDOP a également été modifié. La page de la radio utilise désormais la bande passante ARDOP la plus large pour chaque connexion. Dans la configuration décrite, la valeur par défaut est de 500 Hz lorsque la liste des passerelles demande un réglage 2000MAX. Les notes de version indiquent également qu’un mot de passe saisi dans les propres paramètres de l’application est désormais conservé. Ces détails peuvent sembler modestes, mais ils contribuent à la fiabilité pratique d’un outil intégré pendant une session de trafic réelle.

D’autres changements concernent les commandes et les journaux lorsque l’application numérique est ouverte. Le clavier n’est alors pas disponible, et les journaux peuvent être téléchargés ensemble avec les mots de passe masqués. Ces mesures répondent à deux préoccupations différentes : éviter des interactions inadaptées pendant qu’une application contrôle la radio et limiter l’exposition d’informations sensibles dans les journaux exportés. Une radio capable de communiquer sur un réseau doit considérer sa configuration et les données qu’elle conserve comme des éléments à part entière de son environnement d’exploitation.

La version 0.3.7 ajoute aussi Mercury comme deuxième option de modem expérimentale pour Winlink. Mercury est associé au projet HERMES ; une exigence précise s’applique à la compatibilité : la station distante doit utiliser Mercury 1.9.20 ou une version ultérieure. La description du projet indique qu’il faut sélectionner Mercury dans Pat au moyen de l’option VARA HF. Les opérateurs doivent connaître cette particularité avant de tenter une connexion. Comme Mercury est expérimental dans cette version, il faut voir son intégration comme une fonction supplémentaire en cours de développement, et non comme une garantie de compatibilité avec chaque passerelle ou client Winlink.

Cette réserve est importante dans les réseaux radio. Un modem n’est utile que si l’autre extrémité peut échanger les données avec un protocole et une configuration compatibles. Une implémentation locale peut être techniquement complète tout en ayant une portée pratique limitée si le reste du réseau n’a pas adopté le protocole. À court terme, Mercury pourrait donc intéresser surtout les opérateurs qui expérimentent, effectuent des tests ou peuvent s’organiser avec des stations compatibles. Son utilité à plus grande échelle dépendra de sa prise en charge au-delà de la radio elle-même.

Le travail réalisé autour de Winlink révèle aussi un défi de conception plus général. Une application embarquée doit gérer des décisions qui, dans un programme de bureau, pourraient être réparties entre plusieurs fenêtres : quel modem est actif, quelle bande passante est demandée, si la radio est prête à émettre et ce qui s’est passé après l’échec d’une connexion. Regrouper ces éléments peut simplifier la station, mais l’interface doit alors les présenter clairement. Si elle masque un état important, une configuration compacte peut devenir plus difficile à dépanner qu’une installation reposant sur un ordinateur portable.

Modes numériques et station portable

Le reste des fonctions d’OpenX6X00 permet de comprendre l’importance des changements apportés à Winlink. Le projet prend en charge des applications intégrées pour des modes comme FT8, FT4, FT2, JS8, WSPR, PSK31, PSK63, Olivia, RTTY, SSTV, WeFax ainsi que Navtex avec DSC en réception uniquement. Le niveau précis de prise en charge varie selon l’application et le mode, mais l’idée générale reste la même : l’environnement Linux de la radio héberge des logiciels qui fonctionnent habituellement sur un ordinateur externe. La version 0.3.7 s’appuie sur cette base plutôt que d’introduire le trafic numérique à partir de zéro.

Cela peut changer l’agencement physique d’une station portable. Un opérateur en déplacement emporte déjà parfois un émetteur-récepteur, une batterie, une antenne et un téléphone ou une tablette pour les cartes et le carnet de trafic. Ajouter un ordinateur portable pour chaque mode numérique augmente le poids et la consommation électrique, tout en apportant des câbles et des logiciels à configurer. Lorsque certaines de ces tâches sont transférées dans la radio, la station peut devenir plus autonome. Cela ne rend pas tous les ordinateurs inutiles : un écran plus grand, des outils de journalisation familiers ou des logiciels spécialisés peuvent rester préférables. La radio peut néanmoins prendre en charge une part plus importante du fonctionnement courant.

Les différents modes imposent des contraintes différentes. FT8 et les modes apparentés à signaux faibles dépendent d’une synchronisation précise, du décodage et d’émissions programmées. WSPR est couramment utilisé pour observer la propagation avec des balises à faible puissance. JS8 permet d’échanger des messages au clavier et prend en charge des opérations reposant sur des relais. Winlink répond à un autre besoin et permet de transmettre des messages par des passerelles. Réunir ces outils dans la radio peut faciliter le passage entre expérimentation, contacts et messagerie pratique, sans devoir reconstruire la station autour d’un ordinateur à chaque changement d’activité.

L’écran et les commandes font partie de cette expérience. Un waterfall peut représenter les signaux de manière à faciliter l’accord et l’observation de l’activité. Une vue du DX cluster peut relier les spots à l’accord de la radio. Le contrôle par navigateur permet d’utiliser un appareil familier comme interface distante. L’intérêt provient de l’interaction entre ces fonctions : un spot peut guider un choix de fréquence, une application numérique peut gérer une émission et un journal peut enregistrer le contact dans le même environnement logiciel.

L’intégration concentre aussi la complexité. Une application numérique doit accéder de façon fiable à l’audio, à la fréquence et à la commande d’émission. Une interface de navigateur doit communiquer avec la radio sans laisser une page non fiable détourner ses commandes. Le journal doit conserver des données de contact exactes et les services réseau doivent distinguer les utilisateurs prévus des autres clients. Chacune de ces fonctions peut sembler limitée lorsqu’on l’examine seule, mais leurs interactions exigent une conception et des tests minutieux.

L’évolution du projet illustre ce défi. Des versions précédentes ont ajouté la prise en charge de la X6200, le contrôle à distance par navigateur, Winlink en HF et d’autres fonctions. Le développement a également révélé des défauts dans la journalisation, le contrôle TCI, le PTT par navigateur et d’autres composants. Les responsables indiquent qu’une revue de la version 0.3.6 a découvert 14 défauts, notamment dans le PTT par navigateur, le configurateur, TCI et l’interface web. La version actuelle les corrige et montre que le travail sur un micrologiciel ouvert consiste autant à corriger les interactions entre les fonctions qu’à en ajouter de nouvelles.

La sécurité devient une composante du trafic radio

Une radio équipée d’un configurateur web, d’un contrôle à distance par navigateur et de services réseau présente un profil de sécurité différent de celui d’un appareil doté uniquement de commandes physiques. La version 0.3.7 ajoute une protection contre le DNS rebinding, une technique par laquelle un site malveillant peut amener un navigateur à traiter un nom contrôlé par ce site comme s’il pointait vers un appareil du réseau local. Si le navigateur peut atteindre les pages de configuration ou de commande de la radio, une conception vulnérable pourrait exposer ses paramètres ou permettre des actions à travers la session du navigateur.

OpenX6X00 v0.3.7 limite certaines opérations web aux propres noms de la radio, comme son nom d’hôte local ou un nom configuré par l’utilisateur. Cette restriction concerne l’enregistrement des modifications dans le configurateur web ainsi que les pages et connexions associées, tandis que les programmes TCI peuvent toujours se connecter avec n’importe quel nom. Cette distinction répond à un besoin pratique : les surfaces de commande accessibles depuis un navigateur et les interfaces utilisées par des programmes n’ont pas nécessairement besoin des mêmes règles de nommage. Limiter les opérations sensibles à certains noms peut réduire le risque qu’un site détourne le navigateur pour interagir avec la radio.

Les travaux de sécurité de cette version s’inscrivent dans une série d’audits et de revues de code. Le projet indique que l’analyse de la version 0.3.6 a révélé 14 défauts, corrigés dans la version 0.3.7. Des audits indépendants antérieurs avaient aussi entraîné des corrections dans le contrôle TCI, le traitement des données ADIF, la modification des journaux et le comportement des sessions de navigateur. Il ne s’agit pas seulement de défauts esthétiques. Un problème de contrôle de l’émission peut empêcher la radio de passer correctement en émission ou de revenir en réception. Un défaut de traitement des données peut corrompre les journaux ou rendre le système instable.

Le soin apporté au PTT par navigateur est particulièrement important, car le contrôle à distance change la nature du bouton d’émission. Un bouton physique est directement associé à l’opérateur et à la radio. Une commande dans un navigateur dépend d’une connexion réseau et de l’état du logiciel. Si la liaison se bloque puis revient, l’interface ne doit pas déclencher l’émission de façon inattendue à partir d’une commande ancienne. Les notes de version indiquent qu’un défaut a été corrigé : lorsqu’un bouton PTT du navigateur était maintenu, la radio pouvait se remettre à émettre après le rétablissement d’une liaison interrompue. C’est un cas limite que toute interface bien conçue doit traiter explicitement.

La sécurité intervient aussi dans la façon de proposer l’accès à distance. OpenX6X00 peut utiliser Tailscale pour le contrôle à distance et la version 0.3.7 ajoute Tailscale Funnel, qui rend certaines pages du navigateur accessibles depuis l’extérieur du réseau local. Le projet distingue les pages Panel et Screen des autres services, comme le configurateur, les programmes TCI et les applications Winlink. Cette distinction est importante, car « accès à distance » ne désigne pas une autorisation unique : un panneau de commande en direct, une interface de configuration et un service réseau offrent des capacités différentes et présentent des risques distincts.

La fonction Funnel est soumise à des limites précises. L’association d’un navigateur doit être effectuée avant l’utilisation du lien distant. Un navigateur associé à domicile peut ensuite recevoir son propre lien pour être utilisé à l’extérieur. Seules les pages Panel et Screen ainsi que leurs sockets associés sont accessibles publiquement, et l’accès exige un navigateur précédemment associé à domicile. Les autres services restent inaccessibles par Funnel. La fonction a été testée avec un substitut au démon Tailscale et dans une version PC, mais pas encore avec un véritable tailnet et une vraie radio. Les responsables invitent donc les utilisateurs à partager leurs retours après des tests dans cet environnement.

Cette fonction est plus qu’un simple bouton de confort. Publier un service sur Internet modifie qui peut tenter d’y accéder et le type d’authentification nécessaire. OpenX6X00 sépare l’accès du navigateur distant des autres services de la radio et exige une association préalable. Le projet précise également que le nom d’hôte public devient visible dans les journaux de certificats. Les opérateurs qui n’ont pas besoin de contrôler la radio à distance par navigateur peuvent laisser Funnel désactivé. Ceux qui l’utilisent doivent savoir quelles pages deviennent accessibles et lesquelles ne le sont pas.

Limites de puissance, maintenance et portée de la version 0.3.7

Le comportement de la puissance d’émission de la X6200 constitue une autre modification opérationnelle importante. Avec la version 0.3.7, l’interface limite la puissance sélectionnable à 8 W, et à 5 W lorsque la radio fonctionne sur batterie. Une limite logicielle peut servir de garde-fou, notamment dans une station portable dont l’alimentation peut varier, mais elle ne doit pas être interprétée comme une déclaration générale sur la puissance maximale de la radio. Il s’agit d’une limite appliquée par cette version du logiciel, qui peut influer sur la configuration du poste en fonction de sa source d’alimentation.

La version corrige également plusieurs comportements secondaires. Sur la X6100, le niveau du moniteur est désormais réglé par défaut sur zéro, comme sur la X6200, tout en conservant la valeur choisie par l’utilisateur. Lorsque l’opérateur règle un VFO au-delà d’une limite de bande, l’autre VFO reste à sa position précédente. Le projet corrige aussi des défauts liés au contrôle par navigateur, à TCI, aux formulaires Wavelog et au configurateur. Chaque ajustement contribue à un fonctionnement plus prévisible, même s’il ne s’agit pas d’une nouvelle fonction majeure.

Les utilisateurs qui ont déjà installé OpenX6X00 peuvent lancer la mise à jour depuis la radio. Les notes de version indiquent qu’une X6100 ou une X6200 fonctionnant sous une installation compatible v0.2.x ou v0.3.x peut recevoir la version 0.3.7 par le mécanisme intégré. De nouvelles images de carte sont disponibles pour les premières installations et les radios qui ne démarrent plus assez loin pour lancer une mise à jour. Certaines images plus anciennes doivent être remplacées pour bénéficier de modifications antérieures du chargeur de démarrage ou du pilote Wi-Fi. Ces besoins dépendent toutefois du modèle et de la version installée : tous les utilisateurs n’ont pas à réécrire leur carte pour obtenir la version 0.3.7.

La séparation entre le paquet de mise à jour et l’image de la carte constitue un avantage pratique de l’architecture. Les applications et les pages web peuvent être mises à jour sans réécrire l’image complète du système lorsque le noyau, les pilotes et les composants d’amorçage n’ont pas changé. Le projet indique que la version 0.3.7 ne nécessite pas de nouvelle image pour les radios déjà équipées d’une image antérieure compatible. Les paramètres et les journaux restent sur la partition de données de la carte, mais il est tout de même recommandé d’effectuer une sauvegarde avant la mise à jour. La séparation entre système d’exploitation et applications peut rendre la maintenance moins contraignante, mais les utilisateurs doivent toujours savoir dans quels cas une image complète est nécessaire.

La possibilité de revenir en arrière fait également partie du modèle de mise à jour. La radio conserve la version précédente afin d’y revenir automatiquement si la nouvelle installation ne démarre pas correctement. Cela ne rend pas inutiles les sauvegardes des réglages et des journaux et ne rend pas toute mise à jour sans risque. Cette fonction offre néanmoins un mécanisme de récupération précieux pour un appareil embarqué, qui pourrait sinon exiger une procédure plus complexe de réécriture de la carte.

Le projet illustre également une tendance plus générale dans le matériel radioamateur. Les émetteurs-récepteurs SDR intègrent de plus en plus d’informatique généraliste, des fonctions réseau et des interfaces définies par logiciel. Il devient ainsi possible d’ajouter des capacités après la commercialisation d’une radio, mais la qualité de la maintenance logicielle fait aussi partie de sa valeur au quotidien. La logique des plans de bandes, l’interopérabilité des modems, la sécurité du navigateur, l’intégrité des journaux et la commande de puissance sont autant de questions logicielles qui influencent le fonctionnement réel. Le développement ouvert donne aux utilisateurs une visibilité sur ces changements et un moyen de signaler des problèmes. Il impose aussi aux responsables de maintenir la cohérence d’un système qui s’enrichit.

OpenX6X00 v0.3.7 va donc au-delà de sa liste de nouveautés. Les plans de bandes régionaux adaptent mieux l’interface aux radioamateurs du monde entier. Les changements apportés à Winlink visent à rendre les connexions plus compréhensibles, tandis que Mercury offre aux stations compatibles un moyen expérimental d’explorer une autre option. Les corrections de sécurité et les revues de code montrent que le contrôle à distance par navigateur concerne aussi la fiabilité du fonctionnement radio. Ensemble, ces évolutions font des X6100 et X6200 des plateformes où le micrologiciel peut façonner la manière dont un émetteur-récepteur est utilisé, connecté au réseau et maintenu.

Les images utilisées dans cet article sont générées par IA...

Cet article peut contenir des liens d’affiliation...