¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io

Re: Hamlib/rigctl compatibility?

 

This is very interesting information.

I feel that it belongs in a document for people wanting to add support for their SDR to Hamlib.

I have been reading the README.* files in the Hamlib repo.

May I suggest adding a README.sdr to include this info and any other related info?

IMO it's just not obvious on what the best way to do this is.

Re: "You can connect to any rig via a TCP socket " -- note that README.md says:

Initially serial (RS232) connectivity will be handled, but we expect that IP
(and other) connectivity will follow afterwards.

So it's probably time to update that.

Regards,
Dave, N1AI



Re: Quisk Error on pip install (Cannot open include file: 'sys/time.h') on Windows 11

 

On Fri, Mar 1, 2024 at 01:28 AM, Rob Frohne (KL7NA) wrote:

Does anyone have any ideas on how to fix this problem?
Which compiler? With MSVC I assume since it does not have 'sys/time.h'.

Your student need to use MinGW. But I've no experience with "pip install" and MinGW.

Untested: "python setup.py build -c mingw32" could do it.


Quisk Error on pip install (Cannot open include file: 'sys/time.h') on Windows 11

 

¿ªÔÆÌåÓý

Does anyone have any ideas on how to fix this problem?? This is from ac2yd/remote.c(12).? This is with Python 3.12.1.? One of my students is having this issue.

Rob
KL7NA

--

Rob Frohne, PhD PE

School of Engineering

Walla Walla University

100 SW 4th St

College Place, WA 99324

(509) 527-2075


Re: Hamlib/rigctl compatibility?

Mike Black
 

The reason rigctld emulation is a bad idea is that it changes over time.? And the client may want vfo mode or not so most every command has to be checked for VFO.
A rig definition never changes -- but it can be extended.
Historically rigctld emulation was only necessary if you wanted a socket connection but that's not true anymore.
You can connect to any rig via a TCP socket and in 4.7 you'll be able to have a UDP/Multicast connection to control the rig.

So here's a rigctld emulation in code.

fgets(buf,sizeof(buf),fp);
char vfo[16];
long freqA,freqB;
int n = sscanf(buf,"f %s %ld", vfo, &freq);
if (n == 2) { // then there's no VFO
????int n = sscanf(buf,"f? %ld", &freq);
? ? vfo = current_vfo;? // you have to track which vfo is active -- PITA
}
if (vfo == 'VFOA') freqA = freq;
else if (vfo == 'VFOB') freqB = freq;
else printf("unknown vfo")
printf ("read freq %ld from vfo %s\n", freq, vfo);

And here's a TS-2000 emulator which is very straightforward and easy to understand.

fgets(buf,sizeof(buf),fp);
char vfo[16];
long freq;
int n = sscanf(buf,"FA%d",&freq);
printf ("read freq %ld from vfo %s\n", freq, vfo);
if (n == 1)
{
?freqA = freq;
}
n = sscanf(buf,"FB%d",&freq);
if (n == 1)
?freqB = freq;
}

Mike W9MDB

On Tuesday, February 27, 2024 at 06:31:31 AM CST, Roger David Powers via groups.io <progpwr@...> wrote:





On Fri, Aug 18, 2023 at 01:50 PM, jimahlstrom wrote:

I can alter Quisk's Hamlib code if it makes it more convenient for the Hamlib community, but I need a description of what to change.
In?/g/n2adr-sdr/message/3043?we get a hint.

You probably should read the whole thread when you get a chance.

Personally I think emulating rigctld was a good idea, and I don't know why some think it was a bad idea.

I've read the code of an emulated TS-2000 and it reads like a hex dump.

Yet it seems the current "best practice" is to emulate a real radio closest to the SDR's capabilities, and use a radio-specific back end to tweak any back-end differences.

It seems to me this would lead to lots of copy/paste code since hamlib isn't object-oriented so their is no core object you can extend as far as I can tell.

It seems there are function pointers to call into other radio objects, but still it seems to take a few thousand lines of code to do a back end regardless.

As usual, these are just my opinions, and I'm willing to be corrected.

Regards,
RDP


Re: Hamlib/rigctl compatibility?

 

On Fri, Aug 18, 2023 at 01:50 PM, jimahlstrom wrote:
I can alter Quisk's Hamlib code if it makes it more convenient for the Hamlib community, but I need a description of what to change.
In?/g/n2adr-sdr/message/3043?we get a hint.

You probably should read the whole thread when you get a chance.

Personally I think emulating rigctld was a good idea, and I don't know why some think it was a bad idea.

I've read the code of an emulated TS-2000 and it reads like a hex dump.

