开云体育

ctrl + shift + ? for shortcuts
© 2025 开云体育
  1. BITX20
  2. Topics

Fixed: cw latency and wsjtx/flidigi sidetone

 

I have a minor update?to make zbitx work with wsjtx/fldigi/etc and fixed cw latency.
You have to update?just the raspberry zero.

From a terminal window, type this:
cd ~/sbitx
./update sbitx
this should do it
 

Thank you Ashhar for everything you have done for this project for us all! I appreciate it!


On Sat, Apr 12, 2025, 11:00 Ashhar Farhan via <farhanbox=gmail.com_at_groups.io_0p8dlwo6@...> wrote:

I have a minor update?to make zbitx work with wsjtx/fldigi/etc and fixed cw latency.
You have to update?just the raspberry zero.

From a terminal window, type this:
cd ~/sbitx
./update sbitx
this should do it
 

Tune no longer works.

Leo, AI5II

On Sat, Apr 12, 2025, 11:31 0p8dlwo6 via <0p8dlwo6=[email protected]> wrote:

Thank you Ashhar for everything you have done for this project for us all! I appreciate it!


On Sat, Apr 12, 2025, 11:00 Ashhar Farhan via <farhanbox=gmail.com_at_groups.io_0p8dlwo6@...> wrote:
I have a minor update?to make zbitx work with wsjtx/fldigi/etc and fixed cw latency.
You have to update?just the raspberry zero.

From a terminal window, type this:
cd ~/sbitx
./update sbitx
this should do it
 

I take that back?
Once I opened wsjt-x and? hit tune from there, the tune on the zbitx panel started working?

Leo, AI5II

On Sat, Apr 12, 2025, 11:00 Ashhar Farhan via <farhanbox=[email protected]> wrote:
I have a minor update?to make zbitx work with wsjtx/fldigi/etc and fixed cw latency.
You have to update?just the raspberry zero.

From a terminal window, type this:
cd ~/sbitx
./update sbitx
this should do it
 

First CW contact on YouTube
Thank you Ashar :)
?
Displayed log time is incorrect on this screen, but is correct when I view it via VNC. I'll open a bug report.
?
73
 

I'll be posting another video soon (sigh).
 

开云体育

Many thanks Farhan? !
Now it’s on the way to get really fun in CW ... just upgraded? v 3.052 , much much better.
?
73 & 76 , Jens / HB9JOI
?
+++

On Sat, Apr 12, 2025, 11:00 Ashhar Farhan via <farhanbox=gmail.com_at_groups.io_0p8dlwo6@...> wrote:

I have a minor update to make zbitx work with wsjtx/fldigi/etc and fixed cw latency.
You have to update just the raspberry zero.
?
From a terminal window, type this:
cd ~/sbitx
./update sbitx
this should do it
 

Even after the update to 3.052, working with straight keys isn't possible. There are a lot of dropouts. The "dits" at the beginning of the characters aren't sent, even with a delay of 500. This isn't right! The annoying noise from the speaker is now audible even at volume 0. It's annoying!
 

I agree...
 

You could just tell us in two lines of text what you found and put in a bug report on Github? ?It might be less stressful all around. ?
 

Here is a video with the latest fw installed in the zBitx. CW keying is improved but still poor. Note also the delay in returning to rx after transmitting:
?
?
73,
John AE5X
?
 

开云体育

Yes, it’s still missing dits. ?The full experience of detecting key closure and going all the way to transmit is not happening often enough per second. ? That would drive me nuts.

It seems that Eric demonstrated that the fix proposed works. I’m not clear why it’s not being used. (there may be some other factor that I’m not understanding) ?It is what I have going on all of my V2 units, and it’s a lot of fun!!


I think the problem with return to receive is AGC.
Perhaps it is being altered during transmit?

Gordon kx4z?



On Apr 13, 2025, at 16:09, John AE5X via groups.io <ae5x@...> wrote:

?
Here is a video with the latest fw installed in the zBitx. CW keying is improved but still poor. Note also the delay in returning to rx after transmitting:
?
?
73,
John AE5X
?
 

On Sun, Apr 13, 2025 at 03:17 PM, Gordon Gibby KX4Z wrote:
Yes, it’s still missing dits.
And, less frequently, dahs.
 

Sadly I'm now confirming same, it misses dits and dahs at as slow as 10WPM and regardless of in IAMBIC or IAMBIC B mode.

I field tested it today.. nevermind that the screen was near impossible to read, but CW was near impossible to send. I set the QSK to 650mS and it approached reasonable. Sometimes the memory keyer would work, other times it would abandon partway through the message 'cq pota de ve6lk k'
?
AGC was off.
?
 

