HL-2 IO board testing

[Ed Grafton]

Please post any testing here.

This way, members do not have to scroll through the long lists.

Here is the project:

jimahlstrom/HL2IOBoard (github.com)

Thank you,

Ed

WA4SIX

[James Ahlstrom]

Once you get a board, you can use n2adr_test for an initial test. See my github page.

Jim

N2ADR

[Ed Grafton]

Jim, are you using the Arduino IDE with Pico added, or another one?

I am getting ready to install the pins, then the board this afternoon.

Ed

WA4SIX

[James Ahlstrom]

The code is in C. I am using the Raspberry Pi Pico C/C++ SDK. But the binary file is in the directory, so you don't need to recompile. Just copy it to the Pico.

Jim

N2ADR

[Dan Porter]

I received my board today and managed to do a quick install and test with Jim's n2adr_test code.

All outputs are working correctly and I can also read it with the HL2 Jupyter Notebook page N2ADR IO Board section.

73,
Dan - AI2M

--
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/66a1b86e-4c7a-406a-a26d-bcecb0045229n%40googlegroups.com.

[Raj, N2RD]

Received the board yesterday and tested OK.  On to next steps...

Thanks,

Raj, N2RD

On Friday, May 19, 2023 at 5:54:32 PM UTC-4 Ed Grafton wrote:

[brhl...@gmail.com]

Received my board yesterday, looks fine.Tests will start the next days.

Tnx ,

Uwe DF1UB

[Raj, N2RD]

Thanks all for providing this awesome board and project.

I have created a new fork at https://github.com/n2rd/HL2IOBoard_HermesJ16.git that programs the board to provide Hermes J16 compatible output.  There is an ecosystem around HPSDR Hermes compatible products that use open collector outputs for transverter control.  

In this version of the firmware, you can specify any set of open-drain outputs to be turned on for each transmit band.  There are 23 bands and 7 outputs.  So, you can either setup a band code for each band or if you use fewer than 7 transverters, set up a single open-drain output for each transverter band.  

The advantage of this approach is that you can choose whether to use a band code or demuxed band outputs with no band decoder needed.  

If you choose to use a single open-drain output for each transverter band, switching rf relays and PTT is very easy.  Just use the open-drain as the common ground as long as the total current is less than 500mA (limit of the driver IC).  There are some details here: https://wiki.batc.org.uk/images/6/6e/Tx_switching.JPG

Thanks, and all the best,

Raj, N2RD

[Raj, N2RD]

I just tested this with Quisk and the W6PQL automatic transverter switch.  It works!  I had previously used this with  Hermes/Anan-10.

Raj

[Reid Campbell]

Just reporting that I got my board over the weekend and initial tests have not found any problems.

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/898b2596-c1a9-4de8-be19-f004d6738f16n%40googlegroups.com.

[Raj, N2RD]

Hello,

  I have the card working but QuiSK is the only software that can control the receive mode.  How do I control the receive mode in firmware?

thanks

Raj

On Friday, May 19, 2023 at 5:54:32 PM UTC-4 Ed Grafton wrote:

[Rajiv Dewan]

Looks like setting GPIO2 high turns on RF3.  Is this correct?

thanks

Raj, N2RD

--

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/83132099-c271-4044-9e02-30986b15849an%40googlegroups.com.

-- 
--
Rajiv Dewan, N2RD

[ron.ni...@gmail.com]

I received my IO board last week, and finally found time today to open up my HL2 and solder in the additionally needed 3-pin header. Plugged in the IO board, loaded n2adr's test code, and found that the output of all the IO board test signals look as expected on my oscilloscope.  The Jupyter notebook command: hl.read_ioboard(0)  returned (254, 1, 0, 1), which I assume is the correct result for the test code. (But, for some reason, I needed to first do a "pip install netifaces" on my Raspberry Pi, before I could import hermeslite.py.)  Next step will be to see if I can send the receiver input mode and a frequency value to the IO board from hl2_tcp, and perhaps also figure out some way to test what the IO board actually received (maybe blink something in Morse Code with digits of the received frequency ??).

73, Ron, n6ywu

[Rajiv Dewan]

