Jump to content
F8FKJ

recherche logiciel de duplication/replication de port com

Recommended Posts

F8FKJ

Bonjour,

je ne sais pas si les termes dupliquer repliquer sont les mieux appropriés,

actuellement seul 1 logiciel peu communiquer avec le TRX via le CAT et son port COM.

je recherche un logiciel qui permettrait cette communication pour 2 logiciels en même temps.

un peu comme le fait "device routeur" de microham avec son 2nd CAT.

merci

Share this post


Link to post
F4BKT

Bonjour,

je ne sais pas si les termes dupliquer repliquer sont les mieux appropriés,

actuellement seul 1 logiciel peu communiquer avec le TRX via le CAT et son port COM.

je recherche un logiciel qui permettrait cette communication pour 2 logiciels en même temps.

un peu comme le fait "device routeur" de microham avec son 2nd CAT.

merci

Bonjour Jérôme

Peut être ici : http://k5fr.com/ddutilwiki/index.php?title=Main_Page

Je l'ai ici mais pas encore essayé

Quels sont les logiciels à amener sur le même port ..??

73's Philippe

Edited by F4BKT

Share this post


Link to post
F6FLU

Bonjour Jérôme et Philippe

Je suis dans le même cas et j'ai fais beaucoup de tests mais rien n'est convenable

Pour K5FR ça ne fonctionne que si tu as un SDR et encore pas n'importe lequel, je lui ai envoyé un mail et c'est ce qu'il m'a confirmé

J'ai testé beaucoup de softs mais rien de cohérent

Moi j'aimerai utiliser L32 et CWSkimmer en partageant le port CAT

VSPE ( tout court pas VSPE Manager) fonctionne mais se mélange les pinceaux et donc affiche n'importe quoi comme fréquence suivant le polling et c'est bien dommage

Je suis donc preneur d'info également si vous trouvez quelque chose de cohérent

73

Daniel

Share this post


Link to post
F4BKT

Bonjour Jérôme et Philippe

Je suis dans le même cas et j'ai fais beaucoup de tests mais rien n'est convenable

Pour K5FR ça ne fonctionne que si tu as un SDR et encore pas n'importe lequel, je lui ai envoyé un mail et c'est ce qu'il m'a confirmé

J'ai testé beaucoup de softs mais rien de cohérent

Moi j'aimerai utiliser L32 et CWSkimmer en partageant le port CAT

VSPE ( tout court pas VSPE Manager) fonctionne mais se mélange les pinceaux et donc affiche n'importe quoi comme fréquence suivant le polling et c'est bien dommage

Je suis donc preneur d'info également si vous trouvez quelque chose de cohérent

73

Daniel

Salut Daniel

Merci pour la précision

N’étant pas équipé SDR Je vais gagner du temps ...Hi

Comme tu le sais, je passe tous les logiciels dont j'ai besoin par DXLab d'où ma question plus haut.

Tu as déjà essayé DXLab.., il semblerait que CWSkimmer soit compatible avec la suite DXL.

Regarde ici: http://home.roadrunner.com/~w3oa/SkimmerToCommander/

73's Philippe

*-* Je viens d'y jeter un trés rapide coup d'oeil....on va retomber sur du SDR..je pense

Edited by F4BKT

Share this post


Link to post
F8FKJ

Merci a tous les 2 pour vos réponses,

pour les logiciels :

logiciel sdr + logiciel de log ou de concours

sdr-radio ou hdsdr et logger32 ou n1mm .

l'ajout de skimmer comme cw skimmer ou rckskimmer serait la cerise ;-)

je viens d'essayer ddutil sans grand succes.

Share this post


Link to post
F6FLU

Oui DDUtil fait partie des softs de K5FR et donc ne fonctionne pas

Bon on continue à chercher on trouvera peut être une solution...

Daniel

Share this post


Link to post
F6EEQ

Bonjour,

Pourquoi ne pas laisser tomber la RS232 du côté PC et remplacer par un émulateur USB?

Les câbles convertisseurs RS/USB coûtent une dizaine d'€ et le nombre qu'on peut implanter est largement suffisant pour un besoin OM.

J'ai branché mon FT857 comme ça et ça marche parfaitement. Je n'ai pas encore essayé avec le TS870, mais il n'y a pas de raisons pour que ça ne marche pas.

Apeès il faut tester avec des softs un peu difficiles, mais vu le prix, ça vaut le coup d'essayer.

Share this post


Link to post
F8FKJ

Bonjour

il ne me semble pas que la technologie du port COM soit en cause.

Je recherche bien une solution software.

Ou alors tester une solution mécanique en cablant 2 prise RS 232 en parallèle ?

Share this post


Link to post
F5ADL

bonjour,

Je ne sais pas si cela correspond à ce que vous cherchez, mais pour linker deux logiciels,j'utilise soit "com0com" soit "Vcom" de N8VB.

