Tx Inhibit input (CN8) on HL2

[Hamish Kellock OH2GAQ]

I have been investigating how the Tx Inhibit input (CN8) works on the HL2 board, and how it is reflected in Quisk SDR SW (version 4.1.93). When CN8 is grounded, the RF output is inhibited from the HL2, but there does not seem to be any indication in the Quisk screen that this has happened. When the ground to CN8 is removed, the RF returns.

Does anybody know if any of the popular SDR software suites supporting the HL2 read the status of this CN8 / Inhibit Transmit (or any other external logic input), and then internally move the PTT state from Transmit to Receive ? I also tried to find reference to this in the Protocol document on the Wiki, and it didn't seem to be covered, so there may be no way for the SDR SW to find the state of this input.

The reason I ask this is that in a complete system (in my case with microwave transverters) it may be necessary to protect the (very expensive) high power microwave transmitter parts should high VSWR or RF relay failure etc. occur. In my case this is done anyway, completely independently of the low power transceiver function, but it would be nice to get feedback that a failure had occurred on the SDR screen as well, and for the PTT Transmit status to be de-activated in the SDR SW or other hi-level SW.

(Using a hardware generated PTT command fed to the HL2 via the CN1 pin 10 is fine, as the external controller can provide this functionality so that an external PTT input is inhibited / dropped should such an error occur. But it still leaves an internally (in the SW by screen button push) generated PTT potentially showing the incorrect state. Makes it potentially incomplete for remote operation).

Hamish, OH2GAQ

[Reid Campbell]

Hi Hamish,

The I/O Board could provide an interface for you. The Pico on the board can be programmed to monitor signals or control lines and act to shut down operation. The Tx Inhibit is a input only signal but could be controlled via the Pico using the spare 3v3 I/O line. The shut down can then be communicated over the I/O Board protocol, using the fault register. The SDR software can then flag the fault to the user.

I can only speak for the Thetis software for the HL2. It already reads the fault register but currently doesn't operate on it. There is no definition of the fault register values but any none zero value should be regarded as a fault. A future version of Thetis will monitor this fault register, remove the PTT signal and report the fault.

Hopeful that helps you understand a potential use case for your application.

Cheers 

Reid
Gi8TME/Mi0BOT

--
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/af8472df-a649-4b16-b932-aa79bb6dc977n%40googlegroups.com.

["Christoph v. Wüllen"]

The conventional way is to report digital values in the C&C frames
(C0=0 C1 bits 1:4, IO1 ... IO4)
Then, normal SDR programs already take care of this
(Thetis does.) But this has to be done in the FPGA code.

> To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/9f9fd1b0-8f69-4a10-ac27-d8a554aae074%40gmail.com.

[Hamish Kellock OH2GAQ]

Hi Reid and Christoff,

Thanks for the input, sorry to be a bit long in getting back to this.

What I haven't been able to find is a definition of how the HL2 handles this state in the protocol. As I said in the first post, the version I am using (bit old but ...) certainly stops the RF out, but Quisk doesn't seem to react in any way. Maybe I need to get a protocol analyser SW to see whats going on.

Do either of you know if there is any definition of how HL2 handles the bits in this case ?

Regarding your suggestion Reid, that is more or less what I am doing in my hardware/software interface card. I designed this card a couple of years back, it has an Arduino Micro on it, plus all the interface circuitry for 6 half-duplex + 1 full-duplex transverters plus optical encoder (which has a HID mouse wheel interface to the SDR program) and lots of I/O to various other devices. It is monitoring the state of the Rb Oscillator reference and PLL locked state, and feedback from each transverter as to its operational state when in transmit mode. It immediately turns off the Tx command to the selected transverter when an error is noticed. The card is bigger than the HL2 !

By the way maybe I can't find the right info., but does Thetis run on Linux ? I can only see info about Windows usage. My SW must run on Raspberry Pi environment, its integrated into my equipment.

73, Hamish, OH2GAQ

["Christoph v. Wüllen"]

I think the HL2 does not report the bit in the protocol, but easily could do so:

the right place would be the "Hermes IO" bits in the HPSDR protocol which is used
for TX inhibit for some other rigs and e.g. respected by Thetis.

These bits are in the C&C packets C0=0 C1 bit 2,3,4,5 which in HL2-speak
translates to RADDR=0x00 RDATA bits 25, 26, 27, 28.

These bits are seemingly un-used presently by the HL2 firmware
As far as I can tell from the Thetis source code it will treat RDATA
bit 25 as TX inhibit (active = 0 inactive = 1).

It requires, of course, a firmware update.

> To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/9fe36be8-b2b5-479c-beee-69b06d588678n%40googlegroups.com.

[Reid Campbell]

Hi Hamish,

On 24/11/2023 11:13, 'Hamish Kellock OH2GAQ' via Hermes-Lite wrote:

Hi Reid and Christoff,

Thanks for the input, sorry to be a bit long in getting back to this.

What I haven't been able to find is a definition of how the HL2 handles this state in the protocol. As I said in the first post, the version I am using (bit old but ...) certainly stops the RF out, but Quisk doesn't seem to react in any way. Maybe I need to get a protocol analyser SW to see whats going on.

Do either of you know if there is any definition of how HL2 handles the bits in this case ?

The CN8 just stops the RF. There is no reporting on a state change, using the protocol, back to the PC. It could be added by changing the code for the FPGA but I don't believe there are any plans to make that happen. The protocol and SDR software on the PC would also need to be updated to handle the new signal.

Regarding your suggestion Reid, that is more or less what I am doing in my hardware/software interface card. I designed this card a couple of years back, it has an Arduino Micro on it, plus all the interface circuitry for 6 half-duplex + 1 full-duplex transverters plus optical encoder (which has a HID mouse wheel interface to the SDR program) and lots of I/O to various other devices. It is monitoring the state of the Rb Oscillator reference and PLL locked state, and feedback from each transverter as to its operational state when in transmit mode. It immediately turns off the Tx command to the selected transverter when an error is noticed. The card is bigger than the HL2 !

You could get your Micro to sit on the I2C bus, like the Pico, and interact with the SDR software that way.

By the way maybe I can't find the right info., but does Thetis run on Linux ? I can only see info about Windows usage. My SW must run on Raspberry Pi environment, its integrated into my equipment.

Thetis is Windows only but it has been made to work on Macs and Linux using emulation software. For the Pi, I think the main option would be Christoph's PiHPSDR.

Cheers 

Reid
Gi8TME/Mi0BOT 

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/9fe36be8-b2b5-479c-beee-69b06d588678n%40googlegroups.com.

[Clifford Heath]

Hamish,

I have been studying the HL2 code and Verilog RTL , and can answer some of your questions, confirming Reid’s answer.

CN8 connects to pin 25 of the FPGA, where the signal is known as io_tx_inhibit. This signal is debounced and reappears as ext_txinhibit, which is only used in one place in the code, to inhibit the Tx, here:

