开云体育

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

zbitx cw performance problems solved?

 

Dear CW enthusiasts, I saw a lot of complaints in the past weeks about bad CW performance here.
is this problem now solved?
DL4ZAQ Peter
 

Unfortunately, I haven't received my zBitx yet, but as I cen see from the schematic diagram: , the key (J3) is connected to pins GPIO7 (PTT) and GPIO21 (R-DASH).
Both those pins are interrupt capable (correct me if I'm wrong). The libgpiod offers a possibility where the thread sleeps waiting for the change of the state of a set of interrupt capable GPIOs. Can't that be used to improve the latency instead of periodic polling?
In the worst case, the handling of the interrupt of selected pins can be implemented in the kernel space.
(A few years ago I had to write a few kernel drivers that connected to the GPIO subsystem in linux (e.g. or ). They were not used for low-latency handling interrupts, but that's possible as well.)
?
73,
Wojtek SP5DAA
 

I believe Ashhar has already handled the interrupt recognition on key closure.? ?The problem appeared to be "doing something as a result" - which impacts other portions of the system.? ?That is where the slow polling was appearing to cause the problem.? ?Speeding up THAT part made a HUGE improvement in the sBitx and Erik's results with the zBitx appeared to be the same improvement.? ?Now Ashhar is contemplating integration.? ?

Gordon KX4Z


On Sat, Apr 12, 2025 at 6:33?AM WZab - SP5DAA via <wzab01=[email protected]> wrote:
Unfortunately, I haven't received my zBitx yet, but as I cen see from the schematic diagram: , the key (J3) is connected to pins GPIO7 (PTT) and GPIO21 (R-DASH).
Both those pins are interrupt capable (correct me if I'm wrong). The libgpiod offers a possibility where the thread sleeps waiting for the change of the state of a set of interrupt capable GPIOs. Can't that be used to improve the latency instead of periodic polling?
In the worst case, the handling of the interrupt of selected pins can be implemented in the kernel space.
(A few years ago I had to write a few kernel drivers that connected to the GPIO subsystem in linux (e.g. or ). They were not used for low-latency handling interrupts, but that's possible as well.)
?
73,
Wojtek SP5DAA
 

The kernel GPIO driver may also record the exact time of each interrupt. So if we may accept certain latency, but want to keep the original timing, it is doable. Well, it is inconvenient like playing electric guitar via a high latency virtual amplifier and sound procesor...

73
Wojtek SP5DAA

sob., 12 kwi 2025, 12:43 u?ytkownik Gordon Gibby KX4Z via <docvacuumtubes=[email protected]> napisa?:

I believe Ashhar has already handled the interrupt recognition on key closure.? ?The problem appeared to be "doing something as a result" - which impacts other portions of the system.? ?That is where the slow polling was appearing to cause the problem.? ?Speeding up THAT part made a HUGE improvement in the sBitx and Erik's results with the zBitx appeared to be the same improvement.? ?Now Ashhar is contemplating integration.? ?

Gordon KX4Z


On Sat, Apr 12, 2025 at 6:33?AM WZab - SP5DAA via <wzab01=[email protected]> wrote:
Unfortunately, I haven't received my zBitx yet, but as I cen see from the schematic diagram: , the key (J3) is connected to pins GPIO7 (PTT) and GPIO21 (R-DASH).
Both those pins are interrupt capable (correct me if I'm wrong). The libgpiod offers a possibility where the thread sleeps waiting for the change of the state of a set of interrupt capable GPIOs. Can't that be used to improve the latency instead of periodic polling?
In the worst case, the handling of the interrupt of selected pins can be implemented in the kernel space.
(A few years ago I had to write a few kernel drivers that connected to the GPIO subsystem in linux (e.g. or ). They were not used for low-latency handling interrupts, but that's possible as well.)
?
73,
Wojtek SP5DAA

1 - 4 of 4