OK!!? ?I have preliminary results to report.
?
First, the day started off badly.? ?While working to get going for morning CW practice listening to high speed ops on 80 meters, I got the amplifier going and didn't retune the little auto-tuner between the sBitx & the SB-200 amp.? ?The Sbitx was only at 68% drive (enough to drive the SB-200 to nearly 200 watts, about as much as I dare put into my homebrew 49:1 EFHW balun.)? ?I started to send just a very short identification --- and BAM! the sBitx went DARK.? ? A current meter that hadn't been working very well suddenly showed LOTS of current from the DC power supply (ghosts?) -- and the little DC power supply went into current limiting.? ?Quick, turn off sBitx.? ? Turn back on -- immediate replay of Bad Things -- power goes up, power goes DOWN, something is shorting out the power supply......
?
After getting over the emotions.....somehow I had to have shorted out one of the IRFZ24N's.? ?I have worked with? THREE sBitx's and done all kind of fool things, and NEVER blew out a power amp MOSFET!? ?So this was very, very surprising, when I had used nearly the same setup just a few days before.? ?
?
Later in the day, more composed, I managed to extricate the sBitx from my plywood go-box and the zillion plugs that are normally connected...got cracked open, looked over all the wiring and circuitry that I spent MONTHS diagnosing a shorted diode in the diode-switching systems, a bad MOSFET 7002? and such (MONTHS of work)....got the heatsink back off; my AlN insulators looked fine, but I failed to carefully check the tension on the bar -- but at least the first screw was indeed tight.? ?With some trial and error I found the IRFZ24N that was indeed shorted, and the other one looked fine, so for the moment I left it in there, got the entire thing back together and now it receives again.? ?Drive level set to 1%, can key CW with no output and no damage, so was able then to work with your code.
?
?
Managed after re-learning a bunch of stuff, to insert your very elegant code, recompiles and ran it -- runs.
?
Testing:? ?(this is 32-bit code, my "flatresponse version" from late in 2024
?
1)? Bencher paddle into Sbitx in "Iambic" mode -- seems to key perfectly, very responsive? ? ?The other day I had the feeling it just wasn't timing right and I made lots of errors in sending CW....but this time it seems very responsive at 21wpm internal electronic keying, and I'm not making errors for a change.
?
2)? Bencher paddle into "lil Bugger" ancient transistor/integrated circuit keyer (no longer on the market) -- with sBitx set to "straight key mode" and the "lil Bugger" doing all the electronic wizardry.? ?This keyer COULD NOT PREVIOUSLY SEND GOOD CODE WITH THE SBITX -- IT JUST ACTED LIKE IT HAD BAD LENGTH CODE ELEMENTS -- I THOUGHT IT WAS NOT PROPERLY SHORTING OUT THE SBITX INPUTS OR SOMETHING AND HAD PLANS TO REBUILD THE OUTPUT CIRCUITRY --? ?Now, it is sending GREAT CODE!? ?The sBitx is now responding quite well to the Lil Bugger's code.? ?This suggests your fix is a huge improvement to the Straight Key input.
?
3)? Switched to a homebrew Arduino emulator of a WINKEYER (K3NG code) that our group has laid out boards and built.? ?Bencher paddle into Arduino emulator, output into "straight key" mode of sBitx.? ? ?This is a confirmatory test of the striaght key input -- I sent several sentences and the response of the sBitx was snappy and correct!? ??
?
?
I have not tested the remaining impacts of the change; will have to watch it for a while.? ?Have not yet made the changes you suggest in the T/R code.? This is ONLY the addition to sbitx_gtk.c? you suggested.
?
// 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. [added code is BOLDED]
?
Great going, Mike!!! This little part right here so far looks like a big win. It can't fix the non-real-time behavior of Linux....but it is fixing things that were much more of bother to a 20-25 wpm code operator. Based on the change, I would suspect it works past 30 wpm, making this a far far better CW rig already.
?
Next I'll get around to looking at the T/R delays and your suggestions there.
?
THANKS!!!!!
?
Gordon KX4Z
?
?
?
