Great investigation and work, Mike, I may have some time next week to take a look at it.
This really needs to get solved.
I had an external keyer that I thought was defective because it just couldn’t send good code through the sbitx but it has been come clear that It is probably the sBitx problem.
toggle quoted message
Show quoted text
On Oct 17, 2024, at 19:21, Mike Johnshoy via groups.io <mike.johnshoy@...> wrote:
?I have done some experiments to look into improving sBitx keying. I am running the 64 bit code, v4.02 - the folks maintaining that code base encouraged me to try some things.
The first dit or dah can't get out until the software get's through the tr_switch_de code. I inserted some code at the top of tr_switch_de like this:
void tr_switch_de(int tx_on) {
struct timespec start, end; // FOR TIMING ANALYSIS ONLY
if (tx_on) { // switch to transmit
clock_gettime(CLOCK_REALTIME, &start); // FOR TIMING ANALYSIS ONLY
and then just at the end of code that makes the switch I have this:
// FOR TIMING ANALYSIS ONLY
// Get end time and print it
clock_gettime(CLOCK_REALTIME, &end);
double elapsed = 1000*((end.tv_sec - start.tv_sec) + (end.tv_nsec - start.tv_nsec) / 1e9);
printf("tr_switch_de to transmit: %f milliseconds\n", elapsed);
On my sBitx it takes (on average) 31.6 milliseconds to do the switch to transmit. That's a good chunk of the time "budget" if we think a dit at 30 wpm is 40 milliseconds.
So - looking at the code there are lot's of delay() calls. The DE has electronic TR switching. Have some of these delays been made obsolete by hardware changes to the PA? I just started commenting out the delays until almost all of them are out. RESULTS: The 31.6 milliseconds goes down to 7.3 milliseconds. Seems significant. Similar changes could be made in tr_switch_v2 (I would like to hear some ideas on what the minimum set of differences between de and v2 code really need to be - I could see running them both on the same tr_switch code. I can't test the v2 code).
I have worked CW and FT8 with the trimmed down code, and I'm still on my original finals. Can the RF amplifier folks here talk about the risks involved in streamlining the code?
--
Mike KB2ML
