On Saturday, August 5, 2023 at 03:56:08 PM CDT, Mario Vano AE0GL <mvano@...> wrote:





Hi:

I think I'm seeing something unusual in the behavior of the digital mode for fldigi and wsjtx.

When I key up in either program, the output starts out at a lower level than normal and only gradually rises to full output over a period of around 5 seconds. In my configuration, full output is around 5 watts. The initial output is less than one watt and takes quite a while to rise to 5 watts.
The status panel reflects the same thing!

The radio hardware and shared library have been operating well for FT8 using my own GnuRadio based software for about a year and is very reliable.


The Digital TX0 Input line show a steady -3.1
The IQ TX Sample output first appears at somewhere below -12 and slowly rises to above -6 db (tracking the power output I am seeing).

If I switch manually to CWL without leaving WSJTX and press the key, I get full output immediately.

The band in this example was 17 meters, but similar results happen in all of them.
The mode in question is DGT-U
Quisk version 4.2.19 from PyPy

My radio is somewhat similar to the SoftRock USB in its interface except that all the IO is via I2C, I2S and GPIO via a well debugged shared library.
I have been working with Quisk for about a year, so I think my code is fairly stable, but I'm only now trying to get the digital modes working.?

My hardware.py file is based on modifications to the Softrock hardware file to ignore the USB and call my library where needed.

I have a few other questions concerning the behavior of the tuning controls and keeping things inside my passband limits, but everything else is operating well. I'll bring them up later.

Let me know if you'd like me to upload my hardware file (It's not very big).

Thanks again for all of everyone's work - my "radiohat" project has been on hold during Covid, but it's coming alive again and I have several prototype systems working now. I've decided to make Quisk the primary software for it - now that I've got it nearly 100% functional - It's been working well on the air...

Mario
(AE0GL)

On Saturday, August 5, 2023 at 11:04:45 AM CDT, ag5gt@... <ag5gt@...> wrote:





This is a continuation of a previous thread whose subject matter had drifted from its starting point. Essentially, this relates to a problematic update of Quisk running on an RPi P400 with the default rpi 32-bit operating system. The original installation of Quisk and Hamlib from the RPi repository produced workable results, though interaction was appreciably slow. The update of Quisk from PyPi corrected a minor annoyance, but also exposed a more serious hamlib/rigctl problem.

Here, I am responding to this posting from the previous thread:?/g/n2adr-sdr/message/2803??That post suggests Quisk's interaction with hamlib is failing because Quisk emulates hamlib/rigctld, but has not kept up with hamlib evolution. An incompatibility may have crept in, I guess.

To test, I installed Quisk 4.2.20 and Hamlib 4.6~git. Then I did a simple command-line experiment with rigctl communicating with Quisk to first set and then get frequency. In that particular experiment, setting the frequency worked, but the subsequent read-back was wrong. The read-back was off by 5khz.

I then re-installed WSJTX from the RPi respository. WSJTX was unable to maintain correct frequency sync with Quisk. I believe WSJTX attempts to sync up about once per second. If it happens to come up in sync, it quickly wanders off in a seemingly random way.

Attempts to set and get frequency through one of Quisk's virtual serial ports yield similarly erratic results.

It occurs to me the result might be different with a 64-bit OS installation, but doing that experiment is non-trivial with my setup, so I have not yet done it.

Comments?

On Friday, August 4, 2023 at 05:58:57 PM CDT, ag5gt@... <ag5gt@...> wrote:





I removed the original rpi4 hamlib package and installed the latest from source. I also installed the latest version of Quisk from PyPi (as of a couple of weeks ago). I still see confusing behavior. The screenshot shows an example of the use of rigctl to send a set freq command, "F", to Quisk, followed immediately with a get freq command, "f". In this case, the set freq command was successful, setting quisk's frequency to 7 180 000. However, the immediate read back was wrong, showing 7185000.

This is just one example. A separate tcl/tk script also gets confusing results via one of Quisk's virtual serial ports, using flex formatted commands.

A fact to note is the RPi operating system is the 32 bit version. Would the same thing happen if running the 64-bit version?

Hi all,

I had Quisk running on Windows with no issues, however I made some changes to soundard settings and now Quisk will crash (and close) as soon as the GUI loads. To try and resolve this I have uninstalled Quisk, I have manually deleted all related Quisk files that I can find, I have re-installed Python and Quisk, yet the same issue occurs. Crash on startup.?I can tell that the uninstall process has not cleared the old (incorrect) settings that are causing Quisk to crash (which is frustrating!), because the GUI is still loading in my modified color scheme.??

Can anyone tell me how to completely remove the old Quisk configuration so that I can get the defaults to load on startup? It must be hidden somewhere else that I have not been able to find.. In the registry perhaps??

Any help is greatly appreciated.?

73

?

?