On peut créer des ports, diriger un port vers plusieurs ports....

73.Bruno F5ADL.

Share this post


Link to post
F5WK

Je suis dans le même cas et j'ai fais beaucoup de tests mais rien n'est convenable

Bonjour Daniel,

Je ne peux que confirmer ce constat, et j'ai voulu mieux comprendre le problème posé lorsque deux logiciels essayent de communiquer simultanément avec un même équipement radio.

Pour commencer, j'ai vérifié que j'obtenais les mêmes résultats que vous avec CW Skimmer, Logger32 et un splitter VSPE. Cela fonctionne presque, mais on voit bien que les données reçues par chaque logiciel ne sont pas celles attendues, il y a ce qu'on pourrait appeler des collisions logicielles.

Après un certain nombre d'essais avec le CI-V et un outil de RAD, il apparaît que la solution passe par un programme qui servirait de passerelle CAT vers l'équipement radio. Ce programme maintiendrait continuellement à jour les valeurs de fréquence, mode, et tous paramètres pertinents (en liaison exclusive)

La plupart des logiciels, pour ne pas dire tous, font du polling (interrogation périodique) sur le port CAT. Ils envoient des données et attendent la réponse appropriée. On n'est jamais certain que le traitement des réponses soit totalement asynchrone, donc il est préférable de ne renvoyer des données qu'en réponse à une interrogation.

L'envoi des commandes (fréquence, mode etc..) vers l'équipement radio doit être sérialisé: une commande après l'autre en s'assurant que la réponse à la commande en cours soit bien reçue. Après, se posera la question de la priorité de l'accès au CAT et peut-être faudra-t-il filtrer certaines commandes en fonction de leur provenance.

Si vous trouvez le logiciel ou l' Arduino(*) qui remplit ces fonctions, vous avez gagné !

73,

Michel - f5wk

(*) un Arduino non mais un Raspberry Pi qui traîne dans un tiroir oui !

ou une solution 'pure software' basée sur Hamlib

Share this post


Link to post
F6FLU

Bonjour Michel

effectivement c'est exactement ça

Donc avis aux amateurs qui voudraient se lancer dans cette aventure :-)

Daniel

Share this post


Link to post
Guest

Bonjour,

ça ressemble bien à de la gestion de mémoire partagée:

http://fr.wikipedia.org/wiki/Communication_inter-processus

c'est typiquement ce qui se passe lorsque deux PC veulent accéder à la même imprimante...voir sur le lien 'sémaphore, mutex' etc..

un thread de lecture /écriture par voie et un objet de communication ?

le Rs est le goulet d'étranglement, il vaudrait mieux passer par ethernet ses outils dédiés, y compris logiciels..

http://www.ebay.fr/itm/RS232-TCP-IP-SERVER-Cyclades-TS100-48VDC-5VDC-TES4861-NEU-NETZWERKSERVER-/141234505798?pt=DE_Computing_Server&hash=item20e23b8846

ça ouvre d'autres voies..

Logger32 , HDR ont l'air de supporter le TCP , à voir ?

olivier

Share this post


Link to post
F5WK

Une étude des problèmes rencontrés :

http://www.dh1tw.de/debugging-serial-port

Bonne analyse, qui voit bien le problème d'adressage des paquets.

La solution est 'statistique', on réduit le trafic au maximum avec des timings très différents pour minimiser le risque de collision.

Michel - f5wk

Share this post


Link to post
Guest

j' ai l'impression qu'il joue surtout sur les patterns de la trame, donc modifier la trame de WinTest pour que ca aille bien en l'occurence, 'trier les patates et les saucisses' par un en-tête approprié, ce qui fait appel à l'auteur du dit-logiciel et à son bon vouloir.

Qu'appelez vous une solution 'statistique' ?

Tout le problème vient que RS232 est une liaison bilatérale et que l'UART ne peut être monopolisé par un logiciel à la fois...il faut libérer la ressource, sinon plantage

Deuxièmement , le bus Série c'est un protocole complétement obsolète maintenu pour des raisons commerciales sur des postes à xxx € (FT-1000 par exemple car il est cité dans l'exemple).

L'USB est un bus propriétaire :http://www.usb.org/home, reste ethernet par Tcp/ip et les sockets et leurs dérivés pour la programmation.

olivier

Edited by Guest

Share this post


Link to post
F8FKJ

Difficile a trouver ce logiciel

et pourtant il doit bien y avoir une solution logiciel,

je viens de revérifier et je n'ai pas de problème avec le device routeur de microham. :

N1MM + SDR-radio (omnirig) + FT920 cohabitent, ce n'est pas trés "réactif" mais tous ce petit monde se suit :-)

peu d'explication sur le fonctionnement du 2eme CAT de microham :

