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
<mailto: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 <mailto: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 <mailto: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
