On Dec 31, 2024, at 14:35, Mike Johnshoy via groups.io <mike.johnshoy@...> wrote:

?Gordon,

I have thought about this a bit. There are some good ideas and some smoke out there.

Easiest fix would be to get polling the straight key to work better. Here is how I think that goes. In sbitx_gtk.c there is a function ui_tick(). This function keeps up with user interface changes ... is the volume or frequency knob turning, and what is the state of all the ui buttons that might be pressed and need an update to the screen. ui_tick() increments a ticks counter every time it gets called. At about line #5739 we see this code to call modem_poll() once every 20 ticks.

modem_poll checks on FT8, CW, and any other built in modes. First temptations is to change 20 to a smaller number - good for CW, but then all the modes get more cpu time and attention than they need.

modem_poll() in turn, calls cw_poll()

cw_poll() calls key_poll() which uses digitalRead() to read the right GPIO pin for the key, and we finally see if the key is down or not! [FOOTNOTE: When we see the key is down, it has actually been down for some time, i.e. it either just happened or it has been down the whole sample interval - on average it will be about average - but we are almost guaranteed to miss a bit of the leading edge. Likewise on key up, the software most likely misses the exact moment of key up and the key will seem to 'stick' until the sample interval happens. This makes it look like dot's and dashes are stretched a little, and shifted to the right.]

So what do we do? We saw that modem_poll() gets called every 20 ticks. modem_poll checks on FT8, CW, and any other built in modes. First temptations is to change 20 to a smaller number - good for CW, but then all the modes get more cpu time and attention than they need. So I wanted to add some extra calls when we are in CW mode, so I do this:

// every 20 ticks call modem_poll to see if any modes need work done
if (ticks % 20 == 0)
modem_poll(mode_id(get_field("r1:mode")->value));
else {
// calling modem_poll every 20 ticks isn't enough to keep up with a fast
// straight key, so now we go on _every_ tick in MODE_CW or MODE_CWR
if ((mode_id(get_field("r1:mode")->value)) == MODE_CW ||
(mode_id(get_field("r1:mode")->value)) == MODE_CWR)
modem_poll(mode_id(get_field("r1:mode")->value));
}

This simple change seemingly gives a 20 x increase in polling rate for cw only. Check out the timing table below. at 25 wpm the original timing interval only gave you 2 samples per dit. Sampling theory (which I can only fail to get correct here) seems to tell us, yes, we can just gaurantee that we will see the 'dit' happen, but we won't have the higher freq 'oversampling' needed to have sharply defined edges.

JJ and the 64-bit team have tested all the changes I've given them and and provided great data and feedback (you mentioned using an external keyer to drive the straight key input which I think is a great way to test this - I don't have one). It still doesn't compare to the other rigs the testers have.

I look forward to some feedback and hearing how I might have this all wrong!

re: other approaches ... Still grasping a bit for new ideas. Maybe a hybrid interrupt driven/polling interface. I feel a little constrained by the existing interface to the straight key, but imagine if you could virtually PTT and whistle CW into the microphone (and not use polling to detect the PTT!) ...

I actually started working CW performance by working from the back end - i.e. looking at the timing in the T/R switch. I think there is some un-needed cruft in the old tr_switch that seemed like a good idea in the days of trying not to ruin PA devices (lots of delay() calls, configuring/reconfiguring LPFs, ...) that is no longer needed, I came up with much tinier tr_switch() that runs on all sbitx hardware (but how could I ever guarantee that!!) But those improvements help get sbitx closer to VERY fast break-in times with some new QRP rigs.

Enjoy your ancient family!
--
Mike KB2ML (if I had more time I would have written a shorter message)





<Clipboard_12-31-2024_01.jpg>