开云体育

Hi all,

?

I worked on the CW improvements for the the latest 64-bit code. The real underlining issue is? how GPIO is polling the key input.? However, I did find a major issue in the Iambic B code that has been addressed in the in this code release. I find most people are not Iambic B users, or only uses it as back-and-forth paddle keying and not squeeze keying. Initially before addressing this bug, I could not send at all with the sBitx and would constantly mess up at the ending of the character sequence.

The polling issue is still there using the internal keyer in the 64-bit dev code. The current polling method requires the CW_DELAY? to be delay to be extended to avoid the initial poll. If the paddles are not held for a split second longer, you can still miss a initial character sequence. I've train my mind to let go of the dot/dash after I start hearing the character being sent. This is annoying at higher speeds, but my mind is slowing compensating for this.? I can spend reliably at 30 wpm.?

?

In this release, nothing was changed in the straight key timing. I've looked at improving the straight key mode, and may have improved it slightly, but still not happy, especially with an external keyer at high speeds. This is not included in this release as it's more for experimenting.? Again, the GPIO polling for the input is the issue.? It would require major rework and setting up interrupts to handle the cw key input.?

I also cleaned up the spacing for the keyboard and macros.? The spacing was way too long.? The new code sounds much better.?

IMO, internal keyer now usable, but not perfect.? Another thing to note, the Iambic mode, which I assume should be A, is not correct.? It's still remembering the latest dot or dash, like Iambic B.? I haven't had time to look at that as I can't send using Iambic A.? The Iambic B mode seems to work best for the "non" squeeze CW operators.

?

(Above was copied and edited from another post)

I hope this information is helpful.

?

73,? Chris w0anm

?

?