开云体育

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 – K9ZC
Staunton, Illinois

Owner – Operator
Villa Grand Piton – 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