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 > _______________________________________________ > 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
