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
Search
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) |
|
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) |
|
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 |
|
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 |
|
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) |
|
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. |
|
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. |
|
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. |
to navigate to use esc to dismiss