Hi Steve,? I worked on the CW improvements for the the latest 64-bit dev code. Like you indicated, the issues 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 upcoming 64-bit 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 30wpm.?
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 JJ's release as it's more for experimenting.? Again, the 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.? I am curious to see what you think.
IMO, internal keyer now useable, 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.
73,? Chris w0anm