( extrait de la notice orginale)

---------------------------------------------

2 nd CAT PORT

Beginning with version 7.0, Router provides a unique control capability: the 2nd CAT Port is an intelligent
data fork (software 'Y' connector) that allows a second application to share control of the radio. Router
monitors when data is sent from each application and routes the radio's responses to the correct virtual
port.
IMPORTANT: Both applications must use same communication parameters (baud rate, data length, parity
and number of stop bits) for proper operation!
Neither CAT port has priority. Polls/commands from each application are processed alternately. In order
to avoid collisions and avoid confusion due to unexpected data, responses from the radio are returned only
to the application that generated the command. Unsolicited data from the radio such as automatic
frequency/mode updates (Icom "transceive" packets or "Auto-information" data from Kenwood, Elecraft
and recent Yaesu transceivers) can be forwarded to both CAT ports individually when appropriate
“Forward autoinformation to CAT port” box is checked.
Due to limitations in the data channel throughput in the radio and the controller capabilities in various
transceivers, there are several important rules which must be observed.
● Total data throughput from both applications must not exceed maximum response rate of the
transceiver. In other words, the polling rate from one application may need to be decreased to
provide data space for the second application and vice versa.
● Applications must be tolerant of response delays. Each logger must be able to wait for a response
while the other logger communicates with the radio.
● Due to protocol deficiencies in handling VFO split commands with many transceivers (particularly
Icom), split mode must be initiated and ended by only one application and manual split control (from
the front panel of the radio) should not be used.
NOTE: Although Router has been tested extensively using many different applications on the CAT
and 2nd CAT ports, microHAM cannot guarantee proper operation with every possible combination
of software.
------------------------------------------

Share this post


Link to post
Guest

Ca confirme ce qu' écrivait F5WK c'est de la scrutation (polling). Ils ont l'air de dire qu'il n'était pas exclu que cela fonctionne (sous réserve..).

C'est le principe de la Rs qui ne va pas, ou bien pour un point à l'autre après ca se gate.

olivier

Edited by Guest

Share this post


Link to post
F5WK

j' ai l'impression qu'il joue surtout sur les patterns de la trame, donc modifier la trame de WinTest pour que ca aille bien en l'occurence, 'trier les patates et les saucisses' par un en-tête approprié, ce qui fait appel à l'auteur du dit-logiciel et à son bon vouloir.

Qu'appelez vous une solution 'statistique' ?

Tout le problème vient que RS232 est une liaison bilatérale et que l'UART ne peut être monopolisé par un logiciel à la fois...il faut libérer la ressource, sinon plantage

Deuxièmement , le bus Série c'est un protocole complétement obsolète maintenu pour des raisons commerciales sur des postes à xxx € (FT-1000 par exemple car il est cité dans l'exemple).

L'USB est un bus propriétaire :http://www.usb.org/home, reste ethernet par Tcp/ip et les sockets et leurs dérivés pour la programmation.

olivier

Olivier,

Je voulais dire une solution qui marche de façon aléatoire, mais dont l'aléas est rendu statistiquement peu fréquent. Du tir à travers l'hélice non synchronisé, ça fini toujours par exploser sur un grand nombre de tours !!

Non le problème ne vient absolument pas du RS232 ou de l'UART. D'ailleurs si vous faites le test avec un splitter VSPE vous verrez bien. Je me suis aussi amusé à essayer avec un serveur et deux clients TCP du même VSPE et c'est bien évidemment le même problème. Dans la config chacun ouvre son port COM bien à lui et donc pas de conflit possible.

Le problème provient du mélange de paquets dont la destination n'est pas définie (== adressage) pas du tuyau dans lequel passent les paquets.Il faut d'une façon ou d'une autre marquer les paquets avec l'adresse de retour, CAT compris, et là divine surprise, c'est possible avec ICOM qui définit deux champs d'adresse to et from

Pour plus de détail voir http://www.plicht.de/ekki/civ/civ-p31.htm

Je viens de vérifier que mon adresse, par exemple 0x55 est bien retournée dans les réponses à mes demandes de fréquence ou de mode. Logger32 utilise quant à lui l'adresse 0xE0 A partir de là, cela devient relativement simple de renvoyer la bonne trame à son requérant. Evidemment si tous les logiciels utilisent la même adresse, cela complique un peu les choses car il faudra changer le champ frm de tous les paquets provenant d'un port série.

Maintenant à vous les utilisateurs de mettre les mains dans le cambouis pour implémenter la chose B)

Michel - f5wk

Share this post


Link to post
Guest

Bonjour,

initialement Rs232 ne s'adressait qu'au transfert entre deux points, donc pas d'ambiguité sur les corrrespondants.

