How hard would it be to report the HR-50's PEP, temp, and SWR?

[Bill Cox AK3Q]

Sorry for abusing this list, since this info is all available online, but in case others want to follow along, I'm posting questions here.

The first 19 interface boards from the HL2 to HR-50 are already assembled and have only one level shifter installed, so they can only tell the HR-50 what to do, not ask the HR-50 to report telemetry.

If I were to populate the other level shifter, would that enable the HL2 to read responses from the HR-50?  Would I need to patch the gateware, or is this controlled by a microcontroller?  I can help either way, since I speak C, C++, Python, Verilog and VHDL fluently.

Would we have to modify the protocol used to talk to the HL2 to report telemetry from the HR-50?  Would this be bad?

Could I patch Quisk to enable display of the additional telemetry?  It would also be trigger auto-tune on the HR-50 so we can tune remotely.  I also spent too much time manually tuning output levels to keep the output power from the HL2 between 2.1 and 2.3W, except for 20m, where I aim for 3W.  I'd be interested in automating this, and I don't think it would require any change in the HL2.

73

Bill ak3q

73,

Bill ak3q

[Matthew]

I think a good way to do this would be a micro controller attached to the i2c2 lines on the HL2. The micro controller can talk to the HR50, package up the data then send it over the i2c2 bus to the FPGA, then to the PC. The protocol provides a "pass-through" to allow PC hardware to communicate on the i2c2 bus. This is how PC software sets the PA bias. Hermeslite.py uses port 1025 and allows you to experiment with this whilst running your chosen PC software (on port 1024). This is good for getting your head round how it all works.

In my linHPSDR fork I have written C code to communicate with hardware on the i2c2 bus. I think Quisk is flexible enough to allow you to figure something out on the software end (and already has a lot of the i2c code I think).

This means no Verilog code needs to be changed/added and leaves space in the FPGA to do DSP rather than tasks perfectly suited to a micro controller. Steve has in the past indicated he prefers this approach.

I am working on PCB to measure power, monitor PA current, shutdown 48 V if necessary etc (for typical 100 W LDMOS power amplifiers). I will use the method above with a simple TinyAVR to send data back to the PC. No Verilog modification required.

73 Matthew M5EVT.

[si...@sdr-radio.com]

A generic update to the HL2 protocol would be very interesting.

 

Simon Brown, G4ELI

https://www.sdr-radio.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/d6f8c423-fd70-4d74-9d6c-bfc25ec5c283n%40googlegroups.com.

[Steve Haynal]

Hi Bill,

Currently the UART code is very specific to the HR50 and only sends band change information. It is based on a contribution by JI1UDD. It does not receive information.

In the future, I'd like to have a generic read/write UART pass through. This would enable software to send and receive basic UART information to any device. It wouldn't tie us to the HR50. 

73,

Steve

kf7o

[DL1YCF]

The HL2 to PC communication is based on the HPSDR protocol

so it can be used with standard HPSDR programs. The HL2

already „hi-jacks“ several data fields to report the

temperature, the TX fifo status etc. It would be easy

to add further „Command+Control“ packets

(e.g. with C0=00101xxx and above) to report further

data, but I do not know for 100% whether these are then

silently ignored by all the HPSDR software on the market.

If so, one could add this to the protocol and „HL2 wise“

HPSDR software could easily make use of it.

The other option is to overwrite the HL2 temp, fwd-pwr and

rev-per values with the HR50 ones if these are available.

The advantage is that then possibly „HL2 unaware“

SDR software could display reasonable values.

Yours,

Christoph.

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/027401d79e96%240d254bb0%24276fe310%24%40sdr-radio.com.

[James Ahlstrom]

I am in complete agreement with Matthew here. The HL2 protocol already has provision to read and write the I2C bus. The I2C bus is available at the jumper that connects the filter board to the HL2. So we can make a new jumper board with an extra couple of centimetres of board space to provide room for a microcontroller that speaks I2C , or another I2C bus chip or I2C extender chip. Then the PC reads and writes the I2C bus, the data appears at the jumper board and is available to the microcontroller or other chip. No changes to the gateware are required or desirable.

Jim

N2ADR

[Bill Cox]

SGTM.  I'm interested in helping to design this if needed.  What is the right approach?

Would you make this part of the filter board build, or make it a separate build?  I guess my preference would be to add this to every kit that has the ability to transmit at 5W, so adding it to the filter board kit may make sense.  Alternatively, it could be a separate kit, to keep the overall cost lower for folks who do not need it.

There seem to be at least 4 different places where we could put the microcontroller: the connector board to the filter board, on the filter board itself, on the back plat, or on a custom interface board attached to the DB9 connector, similar to Steve's level shifter board.  What is the right approach here?