https://github.com/softerhardware/Hermes-Lite2/blob/0a6e07c37a23cd3a8721b6c3089e28721c378883/gateware/rtl/control.v#L357

So I can say that no SDR software is able to read the state of this input, because the signal isn’t used elsewhere.

Note that in the absence of any of three inhibit signals, the Tx is enabled either by protocol requirements (Tx data to send) or by PTT. I haven’t chased where the other two inhibit signals come from.

The synchronous response to a command received by the FPGA is assembled here, so perhaps a change as simple as replacing one of the zero’s by ext_txinhibit would allow SDR software to read the state of CN8:

https://github.com/softerhardware/Hermes-Lite2/blob/0a6e07c37a23cd3a8721b6c3089e28721c378883/gateware/rtl/control.v#L472

Clifford Heath.

[Hamish Kellock OH2GAQ]

Hi Clifford,

Thanks for the input regarding the CN8 input and confirmation that there is no way to get this information externally through the current implementation in the HL2. I looked at the two references you gave me, but I have to say that I have no experience in Verilog RTL or any other way of programming FPGA's. I guess you are talking about the bits that are assembled (in line 472) to report status as in the previous answer that Christof mentioned ( C&C packets C0=0 C1 bit 2,3,4,5).  I will look at this a bit more over the next few days, and at least try to understand the correspondence between the two.

Hamish, OH2GAQ

[Clifford Heath]

On 25 Nov 2023, at 9:58 pm, 'Hamish Kellock OH2GAQ' via Hermes-Lite <herme...@googlegroups.com> wrote:

Thanks for the input regarding the CN8 input and confirmation that there is no way to get this information externally through the current implementation in the HL2. I looked at the two references you gave me, but I have to say that I have no experience in Verilog RTL or any other way of programming FPGA's.

I could build modified gateware for you, but until some SDR software decodes the extra bit, you still won’t see anything.

I could also modify a version of Thetis, but I’d have to set up a new Windows build environment to test it. I haven’t built anything on Windows for a couple of years and my tools are probably out of date.

So I just put the possibility of Verilog changes out there, in the hope that authors of SDR software offer to make a test version available for you to test modified gateware. I’ll happily work with them to get the change into the gateware.

I guess you are talking about the bits that are assembled (in line 472) to report status as in the previous answer that Christof mentioned ( C&C packets C0=0 C1 bit 2,3,4,5).  I will look at this a bit more over the next few days, and at least try to understand the correspondence between the two.

Yes, that’s correct. I haven’t studied the Metis protocol enough to know if that’s the right place to expose the signal.

It’s likely that the C&C bits are only sent in a response packet after a command has been received from the SDR software, which would make it appear to lag until that happens. So until I know better, I would assume that the trivial change I suggested won’t work as expected.

Perhaps Steve could chime in here?

Clifford Heath.

Hamish, OH2GAQ

On Saturday, 25 November 2023 at 09:09:44 UTC+2 cliffor...@gmail.com wrote:

Hamish,

I have been studying the HL2 code and Verilog RTL , and can answer some of your questions, confirming Reid’s answer.

CN8 connects to pin 25 of the FPGA, where the signal is known as io_tx_inhibit. This signal is debounced and reappears as ext_txinhibit, which is only used in one place in the code, to inhibit the Tx, here:

https://github.com/softerhardware/Hermes-Lite2/blob/0a6e07c37a23cd3a8721b6c3089e28721c378883/gateware/rtl/control.v#L357

So I can say that no SDR software is able to read the state of this input, because the signal isn’t used elsewhere.

Note that in the absence of any of three inhibit signals, the Tx is enabled either by protocol requirements (Tx data to send) or by PTT. I haven’t chased where the other two inhibit signals come from.

The synchronous response to a command received by the FPGA is assembled here, so perhaps a change as simple as replacing one of the zero’s by ext_txinhibit would allow SDR software to read the state of CN8:

https://github.com/softerhardware/Hermes-Lite2/blob/0a6e07c37a23cd3a8721b6c3089e28721c378883/gateware/rtl/control.v#L472

Clifford Heath.

On 21 Nov 2023, at 2:57 am, 'Hamish Kellock OH2GAQ' via Hermes-Lite <herme...@googlegroups.com> wrote:

I have been investigating how the Tx Inhibit input (CN8) works on the HL2 board, and how it is reflected in Quisk SDR SW (version 4.1.93). When CN8 is grounded, the RF output is inhibited from the HL2, but there does not seem to be any indication in the Quisk screen that this has happened. When the ground to CN8 is removed, the RF returns.

Does anybody know if any of the popular SDR software suites supporting the HL2 read the status of this CN8 / Inhibit Transmit (or any other external logic input), and then internally move the PTT state from Transmit to Receive ? I also tried to find reference to this in the Protocol document on the Wiki, and it didn't seem to be covered, so there may be no way for the SDR SW to find the state of this input.

The reason I ask this is that in a complete system (in my case with microwave transverters) it may be necessary to protect the (very expensive) high power microwave transmitter parts should high VSWR or RF relay failure etc. occur. In my case this is done anyway, completely independently of the low power transceiver function, but it would be nice to get feedback that a failure had occurred on the SDR screen as well, and for the PTT Transmit status to be de-activated in the SDR SW or other hi-level SW.

(Using a hardware generated PTT command fed to the HL2 via the CN1 pin 10 is fine, as the external controller can provide this functionality so that an external PTT input is inhibited / dropped should such an error occur. But it still leaves an internally (in the SW by screen button push) generated PTT potentially showing the incorrect state. Makes it potentially incomplete for remote operation).

Hamish, OH2GAQ

-- 
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/af8472df-a649-4b16-b932-aa79bb6dc977n%40googlegroups.com.

-- 
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/899e0518-82e9-4bf5-b043-79da347ec1e9n%40googlegroups.com.

[Reid Campbell]

Hi Clifford,

Thetis already supports it if bit[1] of C1 where C0 = 00000000 (C&C) is pulled low. Code shown below.

                        // protocol 1
                        if (current_hpsdr_model == HPSDRModel.ANAN7000D || current_hpsdr_model == HPSDRModel.ANAN8000D)
                            inhibit_input = !NetworkIO.getUserI02(); // bit[2] of C1 where C0 = 00000000 (C&C)
                        else
                            inhibit_input = !NetworkIO.getUserI01(); // bit[1] of C1 where C0 = 00000000 (C&C)

This looks like it would be a useful addition to the FPGA gateware.

Cheers 

Reid
Gi8TME/Mi0BOT

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/63018AFA-10D0-4BCA-9698-277327F0F7DB%40gmail.com.

[Hamish Kellock OH2GAQ]

Hi Clifford and Reid,

