1) Turn radio on, set band to 20m
2) Turn radio off
3) Turn radio on, note no audio pumping
4) Change band to 17m, note audio pumping starts
5) Change band to 15m, note audio pumping
6) Change band in sequence, note audio pumping stops on all bands
except 17m and 15m
7) Return band to 17m. Note audio pumping.
8) Switch off radio
9) Switch on radio. Note that audio pumping is not present.
10) Change band in sequence. Note audio pumping resumes on 17m and 15m
but is not present on other bands.
Roger G8JWT
Links:
------
[1] /g/SoftwareControlledHamRadio/message/33937
[2] /mt/113187923/243852
[3] /g/SoftwareControlledHamRadio/post
[4] /g/SoftwareControlledHamRadio/editsub/243852
[5]
/g/SoftwareControlledHamRadio/leave/10484476/243852/1943518115/xyzzy

On May 19, 2025, at 6:01?PM, Oliver KI3P via groups.io <oliver@...> wrote:

?

Update time! I've been working steadily on the code changes for the last month.

?

I've taken this as an opportunity to learn more about test-driven development and the concept of writing unit tests for code. This makes it take longer to write the code, but should make it easier to extend and maintain the code in the future. I'm building a test suite using the so that (almost) every part of the T41 code can be tested on a desktop computer before it touches a Teensy. This also lets me run the code with a debugger (GDB, in my case) which is a much more satisfying way to figure out why the code isn't doing what I want. This testing approach leaves me with confidence that the code is doing what I expect it to do before I load it onto the Teensy. There will undoubtedly still be bugs to find, but they should all be related to hardware integration rather than software bugs.

?

My focus for the last few weeks has been on the Receive signal processing chain. I've ported, cleaned up, refactored, and tested most of the receive DSP chain. I'm using Google Test to do things like run a comb of signals through the convolution filter to make sure that its filtering the frequencies we expect, generating plots like the one below for visual analysis (plotted using Python) as well as numerical tests that don't rely on visual inspection. Working on the receive code has been a great refresher in the principles of digital signal processing! I've had to dust of a lot of knowledge that had been gathering cobwebs in the back of my mind.

?

<inline.0.part>

?

Writing the code with a unit test framework is actually pretty enjoyable and is well worth the time investment. Every time I modify the code, I can run the full set of tests I've written against the entire code base in mere seconds and immediately know if my change has broken anything anywhere. Testing every function with its own dedicated set of tests helps to reveal unanticipated behaviors and edge cases. I can highly recommend it as an approach for a complex project like this! It lets me refactor and change parts of the code without fear that this will break something subtle somewhere else.

?

How am I changing the code? In addition to the cleanup, I'm getting rid of almost all global variables, have found many opportunities to reduce memory usage, and am separating the display code from the signal processing code as I rewrite it. I hope to be at the point where I can run the new receive code on the Teensy in a few weeks (without the display) to have a real-world verification that it's working as expected before continuing.

?

?

software is version 66.9.

Only RF board with RX component installed

No BPF or LPF board? installed

No SHUTDOWN component installed

I can receive stations via RX.

?

Turn radio on, set to band 40 No pumping Change band in sequence.

Note: Audio pumping starts on 17m and 15m, but is not present on other bands.

?

Greetings

wolfgang

On May 19, 2025, at 6:01?PM, Oliver KI3P via groups.io <oliver@...> wrote:

?

Update time! I've been working steadily on the code changes for the last month.

?

I've taken this as an opportunity to learn more about test-driven development and the concept of writing unit tests for code. This makes it take longer to write the code, but should make it easier to extend and maintain the code in the future. I'm building a test suite using the so that (almost) every part of the T41 code can be tested on a desktop computer before it touches a Teensy. This also lets me run the code with a debugger (GDB, in my case) which is a much more satisfying way to figure out why the code isn't doing what I want. This testing approach leaves me with confidence that the code is doing what I expect it to do before I load it onto the Teensy. There will undoubtedly still be bugs to find, but they should all be related to hardware integration rather than software bugs.

