开云体育

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

CW on zbitx

 

I have fixed the two issues of zbitx on CW.
The new update has good keying with Iambic keyer and the cw decode noise is now gone as well.
To get this update, you have to:
1. Flash the new firmware (the firmware version is now 1.06). The firmware is available from?
2. Update the new software on the raspberry pi, the latest version with the CW keyng fixed is 3.051 (or later).
Here is Jose, VU2JOS sending CW with the new firmware update.

With this, I hope we have moved on with CW issues.
- f
?
 

Excellent! Greatest congratulations! The code sounded wonderful! ?Seems that the pie 02W is able to do this well.
?
great work!
gordon kx4z?
?
?
 

Sorry to be a stickler for detail here but, no, CW issues are not fixed.
CW operation has been improved but there are still timing issues. I'll be posting a video later today.
?
73,
?
John AE5X
?
?
 

?
This issue remains unless it is unreachable code.? I posted this in the other thread about CW mode.
?
?
 

Yeah I think the new software update is an improvement but some of the keying is still rough around the edges. It definitely helped with the chugging sound.

On Wed, Apr 2, 2025 at 9:40?AM Ron Carr via <rcarr=[email protected]> wrote:
?
This issue remains unless it is unreachable code.? I posted this in the other thread about CW mode.
?
?
 

Hi Farhan
I loaded firmware 1.06 and I am very happy the chugging sound has gone from cw reception. This afternoon listening on ssb 20m I did notice some less pronounced chugging sounds. I will try and add this to the github bugs list.
Thanks for the fast cw fix.
73 Nigel MW0NDE?


On Wed, 2 Apr 2025, 06:23 Ashhar Farhan via , <farhanbox=[email protected]> wrote:
I have fixed the two issues of zbitx on CW.
The new update has good keying with Iambic keyer and the cw decode noise is now gone as well.
To get this update, you have to:
1. Flash the new firmware (the firmware version is now 1.06). The firmware is available from?
2. Update the new software on the raspberry pi, the latest version with the CW keyng fixed is 3.051 (or later).
Here is Jose, VU2JOS sending CW with the new firmware update.

With this, I hope we have moved on with CW issues.
- f
?
 

Have you considered using interrupts to handle the GPIO pins connected to the keying inputs? ?Interrupts might reduce or eliminate the possibility of missing the first dot before a dash. ?
?
A priority interrupt handler would need to be written with good real-time coding practices (bounded time algorithm, no locks, no API calls that could involve memory management, etc.). ? But this should be possible. ?Then post the key inputs with time stamps to be handled by the priority keying sidetone process, which perhaps will run only a few milliseconds later. ?The time stamps on the interrupt data would prevent the dash from being handled before any dot, if that was the key closure sequence, and solve at least one issue with fast iambic keying that polling with a slow CPU on a loaded system might never be able to completely solve.
?
73, Ron, N6YWU
 

Ron, I would like you to review the code:
1.?
Here, we setup the ISR (interrupt service routine) to call a function called key_isr whenever the state of the paddle chages (press, release).
2. The key_isr () reads the status of the the two paddles (DASH and PTT) and stores them in global variables ptt_state and dash_state.
3. the cw sending loop has to generate 96,000 samples a second. And it cannot spend?time reading the gpio pins to see if the any new symbol (dot/dash/space) has been generated by the user. Instead, it just reads these two variables. This is done by the routine key_poll().
.4 Read key_poll (). You will note that it executes very quickly. To know what type of key we are using, it doesn't even to a string compare of the CW_INPUT settings, instead it just samples the 6th letter with is different for all the three cases (Straight, Iambic and Iambic-B).
Let me know what you think of the?implementation and if it can be improved.
- f



On Thu, Apr 3, 2025 at 6:57?AM Ron, N6YWU via <ron.nicholson=[email protected]> wrote:
Have you considered using interrupts to handle the GPIO pins connected to the keying inputs?? Interrupts might reduce or eliminate the possibility of missing the first dot before a dash. ?
?
A priority interrupt handler would need to be written with good real-time coding practices (bounded time algorithm, no locks, no API calls that could involve memory management, etc.). ? But this should be possible.? Then post the key inputs with time stamps to be handled by the priority keying sidetone process, which perhaps will run only a few milliseconds later.? The time stamps on the interrupt data would prevent the dash from being handled before any dot, if that was the key closure sequence, and solve at least one issue with fast iambic keying that polling with a slow CPU on a loaded system might never be able to completely solve.
?
73, Ron, N6YWU
 