My 2nd HL2 arrived yesterday, and I already have it up and running, with one of Steve's level shifter boards installed, controlling the HR-50.  I've also ordered a Ukrainian transverter to use with the 2nd HL2.  I'll likely need an ATU downstream from the transverter anyway, and maybe I can find one that has a serial port for reporting telemetry.  It would be awesome to control either device from the same DB9 interface.

What about the software side?  Which package is the best place to put the control logic?  E.g, does Quisk leverage hamlib to talk to various rigs, or is it stand-alone?  It would be nice to put this control logic in a library that is already linked into the various SDR applications.

73

Bill ak3q

--

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/3776bd83-a57a-473d-aa50-2d139164ba58n%40googlegroups.com.

[James Ahlstrom]

There isn't any room on the filter board itself, but each of the other three locations is possible. I have had bad luck running long I2C wires. These should be kept short, especially around RF, so my first try would be the filter board connector. As far as the software, Quisk supports Hamlib and other interfaces, but I don't yet understand what is required.

But Matthew has already started this project, so he has already figured this out. And I lack experience with the HR50 amp interface. What are you doing Matthew?

Jim

N2ADR

[Graeme Jury]

The long I2C problem has been addressed see here and I feel that the microprocessor should be away from the HL2 but the I2C processing should be in the HL2 case so a robust I2C signal is available. It works for my filter switching in the presence of 100W RF and I use the same micro chip as an arduino so development can be done on one of these.

73, Graeme ZL2APV

[Matthew]

I would suggest that modifying the n2adr jumper and placing a micro controller on the i2c lines (pin 16 and 17) would make sense. I looked about a month ago and a TinyAVR is still one of the cheapest microcontrollers around. There are lots of much more powerful ones, but for something simple like this I think a TinyAVR would be fine (and leave some room for future adaption) and keep cost down. The ATtiny414 was even in stock in some place (when I looked about 3 weeks ago). The same can't be said for other micros at the moment. For 9600 baud you can simply jumper across to the level shifter board. However, if this went to manufacturing, 2 PCBs doesn't make sense, so putting the level shifters onto a modified n2adr jumper would probably make sense.

For my purposes, I am designing a small board to measure current (up to 8 A), turn on/off FET drain supply, temperature (LM35) and control some fans. This is all for the HL2-MRF101. But I hope it will be generic enough that people who buy cheap PA kits from internet sites could also benefit from this. I haven't got as far as defining read addresses on the i2c bus etc. But I imagine there would be some overlap between data from the HR50 and this module. For your purposes, I don't think you need any ADC/measurement, it is simply about translating RS232 comms to a suitable i2c format. I presume all the measurements you want are available on the HR-50 RS232 interface?

I imagine we would create a standard i2c address and read address for things like; ext PA current, ext PA temp etc and publish this on the HL2 wiki.

I plan to add a PA to my hl2-xvtr. I imagine I will use something very similar to what I describe above.

As far as interfacing into PC software, most software (I think) already has HL2 i2c comms written into the software so it is just about writing a wrapper on top of this. It will require each PC developer to write their own wrapper.

73 Matthew M5EVT.

[Bill Cox]

Hi, Matthew.  Your ham radio work all seems super fun.  It sounds like you're already designing the card we need, ore close to it.  I agree the level shifters on the jumper board seem to make sense.

Is this something we can or should work on together?

73

Bill ak3q

--
You received this message because you are subscribed to a topic in the Google Groups "Hermes-Lite" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/hermes-lite/_Xsh43jTiJc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to hermes-lite...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/62444248-4835-4f78-ad20-73f0dbb31381n%40googlegroups.com.

[Bill Cox]

Your PA500 project looks super-cool.  If you get it working OK, I think I'd like to build one.

Extending the I2C bus with the bus driver chip is cool, but I'd prefer a programmable I/O interface so that my HL2 can talk to a wider set of devices.  Would it be possible to control the PA500 over a DB9 cable, with programmable I/O on the jumper board?

73 Bill ak3q

On Thu, Sep 2, 2021 at 11:39 AM Matthew <bal...@gmail.com> wrote:

--
You received this message because you are subscribed to a topic in the Google Groups "Hermes-Lite" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/hermes-lite/_Xsh43jTiJc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to hermes-lite...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/62444248-4835-4f78-ad20-73f0dbb31381n%40googlegroups.com.

[Matthew]

I'm not sure if your PA500 reply was directed towards me. I have no idea what a PA500 is.

The PA that I have built is the HL2-MRF101. I built this last summer and I've been using it on the air for just under a year. This chronology of this is here, here and here. What I am adding is a small module to measure current for this PA, temperature etc. A picture says a thousand words, I've attached an image and schematic.

I'm not sure if this meets your requirement. I suspect it doesn't. However, if I understand correctly, I think the firmware in the micro will have much commonality and there is an opportunity to share efforts in that space.

73 Matthew M5EVT.