On Thu, Jan 2, 2025 at 12:07 AM, Gordon Gibby KX4Z wrote:
1.? No I have NOT been following anything at all about the 64-bit version
because I have too many other responsibilities etc.? ?This Christmas break
was the first chance I had to take a look at the CW responsiveness
improvements.
2.? I have previously provided some code to avoid unnecessary clattering of
relays in the DE version (but since I don't do GITHUB, that wheel gets
reinvented over and over and hopefully finally implemented in the github
versions.
Looking at the LPF relay noise was was got me into looking at sbitx source! You posted the solution, and I manually edited it into my machine over and over again. It is still an 'issue' on the 32 bit baseline, though the recommended changes have been part of the 64 bit baseline for some time.
3.? Here is where I found what MIGHT be the sbitx.c in the 64-bit version:
I note that it is still using all the same (20 msec, 10 msec) delays as the
original 32-bit code, in the transition from receive to transmit.
You did indeed find the latest version of sbitx.c in the main branch of th 64 bit repository. That is the last version released. You can probably see that it does include the fixes you found a long time ago to correct the relay chatter. There are other branches from main that contain fixes like the CW timing changes you've just looked at, and my simplified (?) tr_switch(). At some point those might get pulled into 'main' and be part of next reelease - I can't say.
4.? You had indicated you have basically removed ALL the delays, did I
understand that correctly???? ? The code doesn't give engineering
explanations of why the delays were instituted so I'm concerned about all of
this.? ?I think our goal might be to reduce the delays (which you measured
at about 30 msec I believe) to 12-15 mSec so that a "dot" at 25 wpm isn't
shortened more than about 25%
Well. Concern is good! But, the 32 bit baseline today still has code for tr_switch_de and tr_switch_v2. But the tr_switch_de may be dead code, unreachable (try inserting a print statement in tr_switch_de and tr_switch_v2 on your DE machine, and see which code gets run). Now that's not a big deal because people like you made the fix on the local baseline. And it gave me some confidence to think, hey, most sbitx users are just running the tr_switch_v2() so it might be very possible to just have one tr_switch and drop the DE code! So I do that.
At one point Farhan sent a short note (somewhere here) explaining that that the electronic T/R switch controlled power to the PA, and an RC element provided timing, so I got a liittle relief (on my own concern!) that hardware was going to look out for me a little.
De-energizing all the LPF relays, re-configuring them for band of operation, just seems unnecessary at the level of break in keying. I think the original plan was probably just do it when you do it at band change, but someone liked the idea (I know, that's engineering judgement) of opening the LPF switches to try to reduce ringing?
Risk. What can I say - it works for me on my DE machine. I can claim a small benefit. A handful of testers have run my simplified tr_switch while testing the CW timing fixes and no problems reported.
Take a look at the code and let me know what you think! It's been a while since I walked through it ...
--
Mike KB2ML
