开云体育

Hello Peter,

By iio I presume you mean the Industrial IO module developed by Analog Devices. I will look at this once I get caught up. It would help if there were any other hardware that used IIO too. An alternative is to work with Soapy developers to get Pluto working.

Jim
N2ADR

Hello Jim,

The keyboard shortcuts are the underlined letters on the button labels.

Jim
N2ADR

Hello Peter,

The 2084 ksps rate is a problem for Quisk. To get to 192 ksps requires decimation by 2084/192 = 10.85416667, a fractional number. The audio is captured and played to/from a sound card with rates of 48, 96, 192 ksps. On receive I can do this at a price. On transmit, I don't know of a fractional rate converter that preserves I/Q balance. The Tx audio is always 48 ksps. I can convert to 96 and 192 ksps by multiplying by 2 or 4. But I do not relish the thought of providing rate converters for any hardware that comes along with different Tx rate requirements.

I have spent a lot of time on Soapy. I am also very unsatisfied with the Tx performance. The API just seems to be broken. If I find time I can work on this, but as of now I have lost confidence in Soapy.

Jim
N2ADR

Hello Jim,

The testusb.py is a hardware file. Put it on you computer somewhere and enter the hardware file path on the Config/radio/Hardware screen. This is an old file and I don't know if it still works.

Jim
N2ADR

I would like to use an external encoder with my Raspberry/SoftRock combination.? I searched out (thanks google) previous efforts and found that the topic was covered before.? It was called Embedded Quisk and Mr. Ahlstrom (Thanks for your efforts!) had a file called? "testusb.py" (May 7, 2018, titled embedded Quisk). I have saved that file but I'm confused "where" I should insert this file to gain access to an external shaft encoder.? Could you point me in the right direction? I'm relatively new to Quisk and Linux.
Jim W0CHL

Hello Rob,

?

Thanks for your advice.

According my configuration I keep the debouncing and pullup circuit since the GPIO is keyed by the relay from my homemade K3NG keyer . It will protect the GPIO since this part is really sensitive. In addition it provide a little filtering regarding any RF issue which is always possible in our hobby.

The possible issues are maybe ?the following assumptions :

-I am using a raspberry PI 3B+ which is behind the RPI 4 in terms of CPU and performance. Currently the CPU load is about 40 to 50 % when using Quisk which is acceptable but not as perfect . My assumption this load is participating to the latency I have noticed.

-I am using the Behringer Ucontrol / UCA202 Interface audio USB for the IN/OUT IQ signals. This device is supposed to be low latency therefore I cannot find any specification regarding the latency provided . To drive this USB audio device I am also using ALSA.

For Quisk in the Config menu my current latency adjustment for the buffering is 150ms , I need to adjust to 50ms in order to reduce the latency when I am? keying the paddle. Therefore at 50ms the audio is downgraded and I notice some clipping (Buffering).

Obviously I did not perform an accurate measurement but even visually when I am keying the paddle and look carefully to the RS-HFIQ I can cleary notice the lag. I will say it is about 100 up to 2 or 300ms . For voice no issue but? very difficult to adjust the keying of the paddle when using CW mode .

As you said , the solution will be to provide a monitoring audio with the GPIO at the ouput of the Raspberry .

The other alternative I choose currently is to use an external Keyer and use the BUG mode in order to key the raspberry using only the dash. Since I still have my homemade K3NG CW keyer this alternative is in fact not so bad and working perfectly. The K3NG is full of capabilities and features and since we are using Quisk or any other software to drive our SDR TRX , using K3NG is something interesting since this keyer is capable to be driven by software in particular with logging software (I am using CQRLOG and Winkey capabilities).

73s Didier / F5NPV

List is here.


I've personally only run on a pi4 2gb.
--
Julian, kf4mot

It's a pretty neat disk image for those interested in sdr on the pi.


Julian, kf4mot

In the interests of decluttering the RS-HFIQ Technical Support forum, I'm crossposting here my latest reply in a thread that Didier F5NPV and I have been having:

Hi Jim,

I am really grateful to you for having developed QUISK and I really enjoy using it with my redpitaya but I am afraid but there is a serious issue with your implementation of soapysdr, at least for the plutosdr.

