Re: Oscillations on high bands
Jerry, please try the latest commit I just pushed to GitHub. I removed a call to setupSWR() that I am concerned might have messed with the registers:
On Saturday, March 22nd, 2025 at 7:30 PM, Oliver KI3P via groups.io <oliver@...> wrote:
toggle quoted message
Show quoted text
I think this is the commit of a version that has no oscillation if you want to do some git diff'ing:
22385bc73b1046f1b095800e5b5009398fb4d57f
?
My screen freezes seem to be happening less often for some reason, so I've been able to do some debugging. No smoking guns yet, though I did see a peculiar behavior where the control pins 4 and 6 on U8 were both LOW, which should not be possible. The problem then fixed it self, somehow, when I probed the inputs to U6. This seems like it might just be a dry solder joint on my board and is unlikely to affect anyone else.
|
Re: Oscillations on high bands
I think this is the commit of a version that has no oscillation if you want to do some git diff'ing:
22385bc73b1046f1b095800e5b5009398fb4d57f
?
My screen freezes seem to be happening less often for some reason, so I've been able to do some debugging. No smoking guns yet, though I did see a peculiar behavior where the control pins 4 and 6 on U8 were both LOW, which should not be possible. The problem then fixed it self, somehow, when I probed the inputs to U6. This seems like it might just be a dry solder joint on my board and is unlikely to affect anyone else.
|
Re: Oscillations on high bands
On 2025-03-22 15:47, K9HZ wrote: Ni idea... I didn't write a line of that code... *** That's mostly a hardware thing. When you read the register, do you get what you wrote or the current non-driven state of the pins? - Jerry, KF6VB Dr. William J. Schmidt - K9HZ 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: www.VillaGrandPiton.com Moderator: North American QRO Group at Groups.IO. Moderator: Amateur Radio Builders Group at Groups.IO. email: bill@... -----Original Message----- From: [email protected] <[email protected]> On Behalf Of jerry-KF6VB Sent: Saturday, March 22, 2025 5:41 PM To: [email protected] Cc: K9HZ <bill@...> Subject: Re: [SoftwareControlledHamRadio] Oscillations on high bands On 2025-03-22 15:34, K9HZ wrote:
No Bad assumption, there is also a "SETBIT" function... *** Couldn't find that string anywhere in the code. Are these port expanders structured so you can read what you wrote? - Jerry, KF6VB
Dr. William J. Schmidt - K9HZ 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: www.VillaGrandPiton.com Moderator: North American QRO Group at Groups.IO. Moderator: Amateur Radio Builders Group at Groups.IO. email: bill@... -----Original Message----- From: [email protected] <[email protected]> On Behalf Of jerry-KF6VB Sent: Saturday, March 22, 2025 5:32 PM To: [email protected] Subject: Re: [SoftwareControlledHamRadio] Oscillations on high bands Looking at Ver66-09, I have changed the calls to setBPFPath() so they are the same regardless of CW/SSB mode. No difference, still oscillates :(. Of course, it's still possible for code somewhere else to muck with it. Looking at setBPFPath() itself, I see that it sets the BPF with a write to port A of the I/O expander in the LPF controller card. It's reasonable to assume that access to that controller card is ONLY through a library function: mcpLPF.writeGPIOA(). So I searched the codebase for all occurrences of that function. I found five of them; two in SWR.cpp, and 3 in LPF_Control_V12.cpp. I temporarily commented out the calls in SWR.cpp - no difference, still oscillates. I found one unneeded call to mcpLPF.writeGPIOA() in LPF_Control_V12.cpp - where it's choosing an LPF. That's controlled by port B. Commented that out, no difference. If I had a version N that oscillated, and a version N-1 that didn't, I might be able to diff it into submission. I'm wondering how the BPF *band* is selected. Right now, I only see the code for selecting the bpf *path*. - Jerry, KF6VB On 2025-03-22 14:44, jerry-KF6VB wrote:
I just downgraded to V50.0. No oscillation. So it is a software problem. "Ver 063-1-beta" - oscillates. "Ver 066-7-SWR" from 3/5/2025 - oscillates "Ver 065" from 2/20/2025 - oscillates "Ver053" - does NOT oscillate. "Ver050.0" from Oliver 1/20/2025 - does NOT oscillate. "Ver066-9" from Oliver - oscillates. - Jerry, KF6VB On 2025-03-22 13:41, K9HZ wrote:
Its not a hardware problem. The radio has been working fine until recently when some software mods were made. Use some sound deductive reasoning here. This problem did not exist a month ago with any transceivers that were build. Then work was done on the software in a mad dash to close it out for the next version of the T41 book. All of a sudden, there are issues with most/ everyone's radio. What conclusion and action would you take from that? Bobb some hardware out of you radio?... or go back and check out an earlier version of the software? DR. WILLIAM J. SCHMIDT - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ VP2EHZ Owner - Operator Big Signal Ranch - K9ZC Staunton, Illinois Owner - Operator Villa Grand Piton - J68HZ Soufriere, St. Lucia W.I. Rent it: www.VillaGrandPiton.com [1] Moderator: North American QRO Group at Groups.IO. Moderator: Amateur Radio Builders Group at Groups.IO. email: bill@... FROM: [email protected] <[email protected]> ON BEHALF OF Rick Price via groups.io SENT: Saturday, March 22, 2025 3:14 PM TO: [email protected] SUBJECT: Re: [SoftwareControlledHamRadio] LPF-Control PCB TX Logic at U3 & U7 Oliver, I was having some kind of feedback/oscillation problems a couple of weeks ago and traced it back to the T/R switch also. The relays and associated parts all checked out but, when I removed the 3-"0" ohm resistors that were there in place of the Low Pass Filter (160M) and inserted the parts for the LPF the problem stopped. I wanted to go back and remove the filter parts and place just two "0" ohm parts at c14-c16 and a single cap at c-15 but never did. Wondering if the oscillation problem boards have the "0" ohm resistors and not the LPF filter in place. Maybe, I will try it later just thought I would mention what I had, when you suggested a possible feedback issue. Rick, KN4AIE ------------------------- FROM: [email protected] <[email protected]> on behalf of Oliver KI3P via groups.io <oliver@...> SENT: Saturday, March 22, 2025 1:40 PM TO: [email protected] <[email protected]> SUBJECT: Re: [SoftwareControlledHamRadio] LPF-Control PCB TX Logic at U3 & U7 The situation I think we might have is that both TX_BPF_SEL AND RX_BPF_SEL are HIGH during SSB transmit. This lets a little bit of the transmitted signal leak through the TR switch back into the amplifier input through the BPF selection stage, like this: These two lines are controller by GPIO register bank A: This register is set by the function call setBPFPath [2]; the code there looks correct and unchanged. Scanning the code, it all appears to be correct. Some judiciously placed statements like this will confirm: Debug("Set LPF GPA state: "+String(LPF_GPA_state,DEC)); The fix that I implemented (major change to radio layout) to cure the short that caused the burning smell has created a display freeze issue, so I'm not able to test this myself right now. Links: ------ [1] [2]
e 69b1d91b7c38/SDTVer066-9/LPF_Control_V12.cpp#L139 [3] /g/SoftwareControlledHamRadio/message/33179 [4] /mt/111571221/243852 [5] /g/SoftwareControlledHamRadio/post [6] /g/SoftwareControlledHamRadio/editsub/243852 [7] /g/SoftwareControlledHamRadio/leave/10484476/243852 / 1943518115/xyzzy
|
Re: Oscillations on high bands
Ni idea... I didn't write a line of that code...
Dr. William J. Schmidt - K9HZ 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: www.VillaGrandPiton.com
Moderator: North American QRO Group at Groups.IO. Moderator: Amateur Radio Builders Group at Groups.IO.
email: bill@...
toggle quoted message
Show quoted text
-----Original Message----- From: [email protected] < [email protected]> On Behalf Of jerry-KF6VB Sent: Saturday, March 22, 2025 5:41 PM To: [email protected]Cc: K9HZ <bill@...> Subject: Re: [SoftwareControlledHamRadio] Oscillations on high bands On 2025-03-22 15:34, K9HZ wrote: No Bad assumption, there is also a "SETBIT" function... *** Couldn't find that string anywhere in the code. Are these port expanders structured so you can read what you wrote? - Jerry, KF6VB
Dr. William J. Schmidt - K9HZ 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: www.VillaGrandPiton.com
Moderator: North American QRO Group at Groups.IO. Moderator: Amateur Radio Builders Group at Groups.IO.
email: bill@...
-----Original Message----- From: [email protected] <[email protected]> On Behalf Of jerry-KF6VB Sent: Saturday, March 22, 2025 5:32 PM To: [email protected] Subject: Re: [SoftwareControlledHamRadio] Oscillations on high bands
Looking at Ver66-09,
I have changed the calls to setBPFPath() so they are the same regardless of CW/SSB mode. No difference, still oscillates :(.
Of course, it's still possible for code somewhere else to muck with it.
Looking at setBPFPath() itself, I see that it sets the BPF with a write to port A of the I/O expander in the LPF controller card.
It's reasonable to assume that access to that controller card is ONLY through a library function:
mcpLPF.writeGPIOA().
So I searched the codebase for all occurrences of that function. I found five of them; two in SWR.cpp, and 3 in LPF_Control_V12.cpp.
I temporarily commented out the calls in SWR.cpp - no difference, still oscillates.
I found one unneeded call to mcpLPF.writeGPIOA() in LPF_Control_V12.cpp - where it's choosing an LPF. That's controlled by port B. Commented that out, no difference.
If I had a version N that oscillated, and a version N-1 that didn't, I might be able to diff it into submission.
I'm wondering how the BPF *band* is selected. Right now, I only see the code for selecting the bpf *path*.
- Jerry, KF6VB
On 2025-03-22 14:44, jerry-KF6VB wrote:
I just downgraded to V50.0. No oscillation. So it is a software problem.
"Ver 063-1-beta" - oscillates. "Ver 066-7-SWR" from 3/5/2025 - oscillates "Ver 065" from 2/20/2025 - oscillates "Ver053" - does NOT oscillate. "Ver050.0" from Oliver 1/20/2025 - does NOT oscillate. "Ver066-9" from Oliver - oscillates.
- Jerry, KF6VB
On 2025-03-22 13:41, K9HZ wrote:
Its not a hardware problem. The radio has been working fine until recently when some software mods were made.
Use some sound deductive reasoning here. This problem did not exist a month ago with any transceivers that were build. Then work was done on the software in a mad dash to close it out for the next version of the T41 book. All of a sudden, there are issues with most/ everyone's radio. What conclusion and action would you take from that? Bobb some hardware out of you radio?... or go back and check out an earlier version of the software?
DR. WILLIAM J. SCHMIDT - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ VP2EHZ
Owner - Operator
Big Signal Ranch - K9ZC
Staunton, Illinois
Owner - Operator
Villa Grand Piton - J68HZ
Soufriere, St. Lucia W.I.
Rent it: www.VillaGrandPiton.com [1]
Moderator: North American QRO Group at Groups.IO.
Moderator: Amateur Radio Builders Group at Groups.IO.
email: bill@...
FROM: [email protected] <[email protected]> ON BEHALF OF Rick Price via groups.io SENT: Saturday, March 22, 2025 3:14 PM TO: [email protected] SUBJECT: Re: [SoftwareControlledHamRadio] LPF-Control PCB TX Logic at U3 & U7
Oliver, I was having some kind of feedback/oscillation problems a couple of weeks ago and traced it back to the T/R switch also. The relays and associated parts all checked out but, when I removed the 3-"0" ohm resistors that were there in place of the Low Pass Filter (160M) and inserted the parts for the LPF the problem stopped. I wanted to go back and remove the filter parts and place just two "0" ohm parts at c14-c16 and a single cap at c-15 but never did. Wondering if the oscillation problem boards have the "0" ohm resistors and not the LPF filter in place. Maybe, I will try it later just thought I would mention what I had, when you suggested a possible feedback issue.
Rick, KN4AIE
-------------------------
FROM: [email protected] <[email protected]> on behalf of Oliver KI3P via groups.io <oliver@...> SENT: Saturday, March 22, 2025 1:40 PM TO: [email protected] <[email protected]> SUBJECT: Re: [SoftwareControlledHamRadio] LPF-Control PCB TX Logic at U3 & U7
The situation I think we might have is that both TX_BPF_SEL AND RX_BPF_SEL are HIGH during SSB transmit. This lets a little bit of the transmitted signal leak through the TR switch back into the amplifier input through the BPF selection stage, like this:
These two lines are controller by GPIO register bank A:
This register is set by the function call setBPFPath [2]; the code there looks correct and unchanged. Scanning the code, it all appears to be correct. Some judiciously placed statements like this will confirm:
Debug("Set LPF GPA state: "+String(LPF_GPA_state,DEC));
The fix that I implemented (major change to radio layout) to cure the short that caused the burning smell has created a display freeze issue, so I'm not able to test this myself right now.
Links: ------ [1] [2]
e 69b1d91b7c38/SDTVer066-9/LPF_Control_V12.cpp#L139 [3] /g/SoftwareControlledHamRadio/message/33179 [4] /mt/111571221/243852 [5] /g/SoftwareControlledHamRadio/post [6] /g/SoftwareControlledHamRadio/editsub/243852 [7] /g/SoftwareControlledHamRadio/leave/10484476/243852 / 1943518115/xyzzy
|
Re: Oscillations on high bands
On 2025-03-22 15:34, K9HZ wrote: No Bad assumption, there is also a "SETBIT" function... *** Couldn't find that string anywhere in the code. Are these port expanders structured so you can read what you wrote? - Jerry, KF6VB Dr. William J. Schmidt - K9HZ 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: www.VillaGrandPiton.com Moderator: North American QRO Group at Groups.IO. Moderator: Amateur Radio Builders Group at Groups.IO. email:? bill@... -----Original Message----- From: [email protected] <[email protected]> On Behalf Of jerry-KF6VB Sent: Saturday, March 22, 2025 5:32 PM To: [email protected] Subject: Re: [SoftwareControlledHamRadio] Oscillations on high bands Looking at Ver66-09, I have changed the calls to setBPFPath() so they are the same regardless of CW/SSB mode. No difference, still oscillates :(. Of course, it's still possible for code somewhere else to muck with it. Looking at setBPFPath() itself, I see that it sets the BPF with a write to port A of the I/O expander in the LPF controller card. It's reasonable to assume that access to that controller card is ONLY through a library function: mcpLPF.writeGPIOA(). So I searched the codebase for all occurrences of that function. I found five of them; two in SWR.cpp, and 3 in LPF_Control_V12.cpp. I temporarily commented out the calls in SWR.cpp - no difference, still oscillates. I found one unneeded call to mcpLPF.writeGPIOA() in LPF_Control_V12.cpp - where it's choosing an LPF. That's controlled by port B. Commented that out, no difference. If I had a version N that oscillated, and a version N-1 that didn't, I might be able to diff it into submission. I'm wondering how the BPF *band* is selected. Right now, I only see the code for selecting the bpf *path*. - Jerry, KF6VB On 2025-03-22 14:44, jerry-KF6VB wrote:
I just downgraded to V50.0. No oscillation. So it is a software problem. "Ver 063-1-beta" - oscillates. "Ver 066-7-SWR" from 3/5/2025 - oscillates "Ver 065" from 2/20/2025 - oscillates "Ver053" - does NOT oscillate. "Ver050.0" from Oliver 1/20/2025 - does NOT oscillate. "Ver066-9" from Oliver - oscillates. - Jerry, KF6VB On 2025-03-22 13:41, K9HZ wrote:
Its not a hardware problem. The radio has been working fine until recently when some software mods were made. Use some sound deductive reasoning here. This problem did not exist a month ago with any transceivers that were build. Then work was done on the software in a mad dash to close it out for the next version of the T41 book. All of a sudden, there are issues with most/ everyone's radio. What conclusion and action would you take from that? Bobb some hardware out of you radio?... or go back and check out an earlier version of the software? DR. WILLIAM J. SCHMIDT - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ VP2EHZ Owner - Operator Big Signal Ranch - K9ZC Staunton, Illinois Owner - Operator Villa Grand Piton - J68HZ Soufriere, St. Lucia W.I. Rent it: www.VillaGrandPiton.com [1] Moderator: North American QRO Group at Groups.IO. Moderator: Amateur Radio Builders Group at Groups.IO. email: bill@... FROM: [email protected] <[email protected]> ON BEHALF OF Rick Price via groups.io SENT: Saturday, March 22, 2025 3:14 PM TO: [email protected] SUBJECT: Re: [SoftwareControlledHamRadio] LPF-Control PCB TX Logic at U3 & U7 Oliver, I was having some kind of feedback/oscillation problems a couple of weeks ago and traced it back to the T/R switch also. The relays and associated parts all checked out but, when I removed the 3-"0" ohm resistors that were there in place of the Low Pass Filter (160M) and inserted the parts for the LPF the problem stopped. I wanted to go back and remove the filter parts and place just two "0" ohm parts at c14-c16 and a single cap at c-15 but never did. Wondering if the oscillation problem boards have the "0" ohm resistors and not the LPF filter in place. Maybe, I will try it later just thought I would mention what I had, when you suggested a possible feedback issue. Rick, KN4AIE ------------------------- FROM: [email protected] <[email protected]> on behalf of Oliver KI3P via groups.io <oliver@...> SENT: Saturday, March 22, 2025 1:40 PM TO: [email protected] <[email protected]> SUBJECT: Re: [SoftwareControlledHamRadio] LPF-Control PCB TX Logic at U3 & U7 The situation I think we might have is that both TX_BPF_SEL AND RX_BPF_SEL are HIGH during SSB transmit. This lets a little bit of the transmitted signal leak through the TR switch back into the amplifier input through the BPF selection stage, like this: These two lines are controller by GPIO register bank A: This register is set by the function call setBPFPath [2]; the code there looks correct and unchanged. Scanning the code, it all appears to be correct. Some judiciously placed statements like this will confirm: Debug("Set LPF GPA state: "+String(LPF_GPA_state,DEC)); The fix that I implemented (major change to radio layout) to cure the short that caused the burning smell has created a display freeze issue, so I'm not able to test this myself right now. Links: ------ [1] [2]
69b1d91b7c38/SDTVer066-9/LPF_Control_V12.cpp#L139 [3] /g/SoftwareControlledHamRadio/message/33179 [4] /mt/111571221/243852 [5] /g/SoftwareControlledHamRadio/post [6] /g/SoftwareControlledHamRadio/editsub/243852 [7] /g/SoftwareControlledHamRadio/leave/10484476/243852/ 1943518115/xyzzy
|
Re: Oscillations on high bands
No Bad assumption, there is also a "SETBIT" function...
Dr. William J. Schmidt - K9HZ 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: www.VillaGrandPiton.com
Moderator: North American QRO Group at Groups.IO. Moderator: Amateur Radio Builders Group at Groups.IO.
email:? bill@...
toggle quoted message
Show quoted text
-----Original Message----- From: [email protected]< [email protected]> On Behalf Of jerry-KF6VB Sent: Saturday, March 22, 2025 5:32 PM To: [email protected]Subject: Re: [SoftwareControlledHamRadio] Oscillations on high bands Looking at Ver66-09, I have changed the calls to setBPFPath() so they are the same regardless of CW/SSB mode. No difference, still oscillates :(. Of course, it's still possible for code somewhere else to muck with it. Looking at setBPFPath() itself, I see that it sets the BPF with a write to port A of the I/O expander in the LPF controller card. It's reasonable to assume that access to that controller card is ONLY through a library function: mcpLPF.writeGPIOA(). So I searched the codebase for all occurrences of that function. I found five of them; two in SWR.cpp, and 3 in LPF_Control_V12.cpp. I temporarily commented out the calls in SWR.cpp - no difference, still oscillates. I found one unneeded call to mcpLPF.writeGPIOA() in LPF_Control_V12.cpp - where it's choosing an LPF. That's controlled by port B. Commented that out, no difference. If I had a version N that oscillated, and a version N-1 that didn't, I might be able to diff it into submission. I'm wondering how the BPF *band* is selected. Right now, I only see the code for selecting the bpf *path*. - Jerry, KF6VB On 2025-03-22 14:44, jerry-KF6VB wrote: I just downgraded to V50.0. No oscillation. So it is a software problem.
"Ver 063-1-beta" - oscillates. "Ver 066-7-SWR" from 3/5/2025 - oscillates "Ver 065" from 2/20/2025 - oscillates "Ver053" - does NOT oscillate. "Ver050.0" from Oliver 1/20/2025 - does NOT oscillate. "Ver066-9" from Oliver - oscillates.
- Jerry, KF6VB
On 2025-03-22 13:41, K9HZ wrote:
Its not a hardware problem. The radio has been working fine until recently when some software mods were made.
Use some sound deductive reasoning here. This problem did not exist a month ago with any transceivers that were build. Then work was done on the software in a mad dash to close it out for the next version of the T41 book. All of a sudden, there are issues with most/ everyone's radio. What conclusion and action would you take from that? Bobb some hardware out of you radio?... or go back and check out an earlier version of the software?
DR. WILLIAM J. SCHMIDT - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ VP2EHZ
Owner - Operator
Big Signal Ranch - K9ZC
Staunton, Illinois
Owner - Operator
Villa Grand Piton - J68HZ
Soufriere, St. Lucia W.I.
Rent it: www.VillaGrandPiton.com [1]
Moderator: North American QRO Group at Groups.IO.
Moderator: Amateur Radio Builders Group at Groups.IO.
email: bill@...
FROM: [email protected] <[email protected]> ON BEHALF OF Rick Price via groups.io SENT: Saturday, March 22, 2025 3:14 PM TO: [email protected] SUBJECT: Re: [SoftwareControlledHamRadio] LPF-Control PCB TX Logic at U3 & U7
Oliver, I was having some kind of feedback/oscillation problems a couple of weeks ago and traced it back to the T/R switch also. The relays and associated parts all checked out but, when I removed the 3-"0" ohm resistors that were there in place of the Low Pass Filter (160M) and inserted the parts for the LPF the problem stopped. I wanted to go back and remove the filter parts and place just two "0" ohm parts at c14-c16 and a single cap at c-15 but never did. Wondering if the oscillation problem boards have the "0" ohm resistors and not the LPF filter in place. Maybe, I will try it later just thought I would mention what I had, when you suggested a possible feedback issue.
Rick, KN4AIE
-------------------------
FROM: [email protected] <[email protected]> on behalf of Oliver KI3P via groups.io <oliver@...> SENT: Saturday, March 22, 2025 1:40 PM TO: [email protected] <[email protected]> SUBJECT: Re: [SoftwareControlledHamRadio] LPF-Control PCB TX Logic at U3 & U7
The situation I think we might have is that both TX_BPF_SEL AND RX_BPF_SEL are HIGH during SSB transmit. This lets a little bit of the transmitted signal leak through the TR switch back into the amplifier input through the BPF selection stage, like this:
These two lines are controller by GPIO register bank A:
This register is set by the function call setBPFPath [2]; the code there looks correct and unchanged. Scanning the code, it all appears to be correct. Some judiciously placed statements like this will confirm:
Debug("Set LPF GPA state: "+String(LPF_GPA_state,DEC));
The fix that I implemented (major change to radio layout) to cure the short that caused the burning smell has created a display freeze issue, so I'm not able to test this myself right now.
Links: ------ [1] [2]
69b1d91b7c38/SDTVer066-9/LPF_Control_V12.cpp#L139 [3] /g/SoftwareControlledHamRadio/message/33179 [4] /mt/111571221/243852 [5] /g/SoftwareControlledHamRadio/post [6] /g/SoftwareControlledHamRadio/editsub/243852 [7] /g/SoftwareControlledHamRadio/leave/10484476/243852/ 1943518115/xyzzy
|
Re: Oscillations on high bands
Looking at Ver66-09,
I have changed the calls to setBPFPath() so they are the same regardless of CW/SSB mode. No difference, still oscillates :(.
Of course, it's still possible for code somewhere else to muck with it.
Looking at setBPFPath() itself, I see that it sets the BPF with a write to port A of the I/O expander in the LPF controller card.
It's reasonable to assume that access to that controller card is ONLY through a library function:
mcpLPF.writeGPIOA().
So I searched the codebase for all occurrences of that function. I found five of them; two in SWR.cpp, and 3 in LPF_Control_V12.cpp.
I temporarily commented out the calls in SWR.cpp - no difference, still oscillates.
I found one unneeded call to mcpLPF.writeGPIOA() in LPF_Control_V12.cpp - where it's choosing an LPF. That's controlled by port B. Commented that out, no difference.
If I had a version N that oscillated, and a version N-1 that didn't, I might be able to diff it into submission.
I'm wondering how the BPF *band* is selected. Right now, I only see the code for selecting the bpf *path*.
- Jerry, KF6VB
toggle quoted message
Show quoted text
On 2025-03-22 14:44, jerry-KF6VB wrote: I just downgraded to V50.0. No oscillation. So it is a software problem. "Ver 063-1-beta" - oscillates. "Ver 066-7-SWR" from 3/5/2025 - oscillates "Ver 065" from 2/20/2025 - oscillates "Ver053" - does NOT oscillate. "Ver050.0" from Oliver 1/20/2025 - does NOT oscillate. "Ver066-9" from Oliver - oscillates. - Jerry, KF6VB On 2025-03-22 13:41, K9HZ wrote:
Its not a hardware problem. The radio has been working fine until recently when some software mods were made. Use some sound deductive reasoning here. This problem did not exist a month ago with any transceivers that were build. Then work was done on the software in a mad dash to close it out for the next version of the T41 book. All of a sudden, there are issues with most/ everyone's radio. What conclusion and action would you take from that? Bobb some hardware out of you radio?... or go back and check out an earlier version of the software? DR. WILLIAM J. SCHMIDT - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ VP2EHZ Owner - Operator Big Signal Ranch - K9ZC Staunton, Illinois Owner - Operator Villa Grand Piton - J68HZ Soufriere, St. Lucia W.I. Rent it: www.VillaGrandPiton.com [1] Moderator: North American QRO Group at Groups.IO. Moderator: Amateur Radio Builders Group at Groups.IO. email: bill@... FROM: [email protected] <[email protected]> ON BEHALF OF Rick Price via groups.io SENT: Saturday, March 22, 2025 3:14 PM TO: [email protected] SUBJECT: Re: [SoftwareControlledHamRadio] LPF-Control PCB TX Logic at U3 & U7 Oliver, I was having some kind of feedback/oscillation problems a couple of weeks ago and traced it back to the T/R switch also. The relays and associated parts all checked out but, when I removed the 3-"0" ohm resistors that were there in place of the Low Pass Filter (160M) and inserted the parts for the LPF the problem stopped. I wanted to go back and remove the filter parts and place just two "0" ohm parts at c14-c16 and a single cap at c-15 but never did. Wondering if the oscillation problem boards have the "0" ohm resistors and not the LPF filter in place. Maybe, I will try it later just thought I would mention what I had, when you suggested a possible feedback issue. Rick, KN4AIE ------------------------- FROM: [email protected] <[email protected]> on behalf of Oliver KI3P via groups.io <oliver@...> SENT: Saturday, March 22, 2025 1:40 PM TO: [email protected] <[email protected]> SUBJECT: Re: [SoftwareControlledHamRadio] LPF-Control PCB TX Logic at U3 & U7 The situation I think we might have is that both TX_BPF_SEL AND RX_BPF_SEL are HIGH during SSB transmit. This lets a little bit of the transmitted signal leak through the TR switch back into the amplifier input through the BPF selection stage, like this: These two lines are controller by GPIO register bank A: This register is set by the function call setBPFPath [2]; the code there looks correct and unchanged. Scanning the code, it all appears to be correct. Some judiciously placed statements like this will confirm: Debug("Set LPF GPA state: "+String(LPF_GPA_state,DEC)); The fix that I implemented (major change to radio layout) to cure the short that caused the burning smell has created a display freeze issue, so I'm not able to test this myself right now. Links: ------ [1] [2]
[3] /g/SoftwareControlledHamRadio/message/33179 [4] /mt/111571221/243852 [5] /g/SoftwareControlledHamRadio/post [6] /g/SoftwareControlledHamRadio/editsub/243852 [7] /g/SoftwareControlledHamRadio/leave/10484476/243852/1943518115/xyzzy
|
Re: LPF-Control PCB TX Logic at U3 & U7
No problem¡ Jerry just confirmed it¡¯s a software bug that got in between version 50.0 and 66.9.?? I¡¯ll let the software gurus figger out where the bug is.? There are plenty of ya here in the forum monkeying with the code.?? Those of you that took parts out of your radios¡. PUT THEM BACK! ? ? Dr. William J. Schmidt - K9HZ 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 jjpurdum via groups.io Sent: Saturday, March 22, 2025 3:56 PM To: [email protected] Subject: Re: [SoftwareControlledHamRadio] LPF-Control PCB TX Logic at U3 & U7? I can't help because my system's been down for over a month and I haven't been able to do anything with the software. On Saturday, March 22, 2025 at 04:41:38 PM EDT, K9HZ <bill@...> wrote: Its not a hardware problem.? The radio has been working fine until recently when some software mods were made. ? Use some sound deductive reasoning here.? This problem did not exist a month ago with any transceivers that were build.? Then work was done on the software in a mad dash to close it out for the next version of the T41 book.? All of a sudden, there are issues with most/ everyone¡¯s radio.? What conclusion and action would you take from that?? Bobb some hardware out of you radio?... or go back and check out an earlier version of the software? ? ? Dr. William J. Schmidt - K9HZ 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@... ? ? ? Oliver,? I was having some kind of feedback/oscillation problems a couple of weeks ago and traced it back to the T/R switch also.? The relays and associated parts all checked out but, when I removed the 3-"0" ohm resistors that were there in place of?the Low Pass Filter (160M) and inserted the parts for the LPF the problem stopped.? I wanted to go back and remove the filter parts and place just two "0" ohm parts at c14-c16 and a single cap at c-15 but never did.? Wondering if the oscillation problem boards have the "0" ohm resistors and not the LPF filter in place.? Maybe, I will try it later just thought I would mention what I had, when you suggested a possible feedback issue.
The situation I think we might have is that both TX_BPF_SEL and RX_BPF_SEL are HIGH during SSB transmit. This lets a little bit of the transmitted signal leak through the TR switch back into the amplifier input through the BPF selection stage, like this: These two lines are controller by GPIO register bank A: This register is set by the function call ; the code there looks correct and unchanged. Scanning the code, it all appears to be correct. Some judiciously placed statements like this will confirm: Debug("Set LPF GPA state: "+String(LPF_GPA_state,DEC)); The fix that I implemented (major change to radio layout) to cure the short that caused the burning smell has created a display freeze issue, so I'm not able to test this myself right now. -- Jack, W8TEE
|
Oscillations on high bands
I just downgraded to V50.0. No oscillation. So it is a software problem.
"Ver 063-1-beta" - oscillates. "Ver 066-7-SWR" from 3/5/2025 - oscillates "Ver 065" from 2/20/2025 - oscillates "Ver053" - does NOT oscillate. "Ver050.0" from Oliver 1/20/2025 - does NOT oscillate. "Ver066-9" from Oliver - oscillates.
- Jerry, KF6VB
toggle quoted message
Show quoted text
On 2025-03-22 13:41, K9HZ wrote: Its not a hardware problem. The radio has been working fine until recently when some software mods were made. Use some sound deductive reasoning here. This problem did not exist a month ago with any transceivers that were build. Then work was done on the software in a mad dash to close it out for the next version of the T41 book. All of a sudden, there are issues with most/ everyone's radio. What conclusion and action would you take from that? Bobb some hardware out of you radio?... or go back and check out an earlier version of the software? DR. WILLIAM J. SCHMIDT - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ VP2EHZ Owner - Operator Big Signal Ranch - K9ZC Staunton, Illinois Owner - Operator Villa Grand Piton - J68HZ Soufriere, St. Lucia W.I. Rent it: www.VillaGrandPiton.com [1] Moderator: North American QRO Group at Groups.IO. Moderator: Amateur Radio Builders Group at Groups.IO. email: bill@... FROM: [email protected] <[email protected]> ON BEHALF OF Rick Price via groups.io SENT: Saturday, March 22, 2025 3:14 PM TO: [email protected] SUBJECT: Re: [SoftwareControlledHamRadio] LPF-Control PCB TX Logic at U3 & U7 Oliver, I was having some kind of feedback/oscillation problems a couple of weeks ago and traced it back to the T/R switch also. The relays and associated parts all checked out but, when I removed the 3-"0" ohm resistors that were there in place of the Low Pass Filter (160M) and inserted the parts for the LPF the problem stopped. I wanted to go back and remove the filter parts and place just two "0" ohm parts at c14-c16 and a single cap at c-15 but never did. Wondering if the oscillation problem boards have the "0" ohm resistors and not the LPF filter in place. Maybe, I will try it later just thought I would mention what I had, when you suggested a possible feedback issue. Rick, KN4AIE ------------------------- FROM: [email protected] <[email protected]> on behalf of Oliver KI3P via groups.io <oliver@...> SENT: Saturday, March 22, 2025 1:40 PM TO: [email protected] <[email protected]> SUBJECT: Re: [SoftwareControlledHamRadio] LPF-Control PCB TX Logic at U3 & U7 The situation I think we might have is that both TX_BPF_SEL AND RX_BPF_SEL are HIGH during SSB transmit. This lets a little bit of the transmitted signal leak through the TR switch back into the amplifier input through the BPF selection stage, like this: These two lines are controller by GPIO register bank A: This register is set by the function call setBPFPath [2]; the code there looks correct and unchanged. Scanning the code, it all appears to be correct. Some judiciously placed statements like this will confirm: Debug("Set LPF GPA state: "+String(LPF_GPA_state,DEC)); The fix that I implemented (major change to radio layout) to cure the short that caused the burning smell has created a display freeze issue, so I'm not able to test this myself right now. Links: ------ [1] [2]
[3] /g/SoftwareControlledHamRadio/message/33179 [4] /mt/111571221/243852 [5] /g/SoftwareControlledHamRadio/post [6] /g/SoftwareControlledHamRadio/editsub/243852 [7] /g/SoftwareControlledHamRadio/leave/10484476/243852/1943518115/xyzzy
|
Re: LPF-Control PCB TX Logic at U3 & U7
Thanks Bill -- I'll build it from the parts.
|
Re: LPF-Control PCB TX Logic at U3 & U7
I can't help because my system's been down for over a month and I haven't been able to do anything with the software.
Jack, W8TEE
On Saturday, March 22, 2025 at 04:41:38 PM EDT, K9HZ <bill@...> wrote:
Its not a hardware problem.? The radio has been working fine until recently when some software mods were made. ? Use some sound deductive reasoning here.? This problem did not exist a month ago with any transceivers that were build.? Then work was done on the software in a mad dash to close it out for the next version of the T41 book.? All of a sudden, there are issues with most/ everyone¡¯s radio.? What conclusion and action would you take from that?? Bobb some hardware out of you radio?... or go back and check out an earlier version of the software? ? ? Dr. William J. Schmidt - K9HZ 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 Rick Price via groups.io Sent: Saturday, March 22, 2025 3:14 PM To: [email protected] Subject: Re: [SoftwareControlledHamRadio] LPF-Control PCB TX Logic at U3 & U7 ? Oliver,? I was having some kind of feedback/oscillation problems a couple of weeks ago and traced it back to the T/R switch also.? The relays and associated parts all checked out but, when I removed the 3-"0" ohm resistors that were there in place of?the Low Pass Filter (160M) and inserted the parts for the LPF the problem stopped.? I wanted to go back and remove the filter parts and place just two "0" ohm parts at c14-c16 and a single cap at c-15 but never did.? Wondering if the oscillation problem boards have the "0" ohm resistors and not the LPF filter in place.? Maybe, I will try it later just thought I would mention what I had, when you suggested a possible feedback issue.
The situation I think we might have is that both TX_BPF_SEL and RX_BPF_SEL are HIGH during SSB transmit. This lets a little bit of the transmitted signal leak through the TR switch back into the amplifier input through the BPF selection stage, like this: These two lines are controller by GPIO register bank A: This register is set by the function call ; the code there looks correct and unchanged. Scanning the code, it all appears to be correct. Some judiciously placed statements like this will confirm: Debug("Set LPF GPA state: "+String(LPF_GPA_state,DEC)); The fix that I implemented (major change to radio layout) to cure the short that caused the burning smell has created a display freeze issue, so I'm not able to test this myself right now.
-- Jack, W8TEE
|
Re: LPF-Control PCB TX Logic at U3 & U7
My testing indicates this is the problem area. I removed C18 and the problem went away. Obviously, as Bill indicated, this is not a fix. ? I think that the state of the switches (U1, U8, U3, U7) in SSB should match the state of the switches in CW. They do not.? dave
toggle quoted message
Show quoted text
On Mar 22, 2025, at 1:40?PM, Oliver KI3P via groups.io <oliver@...> wrote:
? The situation I think we might have is that both TX_BPF_SEL and RX_BPF_SEL are HIGH during SSB transmit. This lets a little bit of the transmitted signal leak through the TR switch back into the amplifier input through the BPF selection stage, like this:
?
?
These two lines are controller by GPIO register bank A:
?
?
This register is set by the function call ; the code there looks correct and unchanged. Scanning the code, it all appears to be correct. Some judiciously placed statements like this will confirm:
Debug("Set LPF GPA state: "+String(LPF_GPA_state,DEC));
?
The fix that I implemented (major change to radio layout) to cure the short that caused the burning smell has created a display freeze issue, so I'm not able to test this myself right now.
?
?
?
?
?
|
Re: LPF-Control PCB TX Logic at U3 & U7
Ok if I just send you the board and parts to build your own?? That will save me some time and its very easy to build. ? ? Dr. William J. Schmidt - K9HZ 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 Oliver KI3P via groups.io Sent: Saturday, March 22, 2025 10:17 AM To: [email protected] Subject: Re: [SoftwareControlledHamRadio] LPF-Control PCB TX Logic at U3 & U7? One quick correction Bill: I have a 3.3V display, not a 5V display. Thank you!
|
Re: LPF-Control PCB TX Logic at U3 & U7
Its not a hardware problem.? The radio has been working fine until recently when some software mods were made. ? Use some sound deductive reasoning here.? This problem did not exist a month ago with any transceivers that were build.? Then work was done on the software in a mad dash to close it out for the next version of the T41 book.? All of a sudden, there are issues with most/ everyone¡¯s radio.? What conclusion and action would you take from that?? Bobb some hardware out of you radio?... or go back and check out an earlier version of the software? ? ? Dr. William J. Schmidt - K9HZ 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 Rick Price via groups.io Sent: Saturday, March 22, 2025 3:14 PM To: [email protected] Subject: Re: [SoftwareControlledHamRadio] LPF-Control PCB TX Logic at U3 & U7? Oliver,? I was having some kind of feedback/oscillation problems a couple of weeks ago and traced it back to the T/R switch also.? The relays and associated parts all checked out but, when I removed the 3-"0" ohm resistors that were there in place of?the Low Pass Filter (160M) and inserted the parts for the LPF the problem stopped.? I wanted to go back and remove the filter parts and place just two "0" ohm parts at c14-c16 and a single cap at c-15 but never did.? Wondering if the oscillation problem boards have the "0" ohm resistors and not the LPF filter in place.? Maybe, I will try it later just thought I would mention what I had, when you suggested a possible feedback issue.
The situation I think we might have is that both TX_BPF_SEL and RX_BPF_SEL are HIGH during SSB transmit. This lets a little bit of the transmitted signal leak through the TR switch back into the amplifier input through the BPF selection stage, like this: These two lines are controller by GPIO register bank A: This register is set by the function call ; the code there looks correct and unchanged. Scanning the code, it all appears to be correct. Some judiciously placed statements like this will confirm: Debug("Set LPF GPA state: "+String(LPF_GPA_state,DEC)); The fix that I implemented (major change to radio layout) to cure the short that caused the burning smell has created a display freeze issue, so I'm not able to test this myself right now.
|
Re: LPF-Control PCB TX Logic at U3 & U7
So I think what you are saying is that either: ? - TX_BFP_SEL is on (=1) and RX_BPF_SEL is off (=0) for TX? ¡OR
- TX_BFP_SEL is off (=0) and RX_BPF_SEL is on (=1) for RX.
? I wonder how/why that got changed.? There are probably change notes in the program header.? I do know from feedback in this thread that the TX select switches but the RX does not switch¡ ? ? ? Dr. William J. Schmidt - K9HZ 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 Oliver KI3P via groups.io Sent: Saturday, March 22, 2025 12:40 PM To: [email protected] Subject: Re: [SoftwareControlledHamRadio] LPF-Control PCB TX Logic at U3 & U7? The situation I think we might have is that both TX_BPF_SEL and RX_BPF_SEL are HIGH during SSB transmit. This lets a little bit of the transmitted signal leak through the TR switch back into the amplifier input through the BPF selection stage, like this: These two lines are controller by GPIO register bank A: This register is set by the function call ; the code there looks correct and unchanged. Scanning the code, it all appears to be correct. Some judiciously placed statements like this will confirm: Debug("Set LPF GPA state: "+String(LPF_GPA_state,DEC)); The fix that I implemented (major change to radio layout) to cure the short that caused the burning smell has created a display freeze issue, so I'm not able to test this myself right now.
|
Re: LPF-Control PCB TX Logic at U3 & U7
Oliver,? I was having some kind of feedback/oscillation problems a couple of weeks ago and traced it back to the T/R switch also.? The relays and associated parts all checked out but, when I removed the 3-"0" ohm resistors that were there in place of?the Low
Pass Filter (160M) and inserted the parts for the LPF the problem stopped.? I wanted to go back and remove the filter parts and place just two "0" ohm parts at c14-c16 and a single cap at c-15 but never did.? Wondering if the oscillation problem boards have
the "0" ohm resistors and not the LPF filter in place.? Maybe, I will try it later just thought I would mention what I had, when you suggested a possible feedback issue.
Rick, KN4AIE
?
toggle quoted message
Show quoted text
The situation I think we might have is that both TX_BPF_SEL and RX_BPF_SEL are HIGH during SSB transmit. This lets a little bit of the transmitted signal leak through the TR switch back into the amplifier input through the BPF selection
stage, like this:
?
?
These two lines are controller by GPIO register bank A:
?
?
This register is set by the function call ; the code there looks correct and unchanged. Scanning the code, it all appears to be correct. Some judiciously placed statements like this will confirm:
Debug("Set LPF GPA state: "+String(LPF_GPA_state,DEC));
?
The fix that I implemented (major change to radio layout) to cure the short that caused the burning smell has created a display freeze issue, so I'm not able to test this myself right now.
?
?
?
?
?
|
Re: LPF-Control PCB TX Logic at U3 & U7
I'm not sure the entire signal path.? But there is a lot of gain in the power amplifier, about 50 dB or more.
Those switches have an isolation of about 48 dB in the HF range.? So two of them in series (both off) will have about 54 dB.
So you need to add up the gains and the losses in the correct transmit configuration and see if you end up with a negative or positive number.
You want a significantly negative number to make sure gain margin is sufficient to prevent oscillation or gain peaking.
?
--
73 Greg KF5N
|
Re: LPF-Control PCB TX Logic at U3 & U7
The situation I think we might have is that both TX_BPF_SEL and RX_BPF_SEL are HIGH during SSB transmit. This lets a little bit of the transmitted signal leak through the TR switch back into the amplifier input through the BPF selection stage, like this:
?
?
These two lines are controller by GPIO register bank A:
?
?
This register is set by the function call ; the code there looks correct and unchanged. Scanning the code, it all appears to be correct. Some judiciously placed statements like this will confirm:
Debug("Set LPF GPA state: "+String(LPF_GPA_state,DEC));
?
The fix that I implemented (major change to radio layout) to cure the short that caused the burning smell has created a display freeze issue, so I'm not able to test this myself right now.
?
?
?
?
?
|
Re: LPF-Control PCB TX Logic at U3 & U7
On 2025-03-22 03:20, Oliver KI3P via groups.io wrote: The code that controls the LPF is here:
Can you try out version 66.9 of the code and see whether the problem persists? This is the fully-featured version that is in beta testing. I just tried this. Rings like a bell. 8W out on 10M without talking. - Jerry, KF6VB
|
Re: LPF-Control PCB TX Logic at U3 & U7
One quick correction Bill: I have a 3.3V display, not a 5V display. Thank you!
|