Si j'ai bien compris , cela ne fonctionne que si le transceiver sait identifier une requète , lire l'identifiant de celle ci, et renvoyer la valeur avec l'identifiant afin d'assurer le tri entre requérants.Ou placer une interface assurant ce rôle de tampon (raspberry par exemple)

Pour ce faire, Il faudrait 'tagger' la requète du logiciel 'A' , l'envoyer au transceiver, attendre la bonne execution, orienter la réponse vers le logiciel concerné. Eventuellement tamponner la requète 'B'...on réinvente le Tcp..

un des problèmes , c'est que cela implique les entrées / sorties de logiciel pour placer cet iditifiant...

ce ne serait pas jouable , une sortie de logiciel vers un serveur (ethernet , wifi , raspberry) , le n° de port serait différent en fct du logiciel, le R.P. coordonne et envoie vers le transceiver en mode CAT? Apparament HRD gère le mode ethernet.

olivier

http://fr.wikipedia.org/wiki/Transmission_Control_Protocol

Edited by Guest

Share this post


Link to post
F6FLU

Bonjour

Merci Martin j'ai également essayé LPB2 mais il faut visiblement obligatoirement un SDR reconnu par le logiciel sinon on ne peut pas creer les ports virtuels en tout cas moi ici il n'a pas voulu

Ce matin j'ai eu une discussion avec l'Engineering de Dyofrad ( fabricant de la Digibox) ils vont étudier le PB et proposer une solution à intégrer au départ dans la digibox puis sans doute une version externe suivant les demandes

Donc si vous êtes vraiment intéressé par ce genre de chose ça serait sympa de mettre un mail à l'équipe de Dyofrad

Http://dyofrad.com

Ce qui les mobilisera :-)

De toutes manières je vous tiens au courant

73

Daniel

Share this post


Link to post
Guest

Bonjour,

le problème de fond ,c'est que la RS sert à communiquer entre deux points. Quand on met plusieurs logiciels s'adressant à du materiel via cette liaison c'est la panique à bord. Cela peut fonctionner ..mais pas toujours. De plus, le protocole CAT n'est pas une norme et les fabricants de transceiver ont leur propre interprétation (voir exemple ICOM).

On peut ajouter des marqueurs aux trames etc.. mais c'est bien compliqué pour un résultat aléatoire.

Une piste: utiliser les logiciels qui envoient aussi vers une adresse IP (TCP) , un petit serveur (raspberry pi) qui identifie les requètes (n° de port) et qui convertit vers le message CAT (TTL, transceiver) et retour à l'expediteur..d'autant que ca ouvrirai la porte au WiFi en connection (pas de boucle de masse, parasites etc..).

Le RS est completement obsolète dans ce cas (logiciels multiples etc..)...

olivier

Edited by Guest

Share this post


Link to post
Guest

bon je vais bricoler dans mon coin. Je pense utilise le raspery pi en serveur avec la distribution Pidora qui inclu le compilateur C * pour architecture ARM ou un compilateur croisé. Evidemment tout cela ne vaut que pour les logiciels supportant le tcp ou alors il faut utiliser un port série virtuel, com2tcp.

Donc , le logiciel xy ->port com virtuel-> com2Tcp -> raspberry serveur/gestionnaire -> port TTL (CAT) -> transceiver et retour. l'@ servira de discriminant entre les logiciels .

Si j'arrive a quelque chose , je vous fait signe..

olivier

* Python est trop borde..ique entre versions 2.7 et 3.xx

Share this post


Link to post
F5WK

Bonsoir,

Je cherche un cobaye du genre tenace pour tester un bout de code qui sera présentable d'ici quelques heures, F6FLU ?

Il a l'air de tourner raisonnablement avec CW-Skimmer et Logger32, plus une troisième appli perso qui ne fait rien à part lire la fréquence et exciter le PTT. La réactivité est correcte voire bonne (en fait elle dépend surtout du soft et pour ça Logger me semble poussif.

J'ai fait un essai rapide avec un Icom IC-7400 et un Yaesu FT-847 et la surprise a été qu'il n'y avait pas de surprise ! La structure de la 'solution' est celle que j'avais exposée dans un message précédent, implémentée avec de l'existant à savoir OmniRig qui est incontournable avec Skimmer.

Seul OmniRig communique avec le transceiver, et en plus il gère bien le CAT (encore que j'ai vu un truc marrant) CW-Skimmer communique directement avec OmniRig et pour les autres applications j'utilise l'API de OmniRig (faut souvent deviner parce qu'il n'y a pas de doc) ce qui implique de décoder les données CAT pour ensuite faire les appels qui vont bien. Comme j'avais commencé avec le cat ICOM, j'ai continué, ce qui implique que toutes les applis connectées devront être configurées pour générer des données au format Icom.

Michel - f5wk

Share this post


Link to post
Guest
This topic is now closed to further replies.

×
×
  • Create New...