Recent Protocol Changes

[James Ahlstrom]

Hello Group,

I am adding recent changes in the Protocol document to Quisk. When the Protocol is unclear, I am editing it to make it clearer. I changed the text for Discovery and Discovery Reply. I changed the text for C0 address 0x09 bits 18, 19 and 20. Please check for accuracy.

I am confused by C0 address 0x00 DATA[13]. It reads "Control MCP23008 GP7 (I2C device on N2ADR filter board) (0=TX antenna, 1=RX antenna)".  We currently send seven bits to the MCP23008, and it looks like this is the eighth bit. But if the bit has a defined meaning then Quisk should set the bit the same as other HL2 software.

So does the bit change on Rx and Tx, so is equivalent (more or less) to the MOX bit? Or is there a setting somewhere to choose between two antennas labeled Rx and Tx? Since the other seven bits are set according to the band, maybe there should be an eighth bit added to the band filter screen. But then it would change with the band , not according to Rx or Tx.

So what is this bit supposed to mean?

Jim

N2ADR

[W. Jozef]

Hi Jim,

It's nice to hear news from you.

This Bit controls pin 13 on your board, it controls the antenna relay of the receiving antenna. or an additional antenna.

It is controlled directly on the GUI front panel.

This bit cannot be equivalent to MOX because it would not be possible to toggle between antennas during reception.

This does not only apply to low-band receiving antennas. But it also applies to experiments with different antennas, and even more to situations where, due to strong interference received by a dipole or vertical, one listens to another RX only  antenna, e.g. small magnetic loop.

You can have such a switch outside of the radio but If the transceiver like HL2 is in a shack and is operated from a computer, for example in the kitchen (or remote), then switching between the two antennas should be done with the control software and, for convenience, it should be on the front GUI panel.

Screenshots are attached
Best regards and stay healthy.
73, Joe,
LB1HI

["Christoph v. Wüllen"]

You are right, but
this bit has already been there in the original
HPSDR protocol.

bit clear: use TX antenna for RX
bit set: use antenna connected to „RX1“ for RX

The original HPSDR protocol uses bit13+14 so it
can switch to other RX antennas (RX2 and XVTR
connector), but for the HL2 this bit simply
means „use alternate RX antenna“.


> Am 18.11.2020 um 16:45 schrieb W. Jozef <sp9...@gmail.com>:
>
> <rxantbut1.jpg>

[W. Jozef]

:-)

[James Ahlstrom]

Hello,

Thank you for that. Am I correct that this only applies if "Alex manual mode" at address 0x09 bit 22 is zero? But if this bit is one, then different filters specified at address 0x09 bits[7:0] and [15:8] are sent to the same I2C address 0x20 instead? And all this is implemented? The protocol says it is "not implemented".

Jim

N2ADR

[Matthew]

Hi Jim,

Ok, short version; this is a bit that can be used as a general purpose control bit and it does not change state during tx/rx crossover. In hindsight, I wish I had used a different bit in the protocol to avoid confusion. Now for the long version....

I was making a modification to the HL2-MRF101 PA. This board uses RF3 on the HL2 to route the RX signal into the HL2. I wanted a relay to be able to listen through either my TX antenna or dedicated RX antenna. I wanted to be able to control this routing to RF3. I wanted to be able to still listen to the rx antenna on tx, so I did not want the relay to change state on TX/RX crossover. I proposed this here. As you will see from my pull request it was a very simple change to the gateware. I have not touched an PTT/MOX bits. I have implemented this in a button in linHPSDR that allows me to switch between listening on my RX or TX antenna.

Having picked an Alex bit to do this, I realised that people were expecting behaviour exactly how a full HPSDR radio implements this in software/hardware. That is, it changes state when MOX is engaged. However, the HL2 gateware does not implement this. So it is down to the PC to control this. PowerSDR does do this. However, I have expressed concern that;

1 - User keys HL2 from key plugged into HL2

2 - packet is sent to PC to inform of "external PTT event"

3 - PowerSDR then toggles what it sends for the bit in discussion. PowerSDR will not send this immediately (due to the way it handles comms with the radio), this may be up to 25 ms. So you have a relay that the user is expecting to change state at exactly the same time the INTTR/EXTTR HL2 signal does, whereas in reality it won't. If people are using WiFi links with packet jitter etc, this delay will only be worse. The user many end up TXing into their receive preamplifer without realise it.