Hi,
?
I don't know enough about the system and application's architecture to understand the latency issues yet.
Are you using the stock Debian kernel? ?Or a kernel with real-time modifications (RTLinux, et.al.)?
What does the CW sending loop look like? ?How often does it poll? ?What sample buffer sizes is it dealing with?
Are there any underflow or overflow issues to deal with when generating samples?
One thing you might try is calling clock_gettime() within the key ISR to time stamp pin state changes.
That information would allow the polling loop to determine which key input changed first, if both changed between polls.
?
There are serious limitations with what can be done given a single-core processor running a non-real-time OS kernel.
?
73, Ron, n6ywu
 

After so many reports about problems with failed updates
I nevertheless decided to update the zBitx this morning - contrary to my intention.
With surprisingly positive, unexpected update results:
Lambic-A and -B and Straight-Key now work fine and usable up to speed 28 !
I usually use around 24, so I'm happy with it so far.
Output is in line with specified values . SSB doesn't sound too bad either.
I already had concerns and was very skeptical that nothing would work after the update as many report .
But: I dared to do the update after all ...
Well, maybe I was “lucky” with the device.?
I will be happy to use it and keep it, contrary to my previous criticism.
?
73 ! Jens / HB9JOI
?
 

Ashar,

I'm an old sbitx DE user, but I have looked at your newest zbitx code a little. Your new change using interrupts insures the state of the key/paddle is updated in a global variable in a very timely fashion. So you have made that end of the problem even better than it needs to be.

You have always noted in the code comments that you don't want CW sending loop reading the gpio pins 96,000 times per second. But even now when you have accurate/fresh data stored in those variables I think you may not sample them often enough. I verified this on my sbitx DE (but I see some changes to tick counts in the zbitx so I may be wrong) but it seems that ui_tick() does not call modem_poll() often enough - so modem_poll doesn't get called to go use that nice fresh input!

Good luck with the zbitx - it looks great!

Mike - KB2ML


Ashhar Farhan
Apr 2 #116851

Ron, I would like you to review the code:
1.
Here, we setup the ISR (interrupt service routine) to call a function called key_isr whenever the state of the paddle chages (press, release).
2. The key_isr () reads the status of the the two paddles (DASH and PTT) and stores them in global variables ptt_state and dash_state.
3. the cw sending loop has to generate 96,000 samples a second. And it cannot spend time reading the gpio pins to see if the any new symbol (dot/dash/space) has been generated by the user. Instead, it just reads these two variables. This is done by the routine key_poll().
.4 Read key_poll (). You will note that it executes very quickly. To know what type of key we are using, it doesn't even to a string compare of the CW_INPUT settings, instead it just samples the 6th letter with is different for all the three cases (Straight, Iambic and Iambic-B).
Let me know what you think of the implementation and if it can be improved.
- f

--
Mike KB2ML
 

Mike,
Thr cw_poll is not the one the one that is doing the actual keying. See cw_read_key() in?

This is the function that is in turn called by cw_tx_get_sample() 96000 times a second.?

The cw_poll only checks for changed sending speed, etc., to keep the keyer, decoder, etc. upto date.

- f


On Thu, Apr 3, 2025, 6:43 PM Mike Johnshoy via <mike.johnshoy=[email protected]> wrote:
Ashar,

I'm an old sbitx DE user, but I have looked at your newest zbitx? code a little.? Your new change using interrupts insures the state of the key/paddle is updated in a global variable in a very timely fashion. So you have made that end of the problem even better than it needs to be.?

You have always noted in the code comments that you don't want CW sending loop reading the gpio pins 96,000 times per second.? But even now when you have accurate/fresh data stored in those variables I think you may not sample them often enough.? I verified this on my sbitx DE (but I see some changes to tick counts in the zbitx so I may be wrong) but it seems that ui_tick() does not call modem_poll() often enough - so modem_poll doesn't get called to go use that nice fresh input!

Good luck with the zbitx - it looks great!

Mike - KB2ML


Ashhar Farhan
Apr 2? ?#116851? ?

