Investigate power (CW) appearing on rx only ports

ramdor commented 11 months ago

This may or may not be related. In addition to a receive only antenna (Beverage) that I attach to port RX2, I also attach a preamplified and multi coupled Shared Apex Loop on Ant Port 3, and my primary transmit output is on Ant Port 1. (I leave Port 2 disconnected as an isolation boost). I discovered when using CWX in break in or semi breakin mode, my transmit power appears on Ant Port 3, for a split second as the internal relays are switching. Consequently, this power burst on what is designated as a "do not transmit" Antenna port, has destroyed a strisberg active multicoupler. This all came together for me, while testing the Pure Signal bug with the rest of the gang. I ultimately determined that RF was appearing on the undesired Ant Port by watching it with a dedicated watt meter. This only happens in CW mode as the internal TRX clack back and forth with semi break in delays of approx 250 ms.

I created a video of the phenomena and will post if none of this makes sense.

Originally posted by @nj2us in https://github.com/ramdor/Thetis/issues/226#issuecomment-1777149557

nj2us commented 11 months ago

https://www.youtube.com/watch?v=mxWFznqrAvI

A you tube video that demonstrates the anomoly.

Jeff NJ2US

ramdor commented 11 months ago

Fantastic video showing the issue @nj2us

Investigation

1) CWX form uses NetworkIO.SetCWX() to turn CW on/off on the TRX. The cwx form code uses threading so this call is happening from various threads. No configuration of alex/antennas are made.

2) A thread called PollPTT in console.cs is running with a 1 ms delay loop looking for a number of ptt states, one of which is PTT from the radio using NetworkIO.nativeGetDotDashPTT() which is set when NetworkIO.SetCWX is used in 1) . This sets the front end MOX state only if QSKEnabled is not set.

3) On mox change in console.cs, HdwMOXChanged() is eventually called with a call to Alex.UpdateAlexAntSelection() updating any necessary antenna selections with NetworkIO.SetAntBits()

Issues:

1) There is potential for a delay between 1) + 2) . Consequently 3) will be delayed sometime after 1) is already outputting power

2) QSK will never update the mox state, so no calls to Alex will be made to setup SetAntBits. QSQ is however disabled if TX/RX antennas are different.

nj2us commented 11 months ago

Here is a more detailed video (as requested by Richie) showing status of RF on all ports:

https://www.youtube.com/watch?v=o6MuSHUVJ8A

nj2us commented 11 months ago

Ramdor asked if I had a clue as to how long this may have been an issue, and I answered thusly,

Richie, it's been an issue for several years, as I have POPPED 4 or 5 of those Stridsberg active multi coupler on Port 2 and Port 3, and never understood why until this Pure Signal anomaly showed up, causing me to investigate further, that maybe I was blowing these devices up through the Output port and not the input port on the Multicoupler! I suspect, very few users attach antennas with electronic components on ports 2 or 3, and if they have, maybe they didnt know that couplers and preamps are blowing because RF is showing up where they least suspect. If you figure that most users may be attaching passive antennas that would igore or radiate the unwanted RF, the OP would probably never realize it.

Jeff NJ2US

ramdor commented 11 months ago

Yeah ramdor/me same ;) It does do it here, but only when using CWX. I do not have a key so cant easily test that, but yes it does put power out to an antenna port that is specified as RX only. This may be a firmware thing, not entirely sure. Will have to get the others involved who know more about these things. A warning should be put out tbh.

Roturbo commented 11 months ago

Hello,

i have a Anan 100D and maybe is not related, but on some occasions i notice one relay activated or released inside the Anan most during TX operation and less on RX.

Most of the time i use SSB and notice this, but once on FM i heard very clear on a audio pause and i make a new pause trying to see if anything have change on power swr etc.

Since this doesn´t present any changes on TX i didn´t care and i have upload the firmware again to see if it goes way but from time to time some relay is activated, reading this topic i remember to post it just in case other have same situation and also want to report.

Regards

ramdor commented 11 months ago

I have decided to undo the changes I made Jeff, until we formulate a better fix. The issue is caused because SetCWX used by the cwx form, and serial pin keying causes the radio to output power before the hardware antenna ports etc have been configured.

The hardware is configured after Thetis detects a cw hardware ptt change, and this obviously will be after power is coming out because of the SetCWX.

A new branch will be created at some point to work on this alone.

ramdor commented 11 months ago

didnt want to close this, oops.

w3ub commented 11 months ago

I ran an RX antenna a couple of years ago, and burnt out the MOSFET in my RX preamplifier about four times, always in CW mode ... I think this was the cause. Doug

RdWing commented 11 months ago

I believe this is the same issue I was seeing with my Mk 2.5 7000. See post on the apache forum from last October 2022.

Note, I am specifically speaking about power being detected (and actually transmitted), on other antenna ports.

I don't think I was using serial port keying at that time.

ramdor commented 11 months ago

@RdWing yes, this is that is exactly this same issue. If you watch Jeff NJ2US excellent vids further up this thread they show the same issue.

n1gp commented 11 months ago

I have verified this also happens on PiHPSDR. It happens on an ANAN-G2. It happens using an Iambic key plugged in to the front, and also with a straight key.

Seems to be on the transition from RX->TX

dl1ycf commented 11 months ago

I think I understand what's happening.

Here I refer to the Anan-7000 PA board but the situation is the same for other boards.

Suppose Ant3 is used for RX and Ant1 for TX.

Upon a RX/TX transition, two relays are switched:

K3 which is closed during RX opens (disconnects Ant3 from T/R circuit) K1 which is open during RX closes (connects Ant1 to T/R circuit)

Relay switching times are relatively slow, of the order 20 msec

If no RF appears quite fast after switching time (and since the T/R circuit in Anan-7000 is with diodes it is likely) then some msec of RF output may still find their way to Ant3 since K3 is not completely opened.

This is in particular a problem with "CW handled in Radio" for the following reason:

you touch the CW paddle
the FPGA puts the radio into TX mode and sets the "PTT" flag
PTT flag is sent to host PC and CW transmission starts
host PC slews down receivers and slews up TX, and then it changes the relays.

I do not see how to solve the problem from the software side in this case, since the RX/TX switching as well as the RF pulse formation is entirely done in the FPGA. So the SDR program is informed about the T/R switch while it is already going on and therefore the commands to change the relays comes late (even if you do it in the SDR program immediately after receiving the "PTT on" in the HPSDR data stream.

If the RX/TX switch is initiated in the SDR program, one can certainly include a delay between antenna switching and setting PTT, but this case is not so dangerous anyway since the TX IQ samples have to make their way through the buffers. The "CW handled in Radio" case it where I have to scratch my head.

The "CWX" case in Thetis should be manageable, since the SDR program sends the "PTT on", doesn't it?

DL1YCF

dl1ycf commented 11 months ago

In my preferred CW setup the problem is much less likely to appear:

use and external (WinKey) keyer
connect Key and PTT of the keyer with the CW and PTT in jacks
use a "PTT lead in" delay of 150 msec

This way, the radio is put into TX mode 150msec before generating RF, and this is usually enough to inform the SDR program that we are going TX and the SDR program then has time to switch the Ant1/Ant3 relays.

n1gp commented 11 months ago

This takes another interesting twist if you change from SEMI to QSK in Thetis. The RF follows the RX Antenna (this case 3) and no RF output on the TX Antenna (this case 1).

laurencebarker commented 11 months ago

Hi Rick

QSK can’t operate with different antennas. I would have expected it to refuse to enter QSK state with split antennas. Thetis never gets to know it is in TX, so never changes the antennas. So the condition you found is definitely bad!

I suspect a full solution will need protocol 2 message change to tell the FPGA the required antenna for TX and RX, so it can initiate instant changeover during the delay period. But I doubt we want to go that far!

In semi breakin antenna changeover will be delayed because it requires a message exchange to Thetis and from Thetis before the relays will be driven to the TX state. Increasing the CW delay may help (Thetis sets 7ms before the CW ramp starts, and the antenna change will definitely still be in progress).

Laurence Barker G8NJJ

@.***

From: Rick Koch @.> Sent: Thursday, November 2, 2023 5:38 PM To: ramdor/Thetis @.> Cc: Subscribed @.***> Subject: Re: [ramdor/Thetis] Investigate power (CW) appearing on rx only ports (Issue #228)

This takes another interesting twist if you change from SEMI to QSK in Thetis. The RF follows the RX Antenna (this case 3) and no RF output on the TX Antenna (this case 1).

— Reply to this email directly, view it on GitHub https://github.com/ramdor/Thetis/issues/228#issuecomment-1791240701 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AEXTXZ6PRQVKCXIY5PKZE7LYCPLAJAVCNFSM6AAAAAA6NXPS42VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJRGI2DANZQGE . You are receiving this because you are subscribed to this thread. https://github.com/notifications/beacon/AEXTXZZNZMXEO46R6FTSZJLYCPLAJA5CNFSM6AAAAAA6NXPS42WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTKYQU72.gif Message ID: @. @.> >

nj2us commented 11 months ago

My band aid approach to masking this problem is to attach my "Active" receive antenna to the "EXT1" port, and then set Receive Antenna Control to EXT1. I couldnt find any operational mode that cause Transmit RF to escape through EXT1. The only functionality lost is that you can't do a fast toggle between TX and RX antennas on the VFO control/Band Stack window in the GUI. Maybe the EXT1 port can be manipulated in software to allow quick toggle between EXT1 and Transmit Antennas.

n4py commented 9 months ago

I would think setting the CW key down value to 15 msec would solve this.

n4py commented 9 months ago

So I just got an Anan 8000DLE. I can confirm this is a serious problem. I did the following experiment. 1) I connected my LP-500 watt meter to antenna 3. 2) I put a dummy load on antenna 1. 3) I set antenna 1 for xmit and antenna 3 for receive. 4) I transmitted 100 watts with my paddles via an external keyer.