Yet it seems the current "best practice" is to emulate a real radio closest to the SDR's capabilities, and use a radio-specific back end to tweak any back-end differences.

It seems to me this would lead to lots of copy/paste code since hamlib isn't object-oriented so their is no core object you can extend as far as I can tell.

It seems there are function pointers to call into other radio objects, but still it seems to take a few thousand lines of code to do a back end regardless.

As usual, these are just my opinions, and I'm willing to be corrected.

Regards,
RDP


Some other questions about the screen

 

What is the Rflna slider, what is its purpose?
What is the screen got when hitting the Bscope button?
How can I show the "slider 0 to 100% to change the transmit power", which is indicated in the HL2 - Bands - Tx level comment?
73 - Pierre - FK8IH


FDV button

 

I'm using Quisk v.4.2.29 with my Hermes Lite 2. After one the last upgrades a "FDV button" appeared but it is in White color and is inoperative. I have already FreeDV v.1.9.8 installed on my computer. What did I miss to use it with Quisk?
73 - Pierre - FK8IH


Re: Bug. Window width pixels

 

?I think that here

? if conf.window_width > 0:
? ? ? wFrame, h = frame.GetClientSize().Get() # client window width
? ? ? graph = GraphScreen(frame, self.width//2, self.width//2, None) # make a GraphScreen to calculate borders
? ? ? self.graph_width = wFrame - (graph.width - graph.graph_width) # less graph borders equals actual graph_width
? ? ? graph.Destroy()
? ? ? del graph
? ? ? if self.graph_width % 2 == 1: # Both data_width and graph_width are even numbers
? ? ? ? self.graph_width -= 1
? ? ? width = int(self.graph_width / conf.display_fraction) # estimated data width
? ? ? for x in fftPreferedSizes:
? ? ? ? if x >= width:
? ? ? ? ? self.data_width = x
? ? ? ? ? break
? ? ? else:
? ? ? ? self.data_width = fftPreferedSizes[-1]


Re: Bug. Window width pixels

 

This is..


Bug. Window width pixels

 
Edited



If you switch from -1 to any value (or from value to -1), then it's fine. But if you switch between different values, then there is a problem. For example, between 1366 and 1920 (forward and backward). The previous value is applied. If the operation is repeated, the new value is applied. You have to apply it twice (button "On").


cw squelsh

 

Hi

Could sqelsh option be extended to cw?

It works with ssb/am and fm ..

It would be useful for monitoring a frequency preparatory to the start of a cw net or waiting for activity on a common calling frequency.
It can be fudged by using lsb (or usb) and offsetting the frequency .. but then has to be converted back to cw when activity occurs

Also .. in 4.2.26 there seems to be a default offset of 600Hz when initiating .. presumably to generate bfo freq for audio .. but there does not seem to be much
control over initial start up (like not? to have it when starting)

Thanks de zl1any stephen
\


Re: Hamlib 'dummy' rig support for quisk?

 

I think I'm seeing the bigger picture now after reading Mike's comments and also reading the pihpsdr manual ( ref:??).

In that pihpsdr manual, search for?19090 to find where it discusses rig control (it's the port number pipsdr uses by default for rig control).

The manual says:

piHPSDR listens on port 19090 (by default, can be changed in the RigCtl menu). For standard digimode operation, choose the Kenwood TS-2000 radio model. If your digimode program can use the hamlib CAT connection library (for example, both Fldigi and WSJTX can), choose the ,,OpenHPSDR PiHPSDR¡± radio model.

And:

The CAT command set is explained in Appendix C. In most cases, using the Kenwood TS-2000 as the radio model would do it, if the digimode or laptop program uses hamlib to interface with radios, either choose TS-2000 or (preferably) the ,,OpenHPSDR PiHPSDR¡± radio model because this uses time- out values adapted to piHPSDR.

And:

Important here is to choose the correct rig model OpenHPSDR PiHPSDR and port :19090 (note the colon!).

So, if I understand this, pihpsdr is implementing TS-2000 commands passed over the network, and it also has its own back-end selected as "OpenHPSDR PiHPSDR" that still mostly implements TS-2000 commands but also extends some timeouts.

This agrees with my reading of pihpsdr's rigctl.c code that is implementing a bit-level protocol to emulate TS-2000, as opposed to quisk and others that implement a character-based protocol to emulate rigcrld.

And, if I can interpret what Mike is saying, quisk users (who have a new-enough version of Hamlib) presumably should select radio model 10 named "Quisk" to send rigctld CAT commands to Quisk, but only ones that Mike (and/or other Hamlib maintainers) think Quisk can/should handle correctly.

I'm typing all this in because reading the posts I linked above suggests there may be some disconnects on this topic.

I sure found it difficult to comprehend.

Thanks,
RDP


Re: Hamlib 'dummy' rig support for quisk?

 

On Sun, Feb 25, 2024 at 05:30 PM, Mike Black wrote:
Because quick and sdrsharp are both trying to emulate rigctld which is a bad idea.

They'd be much better off emulating a rig like the TS-2000 or TS-480 or whatever matches their capability.
?
So had to disable some things that they cannot handle.
If I understand??correctly there was a time where the only way you could emulate a TS-2000 was if you had a (real or virtual) serial port, and many (most?)? SDRs do not have real serial ports, and most linuxes don't have virtual serial ports.? ?Maybe this is still the same now, maybe it has changed?

I also think the client programs forced you to provide serial port names (either COMx or /dev/ttyXX formats) and not TCP names (hostname:port?format) when using TS-2000 but there may be no real notion of connecting via TCP to a serial port so it's easy to understand why a client programmer would not code that.

This suggests that at the time there really was nothing workable except emulating rigctld.??

But this is just me guessing, so if you know more, please share.

PS: gqrx also emulates rigctld ( ref:??)...

Thanks,
RDP


Re: Hamlib 'dummy' rig support for quisk?

Mike Black
 

Because quick and sdrsharp are both trying to emulate rigctld which is a bad idea.
They'd be much better off emulating a rig like the TS-2000 or TS-480 or whatever matches their capability.

So had to disable some things that they cannot handle.

Mike W9MDB




On Sunday, February 25, 2024 at 02:27:29 PM CST, Roger David Powers via groups.io <progpwr@...> wrote:


The hamlib source code on github has:



I'm having a hard time understanding its purpose.

I've read??in detail and it doesn't explain why hamlib would have a back end for quisk in the rigs/dummy directory.

It looks like there's one for sdrsharp as well, so at least one other sdr app thinks it needs one.

It's like 3,000 lines of code so it's hard to pick up on its intent, and it doesn't have a comment block at the top explaining its purpose.

At best I can guess it's for people who want to drive quisk via a (physical or virtual) serial port rather than through quisk's built-in hamlib net rig ctl support?

I thought they would do this by telling their app that they have a Kenwood TS-2000 which is what most SDR apps support?

Not an urgent question, just one that's bothering me...

Regards,
RDP


Re: Hamlib 'dummy' rig support for quisk?

 

To follow up on my own question, maybe this is the code that supports 'rig 10' mentioned in these two messages:
I am not running this code.?

I am just reading source code and web pages trying to figure out how hamlib net rig control works, and this file is confusing me.

I don't understand why quisk needs its own rig/model instead of clients just using '2' for hamlib net rig control.

Regards,
RDP


Hamlib 'dummy' rig support for quisk?

 

The hamlib source code on github has:



I'm having a hard time understanding its purpose.

I've read??in detail and it doesn't explain why hamlib would have a back end for quisk in the rigs/dummy directory.

It looks like there's one for sdrsharp as well, so at least one other sdr app thinks it needs one.

It's like 3,000 lines of code so it's hard to pick up on its intent, and it doesn't have a comment block at the top explaining its purpose.

At best I can guess it's for people who want to drive quisk via a (physical or virtual) serial port rather than through quisk's built-in hamlib net rig ctl support?

I thought they would do this by telling their app that they have a Kenwood TS-2000 which is what most SDR apps support?

Not an urgent question, just one that's bothering me...

Regards,
RDP


Re: PATCH: quisk-4.2.29 fix build with python-3.13

 

Thanks?Jaroslav. I will add this.

Jim
N2ADR


PATCH: quisk-4.2.29 fix build with python-3.13

 

Hi,

it seems python-3.13 relaxed includes, so the following patch is needed, because the code uses gettimeofday which is included by sys/time.h

73! Jaroslav, OK2JRQ


Quisk - Debian 12 - HL2 Filter Board Settings

 

Fresh install of Quisk from git and clicking the boxes to enable the filters on HL2 does nothing. Works by clicking in the empty boxes on Windows. Any suggestions?

73,

James / K4JVV


Re: Quisk 4.2.29 with linux Mint on HP laptop with Softrock 6.1

 

The usb microphone seems to have done the trick. Just received one in the post and plugged it in today.
This was? picked up buy the config menu in Quisk and the screenshot shows the final result that now works with the Raspberry Pi and Startech usb soundcard.
Not tried the Linux Mint laptop yet.
Don m5aky