On Wed, Jan 1, 2025 at 02:43 PM, Mike Johnshoy wrote:
I'd like to give you 2 cents worth on the T/R switch, but I hate to get too many topics going. I'm assuming you are looking at the changes in the 64-bit repo? It might be a good example of code that evolved over time, and several iterations of hardware, that still carries the remnants of good (and less good?) problem workarounds ... My attempt to make things better (I especially like the idea that it seems to get all sbitx hardware back on the same T/R code) should ideally be reviewed and blessed by the original developers.
--
Mike KB2ML
Hi,
?
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.?
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.? ?
?
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%
?
Please correct any misconceptions that you see in the statements (1)(2)(3)(4) above!!? ?On Thursday I will probably try something with reducing the delays, but since my transmitter is currently dead in the water....won't really be able to test for some time....
?
Gordon KX4Z
?
?