Many times I saw a brief 100 watts on antenna 3. Also saw a brief high SWR several times. This also failed in the same way sending CW via an external software program sending KY commands.

So there is definitely a bad timing problem here. I had CW key down delay set at 15 msec. I was using semi breaking at 250 msec delay.

Carl N4PY

mdblack98 commented 9 months ago

You'll see a big warning about that on the release page. Hopefully somebody is working on this as this is damaging equipment and giving Apache Labs a bad name.

https://github.com/ramdor/Thetis/releases/

Mike W9MDB

On Wednesday, January 3, 2024 at 08:09:59 AM CST, n4py @.***> wrote:

So I just got an Anan 8000DLE. I can confirm this is a serious problem. I did the following experiment.

1. I connected my LP-500 watt meter to antenna 3. 2. I put a dummy load on antenna 1. 3. I set antenna 1 for xmit and antenna 3 for receive. 4. I transmitted 100 watts with my paddles via an external keyer.

Many times I saw a brief 100 watts on antenna 3. Also saw a brief high SWR several times. This also failed in the same way sending CW via an external software program sending KY commands.

So there is definitely a bad timing problem here. I had CW key down delay set at 15 msec. I was using semi breaking at 250 msec delay.

Carl N4PY

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>

w-u-2-o commented 9 months ago

It doesn't appear to be a hardware problem, and if that's indeed the case then Apache is not to blame.

All relays are controlled by software and firmware. When they switch or don't switch is up to the code.

On Wed, Jan 3, 2024 at 9:16 AM Michael Black @.***> wrote:

You'll see a big warning about that on the release page. Hopefully somebody is working on this as this is damaging equipment and giving Apache Labs a bad name.

https://github.com/ramdor/Thetis/releases/

Mike W9MDB

On Wednesday, January 3, 2024 at 08:09:59 AM CST, n4py @.***> wrote:

So I just got an Anan 8000DLE. I can confirm this is a serious problem. I did the following experiment.
1. I connected my LP-500 watt meter to antenna 3.

2. I put a dummy load on antenna 1.

3. I set antenna 1 for xmit and antenna 3 for receive.

4. I transmitted 100 watts with my paddles via an external keyer.
Many times I saw a brief 100 watts on antenna 3. Also saw a brief high SWR several times. This also failed in the same way sending CW via an external software program sending KY commands.

So there is definitely a bad timing problem here. I had CW key down delay set at 15 msec. I was using semi breaking at 250 msec delay.

Carl N4PY

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/ramdor/Thetis/issues/228#issuecomment-1875439831, or unsubscribe https://github.com/notifications/unsubscribe-auth/AX4YGS5RLAPM3OQVIFA3SWDYMVR23AVCNFSM6AAAAAA6NXPS42VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZVGQZTSOBTGE . You are receiving this because you commented.Message ID: @.***>

mdblack98 commented 9 months ago

By definition a relay is hardware. However you are correct that control of them is firmware.

However, I would maintain this is the radio's firmware that is allowing power to go out an unselected relay.

I don' think it's Thetis that is telling the rig to turn off the RX antenna while transmitting, is it? I think that's the rig's responsibility. Software should never be allowed to do such things as to cause hardware damage.

Also it's a matter of port isolation during transmit. You should NOT be able to send much power out a 2nd unselected port for any length of time. It's a matter of relay settling to disable the RX port right now. So is the power being seen coming from port cross over or the RX antenna seeing the power being transmitted?

I was just watching VE2DX's video and him showing 80dB of port isolation on his antenna switch.

https://www.youtube.com/watch?v=Sav6k4v9mT4

Mike W9MDB

On Wednesday, January 3, 2024 at 08:25:26 AM CST, w-u-2-o @.***> wrote:

It doesn't appear to be a hardware problem, and if that's indeed the case then Apache is not to blame.

All relays are controlled by software and firmware. When they switch or don't switch is up to the code.

On Wed, Jan 3, 2024 at 9:16 AM Michael Black @.***> wrote:

You'll see a big warning about that on the release page. Hopefully somebody is working on this as this is damaging equipment and giving Apache Labs a bad name.

https://github.com/ramdor/Thetis/releases/

Mike W9MDB

On Wednesday, January 3, 2024 at 08:09:59 AM CST, n4py @.***> wrote:

So I just got an Anan 8000DLE. I can confirm this is a serious problem. I did the following experiment.

I connected my LP-500 watt meter to antenna 3.

I put a dummy load on antenna 1.

I set antenna 1 for xmit and antenna 3 for receive.

I transmitted 100 watts with my paddles via an external keyer.

Many times I saw a brief 100 watts on antenna 3. Also saw a brief high SWR several times. This also failed in the same way sending CW via an external software program sending KY commands.

So there is definitely a bad timing problem here. I had CW key down delay set at 15 msec. I was using semi breaking at 250 msec delay.

Carl N4PY

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/ramdor/Thetis/issues/228#issuecomment-1875439831, or unsubscribe https://github.com/notifications/unsubscribe-auth/AX4YGS5RLAPM3OQVIFA3SWDYMVR23AVCNFSM6AAAAAA6NXPS42VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZVGQZTSOBTGE . You are receiving this because you commented.Message ID: @.***>

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

dl1ycf commented 9 months ago

If it comes to the hardware, ANT 3 is not an "RX only port" (it is in the TX chain). You have bad luck since for the Anan-8000, only the "PS Input" port is "RX only" (the "Ext1" and "Xvrt In", present in the Anan-7000, have been sacrificed).

One can however (nearly) solve the problem in the SDR program. I have done so in piHPSDR, so you can use that program. The Thetis people think it must be solved in the firmware. While it is not unreasonable to demand this, it will take time.

Am 03.01.2024 um 15:09 schrieb n4py @.***>:

So I just got an Anan 8000DLE. I can confirm this is a serious problem. I did the following experiment. • I connected my LP-500 watt meter to antenna 3. • I put a dummy load on antenna 1. • I set antenna 1 for xmit and antenna 3 for receive. • I transmitted 100 watts with my paddles via an external keyer. Many times I saw a brief 100 watts on antenna 3. Also saw a brief high SWR several times. This also failed in the same way sending CW via an external software program sending KY commands. So there is definitely a bad timing problem here. I had CW key down delay set at 15 msec. I was using semi breaking at 250 msec delay. Carl N4PY — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

mdblack98 commented 9 months ago

I just checked the code and I see this

Alex.getAlex().setRxOnlyAnt(band, (byte)ant);

This indicates the RX only selection is controlled by Alex.c

This appears to be controlled in UpdateAlexAntSelection

I see a SendHighPriority which no doubt has some meaning.

Also see SetAntBits but not GetAntBits where one could check status.

