Re: boards and kits and stuff
What I have seen from the Teensy SPI is reliable operation.? Very robust and predictable.
?
--
73 Greg KF5N
|
Re: boards and kits and stuff
The problem is the Teensy SPI interface which has some defects in it...
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 ken WA2MZE Sent: Sunday, March 23, 2025 5:25 PM To: [email protected]Subject: Re: [SoftwareControlledHamRadio] boards and kits and stuff I guess one could use a pico (RP2040) to drive the display via the parallel interface, and talk to the Teensy via SPI. If much of the actual graphical processing is done on the pico, then the I2C interface might be fast enough.
|
Re: boards and kits and stuff
I guess one could use a pico (RP2040) to drive the display via the parallel interface, and talk to the Teensy via SPI.? If much of the actual graphical processing is done on the pico, then the I2C interface might be fast enough.
|
Re: boards and kits and stuff
Please send me your address for shipping the display driver board¡ ? ? 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
|
Re: Oscillations on high bands
Good work Oliver. I¡¯ll try to duplicate this test tomorrow? dave
toggle quoted message
Show quoted text
On Mar 23, 2025, at 7:36?AM, Oliver KI3P via groups.io <oliver@...> wrote:
? I found that the 25 MHz and 30 MHz bands oscillate, but the lower bands don't, matching what others have found.?
?
To figure out why I measured the insertion loss from the output of the PA to the input of the PA. i.e., I connect port 0 of my NanoVNA to J8, and port 1 to J7. What this measures is the magnitude of the feedback loop.
?
?
What I found is that this is a lot higher than it should be, particularly at the higher bands.
?
| 7 MHz | 14 MHz | 21 MHz | 24 MHz | 28 MHz |
|-------|--------|--------|--------|--------|
|<-80dB | -63 dB | -53 dB | -48 dB | -47 dB |
?
I would expect roughly 40dB of insertion loss each through the T/R switch and the BPF selection switch U8. Clearly, I'm not getting that. It seems that the feedback amplitude is getting high enough at the higher bands to cause oscillations. What I would like to do next is:
?
1) Repeat this measurement for a known-good version of the code as identified by Jerry. Is this feedback path amplitude different?
2) Find the reason for the change in the feedback amplitude path by examining the LPF control signals between known-good and known-bad code.
?
Unfortunately, I am tied up for the week and won't be able to do this until next weekend.
?
?
?
|
Re: Oscillations on high bands
I found that the 25 MHz and 30 MHz bands oscillate, but the lower bands don't, matching what others have found.?
?
To figure out why I measured the insertion loss from the output of the PA to the input of the PA. i.e., I connect port 0 of my NanoVNA to J8, and port 1 to J7. What this measures is the magnitude of the feedback loop.
?
?
What I found is that this is a lot higher than it should be, particularly at the higher bands.
?
| 7 MHz | 14 MHz | 21 MHz | 24 MHz | 28 MHz |
|-------|--------|--------|--------|--------|
|<-80dB | -63 dB | -53 dB | -48 dB | -47 dB |
?
I would expect roughly 40dB of insertion loss each through the T/R switch and the BPF selection switch U8. Clearly, I'm not getting that. It seems that the feedback amplitude is getting high enough at the higher bands to cause oscillations. What I would like to do next is:
?
1) Repeat this measurement for a known-good version of the code as identified by Jerry. Is this feedback path amplitude different?
2) Find the reason for the change in the feedback amplitude path by examining the LPF control signals between known-good and known-bad code.
?
Unfortunately, I am tied up for the week and won't be able to do this until next weekend.
?
?
?
|
Re: Oscillations on high bands
Good Morning Oliver,
Another issue that might be related is in the operation of the Audio Band Width Control.? When my radio is first turned on the bandwidth control works as it is supposed to.? Select any matrix button other than Menu and it continues to work correctly.? Select
the menu and exit the control now reverses direction and only moves the on-screen bandwidth bar a little when turning the control a lot.? Also, on the higher bands when trying to adjust PA out calibration with that control on one band it actually adjusts the
previous volume setting along with the output.? On the 10M band its effect is minimal and on the 6M band I cannot adjust the output at all as monitored on the scope on LPF output to the PA. Also, on the higher bands the scope does not show a clean sine wave
with PTT and is fuzzy. When the output is adjusted the sine wave gets fuzzy like it is being modulated by another signal unlike the lower bands which just increase and decrease in amplitude.? This started happening on the release of 063-1 Beta if I remember
correctly. I will check but believe it was ok on Ver 053.? It seemed the oscillation problem came up with the new calibration procedure and version the Al put out a few weeks ago.? All this is probably not related but will put it out there in case it turns
on a light bulb or two.
Rick, KN4AIE
toggle quoted message
Show quoted text
From:[email protected] on behalf of Oliver KI3P via groups.io
Sent:?Sunday, March 23, 2025 6:52 AM
To:[email protected]
Subject:?Re: [SoftwareControlledHamRadio] Oscillations on high bands
Hold the press! I was not checking the high bands. I see the oscillation on the 10m band. Back to investigating...
|
Re: Oscillations on high bands
Hold the press! I was not checking the high bands. I see the oscillation on the 10m band. Back to investigating...
|
Re: Oscillations on high bands
Hmm. I have now restored my radio to the point where it's working (mostly; sometimes display freezes get me) and I don't see the oscillation when transmitting in SSB mode. I am running commit e72d0c9d262d75e7d9a001ef6ee03427c2a3ea75 of the code posted
?
I attached a logic analyzer to J1 (LPF ACC Control) on the LPF board so I could examine the control signals being applied by the board while operating the radio. As shown in the screenshot below, they are working as expected.
?
?
So if this is a software bug, it is a bug that only manifests on some hardware. Why might this be? I wonder if it might be down to timing: there is a 300 us gap between when the BPF is switched between the RX and TX paths () and the TX/RX line is changed (line 3446 of the ino).
?
?
If, for some weird hardware reason, your RX_BPF_SEL switch takes more time to change state, then you might end up in a situation where the radio is transmitting and both the RX and TX paths are connected to the BPF, which would give you feedback. Even if the RX path is later switched away from the BPF path, the feedback signal might have already grown large enough to sustain itself despite the ~40dB attenuation increase it would take when the switch changed state.
?
So, can you try this -- put a 10 ms delay after in the ino? i.e., we want that little section of code to look like this:
?
??? setBPFPath(BPF_IN_TX_PATH);
? ? SetRF_OutAtten(powerOutSSB[currentBand]);
? ? MyDelay(10L);
? ? digitalWrite(RXTX, HIGH); ?//xmit on
?
Sorry I can't be of more help trying to debug since my radio can't replicate the fault.
?
?
?
?
|
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:
Compiling now. I did find the calls in setupSWR() that would have messed with the BPF and comment them out. Just tried it. It oscillates :(. - Jerry On Saturday, March 22nd, 2025 at 7:30 PM, Oliver KI3P via groups.io
<oliver@...> wrote:
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. Links:
------
[1] /g/SoftwareControlledHamRadio/message/33193
[2] /mt/111852470/243852
[3] /g/SoftwareControlledHamRadio/post
[4] /g/SoftwareControlledHamRadio/editsub/243852
[5]
/g/SoftwareControlledHamRadio/leave/10484476/243852/1943518115/xyzzy
|
Re: Oscillations on high bands
±õ²Ô³Ù±ð°ù±ð²õ³Ù¾±²Ô²µ¡
Dr.?William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ ? Owner - Operator Big Signal Ranch ¨C K9ZC Staunton, Illinois ? Owner ¨C Operator Villa Grand Piton - J68HZ Soufriere, St. Lucia W.I. Rent it: www.VillaGrandPiton.com
email:??bill@... ?
toggle quoted message
Show quoted text
On Mar 22, 2025, at 7:25?PM, Oliver KI3P via groups.io <oliver@...> wrote:
? 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:
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
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:
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
|
K9HZ