Ron, I would like you to review the code:
1.
Here, we setup the ISR (interrupt service routine) to call a function called key_isr whenever the state of the paddle chages (press, release).
2. The key_isr () reads the status of the the two paddles (DASH and PTT) and stores them in global variables ptt_state and dash_state.
3. the cw sending loop has to generate 96,000 samples a second. And it cannot spend time reading the gpio pins to see if the any new symbol (dot/dash/space) has been generated by the user. Instead, it just reads these two variables. This is done by the routine key_poll().
.4 Read key_poll (). You will note that it executes very quickly. To know what type of key we are using, it doesn't even to a string compare of the CW_INPUT settings, instead it just samples the 6th letter with is different for all the three cases (Straight, Iambic and Iambic-B).
Let me know what you think of the implementation and if it can be improved.
- f

--
Mike KB2ML
 

Ashar, no not cw_poll(), it is modem_poll() that is not getting called often enough. In sbitx_gtk.c this call is at line #4257 inside of ui_tick(). modem_poll() in turn decides what to do for each of the modes, but in the case of CW modem_poll only gets called ~once per 20 milliseconds, so no matter how fresh the key_poll data is it doesn't get looked at enough.
--
Mike KB2ML
 

Calling anywhere from 5 to 10 times more frequently would probably result in significant improvement. In the sBitx software, he increased it to 20 times more frequently and it was amazing.

On Apr 3, 2025, at 10:40, Mike Johnshoy via groups.io <mike.johnshoy@...> wrote:

?Ashar, no not cw_poll(), it is modem_poll() that is not getting called often enough. In sbitx_gtk.c this call is at line #4257 inside of ui_tick(). modem_poll() in turn decides what to do for each of the modes, but in the case of CW modem_poll only gets called ~once per 20 milliseconds, so no matter how fresh the key_poll data is it doesn't get looked at enough.
--
Mike KB2ML
 

I am not making myself clear. The cw_poll nor modem_poll has any use of reading the keyer.
I hope it is clear. None of the polling routines are used expect to start the transmission.
The keyer is sensed by the isr routine that updates the global variables with the current state of the paddles.
It is the key_poll that reads and returns the state of the paddle 96,000 times a second.
I repeat, nothing to do with either the ui_tick nor modem_poll nor cw_poll.
It would be best if everyone read the detailed email I posted with reference to the exact line numbers of the code. We can then discuss the code.
- f


On Thu, Apr 3, 2025, 9:28 PM Gordon Gibby KX4Z via <docvacuumtubes=[email protected]> wrote:
Calling anywhere from 5 to 10 times more frequently would probably result in significant improvement.? ? In the sBitx software, he increased it to 20 times more frequently and it was amazing.?
> On Apr 3, 2025, at 10:40, Mike Johnshoy via <mike.johnshoy=[email protected]> wrote:
>
> ?Ashar, no not cw_poll(), it is modem_poll() that is not getting called often enough.? In sbitx_gtk.c this call is at line #4257 inside of ui_tick().? modem_poll() in turn decides what to do for each of the modes, but in the case of CW modem_poll only gets called ~once per 20 milliseconds, so no matter how fresh the key_poll data is it doesn't get looked at enough.?
> --
> Mike KB2ML
>
>
>
>
>





 

Farhan,
?
The issue is most likely caused by poling the state of the key 96000 times a second and only acting upon it in modem poll 10 times per second. The solution in the 64-bit branch was to adjust modem_poll to check multiple times in each call.? The transition states are being made but not acted upon.
?
From modem_pol()
?
/*
This file implements modems for :
Fldigi: We use fldigi as a proxy for all the modems that it implements
?
?
General:
?
There are three functions called to implement almost all the digital modes
1. There is the modem_init() that is used to initialize all the different modems.
2. The modem_poll() is called about 10 times a second to check if any transmit/receiver
changeover is needed, etc.
3. On receive, each time a block of samples is received, modem_rx() is called and?
it despatches the block of samples to the currently selected modem.?
The demodulators call write_console() to call the routines to display the decoded text.
4. During transmit, modem_next_sample() is repeatedly called by the sdr to accumulate
samples. In turn the sample generation routines call get_tx_data_byte() to read the next
text/ascii byte to encode.
?
*/
?
I need to look at the details more to verify that the comment is accurate.
?
73
Evan
AC9TU
 