Is the handling of this socket request asynchronous in the rig? Do we need a delay after SetAntBits?

Mike W9MDB

laurencebarker commented 9 months ago

Hi Mike

Actually yes: it is Thetis telling it to turn off the RX antenna and select the TX antenna.

I did write down the sequence hen this was first raised, but following a PC failure I’ve lost my entire email history so I’ll have to do this again.

In QSK mode: Thetis isn’t involved. QSK should only be selected if RX antenna = TX antenna

With no break-in: Thetis tells the hardware to enter TX mode with TX antenna BEFORE key down, so the issue doesn’t arise.

That leaves semi-break in CW, which is where the issue occurs. The issue happens because protocol 2 has a field to select the antenna in use (ANT1-3); it does not have separate data for RX antenna and TX antenna. Thetis tell the firmware which antenna to use; and it needs to send a message to change over between TX and RX antennas if they are different.

In the FPGA firmware, beginning in an RX state:

The user presses the key down
The keyer counts a delay before taking any action (Thetis default I think was 7ms)
The keyer enters TX mode, and signals Thetis
The keyer ramps up the CW power level over around 5ms
When a high priority message arrives from Thetis, the firmware selects the TX antenna

Thetis receives the message that the key is down, selects its TX state and sends a message a while later to select the correct TX antenna.

A “thorough” fix would be to extend the protocol 2 message to send RX antenna and TX antenna, so the firmware can decide immediately which to use. BUT that would require protocol 2 firmware change. Christoph has implemented a software-only solution that enabled piHPSDR to achieve a much more rapid transition, and with a longer “delay before starting to TX” this does seem to solve the problem.

Laurence Barker G8NJJ

@.***