On Sun, Apr 13, 2025 at 04:57 PM, Vince d'Eon VE6LK/AI7LK wrote:
but CW was near impossible to send
To Ashhar: twice now you've released firmware updates that you state "fix" the CW timing problems. Many CW ops realize that the problems remain. What is your criteria for claiming that the issues are fixed? Was the zBitx field tested at all before being offered for sale with CW issues that were truly terrible, making the mode inoperative? The reverse side of the test result card that comes with each zBitx claims that it is ready to go, on all modes.
 

Is the CW fix time-stamping the key closures in the interrupt handlers? ?If not, you will miss dits, as the code can't tell which key closed first, or if it missed a key closure, via polling of a global variable from a process running on a preemptive non-real-time kernel on a single core processor. ?Every time the Linux OS process dispatcher ticks, your code will have very long gaps in its polling loop. ?With IO pin time stamps, the code has enough information available to see whether it handled that time stamped event or not, and in the correct order. ?Making it much harder to miss dits.
?
The other way to solve the problem might be a hardware change. ?Poll the key inputs with one of the Pi Pico state machines, and have the Pico generate the dot dash timing.
?
73, Ron, n6ywu
 

开云体育

Ron, you seem to know a lot more about that than I do. ?When we changed the polling on the SBitx ?it fixed the problem completely. Can you explain why that worked so well??

Gordon kx4z?



On Apr 13, 2025, at 18:55, Ron, N6YWU via groups.io <ron.nicholson@...> wrote:

?
Is the CW fix time-stamping the key closures in the interrupt handlers? ?If not, you will miss dits, as the code can't tell which key closed first, or if it missed a key closure, via polling of a global variable from a process running on a preemptive non-real-time kernel on a single core processor. ?Every time the Linux OS process dispatcher ticks, your code will have very long gaps in its polling loop. ?With IO pin time stamps, the code has enough information available to see whether it handled that time stamped event or not, and in the correct order. ?Making it much harder to miss dits.
?
The other way to solve the problem might be a hardware change. ?Poll the key inputs with one of the Pi Pico state machines, and have the Pico generate the dot dash timing.
?
73, Ron, n6ywu
 

There's one big difference between the SBitx and zBitx. ?
The number of ARM processor cores in the Pi 3B or 4 or 5 is greater than one. ?Whereas the Pi Zero 2 W only has only one ARM processor core.
?
On zBitx, which uses a Pi Zero 2 with a single core, the non-real-time Linux OS kernel is guaranteed to interrupt the polling loop process periodically, and maybe do some random Linux housekeeping or run other processes.
?
I just ssh'd into my zBitx and listed running processes. ?There were 150 processes listed, and 8 to 12 of these process were continually getting measurable CPU time. ?The sbitx process was barely getting 60% of CPU time. ?Which means 40% of the time, it's likely suspended instead of polling, and thus potentially missing key input changes during suspension. ?Polling in a tighter loop has almost no effect on the duration the polling loop spends inactively sleeping while the CPU is busy elsewhere.
?
The SBitx runs on a multicore processor. ?The OS dispatch will often run on a different processor core than the sbitx polling thread. ?Thus one can often get away with polling, as there's a far higher probability that other lower priority processes will run on other cores, and not cause the polling loop to be suspended.
?
Any real-time low-latency goals or software design has to take the above design constraints into account. ?The pin interrupt handlers likely won't miss pin events if those handlers are written correctly. ?But a user processes have to assume it was just woken from many milliseconds of sleep at random time, and could have missed lots of stuff. ?If you write code that can recognize it missed a dit while sleeping, it might handle that dit a bit late, but at least it won't miss that dit completely.
?
Another possibility is to use a real-time Linux kernel patch, and run the CW keyer at real-time priority. ?But real-time coding has lots of restrictions (deterministic max run time, no memory management, no unbounded time OS calls, etc.). ?Using Core Audio for low latency audio (live music performances) on an iPhone has similar hard real-time restrictions. ?So I've had to learn (the hard way).
?
73, Ron, N6YWU
 