So I proposed that in this circumstance of someone wanting to use this as an "antenna switch" the EXTTR/INTTR signals on the HL2 should be used with a logic gate from this GP7 bit, this will ensure switching as expected.

73 Matthew M5EVT.

[James Ahlstrom]

Hello Group,

Based on your kind replies, I changed the description of "Filter Selection" in the  Protocol document . It says that C0 address 0x00 DATA[13] is a pass-through bit from a GUI control, and does not change with Rx/Tx. Furthermore that this bit is only sent for Alex manual mode zero. Please read "Filter Selection" in the  Protocol document and if it is wrong, I am standing by to change it. Note that I am trying to document exactly what the gateware does now.

Jim

N2ADR

[Jim Ancona]

Thanks for updating that section, Jim! Coincidentally, I was having a hard time making sense of that yesterday. Your update seems much easier to understand.

Jim N1ADJ

--
You received this message because you are subscribed to the Google Groups "Hermes-Lite" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hermes-lite...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/c3bba0ac-1e83-4bc0-b9d2-1d757d1c67d9n%40googlegroups.com.

[James Ahlstrom]

Hello Steve and Group,

Here are some more issues with the  Protocol document. I am numbering them and marking them when finished.

Finished 1. Filter Selection description and filter controls at C0 address 0x00 and 0x09.

2. Tune request bits address 0x09 bits 18, 20: Proposed change waiting for approval: Eliminate "Bypass mode".

3. Watchdog timer control address 0x39 "Misc Commands": It is clear that command 0x09 disables the watchdog timer. Is it true that command 0x08 re-enables the timer?

4. Reset on disconnect address 0x3a bit [0]: Set to one to enable the reset. Is it true that zero will remove the reset?

Jim

N2ADR

[Steve Haynal]

Hi Jim,

Thanks for your protocol cleanup. 

2. I will eliminate the current method for bypass and bit 20 will only enable/disable tune. I will use another bit outside of current protocol1 use to enable bypass. If both tune and bypass are selected, then tune will have precedence.

3. Yes, writing 0x08 will reenable the watchdog. For some of this newer functionality, I am using small 4-bit control words instead of control bits as it is easy to accidentally change another bit in the word.

4. Yes. Writing zero for that bit will remove the reset.

73,

Steve

kf7o

[James Ahlstrom]

Hello Steve and Group,

Finished 1. Filter Selection description and filter controls at C0 address 0x00 and 0x09.

2. Tune request bits address 0x09:

     Bit 18 is one: Disable the T/R relay in low power mode (power amp Off). No other meaning.

     Bit 20 is one: Set when the Tune or Spot button is pressed to request an ATU tuning operation.

     ToDo: Allocate another bit to either a) initiate a tune in Bypass mode, or b) indicate that bypass mode is used when bit 20 is one.

Finished 3. Watchdog timer control address 0x39 "Misc Commands": Command 0x09 disables the watchdog timer, 0x08 enables it.

Finished 4. Reset on disconnect address 0x3a bit [0]: Set to zero for no reset, one to enable reset.

Jim

N2ADR

[James Ahlstrom]

Hello Group,

I am running an internal Quisk version with all the updates to the HL2 Protocol. But filter selection fails. Specifically, when "Alex manual mode" is one, changing to Tx does not send the "Alex Tx filters" to I2C address 0x20. I am using gateware 71p3. Is the Protocol document correct? Or do I need newer gateware? Or do I have a Quisk bug? Do not test this with current Quisk because Quisk sends the Tx filters itself in Tx.

I would like to make sure of what is supposed to be happening and program Quisk to that, even if it needs new gateware. I doubt anyone is using different Tx filters anyway.

Jim

N2ADR

[Steve Haynal]

Hi Jim,

The filter selection when alex manual mode one is still not implemented. There was a note saying it was not yet implemented on the protocol page but I see you removed that about 2 weeks ago. Sorry if I gave the impression it was implemented. Only the filter select when alex manual mode is zero is currently implemented. 

How much interest is there in the behavior described on the protocol page for alex manual mode 1?

73,

Steve

kf7o

[James Ahlstrom]

Hello Steve,

I changed the Protocol document to say that "Alex manual mode" set to one is not yet implemented and is under discussion. Unless there is a reason to implement the bit, I would leave it unimplemented.

Jim

N2ADR