From: Michael Black @.> Sent: Wednesday, January 3, 2024 2:51 PM To: ramdor/Thetis @.> Cc: Laurence Barker @.>; Comment @.> Subject: Re: [ramdor/Thetis] Investigate power (CW) appearing on rx only ports (Issue #228)

By definition a relay is hardware. However you are correct that control of them is firmware.

However, I would maintain this is the radio's firmware that is allowing power to go out an unselected relay.

I don' think it's Thetis that is telling the rig to turn off the RX antenna while transmitting, is it? I think that's the rig's responsibility. Software should never be allowed to do such things as to cause hardware damage.

Also it's a matter of port isolation during transmit. You should NOT be able to send much power out a 2nd unselected port for any length of time. It's a matter of relay settling to disable the RX port right now. So is the power being seen coming from port cross over or the RX antenna seeing the power being transmitted?

I was just watching VE2DX's video and him showing 80dB of port isolation on his antenna switch.

https://www.youtube.com/watch?v=Sav6k4v9mT4

Mike W9MDB

On Wednesday, January 3, 2024 at 08:25:26 AM CST, w-u-2-o @. <mailto:@.> > wrote:

It doesn't appear to be a hardware problem, and if that's indeed the case then Apache is not to blame.

All relays are controlled by software and firmware. When they switch or don't switch is up to the code.

On Wed, Jan 3, 2024 at 9:16 AM Michael Black @. <mailto:@.> > wrote:

You'll see a big warning about that on the release page. Hopefully somebody is working on this as this is damaging equipment and giving Apache Labs a bad name.

https://github.com/ramdor/Thetis/releases/

Mike W9MDB

On Wednesday, January 3, 2024 at 08:09:59 AM CST, n4py @. <mailto:@.> > wrote:

So I just got an Anan 8000DLE. I can confirm this is a serious problem. I did the following experiment.

I connected my LP-500 watt meter to antenna 3.

I put a dummy load on antenna 1.

I set antenna 1 for xmit and antenna 3 for receive.

I transmitted 100 watts with my paddles via an external keyer.

Many times I saw a brief 100 watts on antenna 3. Also saw a brief high SWR several times. This also failed in the same way sending CW via an external software program sending KY commands.

So there is definitely a bad timing problem here. I had CW key down delay set at 15 msec. I was using semi breaking at 250 msec delay.

Carl N4PY

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @. <mailto:@.> >

— Reply to this email directly, view it on GitHub https://github.com/ramdor/Thetis/issues/228#issuecomment-1875439831, or unsubscribe https://github.com/notifications/unsubscribe-auth/AX4YGS5RLAPM3OQVIFA3SWDYMVR23AVCNFSM6AAAAAA6NXPS42VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZVGQZTSOBTGE . You are receiving this because you commented.Message ID: @. <mailto:@.> >

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @. <mailto:@.> >

— Reply to this email directly, https://github.com/ramdor/Thetis/issues/228#issuecomment-1875495570 view it on GitHub, or https://github.com/notifications/unsubscribe-auth/AEXTXZ7MUDEWECORCQ73RR3YMVV67AVCNFSM6AAAAAA6NXPS42VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZVGQ4TKNJXGA unsubscribe. You are receiving this because you commented. https://github.com/notifications/beacon/AEXTXZ77I75ZE2PECHWAHQDYMVV67A5CNFSM6AAAAAA6NXPS42WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTPZHFJE.gif Message ID: < @.> @.>

mdblack98 commented 9 months ago

In my case I know what happened to me. I don't normally do CW. So I was happily operating along and then started working on improvements to FLDigi for the frequency measurement test. During that time I started doing CW with Thetis and I now know that's when it blew out my Pixel Pro preamplifier. At the time I didn't know that....thought it was just time for the amplifier to go...got it repaired and it blew a 2nd time (still testing CW at my station). I now know not to do CW with my RX only antenna connected.

This should be a high priority to get fixed in Protocol 2.

Mike W9MDB

On Wednesday, January 3, 2024 at 09:27:00 AM CST, Laurence Barker @.***> wrote:

Hi Mike

Actually yes: it is Thetis telling it to turn off the RX antenna and select the TX antenna.

I did write down the sequence hen this was first raised, but following a PC failure I’ve lost my entire email history so I’ll have to do this again.

In QSK mode: Thetis isn’t involved. QSK should only be selected if RX antenna = TX antenna

With no break-in: Thetis tells the hardware to enter TX mode with TX antenna BEFORE key down, so the issue doesn’t arise.

That leaves semi-break in CW, which is where the issue occurs. The issue happens because protocol 2 has a field to select the antenna in use (ANT1-3); it does not have separate data for RX antenna and TX antenna. Thetis tell the firmware which antenna to use; and it needs to send a message to change over between TX and RX antennas if they are different.

In the FPGA firmware, beginning in an RX state:

The user presses the key down
The keyer counts a delay before taking any action (Thetis default I think was 7ms)
The keyer enters TX mode, and signals Thetis
The keyer ramps up the CW power level over around 5ms
When a high priority message arrives from Thetis, the firmware selects the TX antenna

Thetis receives the message that the key is down, selects its TX state and sends a message a while later to select the correct TX antenna.

A “thorough” fix would be to extend the protocol 2 message to send RX antenna and TX antenna, so the firmware can decide immediately which to use. BUT that would require protocol 2 firmware change. Christoph has implemented a software-only solution that enabled piHPSDR to achieve a much more rapid transition, and with a longer “delay before starting to TX” this does seem to solve the problem.

Laurence Barker G8NJJ

@.***

From: Michael Black @.> Sent: Wednesday, January 3, 2024 2:51 PM To: ramdor/Thetis @.> Cc: Laurence Barker @.>; Comment @.> Subject: Re: [ramdor/Thetis] Investigate power (CW) appearing on rx only ports (Issue #228)

By definition a relay is hardware. However you are correct that control of them is firmware.

However, I would maintain this is the radio's firmware that is allowing power to go out an unselected relay.

I don' think it's Thetis that is telling the rig to turn off the RX antenna while transmitting, is it? I think that's the rig's responsibility. Software should never be allowed to do such things as to cause hardware damage.

Also it's a matter of port isolation during transmit. You should NOT be able to send much power out a 2nd unselected port for any length of time. It's a matter of relay settling to disable the RX port right now. So is the power being seen coming from port cross over or the RX antenna seeing the power being transmitted?

I was just watching VE2DX's video and him showing 80dB of port isolation on his antenna switch.

https://www.youtube.com/watch?v=Sav6k4v9mT4

Mike W9MDB

On Wednesday, January 3, 2024 at 08:25:26 AM CST, w-u-2-o @. <mailto:@.> > wrote:

It doesn't appear to be a hardware problem, and if that's indeed the case then Apache is not to blame.

All relays are controlled by software and firmware. When they switch or don't switch is up to the code.

On Wed, Jan 3, 2024 at 9:16 AM Michael Black @. <mailto:@.> > wrote:

You'll see a big warning about that on the release page. Hopefully somebody is working on this as this is damaging equipment and giving Apache Labs a bad name.

https://github.com/ramdor/Thetis/releases/

Mike W9MDB

On Wednesday, January 3, 2024 at 08:09:59 AM CST, n4py @. <mailto:@.> > wrote:

So I just got an Anan 8000DLE. I can confirm this is a serious problem. I did the following experiment.

I connected my LP-500 watt meter to antenna 3.

I put a dummy load on antenna 1.

I set antenna 1 for xmit and antenna 3 for receive.

I transmitted 100 watts with my paddles via an external keyer.

Many times I saw a brief 100 watts on antenna 3. Also saw a brief high SWR several times. This also failed in the same way sending CW via an external software program sending KY commands.

So there is definitely a bad timing problem here. I had CW key down delay set at 15 msec. I was using semi breaking at 250 msec delay.

Carl N4PY

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @. <mailto:@.> >

— Reply to this email directly, view it on GitHub https://github.com/ramdor/Thetis/issues/228#issuecomment-1875439831, or unsubscribe https://github.com/notifications/unsubscribe-auth/AX4YGS5RLAPM3OQVIFA3SWDYMVR23AVCNFSM6AAAAAA6NXPS42VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZVGQZTSOBTGE . You are receiving this because you commented.Message ID: @. <mailto:@.> >

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @. <mailto:@.> >

— Reply to this email directly, https://github.com/ramdor/Thetis/issues/228#issuecomment-1875495570 view it on GitHub, or https://github.com/notifications/unsubscribe-auth/AEXTXZ7MUDEWECORCQ73RR3YMVV67AVCNFSM6AAAAAA6NXPS42VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZVGQ4TKNJXGA unsubscribe. You are receiving this because you commented. https://github.com/notifications/beacon/AEXTXZ77I75ZE2PECHWAHQDYMVV67A5CNFSM6AAAAAA6NXPS42WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTPZHFJE.gif Message ID: < @.> @.>

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

dl1ycf commented 9 months ago

Michael, you miss the point.

If CW is handled in radio, and the key is pressed, then the radio goes TX and tells the SDR program about it. The SDR program can then react, but this is possibly too late.

Am 03.01.2024 um 16:16 schrieb Michael Black @.***>:

I just checked the code and I see this

Alex.getAlex().setRxOnlyAnt(band, (byte)ant);

This indicates the RX only selection is controlled by Alex.c

This appears to be controlled in UpdateAlexAntSelection

I see a SendHighPriority which no doubt has some meaning.

Also see SetAntBits but not GetAntBits where one could check status.

Is the handling of this socket request asynchronous in the rig? Do we need a delay after SetAntBits?

Mike W9MDB — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

dl1ycf commented 9 months ago

This should be a high priority to get fixed in Protocol 2.

Exactly, a solution is easy in the SDR program, provided that the protocol defines what one should do. One must have two "Alex words" in the protocol, one for RX and one for TX. Then, the TX settings can be sent to the radio in advance, and the firmware restores these setting (when doing CW) before going TX.

mdblack98 commented 9 months ago

OK...so let's fix the firmware....

On Wednesday, January 3, 2024 at 10:13:50 AM CST, dl1ycf @.***> wrote:

Michael, you miss the point.

If CW is handled in radio, and the key is pressed, then the radio goes TX and tells the SDR program about it. The SDR program can then react, but this is possibly too late.

Am 03.01.2024 um 16:16 schrieb Michael Black @.***>:

I just checked the code and I see this

Alex.getAlex().setRxOnlyAnt(band, (byte)ant);

This indicates the RX only selection is controlled by Alex.c

This appears to be controlled in UpdateAlexAntSelection

I see a SendHighPriority which no doubt has some meaning.

Also see SetAntBits but not GetAntBits where one could check status.

Is the handling of this socket request asynchronous in the rig? Do we need a delay after SetAntBits?

Mike W9MDB — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

n1gp commented 9 months ago

I will take this on for putting a fix in to the firmware. I'll look at the current protocol 2 specifications and try to find the best approach to adding the necessary updates for this issue. I'll update here as well as send out an email to all here and others I think should have input.

laurencebarker commented 9 months ago

I'm already looking at the necessary G2 firmware change but that has the luxury that a processor can easily move the bits around.There are 80 sets of alex words in the high priority message. Could we use one of those eg the one that has 16 bits used for RX2 filter settings? Or just 3 unused bits somewhere for TX ant1-3?Backward compatibility might be an issue.Laurence BarkerSent from my Galaxy -------- Original message --------From: Rick Koch @.> Date: 03/01/2024 21:37 (GMT+00:00) To: ramdor/Thetis @.> Cc: Laurence Barker @.>, Comment @.> Subject: Re: [ramdor/Thetis] Investigate power (CW) appearing on rx only ports (Issue #228) I will take this on for putting a fix in to the firmware. I'll look at the current protocol 2 specifications and try to find the best approach to adding the necessary updates for this issue. I'll update here as well as send out an email to all here and others I think should have input.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

n1gp commented 9 months ago

I was looking at using 3 unused bits that are common in each of the Alex0 words for all ANAN boards. Give them to the Tx ANT and use the previous ANT 1-3 for Rx. That would be bits 7,16,17 for Tx Ant and the already assigned bits 24,25,26 for Rx Ant. I think that mitigates the Backward compatibility issues since previous hardware doesn't care about those bits?

Then that would apply to all 8 of the Alex's, although I doubt there are any more than 2 in use using protocol 2.

Updated Doc for reference:

openHPSDR Ethernet Protocol v3.13.docx

dl1ycf commented 9 months ago

Nope. There is nothing to fix in the firmware.

The firmware is OK if it behaves according to the protocol. It is the protocol that needs be extended, that is the problem.

Am 03.01.2024 um 17:16 schrieb Michael Black @.***>:

OK...so let's fix the firmware....

On Wednesday, January 3, 2024 at 10:13:50 AM CST, dl1ycf @.***> wrote:

Michael, you miss the point.

If CW is handled in radio, and the key is pressed, then the radio goes TX and tells the SDR program about it. The SDR program can then react, but this is possibly too late.

Am 03.01.2024 um 16:16 schrieb Michael Black @.***>:

I just checked the code and I see this

Alex.getAlex().setRxOnlyAnt(band, (byte)ant);

This indicates the RX only selection is controlled by Alex.c

This appears to be controlled in UpdateAlexAntSelection

I see a SendHighPriority which no doubt has some meaning.

Also see SetAntBits but not GetAntBits where one could check status.

Is the handling of this socket request asynchronous in the rig? Do we need a delay after SetAntBits?

Mike W9MDB — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

dl1ycf commented 9 months ago

It does not make much sense to (just) extend the Alex word, since in principle each bit here drives its "own" relay.

What one needs is that the firmware automatically changes TX ANT 1/2/3 when going TX.

If you want to put this into the Alex word, you actually need FOUR "unused bits", one flagging that the other three are valid (backwards compatibility problem).

I think one rather should look at the HighPrio packet. This has eight 32-bit Alex words (Alex7 ... Alex0) at position 1404 ... 1435.

Here is ample space e.g. re-naming them

Alex3TX, ..., Alex0TX, Alex3, ..., Alex0

Alex?TX will normally be zero (for currently existing SDR programs), and the firmware could then do then following:

If (transmitting && Alex0TX != 0) { clock out Alex0TX word to Alex0 shift register } else { clock out Alex0 word to Alex0 shift register }

and the same for Alex1. Up do now, Alex2-7 are unused anyway so "restricting" the protocol from 8 to 4 ALEX banks is probably OK.

Then (and only then), SDR programs can start to update their "Alex logic" and populate more bits when sending the HighPrio packet.

Just my $0.02,

Christoph DL1YCF.

Am 03.01.2024 um 23:10 schrieb Rick Koch @.***>:

I was looking at using 3 unused bits that are common in each of the Alex0 words for all ANAN boards. Give them to the Tx ANT and use the previous ANT 1-3 for Rx. Updated Doc for reference: openHPSDR Ethernet Protocol v3.13.docx — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

laurencebarker commented 9 months ago

A better description might be "modify the firmware to implement a revised definition of the protocol" and that is now happening.Laurence BarkerSent from my Galaxy -------- Original message --------From: dl1ycf @.> Date: 04/01/2024 08:14 (GMT+00:00) To: ramdor/Thetis @.> Cc: Laurence Barker @.>, Comment @.> Subject: Re: [ramdor/Thetis] Investigate power (CW) appearing on rx only ports (Issue #228) Nope. There is nothing to fix in the firmware.

The firmware is OK if it behaves according to the protocol.

It is the protocol that needs be extended, that is the problem.

Am 03.01.2024 um 17:16 schrieb Michael Black @.***>:

OK...so let's fix the firmware....

On Wednesday, January 3, 2024 at 10:13:50 AM CST, dl1ycf @.***> wrote:

Michael, you miss the point.

If CW is handled in radio, and the key is pressed, then the radio

goes TX and tells the SDR program about it. The SDR program

can then react, but this is possibly too late.

Am 03.01.2024 um 16:16 schrieb Michael Black @.***>:

I just checked the code and I see this

Alex.getAlex().setRxOnlyAnt(band, (byte)ant);

This indicates the RX only selection is controlled by Alex.c

This appears to be controlled in UpdateAlexAntSelection

I see a SendHighPriority which no doubt has some meaning.

Also see SetAntBits but not GetAntBits where one could check status.

Is the handling of this socket request asynchronous in the rig?

Do we need a delay after SetAntBits?

Mike W9MDB

—

Reply to this email directly, view it on GitHub, or unsubscribe.

You are receiving this because you commented.Message ID: @.***>

—

Reply to this email directly, view it on GitHub, or unsubscribe.

You are receiving this because you commented.Message ID: @.***>

—

Reply to this email directly, view it on GitHub, or unsubscribe.

You are receiving this because you commented.Message ID: @.***>

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

laurencebarker commented 9 months ago

Hi RickAs a suggestion a slight change: use bits 16 to 18 for tx ant 1 to 3. Use bit 7=1 if tx ant bits are being used.This assumes that existing thetis/pihpsdr sets unused bits to zero. This would allow the modified hardware to work with previous versions of the sdr client programs that dont support the tx ant bits. Otherwise if people havent updated thetis/pihpsdr we get a loss of control for tx! Probably no ant selected and trashed final transistors.Laurence BarkerSent from my Galaxy -------- Original message --------From: Rick Koch @.> Date: 03/01/2024 22:10 (GMT+00:00) To: ramdor/Thetis @.> Cc: Laurence Barker @.>, Comment @.> Subject: Re: [ramdor/Thetis] Investigate power (CW) appearing on rx only ports (Issue #228) I was looking at using 3 unused bits that are common in each of the Alex0 words for all ANAN boards. Give them to the Tx ANT and use the previous ANT 1-3 for Rx. Updated Doc for reference: openHPSDR Ethernet Protocol v3.13.docx

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

laurencebarker commented 9 months ago

True but many of the relay output bits are not used. Having a 4th bit to identify this scheme is in use is probably essential though. Laurence BarkerSent from my Galaxy -------- Original message --------From: dl1ycf @.> Date: 04/01/2024 08:30 (GMT+00:00) To: ramdor/Thetis @.> Cc: Laurence Barker @.>, Comment @.> Subject: Re: [ramdor/Thetis] Investigate power (CW) appearing on rx only ports (Issue #228) It does not make much sense to (just) extend the Alex word, since in principle each bit here

drives its "own" relay.

What one needs is that the firmware automatically changes TX ANT 1/2/3 when going TX.

If you want to put this into the Alex word, you actually need FOUR "unused bits", one

flagging that the other three are valid (backwards compatibility problem).

I think one rather should look at the HighPrio packet. This has eight 32-bit

Alex words (Alex7 ... Alex0) at position 1404 ... 1435.

Here is ample space e.g. re-naming them

Alex3TX, ..., Alex0TX, Alex3, ..., Alex0

Alex?TX will normally be zero (for currently existing SDR programs), and the

firmware could then do then following:

If (transmitting && Alex0TX != 0) {

clock out Alex0TX word to Alex0 shift register

} else {

clock out Alex0 word to Alex0 shift register

}

and the same for Alex1. Up do now, Alex2-7 are unused anyway so "restricting"

the protocol from 8 to 4 ALEX banks is probably OK.

Then (and only then), SDR programs can start to update their "Alex logic"

and populate more bits when sending the HighPrio packet.

Just my $0.02,

Christoph DL1YCF.

Am 03.01.2024 um 23:10 schrieb Rick Koch @.***>:

I was looking at using 3 unused bits that are common in each of the Alex0 words for all ANAN boards. Give them to the

Tx ANT and use the previous ANT 1-3 for Rx. Updated Doc for reference:

openHPSDR Ethernet Protocol v3.13.docx

—

Reply to this email directly, view it on GitHub, or unsubscribe.

You are receiving this because you commented.Message ID: @.***>

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

dl1ycf commented 9 months ago

I think using one of the unused Alex words in the HP packet is a good idea. Do you think we need to use both of the Alex 2 words?

In defense of using the '3 unused bits that are common in each of the Alex0 words' my thought was that when going into TX the firmware looks at those 3 bits and validates it on just one bit being set and if more than one bit or zero, don't use it.

I think that is the same as checking the Alex X word and validating it. Either way the bits should be unused. I'm not sure why there would need to be a fourth bit, but I may be missing something.

You mention doing 'and the same for Alex1', I'm not following that logic as there are no ANT control bits in that word.

On Thu, Jan 4, 2024 at 3:29 AM "Christoph v. Wüllen" @.***> wrote:

It does not make much sense to (just) extend the Alex word, since in principle each bit here drives its "own" relay.

What one needs is that the firmware automatically changes TX ANT 1/2/3 when going TX.

If you want to put this into the Alex word, you actually need FOUR "unused bits", one flagging that the other three are valid (backwards compatibility problem).

I think one rather should look at the HighPrio packet. This has eight 32-bit Alex words (Alex7 ... Alex0) at position 1404 ... 1435.

Here is ample space e.g. re-naming them

Alex3TX, ..., Alex0TX, Alex3, ..., Alex0

Alex?TX will normally be zero (for currently existing SDR programs), and the firmware could then do then following:

If (transmitting && Alex0TX != 0) { clock out Alex0TX word to Alex0 shift register } else { clock out Alex0 word to Alex0 shift register }

and the same for Alex1. Up do now, Alex2-7 are unused anyway so "restricting" the protocol from 8 to 4 ALEX banks is probably OK.

Then (and only then), SDR programs can start to update their "Alex logic" and populate more bits when sending the HighPrio packet.

Just my $0.02,

Christoph DL1YCF.

Am 03.01.2024 um 23:10 schrieb Rick Koch @.***>:

I was looking at using 3 unused bits that are common in each of the Alex0 words for all ANAN boards. Give them to the Tx ANT and use the previous ANT 1-3 for Rx. Updated Doc for reference: openHPSDR Ethernet Protocol v3.13.docx — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

dl1ycf commented 9 months ago

Hi Rick

Either way would work. And yes detecting that txant1-3 contain 001, 010 or 100 would be sufficient to know that it had come from an updated version of Thetis or piHPSDR. Whichever set of bits is used, we need some kind of detection that it is from a modified client app.

My job is easiest as I have a processor available to move the bits around.

My Verilog IP is different from Orion’s – partly because it has an AXI4-Lite bus interface to get the input data. What I will implement is a second 16 bit word for the 16 bit shifted settings that include the TX filter and ANT bits. But I can easily get the right data to that register.

Laurence Barker G8NJJ

@.***

From: Rick Koch @.> Sent: Thursday, January 4, 2024 2:44 PM To: Christoph v. Wüllen @.> Cc: ramdor/Thetis @.>; laurence @.> Subject: Re: [ramdor/Thetis] Investigate power (CW) appearing on rx only ports (Issue #228)

I think using one of the unused Alex words in the HP packet is a good idea.

Do you think we need to use both of the Alex 2 words?

In defense of using the '3 unused bits that are common in each of the Alex0 words'

my thought was that when going into TX the firmware looks at those 3 bits and validates

it on just one bit being set and if more than one bit or zero, don't use it.

I think that is the same as checking the Alex X word and validating it. Either way the bits

should be unused. I'm not sure why there would need to be a fourth bit, but I may be missing

something.

You mention doing 'and the same for Alex1', I'm not following that logic as there are no ANT control

bits in that word.

On Thu, Jan 4, 2024 at 3:29 AM "Christoph v. Wüllen" @. @.> > wrote:

It does not make much sense to (just) extend the Alex word, since in principle each bit here drives its "own" relay.

What one needs is that the firmware automatically changes TX ANT 1/2/3 when going TX.

If you want to put this into the Alex word, you actually need FOUR "unused bits", one flagging that the other three are valid (backwards compatibility problem).

I think one rather should look at the HighPrio packet. This has eight 32-bit Alex words (Alex7 ... Alex0) at position 1404 ... 1435.

Here is ample space e.g. re-naming them

Alex3TX, ..., Alex0TX, Alex3, ..., Alex0

Alex?TX will normally be zero (for currently existing SDR programs), and the firmware could then do then following:

If (transmitting && Alex0TX != 0) { clock out Alex0TX word to Alex0 shift register } else { clock out Alex0 word to Alex0 shift register }

and the same for Alex1. Up do now, Alex2-7 are unused anyway so "restricting" the protocol from 8 to 4 ALEX banks is probably OK.

Then (and only then), SDR programs can start to update their "Alex logic" and populate more bits when sending the HighPrio packet.

Just my $0.02,

Christoph DL1YCF.

Am 03.01.2024 um 23:10 schrieb Rick Koch @. @.> >:

I was looking at using 3 unused bits that are common in each of the Alex0 words for all ANAN boards. Give them to the Tx ANT and use the previous ANT 1-3 for Rx. Updated Doc for reference: openHPSDR Ethernet Protocol v3.13.docx — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @. @.> >

dl1ycf commented 9 months ago

Hi Laurence,

I think what I will do, regarding the current P2 spec, is take the unused 1428 & 1429 Alex 1 16 bit word and make that the TxAlex equal to 1434 & 1435 Alex 0 16 bit word but containing the new TX ANT bits.

1428

Alex 1

Reserved for future use

1429

Alex 1

Reserved for future use

1430

Alex 1

[15:8] Orion Mk 11 (ANAN-8000DLE)

1431

Alex 1

[7:0] Orion Mk 11 (ANAN-8000DLE)

1432

Alex 0

[31:24]

1433

Alex 0

[23:16]

1434

Alex 0

[15:8]

1435

Alex 0

[7:0]

In the ANAN firmware I will just switch to that word if it is valid on transmit.

Unfortunately with the 'free' version of quartus, as you know, it does not allow any logic locking. So every compile is new and quartus will many times make a different decision on how to route a signal and/or clocks. So the chances of getting firmware that works just the same as before but with this new Alex switching is going to be hit or miss.

On Thu, Jan 4, 2024 at 2:41 PM @.***> wrote:

Hi Rick

Either way would work. And yes detecting that txant1-3 contain 001, 010 or 100 would be sufficient to know that it had come from an updated version of Thetis or piHPSDR. Whichever set of bits is used, we need some kind of detection that it is from a modified client app.

My job is easiest as I have a processor available to move the bits around.

My Verilog IP is different from Orion’s – partly because it has an AXI4-Lite bus interface to get the input data. What I will implement is a second 16 bit word for the 16 bit shifted settings that include the TX filter and ANT bits. But I can easily get the right data to that register.

Laurence Barker G8NJJ

@.***

From: Rick Koch @.> Sent: Thursday, January 4, 2024 2:44 PM To: Christoph v. Wüllen @.> Cc: ramdor/Thetis < @.>; laurence @.> Subject: Re: [ramdor/Thetis] Investigate power (CW) appearing on rx only ports (Issue #228)

I think using one of the unused Alex words in the HP packet is a good idea.

Do you think we need to use both of the Alex 2 words?

In defense of using the '3 unused bits that are common in each of the Alex0 words'

my thought was that when going into TX the firmware looks at those 3 bits and validates

it on just one bit being set and if more than one bit or zero, don't use it.

I think that is the same as checking the Alex X word and validating it. Either way the bits

should be unused. I'm not sure why there would need to be a fourth bit, but I may be missing

something.

You mention doing 'and the same for Alex1', I'm not following that logic as there are no ANT control

bits in that word.

On Thu, Jan 4, 2024 at 3:29 AM "Christoph v. Wüllen" @.***> wrote:

It does not make much sense to (just) extend the Alex word, since in principle each bit here drives its "own" relay.

What one needs is that the firmware automatically changes TX ANT 1/2/3 when going TX.

If you want to put this into the Alex word, you actually need FOUR "unused bits", one flagging that the other three are valid (backwards compatibility problem).

I think one rather should look at the HighPrio packet. This has eight 32-bit Alex words (Alex7 ... Alex0) at position 1404 ... 1435.

Here is ample space e.g. re-naming them

Alex3TX, ..., Alex0TX, Alex3, ..., Alex0

Alex?TX will normally be zero (for currently existing SDR programs), and the firmware could then do then following:

If (transmitting && Alex0TX != 0) { clock out Alex0TX word to Alex0 shift register } else { clock out Alex0 word to Alex0 shift register }

and the same for Alex1. Up do now, Alex2-7 are unused anyway so "restricting" the protocol from 8 to 4 ALEX banks is probably OK.

Then (and only then), SDR programs can start to update their "Alex logic" and populate more bits when sending the HighPrio packet.

Just my $0.02,

Christoph DL1YCF.

Am 03.01.2024 um 23:10 schrieb Rick Koch @.***>:

I was looking at using 3 unused bits that are common in each of the Alex0 words for all ANAN boards. Give them to the Tx ANT and use the previous ANT 1-3 for Rx. Updated Doc for reference: openHPSDR Ethernet Protocol v3.13.docx — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

rz3qs commented 9 months ago

Thetis has a very old mistake. Why this is done, I do not understand. The speed of the CW and the correct time of switching the relay. Speed CW is one function, the control time ms is another function.

https://drive.google.com/file/d/1Y9eTaGl02th_bRaOREp3fZD-Mn_2l32f/view?usp=sharing

laurencebarker commented 9 months ago

This is not a Thetis problem. The problem is the design of the protocol. There is (and never was) any guarantee about how long it takes ethernet messages to arrive; nevertheless the protocol requires a message exchange to change antenna.

Changes to Thetis might get to the point where the problem was “largely resolved”. But only a change to the protocol can resolve it completely.

Laurence Barker G8NJJ

@.***

From: rz3qs @.> Sent: Friday, January 5, 2024 9:23 PM To: ramdor/Thetis @.> Cc: Laurence Barker @.>; Comment @.> Subject: Re: [ramdor/Thetis] Investigate power (CW) appearing on rx only ports (Issue #228)

Thetis has a very old mistake. Why this is done, I do not understand. The speed of the CW and the correct time of switching the relay. Speed CW is one function, the control time ms is another function.

https://drive.google.com/file/d/1Y9eTaGl02th_bRaOREp3fZD-Mn_2l32f/view?usp=sharing

— Reply to this email directly, view it on GitHub https://github.com/ramdor/Thetis/issues/228#issuecomment-1879272345 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AEXTXZ43SWTE5DIJOYFZ6FDYNBVK7AVCNFSM6AAAAAA6NXPS42VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZZGI3TEMZUGU . You are receiving this because you commented. https://github.com/notifications/beacon/AEXTXZYLBVFSRY7CF5IGLHDYNBVK7A5CNFSM6AAAAAA6NXPS42WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTQANVZS.gif Message ID: @. @.> >

dl1ycf commented 9 months ago

Just an update on this. I want to correct what I last said, 'take the unused 1428 & 1429 Alex 1 16 bit word and make that the TxAlex equal to 1434 & 1435 Alex 0 16 bit word but containing the new TX ANT bits.'

I meant, 'take the unused 1428 & 1429 Alex 1 16 bit word and make that the TxAlex equal to 1432 & 1433 Alex 0 16 bit word but containing the new TX ANT bits.'

I gather from what you said Laurence, that is how you're implementing this as well? We'll have to do the same thing with what's exposed to the client.

I have some modified Orion2 firmware and have made some modifications to pihpsdr for testing it. I went back to Nov 2nd 2023 before Christoph added support to mitigate the RF on RX-only ANT selection. Then added this:

diff --git a/src/new_protocol.c b/src/new_protocol.c index 5028f74..84d2e53 100644 --- a/src/new_protocol.c +++ b/src/new_protocol.c @@ -1178,6 +1178,27 @@ static void new_protocol_high_priority() { break; }

+#if 1

// use upper 16 bits of alex1 for TX relay control like ANT selection
i = transmitter->alex_antenna;
alex1 |= alex0 & 0xf8ff0000; // copy upper alex0 except for ANT1-3
switch (i) {
case 0: // ANT 1
alex1 |= ALEX_TX_ANTENNA_1;
break;
case 1: // ANT 2
alex1 |= ALEX_TX_ANTENNA_2;
break;
case 2: // ANT 3
alex1 |= ALEX_TX_ANTENNA_3;
break;
}
high_priority_buffer_to_radio[1428] = (alex1 >> 24) & 0xFF;
high_priority_buffer_to_radio[1429] = (alex1 >> 16) & 0xFF; +#endif high_priority_buffer_to_radio[1432] = (alex0 >> 24) & 0xFF; high_priority_buffer_to_radio[1433] = (alex0 >> 16) & 0xFF; high_priority_buffer_to_radio[1434] = (alex0 >> 8) & 0xFF;

I no longer see any RF when using an RX-only ANT.

Laurence, have you had a look at what it would take to modify Thetis for this?

On Thu, Jan 4, 2024 at 2:59 PM Rick Koch @.***> wrote:

Hi Laurence,

I think what I will do, regarding the current P2 spec, is take the unused 1428 & 1429 Alex 1 16 bit word and make that the TxAlex equal to 1434 & 1435 Alex 0 16 bit word but containing the new TX ANT bits.

1428

Alex 1

Reserved for future use

1429

Alex 1

Reserved for future use

1430

Alex 1

[15:8] Orion Mk 11 (ANAN-8000DLE)

1431

Alex 1

[7:0] Orion Mk 11 (ANAN-8000DLE)

1432

Alex 0

[31:24]

1433

Alex 0

[23:16]

1434

Alex 0

[15:8]

1435

Alex 0

[7:0]

In the ANAN firmware I will just switch to that word if it is valid on transmit.

Unfortunately with the 'free' version of quartus, as you know, it does not allow any logic locking. So every compile is new and quartus will many times make a different decision on how to route a signal and/or clocks. So the chances of getting firmware that works just the same as before but with this new Alex switching is going to be hit or miss.

On Thu, Jan 4, 2024 at 2:41 PM @.***> wrote:

Hi Rick

Either way would work. And yes detecting that txant1-3 contain 001, 010 or 100 would be sufficient to know that it had come from an updated version of Thetis or piHPSDR. Whichever set of bits is used, we need some kind of detection that it is from a modified client app.

My job is easiest as I have a processor available to move the bits around.

My Verilog IP is different from Orion’s – partly because it has an AXI4-Lite bus interface to get the input data. What I will implement is a second 16 bit word for the 16 bit shifted settings that include the TX filter and ANT bits. But I can easily get the right data to that register.

Laurence Barker G8NJJ

@.***

From: Rick Koch @.> Sent: Thursday, January 4, 2024 2:44 PM To: Christoph v. Wüllen @.> Cc: ramdor/Thetis < @.>; laurence @.> Subject: Re: [ramdor/Thetis] Investigate power (CW) appearing on rx only ports (Issue #228)

I think using one of the unused Alex words in the HP packet is a good idea.

Do you think we need to use both of the Alex 2 words?

In defense of using the '3 unused bits that are common in each of the Alex0 words'

my thought was that when going into TX the firmware looks at those 3 bits and validates

it on just one bit being set and if more than one bit or zero, don't use it.

I think that is the same as checking the Alex X word and validating it. Either way the bits

should be unused. I'm not sure why there would need to be a fourth bit, but I may be missing

something.

You mention doing 'and the same for Alex1', I'm not following that logic as there are no ANT control

bits in that word.

On Thu, Jan 4, 2024 at 3:29 AM "Christoph v. Wüllen" @.***> wrote:

It does not make much sense to (just) extend the Alex word, since in principle each bit here drives its "own" relay.

What one needs is that the firmware automatically changes TX ANT 1/2/3 when going TX.

If you want to put this into the Alex word, you actually need FOUR "unused bits", one flagging that the other three are valid (backwards compatibility problem).

I think one rather should look at the HighPrio packet. This has eight 32-bit Alex words (Alex7 ... Alex0) at position 1404 ... 1435.

Here is ample space e.g. re-naming them

Alex3TX, ..., Alex0TX, Alex3, ..., Alex0

Alex?TX will normally be zero (for currently existing SDR programs), and the firmware could then do then following:

If (transmitting && Alex0TX != 0) { clock out Alex0TX word to Alex0 shift register } else { clock out Alex0 word to Alex0 shift register }

and the same for Alex1. Up do now, Alex2-7 are unused anyway so "restricting" the protocol from 8 to 4 ALEX banks is probably OK.

Then (and only then), SDR programs can start to update their "Alex logic" and populate more bits when sending the HighPrio packet.

Just my $0.02,

Christoph DL1YCF.

Am 03.01.2024 um 23:10 schrieb Rick Koch @.***>:

I was looking at using 3 unused bits that are common in each of the Alex0 words for all ANAN boards. Give them to the Tx ANT and use the previous ANT 1-3 for Rx. Updated Doc for reference: openHPSDR Ethernet Protocol v3.13.docx — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

n1gp commented 9 months ago

The above was from an email I sent, not dl1ycf.

dl1ycf commented 9 months ago

Hi Rick

Because of an ongoing family issue I’m not getting much time for radio stuff!

As far as I can see, the TX antennas are already accessible in alex.cs. I think NetworkIO.SetAntBits() needs a new parameter for TX antenna (at the moment is passes down the ANT1-3 bits already selected for RX or TX). Then it can be saved where the protocol 2 code can access it. Then network.c around line 809 needs to set the 2 new bytes.

This will need a new release because the DLL changes, so we will need to synchronise with Richie.

I was going to do my FPGA code update 1st which is partly why I hadn’t got far. I imagine it will be late in the coming week before I have FPGA code and updated p2app.

Laurence Barker G8NJJ

@.***

From: Rick Koch @.> Sent: Sunday, January 7, 2024 6:44 PM To: @. Cc: Christoph v. Wüllen @.>; ramdor/Thetis @.> Subject: Re: [ramdor/Thetis] Investigate power (CW) appearing on rx only ports (Issue #228)

Just an update on this. I want to correct what I last said,

'take the unused 1428 & 1429 Alex 1 16 bit word

and make that the TxAlex equal to 1434 & 1435 Alex 0 16 bit word but containing the new TX ANT bits.'

I meant,

'take the unused 1428 & 1429 Alex 1 16 bit word

and make that the TxAlex equal to 1432 & 1433 Alex 0 16 bit word but containing the new TX ANT bits.'

I gather from what you said Laurence, that is how you're implementing this as well? We'll have to do

the same thing with what's exposed to the client.

I have some modified Orion2 firmware and have made some modifications to pihpsdr for testing it.

I went back to Nov 2nd 2023 before Christoph added support to mitigate the RF on RX-only ANT selection.

Then added this:

diff --git a/src/new_protocol.c b/src/new_protocol.c index 5028f74..84d2e53 100644 --- a/src/new_protocol.c +++ b/src/new_protocol.c @@ -1178,6 +1178,27 @@ static void new_protocol_high_priority() { break; }

+#if 1

// use upper 16 bits of alex1 for TX relay control like ANT selection
i = transmitter->alex_antenna;
alex1 |= alex0 & 0xf8ff0000; // copy upper alex0 except for ANT1-3
switch (i) {
case 0: // ANT 1
alex1 |= ALEX_TX_ANTENNA_1;
break;
case 1: // ANT 2
alex1 |= ALEX_TX_ANTENNA_2;
break;
case 2: // ANT 3
alex1 |= ALEX_TX_ANTENNA_3;
break;
}
high_priority_buffer_to_radio[1428] = (alex1 >> 24) & 0xFF;
high_priority_buffer_to_radio[1429] = (alex1 >> 16) & 0xFF; +#endif high_priority_buffer_to_radio[1432] = (alex0 >> 24) & 0xFF; high_priority_buffer_to_radio[1433] = (alex0 >> 16) & 0xFF; high_priority_buffer_to_radio[1434] = (alex0 >> 8) & 0xFF;

I no longer see any RF when using an RX-only ANT.

Laurence, have you had a look at what it would take to modify Thetis for this?

On Thu, Jan 4, 2024 at 2:59 PM Rick Koch @. @.> > wrote:

Hi Laurence,

I think what I will do, regarding the current P2 spec, is take the unused 1428 & 1429 Alex 1 16 bit word

and make that the TxAlex equal to 1434 & 1435 Alex 0 16 bit word but containing the new TX ANT bits.

1428

Alex 1

Reserved for future use

1429

Alex 1

Reserved for future use

1430

Alex 1

[15:8] Orion Mk 11 (ANAN-8000DLE)

1431

Alex 1

[7:0] Orion Mk 11 (ANAN-8000DLE)

1432

Alex 0

[31:24]

1433

Alex 0

[23:16]

1434

Alex 0

[15:8]

1435

Alex 0

[7:0]

In the ANAN firmware I will just switch to that word if it is valid on transmit.

Unfortunately with the 'free' version of quartus, as you know, it does not allow any

logic locking. So every compile is new and quartus will many times make a different

decision on how to route a signal and/or clocks. So the chances of getting firmware

that works just the same as before but with this new Alex switching is going to be

hit or miss.

On Thu, Jan 4, 2024 at 2:41 PM @. @.> > wrote:

Hi Rick

Either way would work. And yes detecting that txant1-3 contain 001, 010 or 100 would be sufficient to know that it had come from an updated version of Thetis or piHPSDR. Whichever set of bits is used, we need some kind of detection that it is from a modified client app.

My job is easiest as I have a processor available to move the bits around.

My Verilog IP is different from Orion’s – partly because it has an AXI4-Lite bus interface to get the input data. What I will implement is a second 16 bit word for the 16 bit shifted settings that include the TX filter and ANT bits. But I can easily get the right data to that register.

Laurence Barker G8NJJ

@. @.>

From: Rick Koch @. @.> > Sent: Thursday, January 4, 2024 2:44 PM To: Christoph v. Wüllen @. @.> > Cc: ramdor/Thetis @. @.> >; laurence @. @.> > Subject: Re: [ramdor/Thetis] Investigate power (CW) appearing on rx only ports (Issue #228)

I think using one of the unused Alex words in the HP packet is a good idea.

Do you think we need to use both of the Alex 2 words?

In defense of using the '3 unused bits that are common in each of the Alex0 words'

my thought was that when going into TX the firmware looks at those 3 bits and validates

it on just one bit being set and if more than one bit or zero, don't use it.

I think that is the same as checking the Alex X word and validating it. Either way the bits

should be unused. I'm not sure why there would need to be a fourth bit, but I may be missing

something.

You mention doing 'and the same for Alex1', I'm not following that logic as there are no ANT control

bits in that word.

On Thu, Jan 4, 2024 at 3:29 AM "Christoph v. Wüllen" @. @.> > wrote:

It does not make much sense to (just) extend the Alex word, since in principle each bit here drives its "own" relay.

What one needs is that the firmware automatically changes TX ANT 1/2/3 when going TX.

If you want to put this into the Alex word, you actually need FOUR "unused bits", one flagging that the other three are valid (backwards compatibility problem).

I think one rather should look at the HighPrio packet. This has eight 32-bit Alex words (Alex7 ... Alex0) at position 1404 ... 1435.

Here is ample space e.g. re-naming them

Alex3TX, ..., Alex0TX, Alex3, ..., Alex0

Alex?TX will normally be zero (for currently existing SDR programs), and the firmware could then do then following:

If (transmitting && Alex0TX != 0) { clock out Alex0TX word to Alex0 shift register } else { clock out Alex0 word to Alex0 shift register }

and the same for Alex1. Up do now, Alex2-7 are unused anyway so "restricting" the protocol from 8 to 4 ALEX banks is probably OK.

Then (and only then), SDR programs can start to update their "Alex logic" and populate more bits when sending the HighPrio packet.

Just my $0.02,

Christoph DL1YCF.

Am 03.01.2024 um 23:10 schrieb Rick Koch @. @.> >:

I was looking at using 3 unused bits that are common in each of the Alex0 words for all ANAN boards. Give them to the Tx ANT and use the previous ANT 1-3 for Rx. Updated Doc for reference: openHPSDR Ethernet Protocol v3.13.docx — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @. @.> >

n1gp commented 9 months ago

Firmware with the discussed fix is available for the ANAN-7000/8000 here: https://www.dropbox.com/scl/fi/r8o8iictmcb0qbaka99w7/Orion_MkII_Protocol_2_v2.2.1.rbf?rlkey=8ca3ns4y0u0mrmox8zsl2zb55&dl=0

mdblack98 commented 9 months ago

Do we know if this is a problem with the G2 and G2-1K?My G2-1K is in the pipeline for estimated delivery in Feb right now. Mike W9MDB

On Monday, January 8, 2024 at 06:40:38 AM CST, Rick Koch ***@***.***> wrote:

Firmware with the discussed fix is available for the ANAN-7000/8000 here: https://www.dropbox.com/scl/fi/6rs685y07wlljjuhtj8sd/Orion_MkII_Protocol_2_v2.1.27.rbf?rlkey=3athz5i9t0k84ciy65o1cqqip&dl=0

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

n4py commented 9 months ago

Yes, I would think it is certainly also a problem with the G2.

Carl Moreschi N4PY 127 River Moss Way Hertford, NC 27944 www.n4py.com

On 1/8/2024 9:44 AM, Michael Black wrote:

Do we know if this is a problem with the G2 and G2-1K?My G2-1K is in the pipeline for estimated delivery in Feb right now. Mike W9MDB

On Monday, January 8, 2024 at 06:40:38 AM CST, Rick Koch @.***> wrote:

Firmware with the discussed fix is available for the ANAN-7000/8000 here: https://www.dropbox.com/scl/fi/6rs685y07wlljjuhtj8sd/Orion_MkII_Protocol_2_v2.1.27.rbf?rlkey=3athz5i9t0k84ciy65o1cqqip&dl=0

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/ramdor/Thetis/issues/228#issuecomment-1881145545, or unsubscribe https://github.com/notifications/unsubscribe-auth/A5G66DTFJH4MUTA2KEHY56TYNQA3HAVCNFSM6AAAAAA6NXPS42VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBRGE2DKNJUGU. You are receiving this because you commented.Message ID: @.***>

mdblack98 commented 9 months ago

So what firmware does the G2 use? Mike W9MDB

On Monday, January 8, 2024 at 08:51:33 AM CST, n4py ***@***.***> wrote:

Yes, I would think it is certainly also a problem with the G2.

Carl Moreschi N4PY 127 River Moss Way Hertford, NC 27944 www.n4py.com

On 1/8/2024 9:44 AM, Michael Black wrote:

Do we know if this is a problem with the G2 and G2-1K?My G2-1K is in the pipeline for estimated delivery in Feb right now. Mike W9MDB

On Monday, January 8, 2024 at 06:40:38 AM CST, Rick Koch @.***> wrote:

Firmware with the discussed fix is available for the ANAN-7000/8000 here: https://www.dropbox.com/scl/fi/6rs685y07wlljjuhtj8sd/Orion_MkII_Protocol_2_v2.1.27.rbf?rlkey=3athz5i9t0k84ciy65o1cqqip&dl=0

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/ramdor/Thetis/issues/228#issuecomment-1881145545, or unsubscribe https://github.com/notifications/unsubscribe-auth/A5G66DTFJH4MUTA2KEHY56TYNQA3HAVCNFSM6AAAAAA6NXPS42VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBRGE2DKNJUGU. You are receiving this because you commented.Message ID: @.***>

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

n1gp commented 9 months ago

I know Laurence G8NJJ is working on a fix for this and the G2 but is tied up with other things at the moment. His repo for the firmware is here: https://github.com/laurencebarker/Saturn

ramdor / Thetis

Investigate power (CW) appearing on rx only ports #228