Thanks for the responses and the offer to build a test version of the gateware. I also think it would be good to get some input from Steve. Whatever is arrived at it is better it is a bit discussed before jumping into hasty changes. But I think that having some mechanism for propogating fault information up the control chain is a good idea, so the highest level SW knows about the problem. (Then of course the next level is from the SDR SW to the next level SW (FLdigi, WSJT or so on)). But thats not a gateware issue !

73,

Hamish, OH2GAQ

[Reid Campbell]

Hi Hamish,

I have just build the Gateware using the ext_txinhibit signal and proven that it operates the inhibit in Thetis. The only way to reset the Thetis inhibit is to cycle the power button on the Console screen.

The inhibit can be disabled using menu setting Setup|Transmit|External TX Inhibit|Update with TX Inhibit state

Cheers 

Reid
Gi8TME/Mi0BOT 

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/3edb9e7e-2f77-4718-a4d0-6a47c6c85f9cn%40googlegroups.com.

[Hamish Kellock OH2GAQ]

Hi Reid,

Wow, that's incredible ! Thanks.

Tomorrow then I will have to install Thetis on my Windows PC. And get my other HL2 programmed with an updated version of the gateware that allows me to more easily program the HL2 over the ethernet. Both my current HL2's (I recall build 8) need me to use either a R Pi. or programming device to update the gateware.

I think that having to cycle the power button on a Console screen is a very reasonable after any fault that causes the Tx Inhibit to be operated.

I guess I have some learning to do about Thetis. And then how to get your updated gateware at a slightly later date. I also need to play around/test the new SW to see how it is to use in the system in practice.

I have been putting off this updating for a long time, years in fact. If it's not broken, don't fix it.

It would be good that Steve also had an opinion about this, for example that this kind of feature would become a standard item in the gateware in the future.

73,

Hamish, OH2GAQ (formerly VK3ZMV from the 1960's)

[Mike Lewis]

As a VHF/microwave operator, I normally associate TXInhibit with sequencing.  Prohibit RF transmission until all the downstream T/R related switching has completed through a chain of external transverter, amp, and remote mounted LNA (may leverage indicator contacts) to guarantee I do not blow up a mast mounted LNA for example.  This approach lets PTT flow through the whole system, RF only flowing after all has settled.  In this usage, TxInhibit is a just normal brief signal holding off RF.  This can be easier than trying to insert timing into the PTT chain and can help ensure a PTT chain failure does not cause damage.  

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/088fcb5e-76b2-4148-b75a-45f801914675n%40googlegroups.com.

[Reid Campbell]

Well, it's Clifford that done the hard work, marking the spot for me to hit with the hammer. I don't see any down side with this, you can decide to use it or not.

I will push the change back to github and Steve can integrate into the main development. If you need the bit file, I can send it to you but it would be better for an official build with the correct version number and the like.

Cheers

Reid
Gi8TME/Mi0BOT

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/088fcb5e-76b2-4148-b75a-45f801914675n%40googlegroups.com.

[Reid Campbell]

Hi Mike,

I would tend to agree, as I seen the inhibit as a way to ensure there was on hot switching. With the change we have the best of both worlds. I'm integrating the fault signalling of the I/O Board protocol into Thetis, so faults can be handled through that mechanism as well.

I had wondered if the inhibit could have been used during ATU tuning, to switch off the RF before a C or L was changed. I think there might be an issue with key clicks, as a sharp off and on of RF should be avoided.

Cheers

Reid
Gi8TME/Mi0BOT

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/MW4PR10MB5728B9B3EB06380678F248EEF6BFA%40MW4PR10MB5728.namprd10.prod.outlook.com.

[Clifford Heath]

Hi Reid,

Thanks for the acknowledgement, I'd be happy to have my name on the commit. I've been looking for ways to contribute at the RTL level and this was the first small opportunity that came along (there are plenty of big opportunities in github issues but...). 

Do you think the C&C packet will always be sent promptly? Or we need to observe the change in the ext_trinhibit signal and schedule a response packet? Are these response packets sent continuously or routinely anyhow? 

Clifford Heath

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/4e9967d2-4415-410b-b27c-026602a31519%40gmail.com.

[Reid Campbell]

The C&C packets are sent regularly and as the important bit of stopping the RF has already taken place, I don't think anything special needs to be done.

Mmmm, I wonder if we sent the FPGA code into ChatGPT, would it document and fix any bugs?

Cheers

Reid
Gi8TME/Mi0BOT

[Steve Haynal]

Hi All,

Thanks for the discussion in this thread. The ext_inhibit is already available to software via the pa_exttr and pa_inttr signals in the extended response:

https://github.com/softerhardware/Hermes-Lite2/blob/9e9e0d24410389d1a3a5ab995156fa8aeb63c0e4/gateware/rtl/control.v#L899

But the extended response is used only by hermeslite.py on port 1025. I don't think any standard software has (or should, keep port 1025 for debug applications.) adopted this.

I have no concerns about including this in the C&C bits, especially since Thetis already expects and uses one bit for this purpose. Reid, I see you already pushed the change to github. Thanks.

Moving forward, I think the community is more likely to get updates to the gateware if someone besides just me volunteers to make updates and releases. As you can see, I haven't made a gateware update in over a year. I'm willing to help someone learn the process with this latest change It is is fairly straightforward process:

1. Make all targets in Hermes-Lite2/gateware/variants with the makefile

2. Execute the release.py script

3. Move the new release into Hermes-Lite2/gateware/bitfiles/testing

4. Add some release notes int github markup

5. After some external testing and feedback, move the release from testing to the stable area and remove older stable releases.

I would make this volunteer a contributor to the github repository so that they can work independent of me. Any volunteers?

73,

Steve

kf7o

[Clifford Heath]

I would be happy to be shown how to contribute in this way.

Clifford Heath

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/f60f75c7-89f6-45a3-b4ca-dfa0bfd35a32n%40googlegroups.com.

[John Burch]

I also would not mind helping to contribute.

John

KC0ZOD

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/CAPnXPY1Z0o_s2RkhFd2AvfRYKaQcQH7yYEWRXQEcys%2B3qz7F%3DA%40mail.gmail.com.

[Clifford Heath]

One major concern I have about contributing is the limited amount of testing that can be carried out before “5. External testing”.

I’ve seen Github issues about testing but it looks rather daunting. Can we talk about a phased approach to building a better test procedure?

Clifford Heath.

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/f60f75c7-89f6-45a3-b4ca-dfa0bfd35a32n%40googlegroups.com.

[Steve Haynal]

Hi Clifford and John,

Thanks for volunteering! 

There is a "testing" bitfile release area. Usually I will put a bitfile there and then only after hearing good things from ~5 beta testers will I move it to stable. I open to improving this but it has worked okay for this type of project.

I just committed some release cleanup to github and did a dry release run. Below are are the instructions. Let me know if you have questions. Once you get to step 10, I will add you to the github contributor list, because maybe after seeing the steps you no longer wish to volunteer. :) I'm also open to improving and adding more automation to this release process.