开云体育

?Line 4527: ?modem poll is only being called every 20th tick

Modem_poll , then calls cw_poll -but this cannot happen any faster than every 20th tick with the current code

It is actually CW_POLL that really causes transmit to occur. But this cannot start any faster than every 20th tick because of the way the routines ?are being called.

It is easy enough to prove us wrong. Simply change the calls to modem pole to occur every fourth tick (instead of every 20th tick ) and if it doesn’t get a lot better than we’re wrong.

Wishing you the best!

Gordon




On Apr 3, 2025, at 14:10, Evan Hand via groups.io <elhandjr@...> wrote:

?
Farhan,
?
The issue is most likely caused by poling the state of the key 96000 times a second and only acting upon it in modem poll 10 times per second. The solution in the 64-bit branch was to adjust modem_poll to check multiple times in each call.? The transition states are being made but not acted upon.
?
From modem_pol()
?
/*
This file implements modems for :
Fldigi: We use fldigi as a proxy for all the modems that it implements
?
?
General:
?
There are three functions called to implement almost all the digital modes
1. There is the modem_init() that is used to initialize all the different modems.
2. The modem_poll() is called about 10 times a second to check if any transmit/receiver
changeover is needed, etc.
3. On receive, each time a block of samples is received, modem_rx() is called and?
it despatches the block of samples to the currently selected modem.?
The demodulators call write_console() to call the routines to display the decoded text.
4. During transmit, modem_next_sample() is repeatedly called by the sdr to accumulate
samples. In turn the sample generation routines call get_tx_data_byte() to read the next
text/ascii byte to encode.
?
*/
?
I need to look at the details more to verify that the comment is accurate.
?
73
Evan
AC9TU
 

I updated my Zbitx yesterday (Wednesday) to 3.051 and 1.06. Yes it fixed a couple issues but CW remained unusable. So today (Thursday) I decided to update again, thinking I might have gotten an earlier Raspberry pi copy.
Now I have bricked the radio... No boot up of the Pi ( screen is ok). With an external monitor the Pi doesn't go past the first steps of booting, freezes and ignores keyboard and mouse.
?
It stops at the following:
?????????? USER???????? PID ACCESS COMMAND
/dev/snd/controlc0: Root
 

?
The link is an article on the history of electronic keyers.? It is quite lengthy but if you read it you will learn a lot.? It seems that with each major product introduction a new subtle or not so subtle difference in timing was also introduced.
?
From the article, the major difference between mode A and B is that mode B polls the opposite paddle for a pressed state during the sending of the element and the following element space.? Whereas mode A polls the opposite paddle for a changed of state from not pressed to pressed.? This difference is what prevents mode A from not sending an extra un-keyed element that turns letter K's into C's.
?
The current Zbitx code for mode A polls for a pressed state of the opposite paddle same as mode B during the carrier on? period and does not poll at all during the element carrier off period.?? It would be interesting if some of the users who say it works or say it doesn't work would report what mode they use.? I can't see that a Mode A user would have a good time at all with it working mostly as mode B.
?
The mode B code still has the bug I pointed out twice that will change a DIT paddle contact to sending an unwanted DAH if the paddle contract is made during the carrier off period.
?
? ? ? ? if (cw_mode == CW_IAMBICB){
? ? ? ? ? ? if (cw_next_symbol == CW_IDLE && cw_last_symbol == CW_DOT && (symbol_now & CW_DASH)){
? ? ? ? ? ? ? ? cw_next_symbol = CW_DASH;
? ? ? ? ? ? }
? ? ? ? ? ? if (cw_next_symbol == CW_IDLE && cw_last_symbol == CW_DASH && (symbol_now & CW_DOT)){
? ? ? ? ? ? ? ? cw_next_symbol = CW_DASH;
? ? ? ? ? ? }
? ? ? ? }
?
 

On Thu, Apr 3, 2025 at 09:14 PM, Ron Carr wrote:
It would be interesting if some of the users who say it works or say it doesn't work would report what mode they use.?
It doesn't work on either mode. Straight key mode also omits dots and there is a slight (but very significant) delay between key closure and sidetone/RF generation.
?
73,
?
John AE5X
?

1 - 20 of 31