Oops...make that code this instead...still have to parse the frequency.
CHKSCN1ARG(num_sscanf(buf, "%"SCNfreq, freq));
#if 0
ret = read_string(&rig->state.rigport, buf, BUF_MAX, "\n", 1);
if (ret <= 0) { return (ret < 0) ? ret : -RIG_EPROTO; }
*vfotmp = rig_parse_vfo(buf);#else vfotmp = "Unknown";#endif
On Wednesday, May 13, 2020, 12:47:31 PM CDT, Black Michael
<mdblac...@yahoo.com> wrote:
As a test try changing dummy/netrigctl.c line 622 and block out the code that
expects another argument from "f".
With the new code all you should need to do in spark is also provide the VFO
along with the frequency.So f is now is expected to answer like this to say
which VFO the frequency came from.14074000VFOA
#if 0 CHKSCN1ARG(num_sscanf(buf, "%"SCNfreq, freq));
ret = read_string(&rig->state.rigport, buf, BUF_MAX, "\n", 1);
if (ret <= 0) { return (ret < 0) ? ret : -RIG_EPROTO; }
*vfotmp = rig_parse_vfo(buf);#else vfotmp = "Unknown";#endif
And
On Wednesday, May 13, 2020, 12:38:50 PM CDT, Alan Hopper
<a...@samsararesearch.com> wrote:
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
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