73,

Steve

kf7o

1. Build is setup for Linux
2. quartus_sh must be in your path. I use 20.1. For this old of a FPGA, the version doesn't matter much.
3. Update the VERSION_MAJOR and VERSION_MINOR numbers in hermeslite_core.v if needed
4. cd Hermes-Lite2/gateware/variants
5. make realclean
6. make release (This may take 30-90 minutes depending on your machine.)
7. Check for gross timing violations. There are always a few minor ones due to the tool and constraints on the design which I waive. The below or similar is acceptable.
   The large violations seen in the hl2b2 (hardly used) are expected.

shaynal@sonata:~/Hermes-Lite2/gateware/variants$ grep TNS */build/hermeslite.sta.summary | grep "\-"
hl2b2_main/build/hermeslite.sta.summary:TNS   : -1.643
hl2b2_main/build/hermeslite.sta.summary:TNS   : -0.257
hl2b2_main/build/hermeslite.sta.summary:TNS   : -0.832
hl2b3to4_cicrx/build/hermeslite.sta.summary:TNS   : -0.257
hl2b3to4_cicrx/build/hermeslite.sta.summary:TNS   : -0.124
hl2b3to4_main/build/hermeslite.sta.summary:TNS   : -0.257
hl2b3to4_main/build/hermeslite.sta.summary:TNS   : -0.083
hl2b5up_6rx/build/hermeslite.sta.summary:TNS   : -0.257
hl2b5up_6rx/build/hermeslite.sta.summary:TNS   : -0.060
hl2b5up_cicrx/build/hermeslite.sta.summary:TNS   : -0.257
hl2b5up_cicrx/build/hermeslite.sta.summary:TNS   : -0.177
hl2b5up_main/build/hermeslite.sta.summary:TNS   : -0.257

8. Make the release: python3 release.py
9. Follow the subdirectory naming convention of past releases and move the release to a dated directory in Hermes-Lite2/gateware/bitfiles/testing
10. Add a github markdown description of the changes. Use gateware/bitfiles/testing/20220109_73p3/README.md as an example and template.
11. push to github and announce on the google group.

[John Burch]

I will get a box setup tomorrow to test it all out, is there a linux distro you recommend?

John

KC0ZOD 

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/8dd3b432-52e6-467b-a7cf-30bde420578dn%40googlegroups.com.

[Clifford Heath]

I have it running just fine on Manjaro, an i5 NUC. 

Steve's list doesn't look bad. Could do with more automation and some automated regression tests.

I'll run through the steps tomorrow morning.

Clifford Heath 

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/CAD3moXwFCrHVO0mgUj7JB7juL1WzpF86n%3DKJMzht04tYbtXBFw%40mail.gmail.com.

[Hamish Kellock OH2GAQ]

 Hi Mike (K7MDL) and Reid,

I agree about the use of the Tx Inhibit during sequencing on and off of the Tx, and in my case all this sequencing is handled in the transverters and my Microwave Transverter Controller(MTC), including inhibiting the Tx operation if there are various systems not operating like PLL's, References, etc as well as faults in the Transverters or Antennas. I looked at various ways to feedback fault information into the SDR SW (e.g. using a dedicated input, etc) to let it know there is a fault, else when you push the SW PTT (or if WSJT or FLDigi does the same thing) there is no feedback that something has gone wrong to the SDR SW. In my case the fault is notified to the MTC, then the operator can turn off the SDR. The Tx Inhibit seemed like a pretty logical place for this to be noticed. I have also been looking at other solutions, but still looks to me that the Tx Inhibit is a pretty logical solution.

73,

Hamish, OH2GAQ

["Christoph v. Wüllen"]

If you need TxInhibit to protect your hardware, forget about handling it in the
SDR program, but rather have the protection built into the FPGA.

For example, if you do CW, the HL2 might start transmit no matter what the SDR
program things or does or does not.

> To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/f12bd3dc-918f-4de7-a780-91a4bc00af81n%40googlegroups.com.

[Clifford Heath]

On Tue, 28 Nov 2023, 04:07 "Christoph v. Wüllen", <DL1...@darc.de> wrote:

If you need TxInhibit to protect your hardware, forget about handling it in the SDR program, but rather have the protection built into the FPGA.

Isn't that exactly what Hamish just described? His transverters can signal a fault by inhibiting the HL2 Tx. This thread exists because he wants an upstream indication of that in the SDR program, which Thetis already provides but HL2 doesn't trigger.

I don't think anyone suggested adding protection via the SDR program.

Clifford Heath 

[Hamish Kellock OH2GAQ]

Christoph, Clifford, Reid

Thanks for all the enthusiasm !

I guess it's clear what I was asking about and proposing now ? I think Clifford described the situation pretty well.

What I was also looking for was suggestions about SW that will act on receipt of the type of message that Christoph and Clifford suggested and Reid  has already built and tested with and checked with Thetis SDR program. It seems that the main SDR SW's that are available for Linux/R Pi environment (piHPSDR and Quisk) don't look at these bits at present. I had never used piHPSDR until yesterday, I built it on my embedded R Pi4, configured it with the transverter bands I wanted and the correct "OC bits", and looks like all is working well. So there are at least two "small screen candidates". If I have understood correctly Christoph is the current main author for piHPSDR (?). Any idea as to whether adding this kind of checking and then dropping internally generated PTT commands will require major surgery or not ? At least I am slightly familiar with SW development, but not at all with FPGA's !

73, Hamish, OH2GAQ

["Christoph v. Wüllen"]

Checking the Hermes IO1 bit and then dropping the PTT is trivial
and can be built in in 15 minutes. However, first we need a modified
FPGA code that actually reports this bit. It is then trivial if one
detects a inactive -> active transition of this bit to drop PTT
and to prevent activating PTT again as long as the bit is active
(I guess that is what you want).

piHPSDR is a program started by John Melton, for a couple of years I
have also been working on this program since this is exactly what I
need for my Macintosh.
Until the beginning of 2022 John and I regularly "unified" our codes
but since then there has not been much activity in John's repository.
Lots of updates etc. are now present (only) in my github
version, and this year I also contributed an in-depth manual.

> --
> 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/0a8ec6f8-9564-4bbf-8c55-5c4265805b41n%40googlegroups.com.

[DL1YCF]

I have now implemented TxInhibit in pihpsdr, so once it is in the firmware you
are in the game.

> --
> 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/0a8ec6f8-9564-4bbf-8c55-5c4265805b41n%40googlegroups.com.

[Clifford Heath]

On 29 Nov 2023, at 5:09 am, 'Hamish Kellock OH2GAQ' via Hermes-Lite <herme...@googlegroups.com> wrote:

I guess it's clear what I was asking about and proposing now ? I think Clifford described the situation pretty well.

Ok, but it’s still not entirely clear what you need on the SDR side.

Do you want to activate a custom action when the TxInhibit appears from downstream? Or just display a Fault indicator? (I think Thetis does the latter already)

You mention "dropping internally generated PTT commands”. I’m not familiar enough with the subject to know how to look for your answer. Where and when are PTT commands “internally generated”?

Clifford Heath

[Mike Lewis]

TxInhibit is (in my mind) a separate signal from PTT and prevents RF from flowing and does not interfere directly with PTT signaling.  When conditions are right (externally decided) the TXInhibit will be released.  If PTT was applied, and all devices downstream successfully changed over to the TX state, and any other items in the TxInhibit chain (PLL Lock is popular) are good, then when the TxInhibit is released and PTT is still applied, RF flows and a transmitted signal is radiated.   

 

The HL2 FPGA would do 2 things here.  Stop RF signal when TxInhibit is applied and notify the SDR app that TxInhibit is active.  

 

The SDR App upon receiving the TxInhibit signal for the HL2 would at minimum simply light and indicator.  It has no way of knowing why the TxInhibit signal is active, could be normal sequencing or a brief or long term fault.  If the operator sees this indicator on for too long, then the op would release PTT (if on) and need to investigate the equipment for the reason it is on and resolve it.  In general, leaving the PTT on with no RF flowing will likely cause no harm, assuming no major TX mode catastrophe and magic smoke.

 

Several radios on the market provide good examples of TxInhibit including the FT-817 and K3.  I do not think any of these radios indicate TxInhibit is applied, they just stop RF flowing while it is active.  For me, my FT-817 driving a microwave transverter is held in TxInhibit for every R-T transition until all is lined up.  The circuitry inside the transverter is responsible for aggregating the causes such as relay states, amp negative bias power interlock, and PLL lock state.

 

In summary: The SDR app does nothing but optionally light an indicator. The operator uses that indicator to make a decision about looking at the equipment and/or releasing PTT if it is ON.   The FPGA just stops RF, leaves PTT alone.  A nice to have: The HL2 would light a TXInhibit LED.  No radio I have owned does this though, my Xvtr does instead as the source of the signal.

 

• Mike K7MDL

 

From: herme...@googlegroups.com <herme...@googlegroups.com> On Behalf Of Clifford Heath
Sent: Tuesday, November 28, 2023 3:46 PM
To: Hamish Kellock OH2GAQ <hamish....@pp.inet.fi>
Cc: Hermes-Lite <herme...@googlegroups.com>
Subject: Re: Tx Inhibit input (CN8) on HL2

 

On 29 Nov 2023, at 5:09 am, 'Hamish Kellock OH2GAQ' via Hermes-Lite <herme...@googlegroups.com> wrote:

--

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/1C1C14F1-7975-43AC-931A-DA9D55CB4895%40gmail.com.

["Christoph v. Wüllen"]

I have now implemented TXinhibit in piHPSDR (still needs a GUI to activate/deactivate it) and
when TXinhibit is seen, this is flagged in red colour in the top left of the panadapter.

However, there was demand that the SDR program does a TX/RX transition if TXinhibit is flagged
during TX, and that is would not make a RX/TX transition as long as TXinhibit is active.

This means, that if TXinhibit occurs during TXing and disappears 100 msec later, TX is not
resumed.

However, if the GUI allows that TXinhibit is ignored then everyone is happy.

> To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/MW4PR10MB572874C120131EA357F2C4B7F683A%40MW4PR10MB5728.namprd10.prod.outlook.com.

[Hamish Kellock OH2GAQ]

Nice to see all the comments,  we are in the middle of a rather cold spell here (-10 and plenty of

snow clearing to be done).

So I very quickly looked thru the comments, may have missed something. The stuff below was mainly written in isolation

but updated  after seeing the comments above.

Here are some ideas for how to handle Tx Inhibit input to HL2, both

in the HL2 and in the associated SDR SW. One thing I see as somehow essential is that the
SDR SW does drop out of Transmit mode. See 2(a) below.

1. In the HL2 firmware:

Behaviour:

a) Whilst in Tx. mode and cn8/Tx. Inhibit is asserted, transmit output is turned off.

b) Whilst in Tx. mode and cn8/Tx. Inhibit is asserted, HL2 reports this status in (to quote
Christoph) " in the C&C packets C0=0 C1 bit 2,3,4,5 which in HL2-speak
translates to RADDR=0x00 RDATA bits 25, 26, 27, 28 " (or any other suitable method).

c) As long as the cn8/Tx. Inhibit is asserted, this reporting is continued.

( I think at least a and b exactly matches Mike's description of HL2 behaviour)

Comments:

(a) represents the existing behaviour (as far as I can tell).

(b) represents the minimum new behaviour.

(c) would be desireable, but depends on ease of implementation. For example if
the present behaviour is only implemented when the HL2 is transmitting RF, but not
when in Rx. only mode, it would be OK from my viewpoint.

(d) no state machines wanted in the HL2 firmware for this behaviour, just report the status.


2. In the associated SDR application software:

Behaviour:

a) During the time that MOX/PTT "Button" (here I mean the button on the screen actuated by mouse click/screen tap
or other mechanism like VOX or a request from higher level program like WSJTX, FLDIGI etc.) is
"pressed" (that is we are transmitting), the current "Tx. Inhibit" status is frequently checked, and if it enters an Inhibited state the SDR SW cancels the Transmit state ("toggles" the button). Optionally an error notification is made.
(If the PTT "Button" is a real button/mic. switch at least in my case it is handled in external HW so any transmit request is dropped outside of the SDR SW).

b) A configuration parameter to enable the behaviour in 2a) above is required in the SDR SW. Not everyone will want this behaviour.

c) When MOX/PTT "Button" is first pressed (here I mean the button on the screen actuated by mouse click/screen tap
or other mechanism like VOX or a request from higher level program like WSJTX, FLDIGI etc.),
the current "Tx. Inhibit" status is checked, and if in a Inhibited state the SDR SW does not move to the "Transmit" state. Optionally an error notification is made.

d) Error notifications may be transient and self-clearing, so the only "long term" effect is that the SDR SW drops out of transmit mode.

e) Error notifications can be latched (stored) until cleared. That is, having seen an error once, the SDR SW needs the error to be acknowledged before again entering the transmit status.


Comments:

(a), (b) and (d) are minimum behaviour.

[Mike Lewis]

If txinhibit causes the sdr app to drop ptt, then you can never use txinhibit in a sequencing role.

If both behaviors are desired then it would need to be enabled or disabled.  The indication, if any, would show regardless.  

A 3rd scenario covers the 2 extremes by applying a timer. Inhibit > x msec forces ptt to rx until cleared.

Sent from my T-Mobile 4G LTE Device
Get Outlook for Android

