On Mar 24, 2025, at 7:32?PM, jerry-KF6VB <jerry@...> wrote:

?Working with the Version 66.9 T41 software.

This particular weirdness affects nobody but me....

I use four unused i/o bits to control my homebrew linear amplifier. ?They tell the amplifier what band the transceiver
is on.

These bits ( 28,29,30,31 ) were used in the V11 system to control its four-band LPF. ?There was an 80M pin, a 40M pin etc.

They are not used at all in the V12 system.

So I hooked them up to some transistor buffers and hence out to the linear.

V12 does have internal Yaesu codes in the LPF control card, but they are the wrong polarity. ?Instead of adding hardware
inverters, I just used those other four pins.

Now - with the V66.9 software, I am unable to write to those pins! ?The linear stays at its default - 6M. ?The reason
for that particular default is that it minimizes the risk of transmitting on the wrong band. ?If you use an LPF that is
too high, you run the risk of annoying the FCC. ?If OTOH you transmit through an LPF that's too low, you run the risk of
frying the expensive LDMOS final. ?I do have protection against that in the linear, but I am a "belt & suspenders" guy...

Back to the problem: ?I have verified that the code to write to those pins is being executed. ?ALSO, I wrote separate code at the top of loop() to write to them. ?No joy, no output.

BUT - I wrote a throwaway sketch - not a radio at all - to just write to those pins - actually an incrementing count. ?Yup, they work fine. ?And the linear cycles through its bands.

SO; ?Something in the code is preventing me from writing those pins. ?Gotta be one of two things: 1. ?Something else is writing to them. ?or 2) ?Something is pinMode-ing them to INPUTs.

Darned if I can find it though. ?There are some legacy places where those pins are written, but I'm pretty sure I found them all. ?It has worked on other versions, just not this one.

????????????????- Jerry, KF6VB

On Mar 24, 2025, at 9:14?PM, ken WA2MZE <wa2mze@...> wrote:

?Years ago I worked for Niles Audio, and we produced a product that used plug in cards on a short bus.? The interconnect was via SPI between AVR ATmega128 and ATmega32 processors.? The bus had a buffer at the master side (mega128), the mega32 mcus on the cards were connected unbuffered.? The bus had the usual 3 SPI signals plus one? CS for each of the cards, IIRC there were a max of 4 cards on the bus.? We never had any issues with communication on the bus, I don't recall what the clock speed was, I think it was around 500khz.

On Mar 25, 2025, at 9:19?AM, Greg KF5N via groups.io <greg.electricity@...> wrote:

?

So that would be a reason for the isolation to degrade versus increasing frequency.

Because the module has common ground inductances on the input and output.
Just a SWAG here, it's hard to tell without having a good visualization of the hardware.

But it's a common problem with any RF thing which has an input and an output and connectors.

?

--

73 Greg KF5N

On Mar 25, 2025, at 8:45?AM, Greg KF5N via groups.io <greg.electricity@...> wrote:

?

This switch is a plug-in module?

--

73 Greg KF5N

Hi Oliver, where is the schematic of the TR switch?

I would like to see the circuit topology.? A few decades ago(!) I was designing TR switches and I'm curious about this one.

?

--

73 Greg KF5N

I ran some isolation tests today. Below is the first page of my report (attached).

I have had an oscillation at ~35MHz in the K9HZ 20-watt power amp in my T41 V12 (SW ver 66.4) when I press PTT in the higher bands. It appears to be caused by low isolation between the PA Output, J8 and PA Input, J7, on the LPF-Control board. Below are several plots from my NanoVNA showing the isolation between 21MHz and 25MHz. On my two systems, the feedback oscillations only occur above 22MHz.

The first plot shows the isolation with C18 removed from the PCB. This capacitor is the path between the transmit and receive RF switching circuits on the LPF-Control board. So is C7, but I didn’t bother removing that. Isolation is better than 65dB with C18 removed.

The next two plots show the isolation at 25MHz in the CW mode (key down) and SSB mode (PTT) engaged. Isolation is in the 35dB range. Additionally, the poor return loss in the SSB mode indicates that the LPF is not being connected properly.

The next plot shows isolation at 50MHz in SSB mode with PTT engaged. This is so bad (<25dB) that I must have a bad RF switch.

The final two plots are done with version 50.0 at 21 and 25MHz. Performance in CW and SSB is identical.

Conclusions:

· I may have a hardware problem or a test equipment problem. Could someone else duplicate this test?

· There is a software change in how CW and SSB are controlled between version 50.0 and 66.4, but that bug doesn’t seem to affect isolation.

On Sun, Mar 23, 2025 at 7:36?AM Oliver KI3P via <oliver=[email protected]> 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.