1) The minimal safe raw sampling rate (not accounting for decimation/interpolation) for both TX and RX? with the plutosdr is 2084 khz, this was confirmed to me from several sources, notably this one:


2) In the config menu of QUISK, in the help box for the RX sampling rate, you are indicating in the text several so called "available" sampling rates but NONE of the values proposed are supported by the plutosdr as all values are less? 2084 Khz!!. Most pluto users use values between 2084 and 3126 khz with sdrangel and then DECIMATE to get to lower bandwidth of 192 khz or so. The text of the help box of the RX sampling rate is really confusing for the end user?? so I suggest that you replace the text to indicate clearly that it is the responsibility of each user needs to identify what is the correct RX sampling rates for their devices (instead of making? references to so called "available sampling rates" that varies from one device to the other); a plutosdr is not a limesdr!. Fortunately, the raw RX sampling rate can be set manually to 2084 Khz and this happily produces no errors in the QUISK console and results in reception in a clean waterfall with only a minor DC spike (with TX disabled) and no spurs. How decimation works with QUISK in the case of the Pluto is unclear to me.....but it is only reasonable to expect that user may want? to decimate that raw sampling rate of 2084 Khz? by factors ranging between 1,2,4,8,16,32 or 64 to get to 192 khz or so. So? I suggest you add a check box to allow users to chose a decimating factor.. just like what has been done successfully with sdrangel, this will be much less confusing

3) The big problem? is the TX sampling rate; In my environment with my plutosdr it is IMPOSSIBLE to enter the? value of 2084 Khz in the TX sampling rate box ( it is locked !! - greyed) ! None of the values "available"? proposed in that locked TX sampling rate box are adequate for the plutosdr, the max value proposed is 192!!! 2084 is needed !!!, so please change the TX sampling rate box so any value can be entered manually just like for the RX sampling rate ! Also, the text of the help box? of the TX sampling rate is really messed up big time in my environment with my plutosdr, the sampling rates that are indicated in that helpbox are just NOT AVAILABLE (in my environment) in the list of the values locked in that TX sampling rate box!? I think that the Interpolation factor (ie what is corresponding to the RX? decimation factor but for TX) could be set automatically by QUISK based on the value of the decimation factor chosen for the RX (unless you allow the user to set that value independently? of the decimation factor with a separate menu box, maybe better)

? ?
Many thanks for your work Jim. It would be really nice if you could solve these TX and RX sampling rate issues so I can ALSO use my plutosdr with QUISK.

Regards
Peter

Just a quick update:
I've been fighting a Python 3 problem for about a week now, and finally got
it. Charleston SDR support in Quisk is now working for Python 2 and 3. My
next step is to work on Windows support, then I can send everything to Jim
for integration.
73, Terry, N4TLF

I've finally got my code straightened out for my CW keyer mod for Quisk, and I'm throwing it out there for folks to mess with.? I will note that this has been used in exactly one configuration, which is with Quisk 4.1.52 running on a Raspberry Pi 4, using a HobbyPCB RS-HFIQ as the rig.? The keyer mod itself (which is written in C) should be usable with any PC that has GPIO pins and can support the WiringPi library, but you may have to make some changes.

All of the code is in git repos, and you can find some hastily written instructions at the following web page:?

If your interested, by all means visit the page, download the code, ask questions, make comments... I apologize for not having a good hardware schematic posted.? But really, at a minimum, you just need two GPIO pins for input.? Add some debouncing to them if you want.? Wire up a jack to the pins, plug in your paddles, download/compile the code, and give it a whirl.

Regards,
-Rob KC4UPR

here are the relevant links to the? working soapysdr implementation of sdrangel:
(for? a possible source of inspiration to improve the soapysdr implementation of QUISK)

soapysdroutput plugin:
Soapy ressources:
General architecture:

Ok there is definitively a HUGE problem with the audio signal generated by QUISK in SSB with the Pluto & Soapysdr. Actually even a simple CW signal is not clean (low frequency modulation)

All test below are done with RX samply rate= Rx bandwidth = TX bandwidth = 1000 Khz. I am playing with the tx sampling rate