Ron, thanks for taking the time to write such a nice explanation!
I guess the real question is "what is the distribution of delays caused by operating system housekeeping operations on a single core processor?"
?
I posit that in order to be considered "acceptable" a CW product must be able to send every single dot or dash, and more than HALF of each dot.? ?Without any studies to prove it, I suspect that most CW operators (copying in their own head) will be able to tolerate an "dot" that is shortened by less than "half" of its normal time unit.? ?But MISSING a dot is unforgiveable because it changes the code symbol to either nonsense or incorrect.
?
Apparently the length of a "dot" at 24wpm is on the order of 28 milliseconds (I looked that up, so I could be wrong)
?
We can tolerate no more than 10 milliseconds or so of delay or failure to respond.? ?Can a single core Linux raspberry provide that response more than 95% of the time?
?
We have another piece of evidence.
?
Erik (and at least one other) have already taken the revised code, which not only has fantastic interrupt-driven response to the paddle, but crucially ALSO has sped-up polling to DO SOMETHING in response to the detected changed state of the paddle --- and with this sped-up polling (20X sped up) -- they uniformly report that it "works".? ? ?In fact, they were quite positive about its acceptability.
?
So this would suggest that the bottleneck is NOT the uncontrollable operating system overhead, but is instead the every-20th-tic response pointed to time and time again by Mike Johnshoy and others.? ??
?
This is quite testable.? ? The number of ticks that go by, before anything is DONE in response to a noted change in state of the paddles, can be set to any number between 0 and 20 and users can report whether they consider the code "useable"? ? We already have two datapoints:
?
@20 tick polling:? ?we have multiple reports it is considered UN-useable
@? 1 tick polling:? ?we have at least two reports that it is considered "GOOD"
?
So wouldn't it seem reasonable that the operating system is NOT the bottleneck, and that the code itself IS the problem here?? ?We are not talking difficult code.? ?It is only a line or two of changes.? ?I made the change in my own 32-bit version in moments and my sBitx Version 2's immediately worked "useably" - in fact, excellently.? ? I don't have a zbitx on which to try, but many many others do.? ? I'm unclear why this research hasn't been furthered to allow understanding of exactly what is needed for an excellent product.
?
73,
?
Gordon KX4Z
?
?
 

Before this goes much further, we should correct the record. The Pi Zero 2W does not have a single core processor. It has a quad core of the Pi 3B+ era, but with half the memory of that board. Thus the zBitx should not suffer the single core bottleneck issues that were described earlier in the thread.?

Steven, AC1RZ
73


On Mon, Apr 14, 2025 at 03:20 Gordon Gibby KX4Z via <docvacuumtubes=[email protected]> wrote:
Ron, thanks for taking the time to write such a nice explanation!
I guess the real question is "what is the distribution of delays caused by operating system housekeeping operations on a single core processor?"
?
I posit that in order to be considered "acceptable" a CW product must be able to send every single dot or dash, and more than HALF of each dot.? ?Without any studies to prove it, I suspect that most CW operators (copying in their own head) will be able to tolerate an "dot" that is shortened by less than "half" of its normal time unit.? ?But MISSING a dot is unforgiveable because it changes the code symbol to either nonsense or incorrect.
?
Apparently the length of a "dot" at 24wpm is on the order of 28 milliseconds (I looked that up, so I could be wrong)
?
We can tolerate no more than 10 milliseconds or so of delay or failure to respond.? ?Can a single core Linux raspberry provide that response more than 95% of the time?
?
We have another piece of evidence.
?
Erik (and at least one other) have already taken the revised code, which not only has fantastic interrupt-driven response to the paddle, but crucially ALSO has sped-up polling to DO SOMETHING in response to the detected changed state of the paddle --- and with this sped-up polling (20X sped up) -- they uniformly report that it "works".? ? ?In fact, they were quite positive about its acceptability.
?
So this would suggest that the bottleneck is NOT the uncontrollable operating system overhead, but is instead the every-20th-tic response pointed to time and time again by Mike Johnshoy and others.? ??
?
This is quite testable.? ? The number of ticks that go by, before anything is DONE in response to a noted change in state of the paddles, can be set to any number between 0 and 20 and users can report whether they consider the code "useable"? ? We already have two datapoints:
?
@20 tick polling:? ?we have multiple reports it is considered UN-useable
@? 1 tick polling:? ?we have at least two reports that it is considered "GOOD"
?
So wouldn't it seem reasonable that the operating system is NOT the bottleneck, and that the code itself IS the problem here?? ?We are not talking difficult code.? ?It is only a line or two of changes.? ?I made the change in my own 32-bit version in moments and my sBitx Version 2's immediately worked "useably" - in fact, excellently.? ? I don't have a zbitx on which to try, but many many others do.? ? I'm unclear why this research hasn't been furthered to allow understanding of exactly what is needed for an excellent product.
?
73,
?
Gordon KX4Z
?
?

1 - 20 of 32