VarAC and SparkSDR?

[david.wi...@gmail.com]

Hi, I have tried to use VarAC with SparkSDR but have had no luck getting the CAT to work.

I have VarAC set to use Hamlib RigCtl, with correct port and so on.  There does appear to be some communication as there is no error when TEST is pressed in VarAC, though nothing in Spark changes, and VarAC frequency does not update.  Entering a different port number to the 51111 used in Spark and there is an error.

Is there any way to debug the communication?

Has anyone out there managed to get VarAC to work with SparkSDR?

Dave M0WID

[ahop...@googlemail.com]

Hi Dave,

if you turn on extended logging and restart, the log file should record all the communication, It maybe that VarAC uses commands that Spark does not respond to. Newer versions of spark support a greater range of commands (but I'm aware you have audio issues with them!).

73 Alan M0NNB

[david.wi...@gmail.com]

Thanks.  I tried this and it seems the issue is probably with VarAC.  The log shows it connecting and disconnecting but no commands (unless Spark only shows commands it understands?).  

An example from the log:

Received connection request from 127.0.0.1:52925
04/05/2024 08:36:20 v2.0.974.0
Rigctrl running
04/05/2024 08:40:09 v2.0.974.0
Rigctrl Client closed connection
04/05/2024 08:40:09 v2.0.974.0
Rigctrl closed

 

If WSJT-X is connected with RigCtl then the commands are shown in the log as expected.

I will have to try the VarAC forum to see if there is anything that can be done.

Thanks

Dave M0WID

[ahop...@googlemail.com]

HI Dave,

Spark should show all commands.  It is odd nothing gets sent.  Might be a case of contacting the author of VarAC to find out what it expects.  

73 Alan M0NNB

[Arnd Gronenberg]

Hello Dave, hello Alan,

I did some tracing today between VarAC and SparkSDR using Wireshark, as the logs did not provide any clues.

VarAC terminates each hamlib/rigctl command with '0d'x (ie. CR), but SparkSDR expects commands terminated with '0a'x (ie. NL). The rigctld man page (https://manpages.org/rigctld/8) states: "Each line is terminated with a newline '\n' character.".

So the root cause of the problem of CAT communication between VarAC and SparkSDR is, that VarAC is terminating commands with the wrong termination character. I posted this information today also on the VarAC forum.

Some implementations (like rigctld itself) also accept an incorrect termination character, therefore it would be great if SparkSDR could either accept '0d'x (CR) as well or provide at least some information in the error log regarding incorrect command termination.

Vy 73, Arnd DJ9PZ/AB2QP

[Karl Heinz Kremer]

Supporting non-compliant applications just weakens the specification. Work on getting VarAC fixed - that’s the only clean solution to this problem. Otherwise, we end up with a situation where the information in the protocol specification is useless. 

Here is some background regarding where I come from: I’ve worked for decades with the PDF format, and there are a ton of bad PDF producers out there. My message to my customers always was to invest in technology that produces correct (according to the standard) PDF. 

Karl Heinz - K5KHK 

On Dec 28, 2024, at 9:44 AM, Arnd Gronenberg <arnd.gr...@gmail.com> wrote:

Hello Dave, hello Alan,

--
You received this message because you are subscribed to the Google Groups "SparkSDR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sparksdr+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/sparksdr/9af9c3bf-7965-46f7-9b42-ac1b929ff381n%40googlegroups.com.

[Arnd Gronenberg]

Hello Karl Heinz,

I basically do agree with your position. On the other hand, the "NL" vs "CR/NL" situation has been a common problemin the "*ix vs Windows" area. And even Hamlib removes both CR and NL from incoming messages.

Regarding adherence to specifications, it would be great if SparkSDR would reply with a Hamlib error code when receiving not implemented commands. As stated in the rigctld man page: "Please note that the backend for the radio to be controlled, or the radio itself may not support some commands. In that case, the operation will fail with a Hamlib error code.", therefore it would be great, if SparkSDR would return "RPRT -xx" (xx being the Hamlib error code for "not implemented").

Vy 73, Arnd DJ9PZ/AB2QP