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
|
Restructuring the T41 code
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.
?
?
?
?
?
|
The Ver066.9 code doesn't have a menu option called "Display Options" -- which one did you select?
On Thursday, April 24th, 2025 at 2:35 PM, Tim via groups.io <w4yn@...> wrote:
I reloaded and cleared mwmory
Duplicated it!
Menu
Display Options?
select cancel?
press Select
Back to partial display and rebooting
Tim?
|
Re: LPF Control Board addressing help
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
|
Invoice Incoming ? ? ? Dr. William J. Schmidt - K9HZ J62K(J68HZ) 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ VP2EHZ ? Owner - Operator Big Signal Ranch ¨C K9ZC Staunton, Illinois ? Owner ¨C Operator Villa Grand Piton ¨C J68HZ Soufriere, St. Lucia W.I. Rent it: ? Moderator: North American QRO Group at Groups.IO. Moderator: Amateur Radio Builders Group at Groups.IO. ? email:? bill@... ? ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of Robert Luken W3RDL via groups.io
Sent: Thursday, April 24, 2025 12:56 PM
To: [email protected]
Subject: Re: [SoftwareControlledHamRadio] Kits and parts.? Bill, I would like to order the following: 1 - 20W DL and 40dB Attenuator 1 - 20A Distribution Kit 1450 Lester Court Merritt Island, FL 32952 On 4/24/2025 11:37 AM, K9HZ via groups.io wrote: As of close of business today, I¡¯ll have to stop talking board and kit orders for the T41 and associated electronics.? I¡¯m preparing for Hamvention now.? We will have plenty of boards, kits, and books there.? Our booth was moved from Building #4 into Building #2 this AM¡ now in a very nice spot¡ #2607. In with many of the international groups ad the ARRL.? Very excited to be there. ? In any case, if you have orders, please get them in by close of business today.? Otherwise catch us at Hamvention¡ or wait until the week after Hamvention. ? ? Dr. William J. Schmidt - K9HZ J62K(J68HZ) 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ VP2EHZ ? Owner - Operator Big Signal Ranch ¨C K9ZC Staunton, Illinois ? Owner ¨C Operator Villa Grand Piton ¨C J68HZ Soufriere, St. Lucia W.I. Rent it: ? Moderator: North American QRO Group at Groups.IO. Moderator: Amateur Radio Builders Group at Groups.IO. ? email:? bill@... ? ?
--
73  Bob W3RDL
|
I reloaded and cleared mwmory
Duplicated it!
Menu
Display Options?
select cancel?
press Select
Back to partial display and rebooting
Tim?
|
Bill, I would like to order the following:
1 - 20W DL and 40dB Attenuator
1 - 20A Distribution Kit
1450 Lester Court
Merritt Island, FL 32952
On 4/24/2025 11:37 AM, K9HZ via
groups.io wrote:
As of
close of business today, I¡¯ll have to stop talking board and
kit orders for the T41 and associated electronics.? I¡¯m
preparing for Hamvention now.? We will have plenty of
boards, kits, and books there.? Our booth was moved from
Building #4 into Building #2 this AM¡ now in a very nice
spot¡ #2607. In with many of the international groups ad the
ARRL.? Very excited to be there.
?
In any
case, if you have orders, please get them in by close of
business today.? Otherwise catch us at Hamvention¡ or wait
until the week after Hamvention.
?
?
Dr.
William J. Schmidt - K9HZ J62K(J68HZ) 8P6HK ZF2HZ PJ4/K9HZ
VP5/K9HZ PJ2/K9HZ VP2EHZ
?
Owner -
Operator
Big
Signal Ranch ¨C K9ZC
Staunton,
Illinois
?
Owner
¨C Operator
Villa
Grand Piton ¨C J68HZ
Soufriere,
St. Lucia W.I.
Rent
it:
?
Moderator:
North American QRO Group at Groups.IO.
Moderator:
Amateur Radio Builders Group at Groups.IO.
?
email:? bill@...
?
?
--
73
Bob W3RDL
|
Re: LPF Control Board addressing help
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
|
Re: February 2025 QST Cover Plaque Award
..And my first transmitter had one tube. A 6V6. It was an article in Popular
Electronics.... or maybe Electronics Illustrated.
I built it on a baking tin I stole from my mother. The final
coil was wound on a toilet paper tube, and the tuning indicator was a neon
bulb. The power supply used a transformer liberated from a defunct TV set.
Been an avid builder ever since.
- Jerry, KF6VB
toggle quoted message
Show quoted text
On 2025-04-24 07:00, jjpurdum via groups.io wrote: Sounds like we got started about the same way. My first transmitter
was HB...two tubes, 15W. The receiver was a used S40B that I got for
$25 and my antenna was a 300¦¸ twin-lead dipole cut for 40M. I passed
my Novice in December, 1953, but it wasn't until 1954 until my ticket
arrived...I was chopping at the bit by then!
Jack, W8TEE
On Thursday, April 24, 2025 at 09:43:07 AM EDT, Tom - AJ8X via
groups.io <tom.metty@...> wrote:
Jack, I couldn't help but smile when I read that you got your ARRL
Life Membership in 1972, I did too. I built my novice transmitter in
high school electronics shop from a QST article ... I still remember
the glow of the light bulb when I dipped the plate of the 807. I also
remember buying my first spool of Copperweld from Purchase Radio
Supply, RF burns from my Swan 350, phone patches from South America,
solar cycle 20, and The Adventures of Carl and Jerry. Good times.
--
Jack, W8TEE
Links:
------
[1] /g/SoftwareControlledHamRadio/message/33657
[2] /mt/112341396/243852
[3] /g/SoftwareControlledHamRadio/post
[4] /g/SoftwareControlledHamRadio/editsub/243852
[5]
/g/SoftwareControlledHamRadio/leave/10484476/243852/1943518115/xyzzy
|
As of close of business today, I¡¯ll have to stop talking board and kit orders for the T41 and associated electronics.? I¡¯m preparing for Hamvention now.? We will have plenty of boards, kits, and books there.? Our booth was moved from Building #4 into Building #2 this AM¡ now in a very nice spot¡ #2607. In with many of the international groups ad the ARRL.? Very excited to be there. ? In any case, if you have orders, please get them in by close of business today.? Otherwise catch us at Hamvention¡ or wait until the week after Hamvention. ? ? Dr. William J. Schmidt - K9HZ J62K(J68HZ) 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ VP2EHZ ? Owner - Operator Big Signal Ranch ¨C K9ZC Staunton, Illinois ? Owner ¨C Operator Villa Grand Piton ¨C J68HZ Soufriere, St. Lucia W.I. Rent it: ? Moderator: North American QRO Group at Groups.IO. Moderator: Amateur Radio Builders Group at Groups.IO. ? email:? bill@... ? ?
|
Re: February 2025 QST Cover Plaque Award
Similar here, I built projects from Popular Electronics and other mags. Got side tracked by fumes in 60's-70's didn't rekindle until I got into Boy Scouts with son in 90.
Upped to life shortly afterwards. I built QRP rigs to take on backpacking trips. Building is still my main interest even though I have nice contest/DX station.
Tim W4YN?
|
Re: February 2025 QST Cover Plaque Award
Sounds like we got started about the same way. My first transmitter was HB...two tubes, 15W. The receiver was a used S40B that I got for $25 and my antenna was a 300¦¸ twin-lead dipole cut for 40M. I passed my Novice in December, 1953, but it wasn't until 1954 until my ticket arrived...I was chopping at the bit by then!
Jack, W8TEE
On Thursday, April 24, 2025 at 09:43:07 AM EDT, Tom - AJ8X via groups.io <tom.metty@...> wrote:
Jack, I couldn't help but smile when I read that you got your ARRL Life Membership in 1972, I did too. I built my novice transmitter in high school electronics shop from a QST article ... I still remember the glow of the light bulb when I dipped the plate of the 807.? I also remember buying my first spool of Copperweld from Purchase Radio Supply, RF burns from my Swan 350, phone patches from South America, solar cycle 20, and The Adventures of Carl and Jerry. Good times.
-- Jack, W8TEE
|
jjpurdum
K9HZ