Hi Bill, this is how spark currently works with a connection per virtual transceiver, eliminating the need for virtual audio cables would be the next level of simple. If I were to create a Hamlib module it would probably just use the rigctl protocol which does not make much sense :), I'd prefer to spend my time working on something that improved the situation by including audio as well (multipsk has an interface that allows this). I understand if the protocol is internal and subject to change it is a mistake to use it but it works and does what a number of people find useful, it would be nice to keep using it. I remember looking at the Flex and pihpsdr protocols when I wrote my cat code and chose rigctl because it was so much cleaner, but if needs must. I really appreciate your help with this and don't mean to argue, I just like the rigctl protocol. 73 Alan M0NNB
On Wed, May 13, 2020 at 5:52 PM Bill Somerville <g4...@classdesign.com> wrote: > Hi Alan, > > there are already network capabilities that Hamlib back ends can access, > it is not tied to serial port connections by design, reference the Flex > 6xxx one for example. Using individual connections per Rx must be the way > to go, then a client can open as many rig connections using the Hamlib API > as it wishes or separate clients can open one each etc. This is how it is > kept simple! > > 73 > Bill > G4WJS. > > On 13/05/2020 17:41, Alan Hopper wrote: > > Mike, > thanks very much, If there is anything I can do to help/test or change in > my software please let me know. I've been looking through the dump_state > source and that part is a bit of a reverse engineering job:) but if that is > the cause of the problem I'll dive in if it will fix it in the short term. > In the long term I would really like a network protocol that combines rig > control and audio or iq data, it is a bit crazy that connecting an sdr to > other software is more tricky than a conventional radio. As some > people connect tens of simultaneous instances of digimode sw to spark it is > particularly desirable to keep it simple. > 73 Alan M0NNB > > On Wed, May 13, 2020 at 4:44 PM Black Michael via wsjt-devel < > wsjt-devel@lists.sourceforge.net> wrote: > >> I'm going to see about fixing the backwards compatibility. Hopefully >> today... >> >> Mike >> >> >> >> >> >> On Wednesday, May 13, 2020, 09:27:48 AM CDT, Alan Hopper < >> a...@samsararesearch.com> wrote: >> >> >> Hi Bill and Michael >> thanks very much for your reply. I added the response to 'q' but as >> expected no magic fix. The error message from wsjtx is 'Hamlib error: >> Communicatons timed out while getting current VFO frequency'. >> >> If the protocol has not been published then it has been at least well >> documented here https://www.systutorials.com/docs/linux/man/8-rigctld/ which >> seems to encourage its use directly. I have a personal hatred of virtual >> serial ports (and audio ports), serial and audio connections make perfect >> sense for traditional radios connected to PCs but not for connecting SDR >> clients to digi mode software. I had not realised that the rigctl protocol >> was considered internal and entirely take you point that in that case it is >> my problem, however it is a great protocol that does just what I need and >> the creator is to be commended. I shall investigate other options for >> network connection to Hamlib. The published api for spark is the rigctl >> protocol :) >> >> >> 73 Alan M0NNB >> >> On Wed, May 13, 2020 at 1:02 PM Bill Somerville <g4...@classdesign.com> >> wrote: >> >> On 13/05/2020 11:43, Alan Hopper wrote: >> > Hi Bill, >> > I'm the developer of SparkSDR, spark does indeed pretend to be rigctld >> > and is not the only one, QUISK also does the same thing. To my mind It >> > makes good sense to use a published proven network protocol rather >> > than invent yet another and then have to write further software to use >> it. >> > >> > This is the log from spark which shows connection happens but appears >> > to be dropped and retried after a few messages. WSJTX is actively >> > sending the quit command, is there any debugging/logging I can use in >> > wsjtx to find out what it does not like? >> >> Hi Alan, >> >> I realize that other applications spoof a rigctld server, the problem is >> that AFAIK the Hamlib NET rigctl protocol is not published as useable by >> other applications. That in turn leads to this situation where an >> internal Hamlib change to the protocol breaks other applications. If >> SparkSDR, and others, either emulated an existing rig or preferably >> contributed a driver to Hamlib for their application if it is not >> possible to provide a complete enough emulation, then all that would be >> needed would be a serial port loopback like com0com to get Hamlib rigctl >> clients to talk to their software. IMHO that is the published way to get >> these things interoperating. >> >> Having dug the whole that they have fallen into I believe it is their >> responsibility to look at the Hamlib change history to work out how to >> become compatible with Hamlib v4. >> >> I can help with the immediate issue, the latest version of the Hamlib >> NET protocol is expecting a status reply from the quit (q) command. I >> believe it is expected that the server completes a graceful shutdown of >> that connection before returning an OK status. The key being that the >> server must be ready to re-establish an identical connection immediately >> after the quit status return with no race conditions. As to why the >> client is sending a quit (q) command I can't tell from your example but >> the error message in WSJT-X would probably make things clearer. >> >> 73 >> Bill >> G4WJS. >> >> > _______________________________________________ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel >
_______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
