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? 13/05/2020 11:39:06 v2.0.1.4 rigctl ->\chk_vfo<-CHKVFO 0 13/05/2020 11:39:06 v2.0.1.4 rigctl ->\dump_state<-0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0x0 0x0 0x0 0x0 0x0 0 13/05/2020 11:39:07 v2.0.1.4 rigctl ->v<-VFOA 13/05/2020 11:39:07 v2.0.1.4 rigctl ->m<-USB 2850 13/05/2020 11:39:07 v2.0.1.4 rigctl ->f<-14095600 13/05/2020 11:39:09 v2.0.1.4 rigctl ->T 0<-RPRT 0 13/05/2020 11:39:09 v2.0.1.4 rigctl ->q<-NULL 13/05/2020 11:39:34 v2.0.1.4 Received connection request from 192.168.1.64:62153 13/05/2020 11:39:34 v2.0.1.4 rigctl ->\chk_vfo<-CHKVFO 0 13/05/2020 11:39:34 v2.0.1.4 rigctl ->\dump_state<-0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0x0 0x0 0x0 0x0 0x0 0 13/05/2020 11:39:34 v2.0.1.4 rigctl ->v<-VFOA 13/05/2020 11:39:34 v2.0.1.4 rigctl ->m<-USB 2850 13/05/2020 11:39:34 v2.0.1.4 rigctl ->f<-14095600 13/05/2020 11:39:37 v2.0.1.4 rigctl ->T 0<-RPRT 0 13/05/2020 11:39:37 v2.0.1.4 rigctl ->q<-NULL 13/05/2020 11:39:43 v2.0.1.4 Received connection request from 192.168.1.64:62157Received connection request from 192.168.1.64:60275 73 Alan M0NNB On Tue, May 12, 2020 at 11:40 PM Bill Somerville <g4...@classdesign.com> wrote: > Hi Erik, > > I think you may be misunderstanding what rigctld is, it is the Hamlib > network rig control server. The Hamlib API and the rigctl command line tool > expect to be talking to an instance of rigctld running somewhere on the > Internet (by default localhost:4532). The rigctld server has all the same > rig back end drivers built in as are found in the rigctl library or in > rigctl. It seems that SparkSDR have hijacked the internal network protocol > between the Hamlib library and rigctld, i.e. spoofed a rigctld server, this > makes little sense to me and a far better and conformant option would be > for the SparkSDR authors to contribute a Hamlib back end driver for their > SDR. > > 73 > Bill > G4WJS. > > On 12/05/2020 23:18, runninge...@gmail.com wrote: > > Hi Bill, > > Thanks for looking into this and I can already provide you with the > following answers : > > - WSJT-X reports in its error dialog "Rig Failure" "Hamlib error : > Communication timed out while getting current VFO frequency" > - There is no error in the SparkSDR latest "corelog-2020-05-12-19-35-54.txt" > and I have a suspicion, the WSJTX 2.2.0 command does not reach the network > server at SparkSDR > - The reason for my using the "rigctl-wsjtx" command was to check the > network transport (which seems to work). Now that I presume / understand you > are using rigctld for connecting to a network server, I will check with > M0NNB if we can debug this offline (and put you in email copy). > - Lets maybe keep in mind that this was working in release 2.1.2. > > 73's and thanks again, > Erik > ON4PB > > ------------------------------- > Message: 2 > Date: Tue, 12 May 2020 22:34:02 +0100 > From: Bill Somerville <g4...@classdesign.com> <g4...@classdesign.com> > To: wsjt-devel@lists.sourceforge.net > Subject: Re: [wsjt-devel] WSJT-X 2.2.0-rc1 - Hamlib NET rigctl no > longer works > Message-ID: <6bc371e6-9e40-e938-c597-98af91d1d...@classdesign.com> > <6bc371e6-9e40-e938-c597-98af91d1d...@classdesign.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > On 12/05/2020 22:16, runninge...@gmail.com wrote: > > Hi, > > thanks one more time for all the dedicated work with yet another big > step forward in decoding weal signals . ! > > Let me report that I am no longer able to CAT control my SparkSDR with > the "Hamlib NET rigctl" network server. > > My settings are : "localhost:51111" for Network server, which should > connect to my first (out of four) virtual transceiver in SparkSDR > (which is connected to a Hermes Lite II). > Substituting "localhost" with its IP address or hostname does not > solve the problem neither. > The same settings work fine with WSJT-X 2.1.2. > > Some more observations : > - The "C:\WSJT\wsjtx\bin>rigctl-wsjtx -m 2 -r localhost:51111 F > 7253500 M LSB 0" command correctly sets the VFO and mode. > - Overwriting the 3 rigctl executables with the release 2.1.2 binaries > yields the same result (sorry but I could not withstand doing this .). > > This is on a windows 10 - 64 bit config. > > 73's and best regards, > Erik > ON4PB > > Hi Erik, > > I see no mention of you running any form of rigctld, this makes me think > that SparkSDR has hijacked the Hamlib internal network protocol and is > acting as a fake rigctld. If that is so then the authors of SparkSDR > probably need to update their software to conform with the latest Hamlib > network protocol. It may well be that WSJT-X is sending commands that he > fake rigctld server does not understand. Do you get an error from WSJT-X, if > so what is it including the details? Does SparkSDR have an way of tracing > the commands sent to it? > > 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
