Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
- N2adr-Sdr
- Messages
Search
|
Re: Hamlib/rigctl compatibility?
Mike Black
Model 10 does not exist in Hamlib 4.3.1 It's in the latest.... Mike W9MDB
On Friday, August 18, 2023 at 12:09:19 PM CDT, jimahlstrom <jahlstr@...> wrote:
I tested Quisk 4.2.22 with rigctl 4.3.1 on my Ubuntu 64-bit system using rig model 2 and the "F" and "f" commands worked fine. I tried using your model 10 but my rigctl reports that there is no model 10. What is model 10? There should be no difference between a 64-bit and 32-bit OS, and I doubt that is the problem. What happens if you use rig model 2? Jim N2ADR |
|
Re: Hamlib/rigctl compatibility?
I tested Quisk 4.2.22 with rigctl 4.3.1 on my Ubuntu 64-bit system using rig model 2 and the "F" and "f" commands worked fine. I tried using your model 10 but my rigctl reports that there is no model 10. What is model 10?
There should be no difference between a 64-bit and 32-bit OS, and I doubt that is the problem. What happens if you use rig model 2? Jim N2ADR |
|
Re: Hamlib/rigctl compatibility?
Mike Black
?rigctl -m 10 f -vvvvv -Z >log.txt 2>&1 And send me the log.txt file please. Mike W9MDB
On Friday, August 18, 2023 at 06:53:39 AM CDT, <ag5gt@...> wrote:
There is another little factoid that may be relevant. It does not seem to matter how long one waits to enter the read-back command. I waited several minutes and did this again, having left quisk tuned to 707100: ? ? rigctl -m 10 f The response was still ? ?7067000 There's more than just timing involved. That seems to be systematic corruption of data, independent of timing. |
|
Re: Hamlib/rigctl compatibility?
There is another little factoid that may be relevant. It does not seem to matter how long one waits to enter the read-back command. I waited several minutes and did this again, having left quisk tuned to 707100:
? ? rigctl -m 10 f The response was still ? ?7067000 There's more than just timing involved. That seems to be systematic corruption of data, independent of timing. |
|
Re: Hamlib/rigctl compatibility?
On Sat, Aug 5, 2023 at 11:39 AM, Mike Black wrote:
rigctl -m 10 -vvvvv -Z F 7071000 f >log.txt 2>&1I'm sorry for the slow reply. Life sometimes interferes with ham radio ;-) The log is attached. FYI, at the time I issued your diagnostic command, quisk was tuned somewhere in the 80 meter band. Your diagnostic read-back may reflect that. After your diagnostic command, quisk was tuned to 7071000, as would be expected. I followed that with this command line: ? ? ? ? ?rigctl -m 10 f The response was 7067000 and NOT the 7071000 displayed by quisk. Bruce ag5gt |
|
Re: slow output ramp up with digital audio input
Mike Black
Two things you should be able to do....
toggle quoted message
Show quoted text
#1 Run "top" to see which process is taking the most? CPU time #2 Run "strace" on the process ID to see what it is doing. Mike W9MDB On Monday, August 7, 2023 at 10:00:53 AM CDT, Mario Vano AE0GL <mvano@...> wrote:
Interesting to hear you are seeing it on another linux version. I'm still working on it, but the most effective change I made was to lengthen the SSB TX delay a great deal. I'm using the maximum I can stand for voice work (around 500ms). This continues to point to a task CPU starvation as the cause. It's much more difficult to figure out what process to blame. Watching the CPU utilization graph during the events in question shows massive CPU use while it's happening. It's possible the Pi is hitting 100% briefly and then returning to normal as the audio ramps up. You can get an idea if it's an audio problem or not by watching the Quisk "Status" page. It will show the TX levels coming in from the audio system, as well as those going out to the TX IQ. If, for example it's happening in Quisk, then the digital audio input will be steady, but the IQ output will ramp up. If it's somewhere else, the digital audio input will ramp up and the IQ output will track it. Note also that older versions of WSJTX sometimes refuse to output audio at all on the first transmission. This can confuse testing a bit. I'd like to install a later WSJTX to see if it's the culprit, but have been unable to use anything later than the one in the Raspbian repository due to competely insane dependency problems. I believe there's not currently a maintainer for the WSJTX non-PC versions (due to the death of the man who used to do it). I'm also trying to optimize all my shared library code and QUISK hardware file as much as possible - always a good idea in any case... I'll report back if I learn any more. |
|
Re: slow output ramp up with digital audio input
Interesting to hear you are seeing it on another linux version.
I'm still working on it, but the most effective change I made was to lengthen the SSB TX delay a great deal. I'm using the maximum I can stand for voice work (around 500ms). This continues to point to a task CPU starvation as the cause. It's much more difficult to figure out what process to blame. Watching the CPU utilization graph during the events in question shows massive CPU use while it's happening. It's possible the Pi is hitting 100% briefly and then returning to normal as the audio ramps up. You can get an idea if it's an audio problem or not by watching the Quisk "Status" page. It will show the TX levels coming in from the audio system, as well as those going out to the TX IQ. If, for example it's happening in Quisk, then the digital audio input will be steady, but the IQ output will ramp up. If it's somewhere else, the digital audio input will ramp up and the IQ output will track it. Note also that older versions of WSJTX sometimes refuse to output audio at all on the first transmission. This can confuse testing a bit. I'd like to install a later WSJTX to see if it's the culprit, but have been unable to use anything later than the one in the Raspbian repository due to competely insane dependency problems. I believe there's not currently a maintainer for the WSJTX non-PC versions (due to the death of the man who used to do it). I'm also trying to optimize all my shared library code and QUISK hardware file as much as possible - always a good idea in any case... I'll report back if I learn any more. |
|
Re: slow output ramp up with digital audio input
Hi,
toggle quoted message
Show quoted text
I see similar behaviour on Fedora 37. If I hit the 'Tune' button in wsjtx for the first time the HL2 output power slightly rises from 0 up to 5 W in cca. 2 seconds or so. After that it works OK. I suspect it's some PipeWire AGC which is tuning the channel when it's used for the first time. So far I haven't found how to switch this behavior off 73! Jaroslav, OK2JRQ Mario Vano AE0GL napsal(a): OK, I've confirmed that if I Hide the Quisk window while running WSJTx (by minimizing it in the window manager), the problem completely disappears. |
|
Re: slow output ramp up with digital audio input
OK, I've confirmed that if I Hide the Quisk window while running WSJTx (by minimizing it in the window manager), the problem completely disappears.
I think something in Quisk's display routines is starving other threads when it runs on the pi. I think it's also causing some disruption to the WSJTX output as the power seems to fluctuate a little during the transmission. It's possible something like this is also happening at other times, but as I said, CW operation seems normal, and I've made some SSB contacts as well and hadn't noticed it yet. I don't know if there's a simple fix... thanks, Mario (AE0GL) |
|
Re: slow output ramp up with digital audio input
Even More info:
When I configured WSJTX, I failed to set the Mode in the Radio dialog to Data/Pkt. Doing so has very much reduced the problem. Now it only seems to occur the first time I transmit after launching Quisk - after that it's a much smaller change. Relaunching WSJTX does not repeat the problem... It's probably possible to live with it at this level... M |
|
Re: slow output ramp up with digital audio input
More info:
I've tried raising the Debug level from 0 With it set to 0, I always see the slow ramp up when I press Tune With it set to 1, I only see it once every few times - the rest of the time, full power starts immediately! With it set to 2, I see it most, but not every time I don't ever see any messages in the debug window except the initial date and time. The CPU usage is not excessive in any of the modes - running about 38% except while decoding The Memory usage is low - 26% (on a 2Gb system) M |
|
Re: slow output ramp up with digital audio input
Mike Black
What computer and what OS?
toggle quoted message
Show quoted text
Mike W9MDB 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) |
|
slow output ramp up with digital audio input
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 I see the same behavior in FLDigi as well as WSJTX 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) |
|
Re: Hamlib/rigctl compatibility?
Mike Black
If you want a bit between the commands does it work OK?
toggle quoted message
Show quoted text
Hamlib is simply asking Quisk for current frequency and it SHOULD be waiting for Quisks' set_freq to finish. So try this and send me the output and I'll look at the timing.?? rigctl -m 10 -vvvvv -Z F 7071000 f >log.txt 2>&1 Mike W9MDB 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? |
|
Hamlib/rigctl compatibility?
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? |
|
Re: An audio start-up hitch in 4.1.77 running on a Pi 400
I should mention wsjtx also fails to coordinate frequency settings with this version of quisk and hamlib rigctl. Random frequency changes occur as wsjtx periodically attempts to update tuning status.
I probably should have started a new thread, since the discussion focus has drifted from the minor audio glitch to hamlib/rigctl with quisk versioning... |
|
Re: An audio start-up hitch in 4.1.77 running on a Pi 400
Mike Black
Add -vvvvv to see what's being returned.
toggle quoted message
Show quoted text
I suspect if you wait just a little longer you'll get the right answer. Mike W9MDB 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? |
|
Re: An audio start-up hitch in 4.1.77 running on a Pi 400
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? |
|
Re: Quisk 4.2.0 and HL2 on windows 10 PTT not sending full power on mode USB
Kesh Patel
Problem Solved...
Hi Jim, Thank you for pointing to right place. I found that there was no audio in comming from WSJT. I set it to virtual com port and it started working. Now WSJT can send FT8/FT4 will full power 5.6 watt using USB mode. My FT8 signals are now reaching to USA on a 5.6 watt transmission...amazing... Thank you Jim for your help and time. Regards Kesh VK2KES Request: I am very qurious for HL2 IO board as I have Ukrainian transverter to be tested with Quisk 4.2.21 + HL2. If IO board? left then I am keen to test and provide you test results. |
to navigate to use esc to dismiss