1) When using TX sample rates of 48 and 50 Kkhz, "the TX audio" tab in the config menu gives good results but the output modulated signal is not exploitable. With 48 Khz, there is simply no output signal. With 50 Khz, there is an ouput signal but it is completely distorted actually unusuable. Even a simple CW spot tune will not produce a clean CW signal but something that is slowly low frequency modulated . For 48 and 50 khz is the error is the following

[CRITICAL] sample rate is not supported.
[ERROR] Unable to set BB rate.
[INFO] Using format CF32.
[INFO] Auto setting Buffer Size: 32768
[INFO] Set MTU Size: 32768
[INFO] Using format CF32.
[INFO] Has direct TX copy: 1
[INFO] Has direct RX copy: 1
ALSA lib pcm_dsnoop.c:618:(snd_pcm_dsnoop_open) unable to open slave
ALSA lib pcm_dmix.c:1052:(snd_pcm_dmix_open) unable to open slave
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib dlmisc.c:254:(snd1_dlobj_cache_get) Cannot open shared library /usr/lib/x86_64-linux-gnu/alsa-lib/libasound_module_pcm_equal.so
ALSA lib dlmisc.c:254:(snd1_dlobj_cache_get) Cannot open shared library /usr/lib/x86_64-linux-gnu/alsa-lib/libasound_module_pcm_equal.so
ALSA lib pcm_dmix.c:1052:(snd_pcm_dmix_open) unable to open slave
Pulseaudio threaded mainloop started
Connected to on7yi-ubuntu
Context Terminated

2) For 96 Khz TX sampling rate and above, the audio in "the TX audio" tab in the config menu gives bad distorted results and the rf output signal is also completely distorted (slowed); it does not work at all.
In recception, the audio is completely "hashed" as if there was not enough bandwidth
There is another type of error in the console, see below

root@on7yi-ubuntu:/usr/src/SoapySDR/build# python3 /usr/src/*52/quisk.py
[NOTICE] sample rate needs a FIR setting loaded.
[INFO] Using format CF32.
[INFO] Auto setting Buffer Size: 2048
[INFO] Set MTU Size: 2048
[INFO] Using format CF32.
[INFO] Has direct TX copy: 1
[INFO] Has direct RX copy: 1
ALSA lib pcm_dsnoop.c:618:(snd_pcm_dsnoop_open) unable to open slave
ALSA lib pcm_dmix.c:1052:(snd_pcm_dmix_open) unable to open slave
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib dlmisc.c:254:(snd1_dlobj_cache_get) Cannot open shared library /usr/lib/x86_64-linux-gnu/alsa-lib/libasound_module_pcm_equal.so
ALSA lib dlmisc.c:254:(snd1_dlobj_cache_get) Cannot open shared library /usr/lib/x86_64-linux-gnu/alsa-lib/libasound_module_pcm_equal.so
ALSA lib pcm_dmix.c:1052:(snd_pcm_dmix_open) unable to open slave
Pulseaudio threaded mainloop started
Connected to on7yi-ubuntu

3) here are working settings with sdrangel in TX mode.
Setting all parameters to 1000 Khz works like a charm

Ok reverting to v0.71? of SoapySdr solves the issues (the version available in the Ubuntu repository)
As indicated in the release note of v0.8 of SoapySdr, there is indeed a change of structure of the SoapySDRDevice_setupStream

==========================

?

Build:

- Update to CMake 3.0 style and project config generation

- Increase the CMake build requirement to version 3.1.0

?

API:

- Constants for boolean setting strings SOAPY_SDR_TRUE/FALSE

- Templated read/writeSetting()/readSensor() for SoapySDR::Device

- Added Templated StringToSetting() and SettingToString() helpers

- Python bindings duck typing for read/writeSetting()/readSensor()

- Changed SoapySDRDevice_setupStream() to return the stream pointer

Release 0.8.0 (pending)

Using v0.71 of SoapySDR with the beelding edge version of the SoapySDrmodule NOW WORKS in TX mode....
The spot function was tested sucesfully? (+2 dbm CW signal at 435 Mhz with a gain of 89 in the config settings)

=> However the audio in SSB seems to me awfully distorted with QUISK (though perfect with sdrangel), I still need to investigate if it is just a matter of settiings/configuration in the config menu or if there is something else problematic

thanks, at least it confirms my environment is doing ok,

This looks like something for Jim? ;-)