¿ªÔÆÌåÓý

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

Re: Tips on interfacing I/Q data into quisk?

 

¿ªÔÆÌåÓý

Hi Jim,
My simple test to see how Python keeps up doesn't seem encouraging.? I just did something simple like this:

import os
import serial

port = "/dev/ttyACM0"
baudRate = 460800

try:
? ?ser = serial.Serial(port, baudRate)
except serial.SerialException as e:
? ?print(f"Error opening {port}: {str(e)}")
? ?exit(1)

try:
? ?with open("sound_data.csv", "w") as outFile:
? ? ? ?count = 0
? ? ? ?while count < 1000:
? ? ? ? ? ?data = ser.readline().decode().strip()
? ? ? ? ? ?if data:
? ? ? ? ? ? ? ?outFile.write(data + "\n")
? ? ? ? ? ? ? ?count += 1
finally:
? ?ser.close()

print("Data collection complete.")

It gave me a plot like this:?

With C++, I get this: fdi
which is what I expect, with my finger on the ADC input.? I'm not sure how to make sure there is no blocking I/O or no flow control in Python, but I did that in C++ code which produced the expected result, so this test is maybe not definitive.

73,
Rob
KL7NA


From: [email protected] <[email protected]> on behalf of Rob Frohne (KL7NA) via groups.io <rob.frohne@...>
Sent: Tuesday, March 5, 2024 10:14 PM
To: [email protected] <[email protected]>
Subject: Re: [n2adr-sdr] Tips on interfacing I/Q data into quisk?
?
CAUTION: This email originated from outside the Walla Walla University email system.

Hi Jim,

I was looking at version 4.2.28 since I had the source handy, and was looking at sdriq.cpp as you recommended.? I thought before I got to hacking around to try and get something going, I should update to the latest?version, so I did from github.? Now I cannot find the sdriqpkg directory or sdriq.cpp.? ?Can you clue me in on what I am missing?? It looks?like you moved everything to Python.? You had a nice "API" in the old C++ file.? Is Python going to be fast enough to handle the approximately 3.5 Mbit/s I am expecting over /dev/ttyAC0?? What do you recommend now?

Thanks & 73,

Rob
KL7NA

From: [email protected] <[email protected]> on behalf of Rob Frohne (KL7NA) via groups.io <rob.frohne@...>
Sent: Tuesday, December 26, 2023 3:17 PM
To: [email protected] <[email protected]>
Subject: Re: [n2adr-sdr] Tips on interfacing I/Q data into quisk?
?
CAUTION: This email originated from outside the Walla Walla University email system.

Cool!? Thanks Jim.? I will try and decimate it down to something more manageable on my end,? It is a relief to know Quisk can handle some small mismatch.

73,
Rob
KL7NA


From: [email protected] <[email protected]> on behalf of jimahlstrom via groups.io <jahlstr@...>
Sent: Tuesday, December 26, 2023 1:06 PM
To: [email protected] <[email protected]>
Subject: Re: [n2adr-sdr] Tips on interfacing I/Q data into quisk?
?
CAUTION: This email originated from outside the Walla Walla University email system.

>>Do you have a feel for the best way to deal with the fact that my sample rate is going to be 48.0460 kHz, not 48 kHz?

Quisk can correct small rate differences itself. Otherwise the SDR-IQ rate correction can be used. We will have to deal with this once we have the hardware available.

Jim
N2ADR


Re: Tips on interfacing I/Q data into quisk?

 

¿ªÔÆÌåÓý

Hi Jim,

I was looking at version 4.2.28 since I had the source handy, and was looking at sdriq.cpp as you recommended.? I thought before I got to hacking around to try and get something going, I should update to the latest?version, so I did from github.? Now I cannot find the sdriqpkg directory or sdriq.cpp.? ?Can you clue me in on what I am missing?? It looks?like you moved everything to Python.? You had a nice "API" in the old C++ file.? Is Python going to be fast enough to handle the approximately 3.5 Mbit/s I am expecting over /dev/ttyAC0?? What do you recommend now?

Thanks & 73,

Rob
KL7NA


From: [email protected] <[email protected]> on behalf of Rob Frohne (KL7NA) via groups.io <rob.frohne@...>
Sent: Tuesday, December 26, 2023 3:17 PM
To: [email protected] <[email protected]>
Subject: Re: [n2adr-sdr] Tips on interfacing I/Q data into quisk?
?
CAUTION: This email originated from outside the Walla Walla University email system.

Cool!? Thanks Jim.? I will try and decimate it down to something more manageable on my end,? It is a relief to know Quisk can handle some small mismatch.

73,
Rob
KL7NA


From: [email protected] <[email protected]> on behalf of jimahlstrom via groups.io <jahlstr@...>
Sent: Tuesday, December 26, 2023 1:06 PM
To: [email protected] <[email protected]>
Subject: Re: [n2adr-sdr] Tips on interfacing I/Q data into quisk?
?
CAUTION: This email originated from outside the Walla Walla University email system.

>>Do you have a feel for the best way to deal with the fact that my sample rate is going to be 48.0460 kHz, not 48 kHz?

Quisk can correct small rate differences itself. Otherwise the SDR-IQ rate correction can be used. We will have to deal with this once we have the hardware available.

Jim
N2ADR


Re: Reading band or frequency from quisk_widgets.py

 

I've finally figured out how to do this: The variable can be accessed as "self.application.lastBand" from inside the function "UpdateText(self)"


Re: Bug. Window width pixels

 

The problem was solved as follows.
#wFrame, h = frame.GetClientSize().Get()?# client window width
wFrame = conf.window_width - 15


Reading band or frequency from quisk_widgets.py

 

Hi group,

I am trying to extend the following widget:

What I am trying to achieve is to automatically change the selected band on the Hardrock-50 via an API call. At the moment I have added a button for each band (not in the code linked above) and when I click on it a request is sent to the server component which then sends the serial command to the HR50. Now I want to automate this.
To do this, I need to continuously read the selected band (or frequency if band is not possible), but I can only do this at startup by adding
to the function Widgets_0x06(self, app, hardware, conf, frame, gbs, vertBox)

The function "UpdateText(self)" is called all the time so I tried to read out the value from there as a test but I failed since I cannot reach it from inside this function.

Can you please help me here?

Thanks and 73
Michael, DK1MI


Re: Bug. Window width pixels

 

The value of?wFrame in the second line is incorrect at first, and after the second reboot it becomes correct.


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