---

From: 'Hamish Kellock OH2GAQ' via Hermes-Lite <herme...@googlegroups.com>
Sent: Wednesday, November 29, 2023 2:56:24 AM
To: Hermes-Lite <herme...@googlegroups.com>

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/19e12d8e-5b4c-4867-9afb-ae20987af660n%40googlegroups.com.

[James Ahlstrom]

If I understand correctly, CN8/TxInhibit is an input pin that a user can assert to cut off transmission. But the status of CN8 is not currently returned in the HL2 protocol, so the SDR program can not know its status unless the gateware is modified. This discussion seems to be motivated by the needs of transverters.

The IO board is probably present if transverters are used because it can provide an Rx input that can never have 5 watts applied to it if something goes wrong. So the IO board can report the status of CN8. Just solder a jumper wire from CN8 to one of the five general purpose inputs on J8. The SDR program can read the pin on register REG_INPUT_PINS and discover the status of CN8. 

The CN8 status can also be read from an external program like Steve's hermeslite.py or by my n2adr_ioboard.pyw. In fact, n2adr_ioboard.pyw already shows the status of the input pins and so all you need is the jumper.

Jim

N2ADR

["Christoph v. Wüllen"]

Why not simply report this bit in the appropriate place?

Looking at what comes from the HL2, the protocol bits
(in HL2-speak) RADDR=0x00 Bits[25:28] are always "1",
which means "inactive".

What e.g. Thetis expects is that bit25 follows the status
of CN8, being "0" if TxInhibit is active. It cannot be
*that* complicated to do this in the FPGA firmware.

On the SDR program side, it is implemented at least in
Thetis and piHPSDR, what lacks is that the bit
(Hermes IO1 in HPSDR-speak) follows CN8.

Yours,

> Am 29.11.2023 um 19:15 schrieb James Ahlstrom <jah...@gmail.com>:
>
> If I understand correctly, CN8/TxInhibit is an input pin that a user can assert to cut off transmission. But the status of CN8 is not currently returned in the HL2 protocol, so the SDR program can not know its status unless the gateware is modified. This discussion seems to be motivated by the needs of transverters.
>
> The IO board is probably present if transverters are used because it can provide an Rx input that can never have 5 watts applied to it if something goes wrong. So the IO board can report the status of CN8. Just solder a jumper wire from CN8 to one of the five general purpose inputs on J8. The SDR program can read the pin on register REG_INPUT_PINS and discover the status of CN8.
>
> The CN8 status can also be read from an external program like Steve's hermeslite.py or by my n2adr_ioboard.pyw. In fact, n2adr_ioboard.pyw already shows the status of the input pins and so all you need is the jumper.
>
> Jim
> N2ADR
>
>
>
> On Wednesday, November 29, 2023 at 6:51:48 AM UTC-5 K7MDL wrote:
> If txinhibit causes the sdr app to drop ptt, then you can never use txinhibit in a sequencing role.
>
> If both behaviors are desired then it would need to be enabled or disabled. The indication, if any, would show regardless.
>
> A 3rd scenario covers the 2 extremes by applying a timer. Inhibit > x msec forces ptt to rx until cleared.
>
> Sent from my T-Mobile 4G LTE Device
> Get Outlook for Android

> To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/998e7ea0-2d9b-400b-99fb-390f60cced6cn%40googlegroups.com.

[Reid Campbell]

It's already been done. Clifford identified were the change need to be
made and I updated the Verilog and pushed it back to Github. It will be
in future builds.

Cheers

Reid
Gi8TME/Mi0BOT

[James Ahlstrom]

I only suggested using the IO board as an alternative. In general, I don't like changing the gateware.

Jim

N2ADR

[Clifford Heath]

> On 30 Nov 2023, at 8:44 pm, Reid Campbell <scumballc...@gmail.com> wrote:
> It's already been done. Clifford identified were the change need to be made and I updated the Verilog and pushed it back to Github. It will be in future builds.

I got the impression that Christoff was pointing to a place in the protocol where this signal actually belonged but was not populated, other than the C&C bits.

I’d like to see that clarified before we commit to using the C&C solution.

Clifford Heath.

> To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/2d10408b-8a4d-42d9-8b18-831b640cd32e%40gmail.com.

[Reid Campbell]

Christoff is highlighting where in the protocol the signal should fit and that is were I implemented and tested it, so I think we are good unless somebody knows better?

Cheers

Reid
Gi8TME/Mi0BOT

[Clifford Heath]

Excellent. There are different names for the protocol slots so I wanted to be sure we were talking about the same thing.

If you want to send a pull request on Github I think I should be able to merge it and publish test bit files.

Clifford Heath 

[Hamish Kellock OH2GAQ]

Hi,

I have installed Christoph's latest test version of pihpsdr, which should work with your updated gateware when it is available.

I have updated the gateware in one of my HL2's to version 73.2 from version 64.6 using Quisk to update the gateware, to check

that my updating procedure works.

After quick testing, all seems to be working as before. Quisk reports 73.2 as the gateware version now.

Would it be possible that Reid/Clifford could make available a test version of the updated .rbf file with the change to report the status ?

I can do some testing to see the functionality of the system.

Depending when the update is available I may start later this week or after the weekend.

Hamish, OH2GAQ

[Clifford Heath]

> I have installed Christoph's latest test version of pihpsdr, which should work with your updated gateware when it is available.

...

> Would it be possible that Reid/Clifford could make available a test version of the updated .rbf file with the change to report the status ?

I haven’t seen Reid’s changes. I could make the change myself, but in order to be sure I get the correct bit, I’d rather use the change that he already tested. When he makes it available, I can build and publish the files.

Clifford Heath.

[Steve Haynal]

Reid committed several weeks ago:

https://github.com/softerhardware/Hermes-Lite2/commit/9e9e0d24410389d1a3a5ab995156fa8aeb63c0e4

[Clifford Heath]

Ahh, thank you, that makes sense. I’m more used to seeing pull requests that projects that have multiple committers.

I already had his changes when I updated to get your release cleanup. I’ll go through the process of build and release testfiles now.

Clifford Heath.

--
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/2175f3da-84d5-4d83-a732-b23cc751eb7fn%40googlegroups.com.

[Clifford Heath]

Folk,

I just published testing bitfiles with the TxInhibit changes here:

<https://github.com/softerhardware/Hermes-Lite2/tree/master/gateware/bitfiles/testing/20231207_74p1>

Please report back if you use them successfully, as this is my first release for HL2.

Clifford Heath.

