Pour résoudre le problème on ne peut que s'inspirer de la solution de la SNCF !
Quand un train veut s'engager sur un aiguillage alors qu'un autre l'emprunte déjà, il n'y a qu'une solution, attendre que la voie soit libre. Le second convoi est à l'arrêt et regarde passer le premier train.
Comme dans notre cas il s'agit d'un objet immatériel sous forme de signaux électriques fugitifs, il faut mettre en mémoire les messages qu'ils constituent.
Il faut donc une couche de logiciel supplémentaire entre les applis et le port com pour gérer le conflit d'accès.
Cette couche n'est autre qu'un programme appelé "Routeur" qui route, un peu plus tard, le second message une fois que le premier est passé.
Timing entrée routeur
Timing sortie routeur
Pour que la méthode soit viable il faut que le temps entre deux messages de l'appli 1 soit suffisamment long pour pouvoir y insérer un message de l'appli 2, et inversement.
Ces temps sont réglables dans les menus appli sous le terme " polling rate " en millisecondes.
Le temps mort est nécessaire pour laisser au transceiver le temps de faire le travail que lui ordonne le dernier message reçu avant de s'occuper du suivant.
20/01/2014
Particularités
J'ai relevé trois cas, mais il doit en exister d'autres :
-I- Cas basique, il ne fait que le minimum, comme VSPE, gérer les conflits temporels entre les ports RS-232.
-II- Cas d'une version standard customisée Celle proposée par Telepostinc pour le LP-Pan avec le K3 appelée LP-Bridge est une version customisée d'un produit standard.
Le résultat n'est pas génial, pour un objet qui est au cœur du système informatique d'une station moderne, ce programme doit être en béton, et ce n'est pas le cas.
Ayant eu la configuration K3 + LP-pan, j'en parle en connaissance de cause. Si j'avais gardé le K3 je l'aurais associé à un microHam pour avoir la paix. Le K3 a quitté la station pour d'autres raisons que celle là.
-III- Cas du routeur microHam Pour la partie RS-232 il a été développé en coopération avec VE3NEA Mr CW-skimmer.
- Les programmes basiques gèrent en aveugle les flux ils se contentent des paramètres élémentaires RS-232, Baud rate, bit number, parity et stop number, et ne s'intéressent pas au contenu des trames.
- Le routeur microHam a besoin pour être plus fiable de connaître la marque et le modèle du transceiver utilisé en bout de chaîne. En interprétant le contenu il peut résoudre certains problèmes . Les autres en laissant passer sans rien faire amènent à des impasses, qui finissent en plantages.
Les ports "CAT" pour le Log, et "2ndCAT" pour CW-skimmer ou tout autre SDR compatible CAT, non banalisés donc, ne sont pas spécifiés comme tels par hasard.
Les messages qu'ils dispatchent sont adaptés aux programmes destinataires.
On peut, si besoin, revenir à un mode standard en décochant les cases ad hoc du configurateur.
La dernière valeur ajoutée du routeur microHam est de masquer le time-out du log quand le transceiver est occupé à autre chose. Cela est magique dans mon cas, car quand via le CAT-converter le PC Tx prend le contrôle du PC Rx pour obtenir la fonction "Track" entre tous les VFO, il n'y a pas besoin de reconnecter le Tcvr Rx au log du PC Rx lors du retour en mode "Split"
La dernière amélioration entre la version 7 et la 8 concerne le FT-1000mp. En raison de son firmware âgé de 20 ans... (déjà) époque où les SDR n'existaient pas, Yaesu passait une commande "Squelch" encadrant la commande "CAT", pour masquer le burst AF provoqué par le changement de QRG.
20 ans plus tard cette délicate attention se transforme en calamité, chaque fois que le SDR intérroge le Transceiver, à raison d'une fois toute les 500 ms, la BF se retouve dans un hachoir...
Dans le CAT-converter je m'étais heurté au même problème; pour le résoudre il ne faut envoyer au FT-1000mp aucune commande en doublon. le générateur de messages doit faire le tri.
MicroHam qui a l'habilité de ne laisser aucune niche à ses concurrents a intégré cette nécessité dans la version 8 de son routeur. Vu la taille de la base installée des 1000mp, cela a du sens. Le FT-1000mp est donc maintenant éligible à la fonction "click & QSY" quand il fait la paire avec un log et CW-skimmer ou un autre SDR.
Ce type de programme adapté à notre besoin existe sous deux formes :
-I- Des programmes autonomes, qui créent des port virtuels auxquels les applis envoient leurs messages. Eux-mêmes envoient vers le transceiver via un port physique ou virtuel le flux de messages qu'ils ont élaboré.
Attention, le vocabulaire et les méthodes de configuration de ces logiciels ne sont pas du tout normalisées.
exemple : suivant le logiciel utilisé, - soit chaque appli doit s'adresser à un port virtuel spécifique, - soit elles peuvent s'adresser au même, car dans le mode virtuel tout est possible. ( ou presque )
La seule chose que les routeurs refusent toujours, ( ceux que j'ai essayés en tout cas ) c'est de communiquer avec un port virtuel issu d'un autre logiciel routeur.
C'est bien dommage, car dans certains cas cela oblige à ajouter deux ports physique et un câble "nul-modem" ( un câble croisé tx -rx ) pour faire communiquer deux de ces univers.
-II- Des programmes routant bien plus que du RS232 Le plus connu du monde radio-amateur est certainement celui qui accompagne les interfaces hardware pour transceivers de "microHam".
Ci-dessous le configurateur du programme v8.1.4 pour tous les microHam.
En plus des ports com RS-232 il injecte ou extrait de la liaison USB tout un tas d'informations dans un tas de formats avec l'interface hardware. C'est une sorte d'entonnoir qui gave le "xx keyer" en service pour qu'il alimente correctement toutes les entrées de la face arrière du transceiver et pour faire bonne mesure quelques équipements annexes.
Ceci dit si quelqu'un peut se passer de ce type de configuration, c'est qu' à part un J-37 et/ou un micro-casque il n'y a rien du 21ème siècle dans sa station.