You should be able to return them for a full refund. When you reorder, make sure the ad says that the book ad says it was publish on April 16, 2025. When they ask for the reason for the return, pick the "wrong item sent' option.
Jack, W8TEE
On Friday, April 25, 2025 at 10:27:28 PM EDT, John Zhong via groups.io <john138@...> wrote:
I bought two paper copies of the "Revised Edition" books from , is it possible to get an updated copy for free?
-- 74 John VA6kHz
On Thu, Apr 17, 2025 at 1:38?AM Greg KF5N via <greg.electricity= [email protected]> wrote: Amazon needs to be hammered on again.? They are not getting it done correctly.
?
--
73 Greg KF5N
--
Jack, W8TEE
|
I bought two paper copies of the "Revised Edition" books from , is it possible to get an updated copy for free?
-- 74 John VA6kHz
On Thu, Apr 17, 2025 at 1:38?AM Greg KF5N via <greg.electricity= [email protected]> wrote: Amazon needs to be hammered on again.? They are not getting it done correctly.
?
--
73 Greg KF5N
|
On Sat, Sep 9, 2023 at 10:01 AM, Albert Peter wrote:
Note that Bill (K9Z) rates the amp at 20W PEP, but it is current limited to about 16W (RMS).
What limits the current in this amplifier? Something on Bill's amp board or within the rest of the T41?
?
-Nate?
N8BTR?
|
after reloading (TNX for bug fix Oliver) and recalibrating first Q is in log. 7 w SSB 20M?
unsolicited nice audio report (cheap home made mic)?
onward and upward!?
TNX to all the contributors
Tim W4YN
BTW if anyone needs 3 wire jumper from main to audio hat I have a few already made up from RC flying days.
Just PM me your address I can send in letter envelope.
?
?
|
Re: Restructuring the T41 code
No question that configuring the audio state is an important function.? I've used this method before, usually for things I didn't want to convert into a library or when linker support was deficient or non-existent.
?
The code base has gotten so big that what you've done does make the code more accessible and readable and that is helpful.? But I don't see the need to treat this differently than other modules, other than it's more work to get all of the global variables handled correctly.? Your method has the advantage of not having to bother with that.? I have AudioConfig.h referenced in 8 modules.
|
Re: Restructuring the T41 code
I'm using a different meaning of the word "special".? The code in the AudioSignal.h file is the software heart and lungs of the radio.
?
--
73 Greg KF5N
|
Verified Bug is gone TNX
Tim W4YN
|
Re: Restructuring the T41 code
On Fri, Apr 25, 2025 at 07:26 AM, Greg KF5N wrote:
The one exceptional header file is the T41EEE's AudioSignal.h file.? This is a super-important and special header file which contains the Teensy Audio and Open Audio related code.? This header is included into the T41EEE.ino file.
There isn't anything particularly special about this code.? It can be placed in its own cpp file along with a header file for the global externs and function prototypes.? That's what I've done.
|
Re: Restructuring the T41 code
Yep...we're on the same page.
Jack, W8TEE
On Friday, April 25, 2025 at 10:26:51 AM EDT, Greg KF5N via groups.io <greg.electricity@...> wrote:
Yes, Jack, you've got it!? There is some nuance when someone uses the term "global", and what I was trying to flush out was the "super globals" versus "local file globals".? When I see "extern" that is a pretty good hint.
So what I've been doing, and I think Oliver is doing something similar, is isolating the "local file globals" first.? So that's what I do, is to put them in the existing .cpp file, in their home turf.
At some point it makes sense to re-factor into a class.? That is when a unique new header file is added.? The "local file globals" are scooped up and dropped into that new header file.
Externs are removed from the SDT.h file, and the same goes for function declarations which can be "delisted" from the SDT.h.
?
The one exceptional header file is the T41EEE's AudioSignal.h file.? This is a super-important and special header file which contains the Teensy Audio and Open Audio related code.? This header is inserted into the T41EEE.ino file.
?
--
73 Greg KF5N
-- Jack, W8TEE
|
Re: Restructuring the T41 code
Yes, Jack, you've got it!? There is some nuance when someone uses the term "global", and what I was trying to flush out was the "super globals" versus "local file globals".? When I see "extern" that is a pretty good hint.
So what I've been doing, and I think Oliver is doing something similar, is isolating the "local file globals" first.? So that's what I do, is to put them in the existing .cpp file, in their home turf.
At some point it makes sense to re-factor into a class.? That is when a unique new header file is added.? The "local file globals" are scooped up and dropped into that new header file.
Externs are removed from the SDT.h file, and the same goes for function declarations which can be "delisted" from the SDT.h.
?
The one exceptional header file is the T41EEE's AudioSignal.h file.? This is a super-important and special header file which contains the Teensy Audio and Open Audio related code.? This header is included into the T41EEE.ino file.
?
--
73 Greg KF5N
|
Re: Restructuring the T41 code
Mornin' Greg:
Yes, Al and I found a lot of "dead" variables when we started out. We could tell by their names that some of them were clearly used as temporary debug variables that just didn't get cleared out. We also found a bunch of "dead" functions that were never called anywhere. We tried to remove all of those, but I know some were not removed. At one time, I thought some of these might be resued later on, but ended up not being used. I just never when back to clean them out.
"De-globalizing" the code is a little harder when the variable is used in multiple unrelated functions. In those cases, the variable could be defined in the ino file, but passed to the other functions (as a pointer?) as needed. That does de-clutter things, but is a pain to do. However, if you can isolate the variable to only the file that uses it, the problem is more manageable. Example: If a variable is only used in the display.cpp source file, it can be localized to that file. It sounds like that's what you've done: create a header file for each "functional" cpp file. The reason I didn't do this is because, as you pointed out, it means each cpp file has its own header file, which has the effect of doubling the number of file which is its own form of clutter, albeit it is organized clutter.?
For such global variables that are only used in one cpp file, instead of placing them their own header file (e.g., display.h which ties to display.cpp), you could place those "local globals" in the cpp file, but use the static storage specifier for them. This keyword is more of an attention-gettter to the programmer than a difference in the variable's placement in memory. I say that because, if you define the variable in the display.cpp file outside of a function without the static specifier, it has global scope, but only for the file in which it is defined. If that variable is not called in any other cpp file, you won't get the "undefined" error message. The only thing the static keyword does is allow you to use that same variable name in multiple cpp files and still not generate a "multiply defined" error message. (I don't know why you'd want to do that, but you could!) The only reason I would add the static keyword in this case is to serve as a sentinel to tell other programmers that this is a "local global".
Jack, W8TEE
On Thursday, April 24, 2025 at 11:26:11 PM EDT, Greg KF5N via groups.io <greg.electricity@...> wrote:
Hi Jack-
?
It's a metric of the reduction of global variables.? Note that the .ino file was also greatly de-cluttered in concert with SDT.h.
There were also a bunch of variables which only existed in the SDT.h file.? I suspect they were remnants of earlier functions, tests, and experiments which were never cleaned up.
?
It was a large clean-up job, but the result was worth it.? The code is much easier to work with and debug.? Not really different in effect than that first step you Al took to break the
SDR Convolution code from a single to multiple files.
?
--
73 Greg KF5N
-- Jack, W8TEE
|
Re: Restructuring the T41 code
Great work Terrance!? That is what I aspire to.? It's going to take a few more iterations to get T41EEE that good.
I wholeheartedly agree it makes it easier to find things specific to a particular task.? Debugging is much easier!
?
--
73 Greg KF5N
|
Found the bug -- it was a simple one-line fix in the end. Pushed to GitHub:
On Thursday, April 24th, 2025 at 10:34 PM, Tim via groups.io <w4yn@...> wrote:
SRY?
My bad memory
Spectrum Options
?
Did we have option for averaging in older FW?
Tim?
|
Re: Restructuring the T41 code
Oliver - Thanks for update.? Your diagrams are very helpful.
?
On Thu, Apr 24, 2025 at 07:10 PM, Greg KF5N wrote:
The rest have to be handled one at a time, manually.? It's tedious.
I took this approach.? Yes, it's tedious.? I've gone pretty far with my approach.? My SDT.h is only 209 lines.? This doesn't reflect a massive reduction in global variables but more of a redistribution into the modules primarily related to the variable.? Often these could be made local to specific functions or global to just that module.? When needed outside that module I use module specific header file with the required variable declared as external.? These header files also contain that module's function prototype declarations needed by other modules.? This basically doubles the number of files but makes it easier to find stuff.
|
Re: Restructuring the T41 code
Hi Jack-
?
It's a metric of the reduction of global variables.? Note that the .ino file was also greatly de-cluttered in concert with SDT.h.
There were also a bunch of variables which only existed in the SDT.h file.? I suspect they were remnants of earlier functions, tests, and experiments which were never cleaned up.
?
It was a large clean-up job, but the result was worth it.? The code is much easier to work with and debug.? Not really different in effect than that first step you Al took to break the
SDR Convolution code from a single to multiple files.
?
--
73 Greg KF5N
|
Re: Restructuring the T41 code
Greg:
Curious about the line:
To get an idea of how much progress I have made, the number of lines in T41EEE.9/SDT.h = 1057.? SDTVer066-9/SDT.h = 2640.
What was the impact if you add up the class header file lines. How much net change was there?
Jack, W8TEE
On Thursday, April 24, 2025 at 10:10:13 PM EDT, Greg KF5N via groups.io <greg.electricity@...> wrote:
Hi Oliver-
?
One thing I recommend is writing a script to "de-globalize" the code.? I did this and removed hundreds of globals.? There were even globalized local variables!
What the script does is take a variable from SDT.h, and then does a search on all of the other files (I dont' think the .ino file was included).? Any variable which
shows up only once is a candidate for de-globalization.? The first step is to pull that extern variable out of SDT.h and make it a file scope variable in the file where it belongs.
Once that process is complete, then copy the file scope variables into a header file and make a class.? Not everything is a class yet, but the file scope variables are mostly
sorted to their home files.
?
The script will get a bunch of them.? But I didn't refine it enough to get all of them.? The rest have to be handled one at a time, manually.? It's tedious.
To get an idea of how much progress I have made, the number of lines in T41EEE.9/SDT.h = 1057.? SDTVer066-9/SDT.h = 2640.
There is still a huge amount of work to be done.? But a few variables will have to remain global.
?
The other thing I have done is to "modalize" the code.? I've used scoped enums to great effect.? This was a huge change in T41EEE.9.? I wasn't sure how it would work out,
but it is working extremely well and it's a clear way forward to more robust code.? There are still some things not completely modalized, but I think the next version will get it there.
A lot of things have been working in a state machine pattern for the last several versions.? It's less than perfect, but the modalization was a big step forward in improving that.
?
StateSmith looks pretty cool.? I bought a big artist's pad at Walmart and draw everything out with a pen.
?
--
73 Greg KF5N
-- Jack, W8TEE
|
SRY?
My bad memory
Spectrum Options
?
Did we have option for averaging in older FW?
Tim?
|
Re: Restructuring the T41 code
Hi Oliver-
?
One thing I recommend is writing a script to "de-globalize" the code.? I did this and removed hundreds of globals.? There were even globalized local variables!
What the script does is take a variable from SDT.h, and then does a search on all of the other files (I dont' think the .ino file was included).? Any variable which
shows up only once is a candidate for de-globalization.? The first step is to pull that extern variable out of SDT.h and make it a file scope variable in the file where it belongs.
Once that process is complete, then copy the file scope variables into a header file and make a class.? Not everything is a class yet, but the file scope variables are mostly
sorted to their home files.
?
The script will get a bunch of them.? But I didn't refine it enough to get all of them.? The rest have to be handled one at a time, manually.? It's tedious.
To get an idea of how much progress I have made, the number of lines in T41EEE.9/SDT.h = 1057.? SDTVer066-9/SDT.h = 2640.
There is still a huge amount of work to be done.? But a few variables will have to remain global.
?
The other thing I have done is to "modalize" the code.? I've used scoped enums to great effect.? This was a huge change in T41EEE.9.? I wasn't sure how it would work out,
but it is working extremely well and it's a clear way forward to more robust code.? There are still some things not completely modalized, but I think the next version will get it there.
A lot of things have been working in a state machine pattern for the last several versions.? It's less than perfect, but the modalization was a big step forward in improving that.
?
StateSmith looks pretty cool.? I bought a big artist's pad at Walmart and draw everything out with a pen.
?
--
73 Greg KF5N
|
Re: Restructuring the T41 code
Thanks Oliver. This is a huge effort! And, very exciting! dave,n3ds
toggle quoted message
Show quoted text
On Apr 24, 2025, at 8:52?PM, Oliver KI3P via groups.io <oliver@...> wrote:
? I wanted to share a little information on how I'm going to go about restructuring the T41 code.?
?
The most difficult bugs to track down in the current code have been those caused by the radio being in an unknown state -- some line that controlled a switch on the RF board or a parameter in the DSP chain was inserted or omitted somewhere in the code. Because all variables are global, this could be literally anywhere in the nearly 30,000 lines of code. Finding the source of the bug without the ability to use a debugger is a challenge. It also possible to insert an entirely valid line of code that places the radio in an invalid or undesirable state -- for instance, imagine turning the CAL switch on when trying to transmit SSB.
?
I'm going to solve this problem by using state machines. In the new code structure, the state of the radio hardware will be controlled entirely by a radio mode state machine. This state machine is the only place in the code where the hardware state is changed. Using a state machine to control the hardware ensures that all hardware is always in a known configuration state. I'm working my way through the hardware boards, defining the valid configuration states for that hardware. I will then write functions that put the boards into each valid configuration state. The only way the rest of the code can affect the radio hardware is by calling one of those functions, and the only part of the code that will call those functions is the radio mode state machine. Here's an example of some of the states for the RF board (does not include the calibration states).
?
?
?
State machines can be written entirely in C code, but it¡¯s easier to understand how the state machine operates through a visual diagram. I've found an open-source solution, , that allows you to draw the state machines in a graphical environment (I'm using draw.io) and then automatically generate the C code that implements the state machine. Here's the state machine I've created for the radio hardware.
?
?
?
I'm working on a separate state machine to control the state of the graphical display.
?
Here's how I imagine them all working together:
?
?
The software runs in a loop as shown in the diagram above. It performs three major functions:
- Handle interrupt events: if an interrupt was registered by, for example, a button being pressed, then pass the appropriate event on to the state machines to change the hardware and UI states.
- Perform the appropriate signal processing, based on the current radio mode.
- Update the display, based on the current UI state.
?
Then go back to step 1 and repeat. This loop should take at most 10ms to execute in order to avoid buffer overflows in the IQ buffers.
?
I'm building this up from a blank canvas. I've spent most of my effort over the last few weeks learning how to use StateSmith and how to build an automated test environment using . I've now started to write code, starting with the signal processing, and writing unit tests for the code as I go. I've found the unit tests to be very helpful. If I decide to change a function's prototype or modify what the function does, I'll immediately know if that change breaks something somewhere else in the code. It should make the process of getting the code running on the Teensy much faster.
?
I'm going to clean up the code as I move it over, piece by piece, to this new structure -- remove dead code, apply consistent style formatting, minimize the use of global variables, and write tests for every function so we know what it's supposed to do and when it stops doing this.
?
?
?
?
?
|
Re: LPF Control Board addressing help
Oliver, success, I went back and re-flowed all of the connections
on U15 on the LPF control board and checked continuity on all the
pins again. Everything was ok. Then I remembered that there was a
7991 at U20 which was also connected to the I2C lines. I checked
the pins and found a short and an open and I couldn't tell if the
IC was on correctly. It's so small and the markings are impossible
to read. So I removed it, cleaned up the pads and the IC leads.
Was able to verify an alignment dot and replaced it. Continuity
checks went ok, and now it's working. It was probably on
backwards. Thanks for the help. Now I can get back to winding
Toroids.
On 4/24/2025 7:55 PM, Oliver KI3P via
groups.io wrote:
The
daisy chain test sounds like it might be a clue. Does your radio
find the BPF if that board is connected to the main board? It
uses the same I2C bus, so this will confirm that the problem is
not on the main board side. If adding the LPF board to the daisy
then prevents the main board from discovering both the BPF and
the LPF boards, then this implies that something on the LPF
board is messing with the I2C lines, likely by pulling them high
or low.
If
the test above indicates that the I2C lines are being messed
with on the LPF board then check the other parts of the board
where the I2C lines run for shorts.
- Are the pullup resistors
R14 and R12 present and not shorted?
- Are there any shorts around
pins 1 and 2 of U20?
On Thursday, April 24th, 2025 at
12:51 PM, Robert Luken W3RDL via groups.io
<now.w3rdl@...> wrote:
No joy. I checked continuity from U15 to the band header
pins, OK. I checked all IC pins for solder bridges and opens
and all resistors and capacitors. Powered the board
externally and checked all voltages on ICs. A0, A1, and A2
on U15 show 5v, 0v, and 5v. Checked the cable(pin for pin)
used for the BPF board. When connected to the LPF board, BIT
reports "23017 not found at x25". Since I2SCAN showed a
device at x28, I recompiled with LPF at x28, BIT reports
"LPF 23017 not found at x28".
Made a daisy chain cable for Main to BPF to LPF band. BIT
reports "BPF 23017 not found at x24 and LPF 23017 not found
at x25".
The I2C lines show continuity between the Band connector
header pins and U15. Could U15 be bad?I'll reheat all of the
pins again before I swap it out, assuming I have a spare.
On 4/23/2025 5:30 PM, Robert
Luken W3RDL via groups.io wrote:
Oliver, thanks for the reply. I thought I had traced out
all of the pins on the 23017, but I may have missed
something. I'll check things again. About the AD7991,
"BIT" has been showing an Ad7991 at x29 without the LPF
board installed. I've always wondered about that.
On 4/23/2025 4:41 PM, Oliver
KI3P via groups.io wrote:
Soldering
JP2 while leaving JP1 and JP3 open makes the address
bits 101 (they are high by default and soldering the
junction pulls them to ground). This should correspond
to the address 0x25, as you say.
The
AD7991 chip that is also on the LPF control board has an
address of 0x28 or 0x29, so I think that's what you're
detecting with the I2C scan. This confirms that the
cable isn't broken -- something must be wrong regarding
the MCP23017 chip on your board. Look for solder
bridges, missing parts, misalignments, etc.
On Wednesday, April 23rd,
2025 at 2:41 PM, Robert Luken W3RDL via groups.io <now.w3rdl@...>
wrote:
Finished building the LPF Control board, no
detectable shorts or opens and no smoke escaped. The
board is configured for I2C addressing and the
address jumpers are set for address "25"(Open,
Short, Open). However address LPF not found at 25,
running SDT Ver66-9. I ran I2C Scan and an address
of "28" is showing up on wire 2. How is that
possible?
--
73 
Bob W3RDL
--
73
Bob W3RDL
--
73
Bob W3RDL
--
73
Bob W3RDL
|
jjpurdum