I made a quick revision of the firmware that any of the selected outputs on based on band selected.  (More details at https://github.com/n2rd/HL2IOBoard_HermesJ16.git) 

For Hermes compatibility, I am using the low side switch for my outputs as that is usable with the Hermes ecosystem.  I connected J6 pins 1 thru 4 to the DB9 pins 1 thru 4, and J6 pins 5 thru 7 to DB pins 6 thru 8.  I used DB9-5 for ground (for compatibility with most serial cables, picked up from J12 pin 2) and DB9 pin 9 for PTT (EXTTR from 29/30 back end connector). This way I need a single serial cable for band and ptt.  

I am using mine with the W6PQL automatic transverter switch that steers the RF and PTT to the correct transverter based on band selected on Quisk.  I just added an LED for each band position.  It makes it really easy to see that the Switch follows the transmit frequency as I change bands.

Pretty slick.

Now, I am trying to set turn RF3 on and off using the firmware.  I wish I could turn the PA on and off using the firmware in the IO board.  Is that possible?

Raj, N2RD

--

Rajiv Dewan
rmd...@gmail.com

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/67ea5002-3ec5-429c-93a3-212b1937fd2en%40googlegroups.com.

[James Ahlstrom]

Hello Raj,

You can control the receive mode with Steve's hermeslite.py program. To control in firmware, change the value of rx_input_usage in i2c_slave_handler.c:

static uint8_t rx_input_usage = 0;
  // rx_input_usage == 0: Normal HL2 Rx input, J9 not used, Pure Signal at J10 available
  // rx_input_usage == 1: Use J9 for Rx input, Pure Signal at J10 is not available
  // rx_input_usage == 2: Use J9 for Rx input on Rx, use Pure Signal at J10 for Tx

Jim

N2ADR

[James Ahlstrom]

No, not correct. See the code in i2c_slave_handler.c at case 11 to see how to set the switches.

Jim

N2ADR

[James Ahlstrom]

You can not currently control the filter board from the IO board. To do so you would need to program an I2C master. So you can not turn the PA on and off. But you can use Steve's hermeslite.py to do so.

Jim

N2ADR

[Rajiv Dewan]

Thanks, I will try it. 

Raj

— Sent from my mobile

Rajiv Dewan

rmd...@gmail.com

On May 31, 2023, at 8:36 AM, James Ahlstrom <jah...@gmail.com> wrote:

No, not correct. See the code in i2c_slave_handler.c at case 11 to see how to set the switches.

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/7a61089a-2c2f-4eec-9058-8b2d6d2278cfn%40googlegroups.com.

[Reid Campbell]

Hi All,

I would like to update the protocol for the I2C between the SDR software and the HL2 for address 11. Currently this carries the mode for the PS and secondary receive antenna. I would like to use the remaining bits as aerial switching signals for both RX and TX. Thetis has the ability to allow different antennas to be selected pre band and I would imagine that it would be useful for other SDR software.

I propose the following

             Bits
7 6 5   |  4 3 2  | 1 0
   Tx    |     Rx    | Receive
 Ant         Ant       Mode

The immediate ramification of this is a change to the basic Pico code for the I2C interrupt handler. Around 46 line in i2s_slave_handler.c should be changed to

            case 11:        // How to use the external Rx input at J9

                rx_input_usage = data & 0x03;   // Only interested in lower two bits

                switch (rx_input_usage) {

The Pico software will also require updating to determine if there is a difference between the Rx and Tx antenna and cause them to switch on EXTTR activation.

Anybody any objections?

Cheers 

Reid
Gi8TME/Mi0BOT

[James Ahlstrom]

Hello Reid and Group,

This is actually a rather complicated design request. On a quick look, the IO board Pico already knows the Tx frequency and so it knows the Tx band. Given the band, the correct antenna can be chosen by the Pico.  Recall that the objective was to require only minimal changes to SDR software, and to put almost everything into the Pico. Adding a Tx antenna to the protocol will only work with Thetis while using the Tx frequency to select the antenna will work with any SDR software.

But you have a selection of a receive antenna. That suggests that the correct design is to send the Rx frequency as well as the Tx frequency. But the HL2 can have multiple Rx frequencies and it doesn't seem right to send them all. If Thetis can select antennas for Rx and Tx per band, it is still sufficient to know the band and use the Pico to select the antenna.

But if Thetis wants to send an Rx and Tx antenna selection anyway, it is not necessary or desirable to add the bits to an existing byte. There are 256 registers available, so you can just add another address or two or three. If multiple people think that sending antenna selection is a good idea, we can add register 14 and 15. For SDR features peculiar to Thetis or other software, we can decide that registers 200 and above are for special purposes and not part of the basic protocol.

Just my ideas. What do others think?

Jim

N2ADR

[James Ahlstrom]

Hello Group,

Makerfabs asked me to create a test procedure for the IO board. They want to test boards before they ship them.  I am working on a design with "pogo pins" to make contact with the various IO ports. This requires another PCB and software. I need to know fairly soon whether anyone wants to change the IO board because the tester depends on the IO board layout. Please proceed with testing the IO board and let me know if you want changes in the hardware.

Jim

N2ADR

On Friday, May 19, 2023 at 5:54:32 PM UTC-4 Ed Grafton wrote:

[Reid Campbell]

Hi James,

On 13/06/2023 16:24, James Ahlstrom wrote:

Hello Reid and Group,

This is actually a rather complicated design request. On a quick look, the IO board Pico already knows the Tx frequency and so it knows the Tx band. Given the band, the correct antenna can be chosen by the Pico.  Recall that the objective was to require only minimal changes to SDR software, and to put almost everything into the Pico. Adding a Tx antenna to the protocol will only work with Thetis while using the Tx frequency to select the antenna will work with any SDR software.

But you have a selection of a receive antenna. That suggests that the correct design is to send the Rx frequency as well as the Tx frequency. But the HL2 can have multiple Rx frequencies and it doesn't seem right to send them all. If Thetis can select antennas for Rx and Tx per band, it is still sufficient to know the band and use the Pico to select the antenna.

So what if a user wants to change the receive antenna to their vertical rather than the beam to see if they are receiving better. You can't expect them to reprogram their Pico on the fly. There are some fundamental operations that I think the I/O board should cater for, one is antenna switching, the other is initiating a ATU or loop retuning and reporting it's completion. To cater for this, and possible other operations, the protocol should be expandable. If a software developer wants to support the functionality, well and good but there are other ways of commanding it using the UDP port to control operation.

The Pico is responsible for doing the complex custom functionality but we still need to initiate the action. If Thetis can do antenna switching but a user doesn't need that functionality, then the user interface in Thetis could be used to initiate some other custom operation for the user. One of the problems is that the I/O board doesn't have its own UI, so we need to take that into account.

But if Thetis wants to send an Rx and Tx antenna selection anyway, it is not necessary or desirable to add the bits to an existing byte. There are 256 registers available, so you can just add another address or two or three. If multiple people think that sending antenna selection is a good idea, we can add register 14 and 15. For SDR features peculiar to Thetis or other software, we can decide that registers 200 and above are for special purposes and not part of the basic protocol.

I was trying to keep all the antenna switching as one atom operation but it could be split out. I would still keep
the Rx and Tx aerial selection as one atomic byte, that would give a selection of 16 aerials each. If there is consensus for a particular operation, then the protocol should be updated to support it. There would be nothing worse that several different protocol variants to switch antennas.

What do people want to do with their I/O board when they finally hit the shelves?

Cheers 

Reid
Gi8TME/Mi0BOT

Just my ideas. What do others think?

Jim

N2ADR

On Tuesday, June 13, 2023 at 9:35:53 AM UTC-4 scumballc...@gmail.com wrote:

Hi All,

I would like to update the protocol for the I2C between the SDR software and the HL2 for address 11. Currently this carries the mode for the PS and secondary receive antenna. I would like to use the remaining bits as aerial switching signals for both RX and TX. Thetis has the ability to allow different antennas to be selected pre band and I would imagine that it would be useful for other SDR software.

I propose the following

             Bits
7 6 5   |  4 3 2  | 1 0
   Tx    |     Rx    | Receive
 Ant         Ant       Mode

The immediate ramification of this is a change to the basic Pico code for the I2C interrupt handler. Around 46 line in i2s_slave_handler.c should be changed to

            case 11:        // How to use the external Rx input at J9

                rx_input_usage = data & 0x03;   // Only interested in lower two bits

                switch (rx_input_usage) {

The Pico software will also require updating to determine if there is a difference between the Rx and Tx antenna and cause them to switch on EXTTR activation.

Anybody any objections?

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/829809fb-6055-40b3-ba9b-db6b55ab8f0bn%40googlegroups.com.

[ron.ni...@gmail.com]

I think separate register addresses should be chosen for retune and for antenna selection.  That way both generic SDR software and custom PICO code can either use or ignore these features without needing to mask or preset any particular bits.

Ron, n6ywu

[James Ahlstrom]

Hello Reid, Ron and Group,

>>if a user wants to change the receive antenna to their vertical rather than the beam to see if they are receiving better

That is an excellent point. I didn't think of that. So let's make a list of protocol requests, discuss them, and then I will add them to the Pico protocol and document them.

I slight complication is that command bytes are received by the Pico in an interrupt service routine. There is not enough time to do anything, as the return from an ISR must be immediate. I solve this by keeping a copy of the register. When the Pico has nothing better to do, I check the current register against the copy. If it is different, I move current to copy and start the operation. The user may change the current register several times while the operation commences. After the operation is complete the register will eventually be checked again, and if different, the operation restarts.

There are 255 register addresses and we are using seven. I don't think it is necessary to combine commands into a single byte. And I would like to avoid bits that tell the Pico whether a certain register is valid or has been changed. Here is a suggested list of added command registers. It is subject to discussion.

1. Register 14 is the Tx antenna and register 15 is the Rx antenna. The default antennas are zero, which means the antenna has not been specified by these registers. Valid antennas are 1 to 255. I am open to using a single byte if there is a reason. Remember that the HL2 can have many receivers and there may be antennas plus transverters. I am not sure 15 is enough.

2. Register 16 written as 1 is a retune request. Read this register to determine the status of the retune. I suggest the Pico changes this register to 2, 3, ... as the retune progresses. A final status of 0xF9 indicates success and 0xFA and up indicates failure.

3. We are only reading register zero. Maybe a read of a register should return the value last written. Since a read always returns four bytes, a read of register 14 would return registers 14, 15, 16 and 17.

Jim

N2ADR

[Reid Campbell]

Hi Jim,

On 14/06/2023 14:50, James Ahlstrom wrote:

Hello Reid, Ron and Group,

>>if a user wants to change the receive antenna to their vertical rather than the beam to see if they are receiving better

That is an excellent point. I didn't think of that. So let's make a list of protocol requests, discuss them, and then I will add them to the Pico protocol and document them.

I think that's the way to go.

I slight complication is that command bytes are received by the Pico in an interrupt service routine. There is not enough time to do anything, as the return from an ISR must be immediate. I solve this by keeping a copy of the register. When the Pico has nothing better to do, I check the current register against the copy. If it is different, I move current to copy and start the operation. The user may change the current register several times while the operation commences. After the operation is complete the register will eventually be checked again, and if different, the operation restarts.

I think the only exception is the Rx->Tx->Rx transitions. Things could get interesting further down the line when the UART comes in to play but I think it is only the receive side of the UART that uses interrupts.

 

There are 255 register addresses and we are using seven. I don't think it is necessary to combine commands into a single byte. And I would like to avoid bits that tell the Pico whether a certain register is valid or has been changed. Here is a suggested list of added command registers. It is subject to discussion.

I was thinking that 0 signifies antenna is disconnected but it effectively means the same thing. Useful for remote operating to disconnect the antenna system to avoid static build up.

1. Register 14 is the Tx antenna and register 15 is the Rx antenna. The default antennas are zero, which means the antenna has not been specified by these registers. Valid antennas are 1 to 255. I am open to using a single byte if there is a reason. Remember that the HL2 can have many receivers and there may be antennas plus transverters. I am not sure 15 is enough.

I think I would still like a group of associated antennas to share the one atomic byte. If the upper nibble is not the same as the lower, then on EXTTR, the upper nibble would be used to select the Tx aerial. We could assign a block 4 of addresses 14 to 17 to cover aerial or transverter switching, so increase the total switching options.

The envisage scenario is were you are listening on the vertical but still want to transmit on the beam. The vertical could also be a transmitting antenna, so the receive only option on the I/O board in not suitable for this condition.

2. Register 16 written as 1 is a retune request. Read this register to determine the status of the retune. I suggest the Pico changes this register to 2, 3, ... as the retune progresses. A final status of 0xF9 indicates success and 0xFA and up indicates failure.

If we go with a block of addresses for aerial switching then this would go to address 17.

3. We are only reading register zero. Maybe a read of a register should return the value last written. Since a read always returns four bytes, a read of register 14 would return registers 14, 15, 16 and 17.

This would be useful to determine the state of the I/O hardware, even just for debugging.

Cheers 

Reid
Gi8TME/Mi0BOT

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/0f04c010-ca68-4b37-a310-528a89aac0f7n%40googlegroups.com.

[Alan Hopper]

Hi Group,

I'm just adding the I2C frequency output to SparkSDR for this board, can anyone confirm which of the two I2C buses is used i.e. 0x3c or 0x3d from the protocol?

73 Alan M0NNB

[Reid Campbell]

Hi Alan,

It's 3d, the same one that controls the LPF board.

Cheers

Reid
Gi8TME/Mi0BOT

[Alan Hopper]

Hi Reid,

thanks for that.

For anyone interested there is a windows test version of Spark here https://www.sparksdr.com/download/SparkSDR.2.0.957.win64.zip that should be sending the frequency to the IO board.  I have no real hardware so it is entirely untested so please let me know if it does or does not work.

73 Alan M0NNB

[Reid Campbell]

Hi Alan,

It appears to be working, I was able to see the frequency in the Pico debugger. I assume you haven't done the rx only switching functionality yet.

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/58377cea-e6bd-4ef0-b7e5-42dc69a62248n%40googlegroups.com.

[Alan Hopper]

Hi Reid,

that's great to know, thanks. I need to read up on the the rx switching and find out what people expect form this.  

Alan

[Dan Porter]

Hi Alan,

It is working correctly with my RX preselector setup. My RX input is currently active from the last time I used Quisk. It will stay there unless I power cycle my HL2.

73, Dan AI2M

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/e4f00aa0-3e00-493d-8679-8105937fd916n%40googlegroups.com.

[Alan Hopper]

Hi Dan and all,

thanks for the report.

I'm assuming some sort of UI is wanted to control the RX input and maybe remember it.  I know the idea was to not require software to change but I am wondering about a configurable bit of ui to allow mapping controls to registers.  I'm afraid I've not followed the discussion on this board too closely so may have missed some things.  What are people's thoughts and wishes here?

73 Alan M0NNB

[ai...@danporter.net]

The way Jim N2ADR implemented it in Quisk, as persistent option on the HL2 radio configuration page called IO board Rx input, works well enough for me.

73, Dan AI2M

[Reid Campbell]

Hi Dan,

You can use the I2C control in any of the latest Thetis to control the I/O board.



In the above, I'm reading address 0. You can also write but remember that it's all in hex so 11 is 0x0b

Cheers 

Reid
Gi8TME/Mi0BOT

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/EACE7296-C001-4769-9583-EB1439493FAF%40danporter.net.

[Dan Porter]

Hi Reid,

I’m not sure I’m running the same version. My I2C control options look different:

73, Dan AI2M

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/f3afc103-8125-a107-97ca-02a726971742%40gmail.com.

[James Ahlstrom]

Hello Group,

We have two proposals for antenna switching. Use a single byte, 4 bits for Tx antenna and 4 bits for Rx antenna; and further bytes in the future. Or use a byte for Rx and another byte for Tx antennas. 

I have no personal use for the IO board. My station is controlled by IP plus a one wire bus. The hardware was designed based on discussions in this group, and I think the software should be too. So I will make proposals, but then just program whatever is asked for. If no one has any further input, I will program a single byte for antenna switching.

Jim

N2ADR

[Dan Porter]

But yes, I can confirm the I2C control in Thetis does work to enable or disable the Rx port on my unit.

Dan AI2M

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/E9D2B2E4-437D-4024-A7F3-C6A86FC106A6%40danporter.net.

[Reid Campbell]

That was on Windows 11, Windows 10 looks a bit squarer.

Cheers 

Reid
Gi8TME/Mi0BOT

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/B0CA70B9-DF07-4A52-BECA-38FB52E350D7%40danporter.net.

[Reid Campbell]

Hi Group,

I would like to propose another convention with the I/O board. Currently
GPIO5 (Pin 7 on the Pico) is available and not wired directly to any
where on the board. I propose that GPIO5 be used as a transmit inhibit
by connect it to CN8, Tx Inhibit, on the main HL2 board via a jumper.

It's an active low signal pulled up to 3.3V so conforms to the Pico
interfacing standards. This would allow controlling software on the Pico
to detect fault conditions and stop transmission or temporarily halt the
RF for relay transitions to preventing hot switching.

I also think there should be an alarm/fault bit in the address 0 return
bytes in the protocol to identify an error condition, with the
possibility of reading an error byte at some other address.

Cheers

Reid
Gi8TME/Mi0BOT

[James Ahlstrom]

Hello Group,

I received a request to explain my shack control hardware that I mentioned in my prior post. If there is further discussion, please post to my Quisk group https://groups.io/g/n2adr-sdr, not here.

Quisk or other programs on my PC can create IP traffic and send it directly to any client. But for simple clients such as filters or RF signal generators, IP is overkill. So I send the IP/UDP commands to a gateway box. The gateway redirects the message to one of three busses; an I2C bus, an RS-485 bus or a one-wire bus. These busses connect to microprocessors in the target devices. The I2C bus was a failure because I2C is not designed for distance and is susceptible to RF. The RS-485 bus is quite robust and capable of distances of hundreds of meters. My favorite bus is the one-wire bus. It is not compatible with the official standard by Dallas Semiconductor. I use a stereo headphone cable as the connector. The extra wire provides five volt power. The problem with the one-wire bus is that any unpowered or faulted node brings down the whole bus. The RS-485 uses controller chips to avoid this. But the five volt power is an advantage.

I have no plans to publish the bus because there are some problems with it and it is complicated. There is software on the PC, in the gateway and at each target device. It works so I leave it alone.

Jim

N2ADR

[Lou Scalpati]

Thanks Jim

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/60cf8c1d-e34a-4887-854c-b2b2cb3c3dden%40googlegroups.com.

[James Ahlstrom]

Hello Group,

I am finalizing my test jig for the IO board and I need to know soon whether any hardware changes are needed. Soon the gerbers will go to Makerfabs and changes will be difficult once the board starts production.

Jim

N2ADR

[Dan Porter]

Jim,

No changes for me.

Thanks, Dan AI2M

--
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/62456ba9-a1b3-4960-8700-359abe0cdc5dn%40googlegroups.com.

[James Ahlstrom]

Hello Group,

.

I am planning to make these changes to the HL2 IO board protocol unless there are objections.

1. The I2C read now returns the value of the write registers. So if you write to register zero, a read from zero returns registers 0, 1, 2 and 3. That means I must change the protocol for reading register zero. The data returned by a read from zero is now returned by a read from four. There is a table of registers in https://github.com/jimahlstrom/HL2IOBoard.

2. I have a plan for the ATU tune request. A write to register REG_ANTENNA_TUNER is a command to the tuner. I am modeling this on the Icom AH-4 but I want it to work in general. A write of 1 starts a tune request. A write of 2 is a bypass command. Other tuners may have more commands. The Pico will talk to the ATU and change the register to higher numbers to indicate progress. The PC must read this register while tuning progresses. If the register reads as 0xEE the PC must send RF to the ATU, and stop RF when 0xEE stops. A final value of zero indicates a successful tune. Values of 0xF0 and higher indicate that tuning failed. Note that the IO board can not initiate RF and so the need for 0xEE.  SDR software is not required to implement this command. In the future there may be an external program to do this.

Jim

N2ADR

[ron.ni...@gmail.com]

Hi Jim,

I have no objections.  Change #1, the read-back capability, makes it easier to test whether both the IO board and SDR software use of the protocol are working properly.

Ron

n6ywu

[James Ahlstrom]

Hello Group,

I am still working on antenna switching. Please correct me if my understanding is incorrect.

It appears that Thetis can select one of three antennas for each band. The HPSDR radios have three antenna connectors, and this selects which one to use. The main antenna selection depends on the open drain bits set for each band. Our Hermes Lite 2 does not switch this way. With the IO board installed, it has two Rx inputs, one 5 watt and one low power Tx output.

But Reid wants to send the Thetis antenna selection to the IO board in case someone has two or three antennas for a single band. That makes sense. So how about if we add either one or two protocol bytes for antenna selection per band with the understanding that the band selects the antenna, and the extra bytes only select among multiple antennas per band? Reid wants to use a single byte. Does anyone feel that two bytes, one for Rx and another for Tx, would be better?

Jim

N2ADR

[Reid Campbell]

Hi Jim,

I think we are over complicating something which should be quite simple, possible being driven by the desired to control antenna selection via the frequency. That is certainly achievable but where is the UI to control it and we would need non volatility to program it into the I/O hardware.

My requirement for Thetis is to be able to select Rx and Tx antennas pre band. Thetis already has all the logic and it would normal talk to the hardware via Protocol 1 to preform the functionality. I would just like a register to pass that information.

I would also like it combined into one byte to make it atomic, so there is not chance of something happening in between the transmission of two bytes. As the I/O hardware will be responsible for switching between receive and transmit aerials, there is the potential for an accident if only one aerial selection takes place.

One other question, now that register locations are read/write, what is the register layout regards the transmission of the frequency information?

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/7800e5fb-5ec3-497d-8063-0e9d67f6f71dn%40googlegroups.com.

[Alan Hopper]

Hi Jim and Reid,

I'm wondering how all this might work when many receivers are used at once on different bands.  Spark has the option of a large lookup table to open an appropriate hole in the standard filter board based on selected bands.  Should all rx frequencies be sent as well to allow people to do similar things in firmware?

73 Alan M0NNB

["Christoph v. Wüllen"]

The band filter selection entirely depends on the hardware.

This is how I do it in piHPSDR, but I think the Windows programs behave
similarly:

For older ANAN models (for example), there are separately switchable low-pass and high-pass filters
in the RX frontend (the TX LPF are re-used). So, if there are two RX running on two different bands,
the lower frequency determines which high-pass and the higher frequency determines which low-pass
to use, thus a "frequency window" is opened which fits both RX (of course, during TX, the TX freq
determines the LPF).

For newer Anans (e.g. Anan-7000) this is not possible, since the RX has switchable *bandpass*
filters. Two RX on two different bands with the same ADC is only possible if you by-pass
the band-filters (what you normally won't want) so what I do at the moment is to use the
bandpass for the first RX and the second one gets little signal.

Bottom line: send two frequencies flow and fhigh. During RX this is the highest and lowest frequency
of all active RX,
during TX both frequencies are equal and match the TX freq.

Then, do HPF switching according to flow and LPF switching according to fhigh. If both flow and
fhigh fall into the same band (this is always the case for TX) you get the "old" behaviour.

Or am I missing the point here?

[Alan Hopper]

Hi Christoph and All,

to clarify what spark does with the standard filter, it assigns a bit to each band and sets any that are being used (often more than 2), the resulting word is then used as a key into a lookup table to get the control word to send to the filter.  This way it can cope with any mixture of lowpass, highpass, bandpass and other special cases.  A lookup table has to be created for each filter arrangement.

 I just brought this up as much of the discussion assumes one band is being used and only one frequency is sent to the io board.  If someone wanted to emulate what spark does in the io board there is not currently the data being sent to do it. Maybe there is no real desire for this so please treat just as food for thought.

73 Alan M0NNB

[James Ahlstrom]

Hello Alan,

I do understand that Spark uses multiple receive bands, and I have every intention of supporting this in the protocol. When you set a bit field for the bands in use, how wide is the bit field?

Jim

N2ADR

[James Ahlstrom]

Hello Christoph,

On Wednesday, June 28, 2023 at 4:53:46 AM UTC-4 "Christoph v. Wüllen" wrote:

Bottom line: send two frequencies flow and fhigh. During RX this is the highest and lowest frequency
of all active RX,
during TX both frequencies are equal and match the TX freq.

Then, do HPF switching according to flow and LPF switching according to fhigh. If both flow and
fhigh fall into the same band (this is always the case for TX) you get the "old" behaviour.

Yes, that makes sense. The only awkward part is that frequencies in the IO board are five bytes, and the HL2 only sends one byte at a time.  And the actual Rx frequency is not really known. The Rx frequency sent to the HL2 is the center frequency, and the user may be tuning above or below that frequency. 

What would you think about sending a high and low band index instead. A band index fits into one byte. We could send the 5-byte Tx frequency and an optional high and low Rx band.

Jim

N2ADR

[Alan Hopper]

Hi Jim,

thanks for considering this, it may well be something that is never required.  I have attached a config file used for your filter board, the first section describes the bands and tx output values (I have never tried to deal with multi band tx), the second section is every combination of the bands with an rx output value. Internally to spark the bitfield is uint32 but that was purely chosen to work on 32 and 64 bit platforms and is over the top for existing filters.  I currently send tx frequency to the io board with any transverter offset included (i.e. not what is used for the standard filter), there is obviously a very much greater number of possible bands in this case. I've not thought this through enough to make a useful suggestion, I do know that the low level of spark needs to know all rx frequencies, the best guess tx frequency (typically the last one tx'd on) and transverter offset. I do have a personal use for the io board as I'd like to use hf and a 2m xverter with a single HL2 on my /mm station but again am only just getting up to speed but looking forward to it.

73 Alan M0NNB

[James Ahlstrom]

Hello Reid,

On Tuesday, June 27, 2023 at 4:30:54 PM UTC-4 scumballc.. wrote:

I think we are over complicating something which should be quite simple,

It is simple to program features for Thetis.  It is not simple to invent a protocol that is easy for an amateur to program in the Pico, and that enables the amateur to switch among several SDR's without worrying about how each sends bytes.

possible being driven by the desired to control antenna selection via the frequency.

Yes, it is part of the design to send the Tx frequency instead of the Tx band. That was discussed on this group previously. The Tx frequency  is more general and can be used to pre-tune an antenna tuner or a loop antenna. Given the Tx frequency, the Pico can figure out the Tx band.

My requirement for Thetis is to be able to select Rx and Tx antennas pre band. Thetis already has all the logic and it would normal talk to the hardware via Protocol 1 to preform the functionality. I would just like a register to pass that information.

I would also like it combined into one byte to make it atomic, so there is not chance of something happening in between the transmission of two bytes. As the I/O hardware will be responsible for switching between receive and transmit aerials, there is the potential for an accident if only one aerial selection takes place.

 

OK, is four bits of antenna selection enough?  How about this, which is based on your previous post: The upper nibble is the Tx antenna for the band, and the lower nibble is the Rx antenna. The band is selected by the Tx frequency. Antennas are 0 to 15 inclusive. Of course, both nibbles could be the same. The default byte is 0x00 and means the first antenna for Rx and Tx. When the user changes bands, the SDR sends the byte for that band. The Pico would use this byte in the event that there were multiple antennas for a band.

One other question, now that register locations are read/write, what is the register layout regards the transmission of the frequency information?

So far, the Tx frequency is five bytes in registers MSB 0, 1, 2, 3,  13 LSB. The first four registers are static buffers, and the Tx frequency is recorded when register 13 is written. Now that we can read registers, it would be better if the five registers are sequential and are only used for the Tx frequency. But changing them would be inconvenient for existing Pico programs, if any. 

Jim

N2ADR

[Reid Campbell]

Hi Jim,

On 30/06/2023 17:16, James Ahlstrom wrote:

Hello Reid,

On Tuesday, June 27, 2023 at 4:30:54 PM UTC-4 scumballc.. wrote:

I think we are over complicating something which should be quite simple,

It is simple to program features for Thetis.  It is not simple to invent a protocol that is easy for an amateur to program in the Pico, and that enables the amateur to switch among several SDR's without worrying about how each sends bytes.

possible being driven by the desired to control antenna selection via the frequency.

Yes, it is part of the design to send the Tx frequency instead of the Tx band. That was discussed on this group previously. The Tx frequency  is more general and can be used to pre-tune an antenna tuner or a loop antenna. Given the Tx frequency, the Pico can figure out the Tx band.

I think the problem is requiring the potential user to build their own code and many will not be comfortable with that. Would it be possible to consider some NVRAM solution with a simple UI, written in python, to allow a limited configuration of the IO board?  

My requirement for Thetis is to be able to select Rx and Tx antennas pre band. Thetis already has all the logic and it would normal talk to the hardware via Protocol 1 to preform the functionality. I would just like a register to pass that information.

I would also like it combined into one byte to make it atomic, so there is not chance of something happening in between the transmission of two bytes. As the I/O hardware will be responsible for switching between receive and transmit aerials, there is the potential for an accident if only one aerial selection takes place.

 

OK, is four bits of antenna selection enough?  How about this, which is based on your previous post: The upper nibble is the Tx antenna for the band, and the lower nibble is the Rx antenna. The band is selected by the Tx frequency. Antennas are 0 to 15 inclusive. Of course, both nibbles could be the same. The default byte is 0x00 and means the first antenna for Rx and Tx. When the user changes bands, the SDR sends the byte for that band. The Pico would use this byte in the event that there were multiple antennas for a band.

I think that sounds fine but I would request a master register. This register would OR'ed with the current band selected register to produce the final result. That would allow the best of both world's where the SDR software can take control when it already has the aerial change over functionality.

One other question, now that register locations are read/write, what is the register layout regards the transmission of the frequency information?

So far, the Tx frequency is five bytes in registers MSB 0, 1, 2, 3,  13 LSB. The first four registers are static buffers, and the Tx frequency is recorded when register 13 is written. Now that we can read registers, it would be better if the five registers are sequential and are only used for the Tx frequency. But changing them would be inconvenient for existing Pico programs, if any.

I think we are at the early days and the on going development is making us rethink the protocol. I'm happy to change my code to apply a more uniform protocol. I think Alan is the only other one who has produce code, so if he is happy, I would make the changes.

I have one other thought on the protocol. We receive a total of 4 bytes every time we read from the IO board. In a case were continuous information is required, i.e. reading the power and SWR from a connect amp, this should all come from the same read. We also should consider fault/error flags.

To make this as flexible as possible, a block of 7 registers should be assigned with the Status/error/fault one in the middle of the block. Assume the address range is 8 to 14, with 11 be in the status register. A read of register 8 would return the 3 bytes of data plus the status in the last byte. A read of 11 would return the status in the first byte plus 3 more data bytes.

After two reads we have a fast recovery of the Status/error/fault byte plus 6 other bytes of data which can be user defined based on what the IO board is used for.

Cheers 

Reid
Gi8TME/Mi0BOT 

Jim

N2ADR

--
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/95acc767-f768-4e72-a2fe-3e156c69b09bn%40googlegroups.com.

[Reid Campbell]

Hi All,

I though I would post a picture of the I/O board in the 40mm case to show that an end plate should be possible for this case type.

Cheers 

Reid
Gi8TME/Mi0BOT

On 30/06/2023 17:16, James Ahlstrom 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/95acc767-f768-4e72-a2fe-3e156c69b09bn%40googlegroups.com.

[David Taylor]

On 05/07/2023 12:42, Reid Campbell wrote:
> Hi All,
>
> I though I would post a picture of the I/O board in the 40mm case to show that
> an end plate should be possible for this case type.
>
> Cheers
>
> Reid
> Gi8TME/Mi0BOT

That looks promising, Reid.

Suggestion: leave off the DB9 connector in manufacture and let the user add it
afterwards if required. Makes it a "kit", not an assembled item.

73,
David GM8ARV
--
SatSignal Software - Quality software for you
Web: https://www.satsignal.eu
Email: david-...@blueyonder.co.uk
Twitter: @gm8arv

[jason kitchens]

On my HL2 it clears the 40mm case as well but the pcb is tilted to clear but I also think an endplate could be made.

--
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/0b7aacf9-a696-d3b8-8087-87e47a51ce55%40gmail.com.

[radi...@mail.com]

Looks like phono (RCA) and SMA sockets so close together that it renders the simultaneous use of both of them impossible? Particularly thinking size of an average phono plug body? Ditto if SMA is in use, can't use RCA surely?

I've got 55mm case that contains my first HL2 so think I will be using that. I wonder if it's intended to make end plates for the 55mm case?

If some people want DB9 left off maybe that's an option Makerfabs could offer to the buyer? I'd personally like my IO board to be complete, as I imagine would most others?

Max

[Reid Campbell]

Hi Jason,

There is a slight tilt, about 2mm over the length of the board but I don't think it should be a problem.

Cheers 

Reid
Gi8TME/Mi0BOT

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/CADfPxqHwqHNsXLHuhH7%2BPX6x518Z-VKaDQDKzKg1qE18P4Xzpw%40mail.gmail.com.

[Reid Campbell]

Hi Max,

I have just checked and I can get a phono and SMA plugged in at the same time.

I believe a 55mm end plate has already been laid out and may be supplied with the I/O board from Makerfabs.

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/600ba2f3-8e94-4cf0-9c6e-2e511b2af102n%40googlegroups.com.

[Alan Hopper]

Hi Testers,

there is a test version of spark here  version 2.0.963 (google.com) for all platforms that has both frequency sent to the board and a control for rx source in radio settings.

73 Alan M0NNB

[James Ahlstrom]

Hello Reid,

OK, is four bits of antenna selection enough?  How about this, which is based on your previous post: The upper nibble is the Tx antenna for the band, and the lower nibble is the Rx antenna. The band is selected by the Tx frequency. Antennas are 0 to 15 inclusive. Of course, both nibbles could be the same. The default byte is 0x00 and means the first antenna for Rx and Tx. When the user changes bands, the SDR sends the byte for that band. The Pico would use this byte in the event that there were multiple antennas for a band.

I think that sounds fine but I would request a master register. This register would OR'ed with the current band selected register to produce the final result. That would allow the best of both world's where the SDR software can take control when it already has the aerial change over functionality.

The IO board recognizes 23 bands and that requires 5 bits, so I don't think all this will fit into a byte. If you don't like the above protocol, please suggest another, but specify the exact layout of the byte and how it is to be interpreted by the Pico.

I think we are at the early days and the on going development is making us rethink the protocol.

I will give some thought to renumbering the registers. I will make a *.h file with register names to make things easier for SDR authors.

 

We also should consider fault/error flags.

The IO board does not have knowledge of faults unless they come from the input pins or the ADC's, and these are available to the SDR software. What circumstance would require fault/error flags?  

Jim

N2ADR

[Steve Haynal]

Hi All,

There is quite a bit of interest in this board on the Facebook group. They are considering doing their own run. Jim and others, what is your plan for production and sales? My opinion is that things will go smoother if there is one source for the mostly assembled board. Since Makerfabs did the prototype run, they are a good option. They can also do some testing of the board. To me this has less potential for problems compared to just sending the board and BOM out to any small batch manufacturer in China as currently being discussed on the Facebook group.

73,

Steve

kf7o

[Reid Campbell]

Hi Jim,

On 06/07/2023 11:03, James Ahlstrom wrote:

Hello Reid,

OK, is four bits of antenna selection enough?  How about this, which is based on your previous post: The upper nibble is the Tx antenna for the band, and the lower nibble is the Rx antenna. The band is selected by the Tx frequency. Antennas are 0 to 15 inclusive. Of course, both nibbles could be the same. The default byte is 0x00 and means the first antenna for Rx and Tx. When the user changes bands, the SDR sends the byte for that band. The Pico would use this byte in the event that there were multiple antennas for a band.

I think that sounds fine but I would request a master register. This register would OR'ed with the current band selected register to produce the final result. That would allow the best of both world's where the SDR software can take control when it already has the aerial change over functionality.

The IO board recognizes 23 bands and that requires 5 bits, so I don't think all this will fit into a byte. If you don't like the above protocol, please suggest another, but specify the exact layout of the byte and how it is to be interpreted by the Pico.

OK, you have the 23 registers to cover all the bands. What I'm suggesting is one extra "Master" register which is OR'ed with the one designated by the current band. This allows the master to select the aerial if all the other band resisters are zero and the SDR handles the aerial by band selection by itself.

I think we are at the early days and the on going development is making us rethink the protocol.

I will give some thought to renumbering the registers. I will make a *.h file with register names to make things easier for SDR authors.

 

We also should consider fault/error flags.

The IO board does not have knowledge of faults unless they come from the input pins or the ADC's, and these are available to the SDR software. What circumstance would require fault/error flags? 

I can think of one use case with the Hardrock amp. I believe it has a serial interface, so the I\O board could read status, power and SWR via that interface. A SWR trip could raise the fault flag, so informing the SDR software of an issue. This is particular important for remote operation.

I was talking to a ham today who has a home brew amp after his HL2. He is interested in the I/O board becoming his controller to select LPFs. The uses for the board is only limited by people imagination.

Cheers 

Reid
Gi8TME/Mi0BOT

Jim

N2ADR

--
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/faf97de9-a0c0-4095-9e91-074adaf39718n%40googlegroups.com.

[Ed Grafton]

Steve, that FB post just came back up because someone commented that they are interested. It was the post that got me onto the idea of production. 

I wish I could do more with the group, but am taking care of my mother up in Mass. It's been a rough 2 1/2 months.

Ed

[radi...@mail.com]

That's great Reid. Probably I thought too close because I can now see the photo was taken slightly low angle and most likely makes the two sockets look a bit closer together than they are. That's good because when I bought my last HL2 in the latest batch I also bought a spare 40mm case so might transfer my previous the Build 9 board into that too if the end plates become available for 40mm.

Best

Max

[ron.ni...@gmail.com]

Just remember that the lowest common denominator of a protocol is important for interoperability compatibility.  A lot of SDR apps are not going to be aware of all these possible amplifiers and other optional antenna equipment, and are only going to send the most basic data (maybe only the frequency?), if anything, over I2C.  So the common denominator protocol has to include almost non-of-the-above control settings as a requirement.  My app on a tiny display has room for a "tune" button, and maybe an antenna switch, without hiding stuff in layers of menus that nobody will find or ever use.
73,

Ron

n6ywu

[James Ahlstrom]

Hello Steve,

>>There is quite a bit of interest in this board on the Facebook group. They are considering doing their own run. Jim and others, what is your plan for production and sales?

Makerfabs requested that I create a way to test the IO boards. I am working on a pogo pin test jig. I am finding it difficult. Meanwhile, I have had little feedback from the testers. Most have just reported success with the test pattern on the io pins. I was hoping that someone would test the UART. There is no problem with the  software that runs on the IO board, although we may renumber the registers.

We can make a production run now if Makerfabs will ship without testing. What is your advice?

Jim

N2ADR

[Reid Campbell]

Hi Jim,

I noticed a small issue with placement of the 9 pin connector, see pic attached. It should be at the edge of the board to allow the screws on either side to provide support. I would only consider it if you were to spin the board for other reasons. It can be compensated for with a couple of nuts but would require a longer thread on the stand-off used for locking the plug to the socket.

What tests would you like to see for the UART? If the traces ring out from the Pico to the input protection and the output driver chip, it should just be a matter of programming the Pico. I just noticed the input don't look like they have protection for negative voltage, else RS232 input could have been handled directly. I assume the Pico has protection diodes but I wouldn't like to rely on them.

If you let me know what type of UART test you are thinking of, I'll try and give it a go.

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/9acdd41c-cf5e-4f46-8338-c11c3ea53f08n%40googlegroups.com.

[James Ahlstrom]

Hello Reid,

I noticed a small issue with placement of the 9 pin connector, see pic attached.

I used this 9-pin connector LD09P13R4GX00LF  and it does go to the edge of the board. If your board is from Makerfabs, we need to tell them that substitute parts must go to the board edge.

What tests would you like to see for the UART? 

As you said, the Pico UART is not able to handle standard UART voltages of +/- 8 volts. So the UART must not be connected to a PC or USB serial device. The IO board UART signals are +5 and zero volts. This is a "standard" for communication between microprocessors.  So to test the UART you need a microprocessor target. I think the HR50 amp has such a microprocessor.

Jim

N2ADR

[Reid Campbell]

Hi Jim,

On 08/07/2023 15:00, James Ahlstrom wrote:

Hello Reid,

I noticed a small issue with placement of the 9 pin connector, see pic attached.

I used this 9-pin connector LD09P13R4GX00LF  and it does go to the edge of the board. If your board is from Makerfabs, we need to tell them that substitute parts must go to the board edge.

Yeah, Makerfabs must have used what they had to hand. Good that there is a specific part to solve the issue.

What tests would you like to see for the UART? 

As you said, the Pico UART is not able to handle standard UART voltages of +/- 8 volts. So the UART must not be connected to a PC or USB serial device. The IO board UART signals are +5 and zero volts. This is a "standard" for communication between microprocessors.  So to test the UART you need a microprocessor target. I think the HR50 amp has such a microprocessor.

The easiest way to test would be with a loopback. I'll see what code is out there for the Pico in relation to the UART and stand on their shoulders.

Cheers 

Reid
Gi8TME/Mi0BOT

Jim

N2ADR

--
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/1aef5035-39c9-460d-a89a-9fd8d1b4f7fen%40googlegroups.com.

[Steve Haynal]

Hi Jim and Ed,

Sorry, I didn't notice that the Facebook post was old, but there is still probably a lot of interest. I really don't have any good wisdom or advice regarding testing or when to go to production. Any testing is better than none. The simpler the board, the more likely things will be okay just with visual inspection, or not as costly to exchange if there is a problem. You should discuss this with Makerfabs.

One other good reason to use a place like Makerfabs is that they will handle fulfillment and exchanges. That can be whole lot of boring work after one or two dozen boards if you try to do it on your own.

73,

Steve

kf7o

[James Ahlstrom]

Hello Ron,

I completely agree. The common denominator protocol must consist of only the most basic data. A user should be free to change their SDR app and still have their Pico code operate unchanged. Otherwise, we don't really have a Protocol. Or, as someone once said, the nice thing about protocols is that there are so many.

Jim

N2ADR

[James Ahlstrom]

Hello Group,

I decided against changing the Tx frequency register numbers because this would renumber most registers. The SDR software sends the Tx frequency so there should be no need to read it except for debug. And reading the four contiguous registers gives the frequency within 128 Hertz. I did change the antenna tuner register from 14 to 7. This makes it contiguous with the input pin register and the newly added fault register. Please write your code using the register names shown in the github page. The names are also in i2c_registers.h.

I did not add the per-band antenna selection because I have no agreed protocol for it. I did not add the low and high receive band index because I am working on the correct form of the index.

Jim

N2ADR

[Reid Campbell]

Hi Jim,

I had a play with the UART on the Pico and got a loop back going which took the 5V signal from Pin 1 J4 and fed it back in to Pin 1 J8, the UART input.

I formatted a Yaesu CAT command (FA<Frequency>;) from the frequency data sent over the I2C and sent it out the UART. I was able to receive it via the loop back and sent it as a debug message to the USB serial comms channel.

I'm happy that that part of the circuitry works.

I believe that a limited configuration of the I/O Board should be possible via the USB port and a simple terminal program like Putty on Windows. Something to consider.

Cheers 

Reid
Gi8TME/Mi0BOT

[James Ahlstrom]

Thanks Reid, I am glad to hear that the UART works as I did not test it myself.  I think we are almost ready for production.

Jim

N2ADR

[James Ahlstrom]

Hello Reid,

Regarding the DB9 not reaching the edge of the board, did you get this board with the DB9 from Makerfabs? I was going to complain, but my BOM lists the correct part number. I want to verify what is happening.

Jim

N2ADR

[Reid Campbell]

Hi Jim,

Yes, it was purchased from Makerfabs in the special build for testers run.

Cheers 

Reid
Gi8TME/Mi0BOT

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/e3f59922-41c4-4f3b-a355-b97566d74aecn%40googlegroups.com.

[James Ahlstrom]

Hello Alan,

The HL2 implements multiple receivers and so it makes sense to send either all the Rx frequencies in use or, alternatively, all the bands. But frequencies in the IO board are 5 bytes, and this seems excessive. I think I understand that Spark tries to open up a "hole" in the Rx filters so it can scan multiple bands at once. So I am trying to design a way to accommodate that in the IO board protocol. What would you think of the following:

I propose that the IO board protocol accepts an optional upper and lower Rx frequency code. The frequency code is a 16-bit unsigned integer calculated from the frequency by a piece-wise linear function. This is easy to calculate from the Rx frequency. It is also easy to calculate an approximation of the frequency from the code. Frequencies below 32 MHz will fit into one byte. So if you are on HF,  you just send two one-byte codes to the HL2 to open up your frequency "hole".

I thought about sending the band, but the above is easier for you to program and more powerful. And the "band" approach has problems if bands are added and the band list is no longer in order of frequency.

How does this sound, and will it satisfy your needs?

Jim

N2ADR

On Friday, June 30, 2023 at 12:13:59 PM UTC-4 ahop...@googlemail.com wrote:

Hi Jim,

thanks for considering this, it may well be something that is never required.  I have attached a config file used for your filter board, the first section describes the bands and tx output values (I have never tried to deal with multi band tx), the second section is every combination of the bands with an rx output value. Internally to spark the bitfield is uint32 but that was purely chosen to work on 32 and 64 bit platforms and is over the top for existing filters.  I currently send tx frequency to the io board with any transverter offset included (i.e. not what is used for the standard filter), there is obviously a very much greater number of possible bands in this case. I've not thought this through enough to make a useful suggestion, I do know that the low level of spark needs to know all rx frequencies, the best guess tx frequency (typically the last one tx'd on) and transverter offset. I do have a personal use for the io board as I'd like to use hf and a 2m xverter with a single HL2 on my /mm station but again am only just getting up to speed but looking forward to it.

73 Alan M0NNB

On Friday, June 30, 2023 at 3:58:06 PM UTC+1 jah...@gmail.com wrote:

Hello Alan,

I do understand that Spark uses multiple receive bands, and I have every intention of supporting this in the protocol. When you set a bit field for the bands in use, how wide is the bit field?

Jim

N2ADR

[Mike Lewis]

16 bits, if at 1Hz resolution, would not cover frequencies above 65GHz for transverters. We are using a few bands above 65GHz. Including 122GHz.  Niche audience for sure. If the usage is just band selection limits. The 10, 100, or 1000Hz resultion might suffice.

Mike K7MDL

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

---

From: herme...@googlegroups.com <herme...@googlegroups.com> on behalf of James Ahlstrom <jah...@gmail.com>
Sent: Thursday, July 20, 2023 1:35:38 PM
To: Hermes-Lite <herme...@googlegroups.com>
Subject: Re: HL-2 IO board testing - Receive Mode

 

--

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/1615e9a0-c02f-4362-a81f-14a2802116ban%40googlegroups.com.

[Clifford Heath]

James,

As a long time designer of protocols and information sharing standards, I would ask that you don’t try too hard to pack the data into the fewest bits possible. It simply isn’t necessary. Memory is cheap and we have plenty of compute resource. It is better to make a protocol that’s easier for a human to scrutinise, and one that uses parameters that are orthogonal and allow the recipient of a message some room to interpret what is requested in a way that most suits its own capabilities.

I’ve been quietly watching the talk of packing bits and bytes, and remembering the 1990s with some horror - but we aren’t still living in such resource-constrained times.

I am gearing up to be able to produce new or modified gateware for the HL2, possibly including (for example) a range of digital modes (CW, QPSK, etc) so that SDR software just needs to send the digital bitstream, and the radio can produce and decode the required modulations. In order to support this kind of flexibility, we need to design protocols that are wide-open, and also to allow the software to query and configure the capabilities of the radio in whatever configuration it is currently running. I’m pretty sure that this will require a completely new protocol to be supported, but meantime let’s just let the IO board expose its bare capabilities, and provide it with a message protocol that is flexible to new purposes so far as possible.

Clifford Heath.

[Reid Campbell]

Hi Jim, Clifford,

Maybe we can keep the 5 bytes for frequency but add a purpose byte which specifies what the frequency is means. 1 would be Tx frequency, 2 - Rx 1 and so on.

Cheers 

Reid
Gi8TME/Mi0BOT

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/0F16A90D-BD93-4F13-AD75-FEFAB0986E47%40gmail.com.

[Alan Hopper]

Hi Jim, Clifford &Mike,

thanks for looking at this.  The table approach used in spark will allow more complex setups than just a single hole in the filtered spectrum,  for example a filter board with a bandpass for each band that allowed more than one at a time could open multiple holes. I have no idea if anyone every does this but it seems a shame not to allow it as who knows what an experimenter might want to try. I think sending every frequency is the most flexible.

I have a similar view to  Clifford and wonder if treating the i2c data as a stream rather than letting the i2c registers dictate the protocol might be more flexible.  I have not thought through the data rate requirements so maybe the current approach is needed for efficiency. 

Thinking out load as I write but this just popped into my head :- using the register approach effectively sends two bytes (address and value), if you simply went for a stream approach over one address you would halve the data rate but you could stream 16 bits at a time by encoding them in address and value. pico code takes each write as a 16bit number by combining address and value and can treat it as a 16bit stream that can have some other packet protocol on top.  The higher level packet protocol can the have unlimited cmd ids. Just a thought and probably an unwanted distraction (sorry).

73 Alan M0nnb

[James Ahlstrom]

Hello Clifford,

>>As a long time designer of protocols and information sharing standards, I would ask that you don’t try too hard to pack the data into the fewest bits possible.

I agree that trying pack things into the smallest memory is a bad policy. I did argue against using two nibbles for Tx and Rx antennas. But the real issue is not memory, but the limitation to one-byte writes in the HL2 gateware. And the need to send these writes at intervals, not all at once. And yes, I am looking for a protocol that just sends what the SDR software knows, and leaves what to do about it to the Pico code.

>>let’s just let the IO board expose its bare capabilities

I can write code to let an external program read and write the Pico GPIO pins directly. By external program, I mean something like Steve's hermeslite.py program that runs along with the SDR software and uses port 1025 instead of 1024. But I don't want the external program to have to query the SDR program for things like Tx frequency. The SDR program knows the Tx frequency and should send it itself.

Jim

N2ADR

[James Ahlstrom]

Hello Alan,

OK, let's work on a protocol that sends all ten or so Rx frequencies, not just the lowest and highest. But ten Rx frequencies times 5 bytes per frequency is fifty writes. We really don't need an accurate Rx frequency to choose antennas, and so we need a compact approximate frequency code that covers about 10 kHz to 122 GHz. Ideas anyone?

Jim

N2ADR

[Clifford Heath]

On Sat, 22 July 2023, 04:12 James Ahlstrom, <jah...@gmail.com> wrote:

But the real issue is not memory, but the limitation to one-byte writes in the HL2 gateware. And the need to send these writes at intervals, not all at once.

If that's the real limitation, why don't we fix the gateware? Add a FIFO and maybe some flow control. I'm l sure there is some spare room for improvement in the FPGA. 

I've been working on a mesh enumeration and routing protocol design that allows any node in a mesh to run discovery (like USB enumeration) of the shape of the entire mesh (identity and ports of each node) and also discover, read, and set the parameters of any node. It uses minimal routing resource, but does require some storage of the data by which each node describes itself.

Perhaps some version of this protocol could be implemented in the HL2 gateware and in the Pico to allow full flexibility? In any case I am educating myself to be able to make changes to the gateware.

Clifford Heath 

[Graeme Jury]

Hello Group,

Just thought that I would post on my current filter switching method. I use the 8 bits as the first 3 bits in a 3 of 8 code for Rx and the second 3 bits as 3 of 8 for Tx filter selection. My filters are diode switched so can change in a fraction of a millisecond so cross-band operation is possible. My filter board has an ATmega328 microprocessor on it and communicates with the HL2 via I2C which gives me no problems in a very short interconnection. When using Spark for WSPR I have a band select positions which switches in the 80M Hi pass filter and the Lo pass filter on Tx appropriate for the band being transmitted. The diode switched filter board is for the HL2 only and repeats the filter switching to my linear via a wire for each filter rather than I2C and I lose my break-In CW ability for cross band but otherwise it all works well. Of course the Pico board can be programmed to do the same thing as my ATmega328 and offers another possibility for programming filters.

73, Graeme ZL2APV

[Reid Campbell]

Hi Jim,

I have been thinking about this a bit more and have the following suggestions. Currently we have 5 bytes carrying frequency information. This gives over 274 GHz to a resolution of 1 Hz. If we were to reduce that to 4 bytes, we would have 4.2 GHz at a 1 Hz resolution. Is that enough to cover any requirements for 1 Hz resolution?

To cover the cases that require greater frequency coverage, we specify a reduced resolution, 10 Hz, 100Hz or 1KHz. 4 bytes at 1K resolution would give 4.2 THz. Would that cover potential experimental work?

The resolution information could be specified, along with usage information, in a single byte. The format could could be:

Bit 7|6 - resolution
Bit 5|4|3|2|1|0 - Usage

The resolution could take the form:

00 - 1KHz
01 - 100Hz
10 - 10Hz
11 - 1Hz

The usage would start at

0 - Current Tx frequency - as it currently is. That would give 63 usage terms but if we needed more, 111111 (63) could be a continuance flag and a new byte would define the usage.

This would give the following change to the protocol

Byte 0 - MSB of frequency
Byte 1 - Second MSB of frequency
Byte 3 - Third MSB of frequency
Byte 4 - LSB of frequency - Writing this byte specifies the frequency operation to the Pico
Byte 5 - Resolution and usage information

I have gone with '00' being a 1KHz resolution to set a default for byte 5 of 0. This would limit the amount of frequency updates over the I2C as only after a 1KHz frequency change, would the Pico need to be informed. Do we need 1Hz updates?

The uses for the frequency that I can come up with at the minute is band selection, ATU tuning and Magnetic Loop tuning. I would have though the 1KHz would be a close enough frequency? What have other people got in mind for their I/O board.

I would see 1Hz resolution being useful for specifying the LO of a transvertor or some frequency correction.

It would be interesting to have other opinions as we are getting close to have a product on the shelves.

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/4ab51234-49fa-496d-84d5-ed25d0e8ca81n%40googlegroups.com.

[James Ahlstrom]

Hello Ed and Group,

I think we are ready to move to production. I am working on a test fixture that Makerfabs can use to test the boards. It is almost ready. But how many boards should we make for the initial run? Does anyone have an idea of how much demand there is?

Jim

N2ADR

[James Ahlstrom]

Hello Alan,

>>I think sending every frequency is the most flexible.

OK, how about if we send every Rx frequency at reduced precision in two bytes. There could be an array of frequencies. Zero frequency would be the default, and means that the frequency is unspecified. The Pico could read the array, look for non-zeros and decide what the filter arrangement should be. The two-byte code would be precise enough to determine the band, and probably better. 

Is this OK? And how big is the array? How many receivers can the HL2 have? 

Jim

N2ADR

[James Ahlstrom]

Hello Group,

The protocol is not finished, but I think we need to do some renumbering now before boards start shipping to users. I made the change we discussed earlier, namely that the Tx frequency registers 0, 1, 2, 3, 13  are now 0, 1, 2, 3, 4. If the Tx frequency is less than 4GHz, it can be obtained in one read. Please see the documentation at https://github.com/jimahlstrom/HL2IOBoard.

Jim

N2ADR

[Ed Grafton]

Jim, I counted 126 people interested when the subject first came up. I would suggest an initial batch of 50 to wet the whistle out there & guarantee that they sell out. Then, I would guess it's up to Makerfabs for future production schedules. As a guess, I would say that about 250 should sell the first year.

Ed

[Colin Larsen]

I'm in please, how do I get added to a list? Or will it just be first in first served at MF?

Colin

ZL2FL 

--

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/a44198c5-ead7-4b25-b73a-be6c29ceb930n%40googlegroups.com.

[Tom Cooleen]

Count me in for 2 of the I/O boards

Tom , K2TC

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

[Clifford Heath]

> On 25 Jul 2023, at 10:42 pm, Reid Campbell <scumballc...@gmail.com> wrote:
> To cover the cases that require greater frequency coverage, we specify a reduced resolution, 10 Hz, 100Hz or 1KHz. 4 bytes at 1K resolution would give 4.2 THz. Would that cover potential experimental work?
>
> The resolution information could be specified, along with usage information, in a single byte. The format could could be:
>
> Bit 7|6 - resolution
> Bit 5|4|3|2|1|0 - Usage
>
> The resolution could take the form:
>
> 00 - 1KHz
> 01 - 100Hz
> 10 - 10Hz
> 11 - 1Hz

> It would be interesting to have other opinions as we are getting close to have a product on the shelves.

So the resolution figure moves the decimal point? What an innovation, we need a name for this new numeric format. We could call it something like “floating point”, that sounds cool…

Seriously though, are we still arguing over a bit here and a byte there?

Choose a format with milli-hertz resolution and THz range and let the computers do the arithmetic. That’s what they’re for.

Clifford Heath

[smit...@gmail.com]

Two IO boards for me too.

 

Thanks,

 

Rich W1EZ

 

From: herme...@googlegroups.com <herme...@googlegroups.com> On Behalf Of Tom Cooleen
Sent: Tuesday, July 25, 2023 5:48 PM
To: Colin Larsen <colin....@gmail.com>
Cc: Hermes-Lite <herme...@googlegroups.com>
Subject: Re: HL-2 IO board testing - Receive Mode

 

Count me in for 2 of the I/O boards

 

Tom , K2TC

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

[Jean-Baptiste GALLAUZIAUX]

Count me for one HL-2 IO board.

73

Pierre

FK8IH

[VU3NXI Siddhalingesh Basawanal]

Hi, I am in. Please count me for one HL-2 IO board.

73

Sid VU2YYF

[Ed Grafton]

The boards will be sold through Makerfabs, just like the HL-2. No need to post here. There will be an announcement when they are ready for order.

Thank you,

Ed