?

My focus for the last few weeks has been on the Receive signal processing chain. I've ported, cleaned up, refactored, and tested most of the receive DSP chain. I'm using Google Test to do things like run a comb of signals through the convolution filter to make sure that its filtering the frequencies we expect, generating plots like the one below for visual analysis (plotted using Python) as well as numerical tests that don't rely on visual inspection. Working on the receive code has been a great refresher in the principles of digital signal processing! I've had to dust of a lot of knowledge that had been gathering cobwebs in the back of my mind.

?

<inline.0.part>

?

Writing the code with a unit test framework is actually pretty enjoyable and is well worth the time investment. Every time I modify the code, I can run the full set of tests I've written against the entire code base in mere seconds and immediately know if my change has broken anything anywhere. Testing every function with its own dedicated set of tests helps to reveal unanticipated behaviors and edge cases. I can highly recommend it as an approach for a complex project like this! It lets me refactor and change parts of the code without fear that this will break something subtle somewhere else.

?

How am I changing the code? In addition to the cleanup, I'm getting rid of almost all global variables, have found many opportunities to reduce memory usage, and am separating the display code from the signal processing code as I rewrite it. I hope to be at the point where I can run the new receive code on the Teensy in a few weeks (without the display) to have a real-world verification that it's working as expected before continuing.

?

?

On May 19, 2025, at 3:12?PM, Tim O'Rourke via groups.io <w4yn@...> wrote:

?

You could ask Justin AI6YM what he paid for his boards to be populated.

Tim W4YN

Update time! I've been working steadily on the code changes for the last month.

I've taken this as an opportunity to learn more about test-driven development and the concept of writing unit tests for code. This makes it take longer to write the code, but should make it easier to extend and maintain the code in the future. I'm building a test suite using the so that (almost) every part of the T41 code can be tested on a desktop computer before it touches a Teensy. This also lets me run the code with a debugger (GDB, in my case) which is a much more satisfying way to figure out why the code isn't doing what I want. This testing approach leaves me with confidence that the code is doing what I expect it to do before I load it onto the Teensy. There will undoubtedly still be bugs to find, but they should all be related to hardware integration rather than software bugs.

My focus for the last few weeks has been on the Receive signal processing chain. I've ported, cleaned up, refactored, and tested most of the receive DSP chain. I'm using Google Test to do things like run a comb of signals through the convolution filter to make sure that its filtering the frequencies we expect, generating plots like the one below for visual analysis (plotted using Python) as well as numerical tests that don't rely on visual inspection. Working on the receive code has been a great refresher in the principles of digital signal processing! I've had to dust of a lot of knowledge that had been gathering cobwebs in the back of my mind.

Writing the code with a unit test framework is actually pretty enjoyable and is well worth the time investment. Every time I modify the code, I can run the full set of tests I've written against the entire code base in mere seconds and immediately know if my change has broken anything anywhere. Testing every function with its own dedicated set of tests helps to reveal unanticipated behaviors and edge cases. I can highly recommend it as an approach for a complex project like this! It lets me refactor and change parts of the code without fear that this will break something subtle somewhere else.

How am I changing the code? In addition to the cleanup, I'm getting rid of almost all global variables, have found many opportunities to reduce memory usage, and am separating the display code from the signal processing code as I rewrite it. I hope to be at the point where I can run the new receive code on the Teensy in a few weeks (without the display) to have a real-world verification that it's working as expected before continuing.

I've got the same issue with a completed radio. It does not affect the spectrum display or the S meter, only the audio. It's confined to 17 and 15 metres. The pumping occurs about twice per second. It does not occur if the radio starts up on 17 or 15 metres direct from switch-on but starts as soon as the band is changed to one of these two bands.

?

Roger G8JWT