The internal protocol has never been published.The method to integrate is to
use the hamlib client interface.As it is your emulation doesn't do the
dump_state correctly for example.
Since SparkSDR is emulating a rig it's much more logical to write a backend for
SparkSDR or have SparkSDR emulate a rig like a TS-2000 or Flex or such.
Do you have a published API for SparkSDR?
de Mike W9MDB
On Wednesday, May 13, 2020, 06:48:54 AM CDT, Alan Hopper
<a...@samsararesearch.com> 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?
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>
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>
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
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
