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
So the next question is what if you keep rigctl runn?
toggle quoted message
Show quoted text
rigctl -m 10 f F 7071000 f f F 7072000 f f Does Quisk follow and you get the right answers every time? One other possiblity rigctl -m 10 --set-conf=cache_timeout=0 f See? if that? makes a difference. Mike W9MDB On Sunday, August 20, 2023 at 01:24:31 PM CDT, ag5gt@... <ag5gt@...> wrote:
Mike, This is interesting. I fired up the rpi P400 and quisk, and did what you asked, though quisk was initially at 3903000 rather than 7060000. The response was correct. I then followed that with another query of quisk's frequency. I got the same wrong answer (7067000) as in previous tests. Here's the exact sequence: rigctl -m 10 f F 7071000 f 3903000 7071000 rigctl -m 10 f 7067000 I am poised to wipe the 32 bit OS and try re-building with 64 (a laborious process), but will hold off, if you need more experimentation with 32 here. Bruce |
|
Re: Hamlib/rigctl compatibility?
Just for grins, I did a couple more combinations where I set quisk's frequency on its display and then tried a read-back from rigctl . Here's the sequence:
Set quisk to 7072000, then: rigctl -m 10 f
7071000
rigctl -m 10 f 7071000
There was a consistent read-back error of 1khz in that case. Then, after I set quisk to 7080000: rigctl -m 10 f
7088000
rigctl -m 10 f 7088000
Again the read-back error is consistent, once it happens, until the next change at quisk's display. I'm no pro as a programmer, but when I encounter stuff like that, I go looking for a number type conversion problem. That's the sort of thing that can work on one version/revision of a compiler and not on another. ?
? |
|
Re: Hamlib/rigctl compatibility?
Mike,
This is interesting. I fired up the rpi P400 and quisk, and did what you asked, though quisk was initially at 3903000 rather than 7060000. The response was correct. I then followed that with another query of quisk's frequency. I got the same wrong answer (7067000) as in previous tests. Here's the exact sequence: rigctl -m 10 f F 7071000 f
3903000
7071000
rigctl -m 10 f
7067000
I am poised to wipe the 32 bit OS and try re-building with 64 (a laborious process), but will hold off, if you need more experimentation with 32 here. Bruce ? |
|
Re: Hamlib/rigctl compatibility?
Mike Black
I can't duplicate the problem here.? I get the actual frequency Quisk shows every time.
toggle quoted message
Show quoted text
So what happens with this.... rigctl -m 10 f F 7071000 f I get this... rigctl -m 10 f F 7071000 f 7060000 7071000 Mike On Saturday, August 19, 2023 at 11:05:39 PM CDT, ag5gt@... <ag5gt@...> wrote:
Mike, I'm replying to your message sent before Jim responded. First, your command line didn't work. I'm guessing you meant this, " rigctl -m 10 -vvvvv -Z f >log.txt 2>&1". The log file from that is attached. FYI, the computer and quisk had been shut down after this morning's test. Interestingly, powering up tonight and repeating the sequence produced the identical result: Quisk displays 7071000 and the read-back from rigctl reports 7067000. Perhaps I should remind everybody this problem shows up on a Raspberry Pi P400 while running the 32 bit version of the Pi OS. Could we have a bug that is hardware or compiler specific? Bruce ag5gt |
|
Re: Hamlib/rigctl compatibility?
Mike,
I'm replying to your message sent before Jim responded. First, your command line didn't work. I'm guessing you meant this, " rigctl -m 10 -vvvvv -Z f >log.txt 2>&1". The log file from that is attached. FYI, the computer and quisk had been shut down after this morning's test. Interestingly, powering up tonight and repeating the sequence produced the identical result: Quisk displays 7071000 and the read-back from rigctl reports 7067000. Perhaps I should remind everybody this problem shows up on a Raspberry Pi P400 while running the 32 bit version of the Pi OS. Could we have a bug that is hardware or compiler specific? Bruce ag5gt |
|
Re: Hamlib/rigctl compatibility?
Mike Black
I need to know what the problem is..... What's not working?? I'm lost now in this thread.
On Friday, August 18, 2023 at 12:50:23 PM CDT, jimahlstrom <jahlstr@...> wrote:
I downloaded Hamlib 4.6~git and built rigctl. I tested rigctl with my Quisk 4.2.22 using model 10. The "F" and "f" commands worked fine. This is still on Ubuntu 64-bit. 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. And I have struggled to find documentation. Jim N2ADR |
|
Re: Hamlib/rigctl compatibility?
I downloaded Hamlib 4.6~git and built rigctl. I tested rigctl with my Quisk 4.2.22 using model 10. The "F" and "f" commands worked fine. This is still on Ubuntu 64-bit.
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. And I have struggled to find documentation. Jim N2ADR |
|
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 |
to navigate to use esc to dismiss