[Hamish Kellock OH2GAQ]

  I have updated the gateware in my HL2 to have the test SW released by Clifford last night. I made a very short functionality test (checking Rx and Tx operation) with both Quisk and your test version of pihpsdr (with the Tx Inhibit Input disabled) and both seem to work fine.

     However when I enable the operation of the Tx Inhibit Input in pihpsdr, the Red message "TX Inhibit" immediately appears in the Rx screen area (when the Tx Inhibit input on the HL2 is not low), and the MOX button does not operate. If I bring the Tx Inhibit input on the HL2 to the low state, the  Red "Tx Inhibit" message is removed from the Rx screen area and the MOX button operates as expected. Removing the low input from the Tx Inhibit input on the HL2 results in the pihpsdr dropping out of transmit mode.

    Conclusion: There is a mismatch in the assumption of the active state of the Tx Inhibit bit sent from the HL2 and the pihpsdr SW (I couldn't see anywhere to select the active state in pihpsdr, only the place to enable the function).

    Apart from this minor glitch, it would seem that the operation is exactly as I would hope.

    Quickfix would be to invert how pihpsdr interprets the bit from the HL2.

   ( Betterfix would be to make the state selectable.)

    (of course the gateware can be changed rather than pihpsdr !)

73,

Hamish, OH2GAQ

[James Ahlstrom]

Please be sure to update the protocol page to document the new bit.

Jim

N2ADR

[Reid Campbell]

Hi Clifford,

I have loaded the new file and it is working with Thetis.

Cheers

Reid
Gi8TME/Mi0BOT

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/A061A3CB-5599-4A57-9F03-8D9E5AD4610A%40gmail.com.

[Reid Campbell]

I have updated the Wiki

RADDR	RDATA	Description
0x00	[25]	Tx Inhibited (Active Low)
0x00	[24]	RF ADC Overload (Active High)
0x00	[15]	Under/overflow Recovery**
0x00	[14:8]	TX IQ FIFO Count MSBs
0x00	[7:0]	Firmware Version
0x01	[31:16]	Temperature
0x01	[15:0]	Forward Power
0x02	[31:16]	Reverse Power
0x02	[15:0]	Current

 

Cheers

Reid
Gi8TME/Mi0BOT

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/9bafc2e2-9300-4ca5-a565-a2f319d4d55an%40googlegroups.com.

[Hamish Kellock OH2GAQ]

Hi,

To continue on from previous report, I have made a one line change to my local version of Christoph's pihpsdr to invert the sense of the data read from the HL2, and it is now working as I would expect when usage of the TxInhibit is enabled:

Notifies Tx Inhibit in Red on the display when it (CN8) is shorted to ground.

Drops out of Tx (MOX) when shorted to ground.

Won't enable Tx(MOX) when shorted to ground.

Works normally when not shorted to ground.

I would rather Christoph make any final change, as he knows best how to fix it.

(I added a line in my local copy of the file: old_protocol.c after line 1180, "data = !data;")

(I am away until next week, can read emails etc but can't test anything)

Hamish

OH2GAQ

[Mike Lewis]

Does PTT stay asserted while TxInhibit is active?  This would be desirable for a brief time to let a device chain settle, then releasing TxInhibit permits the RF to flow.  This requires RF flow (I/Q data not 0) and PTT states to be separate things.  That may not be how SDR apps are built today.   I think MOX controls both TX data and PTT in same action inside the app.

 

 

 

From: 'Hamish Kellock OH2GAQ' via Hermes-Lite <herme...@googlegroups.com>
Sent: Thursday, December 7, 2023 9:07 AM
To: Hermes-Lite <herme...@googlegroups.com>
Subject: Re: Tx Inhibit input (CN8) on HL2

 

Hi,

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/c79249fb-0492-4e06-9389-ccaf4fa40e60n%40googlegroups.com.

[Clifford Heath]

Back on-list.

It’s trivial to change the gateware again, but I want to be sure there’s a good reason to.

Electrically, the CN8 signal is active low, with a capacitor providing a 30ms debounce for a default pull-up. Pull it down to inhibit the RF.

The FPGA debounces this, inverting it in the process, so the ext_txinhibit signal is active (inhibit) high.
At present, it gets sent like that in the protocol, high means the Tx is inhibited.

Where does the protocol specify that this protocol bit should be active-low?
Without any other precedent, I would expect an inhibit signal to be active high, as Reid had it and Thetis implements it.

If I see a cogent argument for changing it, I’ll do that and release another patch.

Clifford Heath.

> On 8 Dec 2023, at 4:20 am, Christoph v. Wüllen <DL1...@darc.de> wrote:
>
> Hmmm....
>
> the correct state of the bit in the protocol is
>
> bit set ==> inactive, TX inhibit not set
> bit clear ==> active, TX inhibit set
>
> With the "old" gateware, all these bits were always set (inactive),
> and the correct behaviour is that the bit becomes zero if the TX inhibit
> condition is TRUE.
>
> With the old gateware, piHPSDR works so I suspect the new gateware "normally"
> reports a bit zero there? I also send this to Clifford.
>
> So in the FPGA code: the bit ext_txinhibit must be ZERO if tx_inhibit is true.
>
> @Clifford: the bit *must* be 1 in the "normal state". If not, the gateware must be changed.

>> To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/462d029c-220b-468e-b15c-6975973c1f18n%40googlegroups.com.
>

[Clifford Heath]

Reid,

> On 8 Dec 2023, at 3:11 am, Reid Campbell <scumballc...@gmail.com> wrote:
>
> I have updated the Wiki
>
> RADDR RDATA Description
> 0x00 [25] Tx Inhibited (Active Low)

I don’t think the current implementation is active low. The physical wire is active low with a pull-up, but the FPGA debounce inverts it and that’s what gets sent.

Clifford Heath.

[Reid Campbell]

OK Clifford, I'm having a look at it now.

[Reid Campbell]

Yes the signal is wrong. The protocol defines those 4 user inputs to be
active low and I thought that "ext_txinhibit" reflected the true state
of the signal, being active low. Can you add the ! or ~ to that signal
grouping and do a rebuild. I'll test it here in the debug and release
versions.

It did trip the transmit but maybe that was running it in debug mode
which causes a very choppy transmission.

Cheers

Reid
Gi8TME/Mi0BOT

[Clifford Heath]

The new testing bitfiles release is available, with the protocol TxInhibit signal active low.

This release uses some new release automation, which checks that the code is clean in git and includes the git short commit-hash in the directory name (so I didn’t bump the patch version this time).

The new testing release is here:

<https://github.com/softerhardware/Hermes-Lite2/tree/master/gateware/bitfiles/testing/20231208_74p1_a0bcd34>

Clifford Heath.

["Christoph v. Wüllen"]

First it is the HPSDR protocol where the HL2 protocol is based on, see here:

[Reid Campbell]

That's for the Anan 7000 series of transceiver, it different for
Protocol 1 and the original Hermes board. Could you post the document
those lines come from? My version of the protocol doc is
USB_protocol_V1.60 which was last updated in Jan '19

On 08/12/2023 08:21, "Christoph v. Wüllen" wrote:
> First it is the HPSDR protocol where the HL2 protocol is based on, see here:
>
>
>

> Until recently, these bits were not defined in the HL2 protocol, but
> ist has be recently modified, see
>
> https://github.com/softerhardware/Hermes-Lite2/wiki/Protocol
>
>
>
>
>
> so it should be crystal clear that the bit must be zero in the
> "inhibted" state and one in the "normal" state.

["Christoph v. Wüllen"]

Nope. The original document is the original protocol. In Yellow are my personal notes
based on measurements with my ANAN-7000.

BTW the original protocol does not state where these signals are good for, but
it states that 0=active. It *seems* (although not documented in the protocol)
that most radios that do have a TxInhibit use Hermes I01, while Orion-II
boards use I02. There is no "official" P2 firmware for Saturn, so I cannot
tell how it is there.

FYI I attach the protocol file. Note my additions are in yellow, apart from that it is
Phillip's (VK6PH) version 1.60 which to my knowledge is the most recent one.

The HL2 protocol is a variant thereof, based on it, but not identical.

[Reid Campbell]

Here is a clip from the Thetis software and the 7000/8000 are treated
differently to all other models when it comes to Protocol 1. The G2
model fall into the same category for Protocol 2.


                  if (NetworkIO.CurrentRadioProtocol == RadioProtocol.USB)
                    {
                        // protocol 1
                        if (current_hpsdr_model == HPSDRModel.ANAN7000D
|| current_hpsdr_model == HPSDRModel.ANAN8000D)
                            inhibit_input = !NetworkIO.getUserI02(); //
bit[2] of C1 where C0 = 00000000 (C&C)
                        else
                            inhibit_input = !NetworkIO.getUserI01(); //
bit[1] of C1 where C0 = 00000000 (C&C)
                    }
                    else
                    {
                        // protocol 2
                        if (current_hpsdr_model == HPSDRModel.ANAN7000D
|| current_hpsdr_model == HPSDRModel.ANAN8000D ||
                            current_hpsdr_model == HPSDRModel.ANAN_G2
|| current_hpsdr_model == HPSDRModel.ANAN_G2_1K)
                            inhibit_input = !NetworkIO.getUserI05_p2();
// bit[1] of byte 59 from the HPSP 1025 packet
                        else
                            inhibit_input = !NetworkIO.getUserI04_p2();
// bit[0] of byte 59 from the HPSP 1025 packet

>> To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/9a46fe00-0917-4c34-aecb-62ebe221ab12%40gmail.com.
>>

[Reid Campbell]

It's working correctly now but Thetis does have a issue when the inhibit is removed. It leaves the TUN button in an on state but not transmitting and you have to click it again to go back to normal. I'll have to have look at that.

Cheers

Reid
Gi8TME/Mi0BOT

[Hamish Kellock OH2GAQ]

Hi Clifford, Reid, Christoph,

OK Back in the shack and did some testing with the new gateware and Christophs pihpsdr. It all seems to work pretty well except I noted one strange thing, item 7 in the report.

Hamish, OH2GAQ

Brief Test Report made to confirm operation of TX Inhibit Input (CN8)

Date: 11/12/2023

Gateware in HL2: 20231208_74p1_a0bcd34, hl2b5up_main.rbf
Version of pihpsdr: Development version from 5/12/2023, unmodified
Operating environment: R. Pi 4, 32 bit OS Bullseye

Initial functional testing:

Use of Tx. Inhibit Input not enabled in pihpsdr.

1. No indication of Tx Inhibit on pihpsdr when the CN8 input was shorted to ground.

2. No affect on pihpsdr entering into Tx mode from MOX, TUN or VOX with CN8 shorted to ground.

3. No affect on pihpsdr exiting Tx mode (from MOX, TUN or VOX) when CN8 shorted to ground.


Use of Tx. Inhibit Input enabled in pihpsdr.

4. Indication of Tx Inhibit on pihpsdr spectrum display when the CN8 input was shorted to ground.

5. pihpsdr would not enter into Tx mode from MOX, TUN or VOX when CN8 shorted to ground.

6. pihpsdr would exit Tx mode (from MOX, TUN or VOX) when CN8 shorted to ground.


Attempts to induce failure by random operation of CN8 and MOX, TUN and VOX.

7. It was possible to induce a condition where the pihpsdr Tx spectrum window would become "locked on"
   to the screen when Tx was activated by using VOX and random activations and de-activation of CN8 were
   made. When this occurred, the HL2 was not in Transmit mode (indicated by the EXTTR output). A
   re-activation and de-activation of the VOX with CN8 inactive cleared this error condition.

   (this was not noticed yet with MOX and TUN activations of Tx)

[Hamish Kellock OH2GAQ]

Christoph, Reid and Clifford

Hi, the new development version of pihpsdr seems to be working well now with the CN8/TxInhibit

input to the HL2.

Hamish OH2GAQ

Brief Test Report made to confirm operation of TX Inhibit Input (CN8)

Date: 18/12/2023

Gateware in HL2: 20231208_74p1_a0bcd34, hl2b5up_main.rbf

Version of pihpsdr: Development version 2.3 from 18/12/2023, unmodified

Operating environment: R. Pi 4, 32 bit OS Bullseye

Initial functional testing:

Use of Tx. Inhibit Input not enabled in pihpsdr.

1. No indication of Tx Inhibit on pihpsdr when the CN8 input was shorted to ground.

2. No affect on pihpsdr entering into Tx mode from MOX, TUN or VOX with CN8 shorted to ground.

3. No affect on pihpsdr exiting Tx mode (from MOX, TUN or VOX) when CN8 shorted to ground.


Use of Tx. Inhibit Input enabled in pihpsdr.

4. Indication of Tx Inhibit on pihpsdr spectrum display when the CN8 input was shorted to ground.

5. pihpsdr would not enter into Tx mode from MOX, TUN or VOX when CN8 shorted to ground.

6. pihpsdr would exit Tx mode (from MOX, TUN or VOX) when CN8 shorted to ground.


Attempts to induce failure by random operation of CN8 and MOX, TUN and VOX.

7. It was no longer possible to induce a condition where the pihpsdr Tx spectrum window would become "locked on"

   to the screen when Tx was activated by using VOX and random activations and de-activation of CN8 were

   made. This was true for MOX and TUN also.

Conclusion:

The new gateware and updated pihpsdr are working as specified.

[Clifford Heath]

Thanks for the report Hamish.

If needed, we can make this an official release. I’m away from home presently and can’t make a fresh build, but I could re-release the same bitfiles.

However, I should also read the git logs and diffs since the last production release in order to write a complete release note, because there were minor changes made but not released. Perhaps they don’t affect the functionality, but it should be checked.

Clifford Heath.

-- 
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/43278bbf-ac5c-43d3-b8f8-d8b1f0ff7bc5n%40googlegroups.com.