Power / SWR Meter, Meter Display Calibration

[Scott Massey]

Hi All,

First post.  I've looked through several message thread and have not found a good way to calibrate the the power and/or SWR meters even though the actual output is in proper adjustment.  Is there a way to set the weighting of the displayed value based on external measurements?  I hope I've not missed it.

Hermes Lite 2, Thetis v2.10.3.3 x64 HL2, No power amp (yet).

Thanks, Scott KE8KYP 

[Steve Haynal]

Hi Scott,

The Thetis HL2 should show a correct SWR. You can try with Quisk to verify there is no hardware issue with SWR measurement on you unit. Some software (like Quisk) does allow you to create a profile by measuring power output with a more accurate device at various levels and then creating a correction table. Although this is for power output, it should indirectly apply to SWR.

73,

Steve

kf7o

[Scott Massey]

Hi All,

I've made some progress but still have questions.  Thanks for the feedback.

I acquired a Micro PA50+ PA.  I've installed MI0BOT's v2.10.3.4-beta3 for HL2 and I can fairly calibrate the HL2's 0-5 watt power meter within the software.  It is working but is there a way to calibrate the power meter to indicate the PA50's output?  In v2.10.3.3 I seem to remember a meter indication in the PA Settings>PA Gain settings that might allow this kind of display but it is grayed out in 3.4.  Is this the place to make this kind of adjustment?  Or am I asking for something that can't be done?

Perhaps a way to make this work would be in the Multi Meter section.  For example, if I could use the cross meter set for the 5 watt indication, the scale would be correct IF I could change the labeling.  The Thetis meter would indicate the 0-5 watt output normally but the cross meter would indicate the PA output.  In my case, it would be a 10x labeling only change for the 0-5 watt meter.

Thanks in advance, Scott KE8KYP

[Rick Langford (N8SDR)]

Simply Not Like your wanting:

that meter (actually all meters) in Thetis Spark, LinSDR, SDRConsole etc. are for internal use to the actual PA section of the hardware it is controlling, your amp is external so no: Use an external meter- I'd look for a low input scalable one that why can use it with amp in bypass more or inline and on 

[Scott Massey]

Ok.  That's kind of what I thought but had to ask.  Thanks for your response.

Perhaps an option can be added to one of the multimeters within Thetis.  To be clear, I don't want to change the scaling of the meter.  The math that calculates power and SWR works fine.  What I'm thinking of is the ability to change the meter labeling by a factor.  I get that the Hermes cannot "see" the output of the PA.  All I am exploring is the possibility of making a convenience indication that can be viewed on one display.  The hardware would not calculate anything differently.  Only the graphics of the chosen meter would be adjustable.

I'll ask the Thetis guys what they think.  It might be a futile ask.

Thanks again, Scott  

[John Williams]

Scott,

The fallacy in your thinking is that the inboard PA will track linearly with your PA-50 amplifier. It may or may not. Probably not. Folks get picky about precision on power readings. Best way is to buy a _reliable_ power meter and put it on the output of the PA-50.

By the way, I made a board in the HL1 timeframe that looked at the output of my 5W amp and fed the comparator input back into the A/D converter. It worked OK at those power levels. I used it on the HL2 for a while but it was not reliable at higher power levels. Kind of a lot of complexity for the effort. I now have my trusty Bird meter that tells me the truth (sort of - no meter is 100% accurate at all times). 

John W9JSW

--
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/a9dbc4f3-6a75-4689-9768-b9876943f2c8n%40googlegroups.com.

[Rick Langford]

I understand what you're asking

Keep in mind even though your trying to represent a x factor rough display

Your external amp is going to vary per band on input power versus output (it's not going to be a linear) transition so 2 watts on 80 might give you say 40w as an example. Chances are very good that same 2 watts on say 40m or 10m input is going to produce something different on output.

So how could one scale for that and ever amp is different so how does that get controlled?

Example that same 2 watts for me produces 875 or more depending on band . Then there is AM mode where carrier can vary depending on ratio selected and again per band.

Again an external meter is your friend here 

Get Outlook for Android

---

From: herme...@googlegroups.com <herme...@googlegroups.com> on behalf of Scott Massey <jmass...@gmail.com>
Sent: Friday, January 19, 2024 4:51:33 PM
To: Hermes-Lite <herme...@googlegroups.com>
Subject: Re: Power / SWR Meter, Meter Display Calibration

 

--
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/rMhhQW-h7Rs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to hermes-lite...@googlegroups.com.

[Ed Grafton]

Maybe Reid could put this in with the IO board, as it has inputs possible. It would require a coupler &  probably a calibration section. 
Otherwise, it really will not be represetitive of what you are actually outputting.

Ed

[Scott Massey]

Hi Everyone,

Thank you all for your responses.  

Hi John,

I understand the fallacy of my request.  It is not a perfect solution because it does assume that the reaction of the PA will always be directly proportional to it's input.  My experience is that it is pretty close (i.e. a 2 watt input makes 20 watts out, 3 watts make 30, etc.).  The PA calibration in settings for Watt Meter for each band significantly improves this response so if the labeling was adjustable, I'm pretty sure this will work at least for what I'm experiencing.

 Hi Service,

I do have an external meter.  Unfortunately, because the way my radios are configured, they are not directly visible.  It's not what I prefer but it's what I've got.

For 20 and 40m (the bulk of my use), the power and SWR reaction is pretty close to each other for my antenna.  I've not tested other bands but I would agree, the response will likely be different.  I suppose a more extensive calibration matrix for an external amplifier could manage the variations but I'm not asking for that.

Hi Ed,

Ideally, I believe this is the best solution.  I have the IO board but haven't jumped into it working it, yet.  I can easily build a bridge and could incorporate a Tiny85 or some other programable controller to output forward and reverse power (and I'd have to figure out the programming) but I still think it's a bit simpler to change the meter scale.  At least it would for the short term. 

I also have future plans to remote into this radio.  Having an indication of external output power, I think would be pretty important since I can't look around and see it's meter.     

   
Again, I appreciate everyone's thoughts on this.  If we were to develop with this concept, how would you proceed?

Thanks, Scott KE8KYP

[James Ahlstrom]

Hello Group,

To measure power and SWR at the output of your external amp you need an SWR bridge that produces zero to three volts for forward and reverse power. Then connect this signal to connector P9 of the N2ADR filter board after you remove R12 and R15. This works without modifying the radio software.

Or you connect the signal to the ADC inputs on the N2ADR IO board. But then the radio software must be modified to calculate and display power and SWR from this new source.

Jim

N2ADR

[Scott Massey]

Hi Jim,

Thank you very much.  I'm going to look at the N2ADR modification but ideally, I'd like to keep the board original.  I am thinking that the IO board could make this calculation independently from the HL2 processes but ultimately the calculation has to be sent out the Ethernet port for the SDR software to display.  From what you've written, I'm thinking the hardware doesn't transmit more than one calculation.  To confirm, are you are you talking about the software/firmware of the HL2 board or the SDR software (i.e Thetis)?  Or both?  My guess is both because an additional register (or two) would have to be translated.

Curious, does the interface for a Hardrock amplifier translate power and SWR for display?

Thanks again, Scott KE8KYP 

[James Ahlstrom]

I think the design would be for the SDR software to read the two ADC values from the IO board, and then calculate and display the SWR itself. But that requires the SDR author to write the code.

Note that the Pico only has one ADC, so the two values are not quite simultaneous. So low pass filtering the DC signals would be helpful. 

Jim

N2ADR

[Scott Massey]

Hi Jim,

My understand of the IO board is it communicates with the HL2 on it's I2C buss.  What I don't know is what can the HL2 do with this information.  I assume the HL2 can do something with this information such as display a value or create an alarm.  I also assume that the Pico could poll the data from two digital inputs, multiplex it and send it on to the HL2.  If that is the case, is it possible that the guys that write the multi-meter program and graphics code could take that data from the I2C buss and use it?  I don't completely understand all of the details but it seems possible.  Is it?

I can build a bridge and pull its information into the IO board and develop a I2C data stream but I don't know how the meter graphics are managed.  Can a multi-meter pull it's data from a HL2 register populated from the I2C buss?  Hopefully, a programmer can comment.

Thanks, Scott KE8KYP

[James Ahlstrom]

The HL2 hardware doesn't do anything with the two ADC voltages. It is just a communication conduit. And the IO board can not decide to send any data.It is strictly an I2C slave. The SDR radio program (Thetis, Quisk, Spark, etc.) must poll (read) the IO board when it wants to know the voltages. The IO board then responds to the read request. It is up to the SDR radio software to do something with the data.

Jim

N2ADR

[Scott Massey]

Hi Jim,

Thanks again for the explanation.  I think I get it.  Do you think this can work:

1. The IO is programmed to receive the forward and reverse measurements from a bridge.

2. In sequence, the Pico performs the ADC calculation on the first port and then the second.

3. These results are written into separate memory locations.

4. The Pico combines the two values into one I2C value.

5. The HL2 polls the I2C value.

6. The HL2 separates the two values and uses them to drive meter processes/graphics.

This presupposes that the HL2 has this ability and the meter graphics can update from the I2C information.  If it can't I'll look for other solutions.

I know the thinking is I shouldn't worry about this but IF a user is going to remote into a Hermes, the user should be able to "see" his complete system.

Thanks again, Scott KE8KYP 

[Mike Lewis]

Scott, I believe you are on the right track, and this is good stuff to discuss.  Here is some refinement info to work on.

 

Conceptually it seems you are treating the HL2 and the SDR app as a single device in your workflow below.  Perhaps you mean the “SDR app” in steps 5 and 6, not the actual “HL2” device?  It makes a big difference. Further you would need to define what you mean by “remoting”. 

 

The SDR app (or a user script) is responsible for requesting the values from the IO board pico via I2C and then display/react however the SDR app author decides. The HL2 is not in the decision tree, it merely converts the i2c bus data to the ethernet stream so the SDR App can get/put values to the pico and/or N2ADR filter boards (separately).  There are timing and data rate concerns.

 

So #5 and # 6 below would be reworded replacing “HL2” with “SDR App”.

 

That is a significant detail since the HL2 is just a conduit, it is up to the SDR app and Pico firmware authors to decide what to do with the values.  There are no HL2 firmware changes required. As there are several SDR apps that support the HL2 and a subset of them currently offer limited support for the pico-based IO board, discussion is directed to the SDR app and any pico code authors, not the HL2 firmware.  There is a set of registers agreed to for the pico and adding more is not difficult, it was designed for that. The SDR apps have to change to leverage the new registers – and still catch up to the existing ones more fully over time if they choose to do so.  

 

You mention the HL2 needs to take care of this SWR process to permit remoting.  You will need to clarify what remoting means to you. Since the HL2 is a headless device, you can argue remoting is always how things are done.  By using the term “remoting”, you want to clarify at what level, and in or outside the LAN.  If “remoting” to you is access outside the local network through a firewall/router, SDR apps can access the HL2 directly via ethernet if proper port forwarding/security work is done, provided the performance considerations are handled (difficult).  Alternately, more robust, some SDR apps have built-in remote capability such as the new Quisk feature for example, or is accessed by a suitable remote desktop app.  Either way, the SDR app or a user script (a modified hermeslite.py for example) has to request and process the I2C values received over ethernet and display the results.  Since the SDR app runs on a “remote” computer separate from the HL2, there are real time considerations for response times, maximum update rates and congestion, and any resulting control type features such as protection and tuning, if any, you want to happen on site. Example: a high power amplifier HI SWR shutdown feature initiated by a SDR app vs the pico code.

 

As Jim pointed out,  The forward and reflected pico ADC sample values are not sampled at the same moment.  Highly variable modulation types like SSB and Tx/Rx transitions that happens during the sampling period will generate false SWR results requiring they be filtered out.  PTT state is easily monitored in the pico (EXTTR) to help with the filtering process and place only good values in the new registers.  Same for a tuning process.  Doing this filtering at the SDR App which has time delays is less precise, especially if truly remote.

 

Once the SDR authors make the changes, if they do, to retrieve this new data, they will have 2 sets of meter data to choose.  They could display either or both.  You can also extend hermeslite.py script and build your own metering UI app that runs in parallel with the SDR apps thus not require any SDR app changes to get what you desire.  Further, is there a case that both meter data sets interact and require action somewhere?  At the SDR app, or on the pico, or both?

 

 

• Mike K7MDL

 

[Scott Massey]

Hi Mike,

Thank you very much for the information.  Specific terms are always important as a project evolves.  I understand the difference between the hardware and software and will endeavor to make that distinction as this discussion progresses.

SDR App is a more appropriate term than the way I used HL2 in my previous messages. Remoting refers to the act of remote controlling the host PC/SDR App from a network connection.  Security would not be part of the SDR App.

I envision a fairly heavily damped power/SWR indication.  I look at the IO Board (and associated IO script) as the process that could average several measurements over a time period to populate the I2C register(s) for the SDR App to read.  My guess is the IO script could process very quickly on the order of hundreds if not thousands of times per second.  I'm ultimately not sure how fast the on IO board Pico can process this kind of program but I would think it would be fast.  I am uncertain if this process would need to be interrupt driven but I tend to think it would not need to be so.  The overall result of the IO script, Pico processing, SDR App program, etc. would be a fairly filtered meter.

Full disclosure, I am a novice programmer.  I am intrigued with the idea of building a hermeslite.py extension that runs parallel but I'm not sure how to begin. It's probably a good way to get my feet wet and later think about the SDR.app integration.  I am mostly a hardware guy that has modified several C++ programs to suit personal needs but I am a much better "solder jockey" than programmer.  I can build a front end process that can read a SWR bridge with an Arduino but I've not jumped into programming a Raspberry Pi.  I know it will be similar but you know how it goes, there is always a learning curve.

I would love to contribute by starting this project but I could use some guidance getting started.  I'm going to look at the hermeslite.py script for clues.  Anything else to get started?

Thanks, Scott KE8KYP               

[Mike Lewis]

I had not looked at the Pico specs before.  Thought I would share my investigation since it is relevant to Scott’s goal and likely many others. 

 

About the ADC I summarized my findings below:

 

Reading the pico ADC specs and other data Raspberry Pi Pico Datasheet, it has a single 12bit resolution SAR ADC with 4 channels, 3 available externally (ADC0=26,ADC1=27,ADC2=28), one that measures internal temperature (ADC3).  It does not have an onboard voltage reference.  The ADCs can operate in polling, interrupt, and use FIFO in DMA mode.  Conversion speed = 2uS, 500,000 samples per second max.  Input range is 0 to 3.3VDC with the Picos’ switch mode power supply at 3.3V (plus noise impacts) used as the reference voltage.  Further reading turns up a data sheet note the effective number of bits (ENOB is 8.64 if everything else was ideal for the full range usage. Grounding will impact this among other factors and the AGND runs under the ADC related pins and can be connected to DGND if high accuracy is not required.  There an amount of offset due to current draw with temperature impacts.  The ENOB (effective number of bits) of 8bits can be improved some by avoiding 4 particular ADC results and control of VCC and VDD noise.

 

On the IOBoard the DGND is connected to AGND and all 3 ADC inputs are unconnected.  Solder a jumper direct to a pico edge connector pad (31, 32, or 34) to use them.  The IOBoard has a 3.0VDC (+/-1%) LM4040DIM3X-3.0/NOPB precision voltage reference on the ADC_VREF pin so the ADC input range is max = 3.0VDC and lower noise than the internal Pico 3.3V.  Using an unused ADC input tied to ground can help determine then noise floor if desired. Separating the AGND for DGND could also be done if you have a better plan to deal with it.   jimahlstrom/HL2IOBoard (github.com)

 

With that, lets keep things simple and assume we get a decent 8 bit accuracy with a range of 0 to 3.0V inputs and assume that is good enough for our needs. Unknown for now is the accuracy of the external FWD and REF power signals.  Let’s also assume they are good enough (It is what it is). Since there is only 1 ADC, the 4 inputs have to be selected one at a time, sampled in turn so it is not possible to get 2 readings at the exact same time so must account for that.  In this case of not using temperature, and connecting ADC2 to ground to get a decent idea of what 0 volts is, we only need to switch between ADC0 and ADC1 keeping their results a bit closer to same time sampling.

 

To throw out another idea, in my external remote wattmeter projects I use one or more external surplus commercial bi-directional couplers appropriate for the power and frequency of interest.  I use a ADL5519 RF Power Detector - sv1afn.com dual 10GHz log RF power detector board from SV1AFN.  I do mostly VHF and microwave so this is handy but there are many lower cost, lower frequency detector boards also.  I get a predictable output voltage for both channels that allows for easy coupler calibration and works for any amplifier chain.  Not many amps come with voltage outputs for Power and SWR calc after all.  You may have power sensors hanging around from old or current remote wattmeter products.  They maybe diode based and require a lot more calibration effort.  This does not address the problem of sampling at the same exact time.

 

The pico board runs complied code generated from C/C++ or Python(microPython) we call firmware.  Let’s use the term script here to refer to the hermeslite.py Python code. The script has examples to access the HL2’s connected I2C busses which in turn connect to various IO objects in and outside of the HL2 main board, one is the Pico board.   SDR app uses the same access.  One useful detail to know is that you can talk to the HL2 on 2 ports.  So while the SDR apps usually connect to a HL2 via UDP port 1024 another process like the script, or the IO Board Control app HL2IOBoard/software at main · jimahlstrom/HL2IOBoard (github.com) can connect via Port 1025.  You should get familiar with that program by using it and looking at the code.  It already reads ADC0, 1 and 2.  Note the unconnected ADC pins input are not really 0.0 for reasons above. As seen below on ADC0, here it is 0.289V.  Max will be around 3.0V.  4095 bits will give 3.0/4095 = 0.0007V per bit.    In addition to the IO Board Control code you might find this useful -  Raspberry pi PICO ADC reading - Stack Overflow

 

 

 

You could extend the Control app to add your own info printing out the ADC average voltages calculate SWR, check for nonsensical results.  IN your Pico code you can stash the filtered sample results in a new “registers”.  Note that registers 25-30 already exist but they raw readings by default.  You can modify the pico code to process the values in these register and thus avoid defining new registers.  SWR can be calculated on the UI side easily enough. If calculated on the Pico you will need want a new register to share that value to the SDR app or script easily.  You will want to decide where you will store and apply calibration for your chosen sensors.  It could be hardcoded, or a UI developed to input or acquire data during a calibration process.  

 

Having built several remote band decoders+power meters on multiple CPU types, the details are the same and burned into my brain. 😊  My last QTH (and soon new QTH)  VHF+ station is built around remote transverters and amps. IF rig is in the shack and all else for 144-1296 is located outside near the antennas connected by ethernet and a few control and low power IF cables) that depend on all of this stuff.  Even the rotator controller is enet controlled from the same desktop monitor/calibration Python UI.

 

While hermeslite.py (see IO Board version link above) is useful I think you will get further faster by starting out with the IO board control program.  Get your Pico build environment setup by reading/watching the many tutorials.  Edit the code with any editor, compile it on the command line is simple enough.  Drop the file on the Pico USB drive at pico boot per the instructions on the IO board page.  You should practice that compiling and uploading the test and main example programs first as a baseline then attempt modifying things.    You can get started very fast by modifying the Control program code on the PC side and simulate or connect pots to 3V for test voltages.

 

• Mike K7MDL

 

From: herme...@googlegroups.com <herme...@googlegroups.com> On Behalf Of Scott Massey
Sent: Tuesday, January 23, 2024 5:53 AM
To: Hermes-Lite <herme...@googlegroups.com>
Subject: Re: Power / SWR Meter, Meter Display Calibration

 

Hi Mike,

--

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/fdefb177-c57a-4577-9c23-1c4ef75e5203n%40googlegroups.com.

[Scott Massey]

Hi Mike,

Thank you very much. Oh, and by the way... WOW!  I've got some work to do.  I'm sure I'm going to have a number of questions.  More later.

Thanks again, Scott KE8KYP

[James Ahlstrom]

Hi Mike,

First, thanks for the excellent description. Let me add one thing. A read of ADC0 performs a read of ADC0 and ADC1 in quick succession. The four bytes are returned in the read request. This is meant for SWR calculation. Similarly, a read of ADC1 returns ADC1 and ADC2. 

Jim

N2ADR

[Scott Massey]

Hi Jim,

You don't happen to have a sample script (partial or otherwise) of the ADC0 read command you are referring to, do you?

Scott KE8KYP

[Mike Lewis]

Scott, the code on the GitHub page already does the ADC reads.  Look at the i2c_slave_handler.c  HL2IOBoard/n2adr_lib/i2c_slave_handler.c at main · jimahlstrom/HL2IOBoard (github.com)   starting at line 166 for the pico side and line 215 for the Control program side code HL2IOBoard/software/n2adr_ioboard.pyw at main · jimahlstrom/HL2IOBoard (github.com) that makes the request and displays it.

 

 

Jim, regarding the 2 ADC values returned each read you mentioned.  Looking at the i2c_slave_handler.c, I do not see in the code where 2 ADCs are read in sequence, I only see 1 ADC channel is read per request.

 

At line 166 for ADC0 for example it reads the ADC with input 0 selected and shifts data into the MSB and LSB registers then breaks.  How does it come back around to pick up ADC1? 

 

On the Python side (begins at line 215) each elif collects the MSB and LSB for 1 ADC only, I do not see how it becomes 2 ADCs read here.  poll_state == 5 at that point so would exit after the one selected ADC is read each update cycle.  

 

I see there are 4 bytes read from the returned pico data but I do not see how more than 2 bytes are filled with ADC data by the slave handler.

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/322f70b7-fe9a-4de9-85a9-b40d44ab780dn%40googlegroups.com.

[James Ahlstrom]

You may be right. I am away skiing and don't have the code. I will check this when I get back. But if it doesn't do ADC0 and ADC1 at once, it should.

Jim

N2ADR

[Reid Campbell]

Hi Scott,

I have been keeping an interested eye on this thread, as I think many people would like the reporting of external equipment through the I/O Board.

I think Jim has a low level interface to access all of the I/O Board's resources, using the I2C protocol.  I think a dedicated interface should be defined to make it easier for SDR software to interface with the results in the future.

As an I2C read of a register will return four 8 Bit values, it would be best to have consecutive registers to limit the amount of I2C traffic. What values should be returned? I would suggest forward power, reverse power, current and temperature. I would imagine a maximum  updating rate to display the values of 10Hz but that might cause to much traffic on the I2C bus, time would tell.

As we are limited to 0 to 255, logarithmic values should be used for the power readings, maybe even the current but linear for the temperature. There are a lot of more mathematical people on the group than me, so please use your talents to devise the correct scaling. 

I can see this going into future versions of Thetis, when the integration with the official Thetis is completed.

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/fdefb177-c57a-4577-9c23-1c4ef75e5203n%40googlegroups.com.

[Scott Massey]

Hi Reid,

I am not sure how quickly the IO board can update registers either but I would think it would be faster than the I2C polling.  Initially, I was going to build the bridge and see what the Pico can output.  I expect some averaging of the bridge data will have to be performed to keep a meter from dancing into unreadability but how that effects the Pico refresh rate is unknown.  Are you thinking about a separate processor feeding the I2C bus other than the IO board or are you thinking of possibly reprogramming the Pico for a limited task? 

As soon as I receive some materials, I was going to concentrate on building the bridge with some initial signal conditioning and use the two ADC inputs of the IO Board (forward and reverse power from the bridge circuit) to feed the I2C buss.  Later, I may try multiplexing more information (temperature, current, Santa shoveling snow, etc.) but not for this first round.

I reasoned that by going this initial route, it simplifies the external wiring to the radio which might lead to others experimenting.  I do agree, time will tell how much traffic the I2C process can handle.

Cheers, Scott KE8KYP

[Mike Lewis]

The Pico can read and stuff the local registers no problem, do some averaging even.  The sdr app polls the registers over i2c. This rate is limited, how much I do not know.  I suspect it is good enough for monitoring the meter by eyeball and yield a smooth enough meter response avoiding false values.

As part of a tuning loop or high swr protection, i would lean toward doing that on the Pico. Tuning is already being done that way.

What sample source do you plan to feed into the pico?  How will you calibrate it?  Will the cal change per band and have multiple sensors?

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

---

From: herme...@googlegroups.com <herme...@googlegroups.com> on behalf of Scott Massey <jmass...@gmail.com>

Sent: Friday, January 26, 2024 6:41:55 AM

To: Hermes-Lite <herme...@googlegroups.com>
Subject: Re: Power / SWR Meter, Meter Display Calibration

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/a6e3adbb-b904-475a-b7c6-d904e64ddd1dn%40googlegroups.com.

[Clifford Heath]

On Sat, 27 Jan 2024, 00:10 Reid Campbell, <scumballc...@gmail.com> wrote:

... 

As we are limited to 0 to 255, logarithmic values should be used for the power readings, maybe even the current but linear for the temperature. There are a lot of more mathematical people on the group than me, so please use your talents to devise the correct scaling.

The design procedure for a logarithmic number system is fairly simple, involving the answers to a small number of questions:

1) Maximum value to be represented? 

2) Minimum value to be represented? 

3) Is a special case of zero desired? 

4) How many distinct values can be represented (255 or 256 in this case)? 

5) Is it desirable sacrifice a little possible precision to include any memorable or distinctive round numbers?

If you think this might get adopted by Thetis upstream, please answer in that context.

Clifford Heath 

[Ed Grafton]

On the N2ADR filter board  Hermes-Lite2/hardware/companions/n2adr/n2adr.pdf at master · softerhardware/Hermes-Lite2 (github.com) at CN 5, you can atatch an external sender by removing R12 & R15. Then, it should just be a recalibration of the Thetis metering software (Easily done in PA Settings>Watt Meter).

I would think it would be much easier than using the IO board.

Ed

[Scott Massey]

Hi Ed,

Does your procedure disconnect the HL2's 5W output measurement.  I may be wrong but that's how I read it.  If not, I agree.  However, if we can monitor both amplifiers, we might be able identify a pending problem(s).  There may be other systems we want to monitor that can use this kind of programming current and temperature like what Reid suggested, antenna switches or reset processes... I don't know what's all possible... but to me, using the IO board seems like a good way to start finding out.. 

It will be harder but I am hoping to learn something.

Thanks, Scott KE8KYP

[Scott Massey]

Hi Cliff,

Good stuff.  I am not sure how this is going to fully materialize but I am anticipating the need for signal conditioning (both analog and digital).  (I am reminded of the statistic class I never used.)  As I get further along, I hope to be able to reach some of you wizzkids for guidance/assistance.

Thanks in advance, Scott KE8KYP

On Friday, January 26, 2024 at 3:58:20 PM UTC-5 cliffor...@gmail.com wrote:

[Ed Grafton]

Yes, it will remove the 5 watt measurement. That could lead to problems in the future. Maybe the IO board could be used to switch between the N2ADR board measurement & an outboard detector. If I remember right, Jim stated that the N2ADR board will only take a VDC signal. Another thing to watch for.

Ed

[Ed Grafton]

** 3VDC**

Ed

[Scott Massey]

Hi Ed,

Good notes.  Thanks.

Yes, 0-3VDC for the ADC inputs.  The bridge I'm planning on using is a 100 watt device with a 0-7VDC output.  I can easily build a voltage divider to match the 3V maximum.   When I did this some time ago, I got at least 100 steps, if memory serves.

Thanks again, Scott KE8KYP

[James Ahlstrom]

On Thursday, January 25, 2024 at 7:06:15 AM UTC-5 K7MDL wrote:

Jim, regarding the 2 ADC values returned each read you mentioned.  Looking at the i2c_slave_handler.c, I do not see in the code where 2 ADCs are read in sequence, I only see 1 ADC channel is read per request.

I am back from skiing and looked at the code. The key is that all HL2 reads are four bytes. When you read REG_ADC0_MSB which is index 25, then  i2c_slave_handler() is called four times for registers 25, 26, 27 and 28. The read of register 27 triggers the read of ADC1. See line 228 where i2c_regs_control++ is used to keep track of the register to read.

Jim

N2ADR

[Mike Lewis]

I guess what am not seeing is where or how the slave handler is called the 4 times.  Presumably from a IOboard i2c read function on the python side but I am not seeing it yet, it looks like reg 25 and 26 only are read to me.

 

From: herme...@googlegroups.com <herme...@googlegroups.com> On Behalf Of James Ahlstrom
Sent: Wednesday, February 7, 2024 12:48 PM
To: Hermes-Lite <herme...@googlegroups.com>
Subject: Re: Power / SWR Meter, Meter Display Calibration

 

 

On Thursday, January 25, 2024 at 7:06:15 AM UTC-5 K7MDL 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/c0dd0132-20c4-405b-a9d9-6a0532561ad4n%40googlegroups.com.

[James Ahlstrom]

The four read requests come from the I2C gateware in the HL2. It is hardwired to request 4 bytes for every read request from Python. Each I2C read only returns one byte. So for a read of register 25 the HL2 gateware does this:

Write the I2C register address as 25; perform four I2C read requests calling i2c_slave_handler() for each one; set a Stop condition. It is up to the client i2c_slave_handler() to increment the register address for each read. See line 228.

So Python requests a read of register 25; the HL2 reads four bytes at 25, 26, 27 and 28; the HL2 replies with a 4-byte array; then Python can throw away any bytes it doesn't want.

Jim

N2ADR

[Mike Lewis]

That is why I did not see it.  It was in the gateware.   Thanks Jim!

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/f69fafe7-c933-4fd1-b454-04000314bd55n%40googlegroups.com.

[Scott Massey]

Hi Guys,

If I am reading these comments right, when a SWR bridge is connected to the ADC inputs of the RPI through the DB9, the IOBoard firmware populates its I2C register so the SDR software can poll the data. Within the SDR software, the I2C data can drive a meter graphic.  

At the risk of exposing my lack of programming experience, I have a few questions:

Is the 12c_slave_handler.c program the only program required for the IO Board to read the two ADC inputs and populate the appropriate registers?

Does this process set up the SDR software (in this case Thetis) to read the data alone or is there more to it?

My thought is it could be that simple for the IO Board programming but I have never programmed a RPI.  My experience is limited to the Arduino products however the examples of C programming appear to be similar. 

I hope I’m not pestering you guys.  I’m trying to be fully prepared to build up the SWR front end by the time my SWR bridge arrives from Ukraine.  In hindsight, I should have just wrapped my own but I have had good success with 60dbm.com products.  I expect my shipment any day.  Then the fun begins!

 

Off to Hamcation today.

Thanks in advance, Scott KE8KYP   

iPad transmission

On Feb 7, 2024, at 21:54, Mike Lewis <k7...@hotmail.com> wrote:



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

[James Ahlstrom]

Hello Scott,

You need to poll the IO board from within the SDR software to cause a read of the ADC. The returned values are used to calculate the SWR. Better yet, ignore the SDR software and just write a small stand-alone program running in its own window.

Jim

N2ADR

[Scott Massey]

Hi Jim,

I think I understand.  The Pico runs the ADC independently of the SDR program and constantly overwrites the I2C registers when the values change. If that's case then the front end is complete.  The rest is done by the SDR program, right?

Is the 12c_slave_handler.c program the only program required for the IO Board to read the two ADC inputs and populate the appropriate registers?

Thanks, Scott KE8KYP

[James Ahlstrom]

No, the Pico never reads the ADC until requested by the SDR program. The request from the SDR program goes to i2c_slave_handler() and it returns the values to the SDR program.

Jim

N2ADR

[Scott Massey]

Got it.  The SDR program requests the data and then the Pico processed the request.  It’s the i2c_slave_handler process that waits for the request.  Are any other processes require to run on the Pico?

Scott Massey | M +1.248.535.6510

(iPhone transmission)

On Feb 10, 2024, at 11:24, James Ahlstrom <jah...@gmail.com> wrote:

No, the Pico never reads the ADC until requested by the SDR program. The request from the SDR program goes to i2c_slave_handler() and it returns the values to the SDR program.

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/679822ed-83ff-433e-9546-49d1f52b5cb4n%40googlegroups.com.

[James Ahlstrom]

 No other processes.

Jim

N2ADR

[Scott Massey]

Hi Guys,

I got my bridge built and have configured my IO Board to run I2C_slave_handlier but I can use some help with the Thetis programming.  Anyone willing to help me tackle this?

Thanks in advance, Scott KE8KYP

On Friday, January 26, 2024 at 8:10:09 AM UTC-5 scumballc...@gmail.com wrote:

[Reid Campbell]

Hi Scott,

The first thing that needs to be defined is the interface between the I/O Board and the SDR software. I had suggested forward and reverse power , current and temperature. The scaling is the next factor. I had a quick look and the following would work:

Forward power, register/5 + 12 would give a value in dBm, so 255 would be 63 dBm which is 1955 watts

Revere power, register/5 + 6 would give a value in dBm, so 255 would be 57 dBm which is 501 watts

Temperature, register - 50 would give a range from -50 to 205 C

I'm not sure about current but here is one option 10^(register*0.0145 - 2) which would give a current from 0.01 to 49.8 Amps. Register value 0 would be defined a zero current.

Maybe somebody else can come with better transfer functions or many the ranges are not suitable, please speak up.

As for Thetis supporting and displaying this values, I wouldn't hold your breath. The priority is integration with the official source base.

Cheers

Reid
Gi8TME/Mi0BOT

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/9ed2d788-7e85-43d6-83f6-ca1e14d93630n%40googlegroups.com.

[James Ahlstrom]

Hello Scott,

I don't think there will be agreement among the SDR programs for how to handle ADC values from the IO board. Your best bet is to write a small program running in its own window and then you can display what you want. You can use Steve's hermeslite.py and my n2adr_ioboard.pyw as models.

Jim

N2ADR

[Scott Massey]

Hi Jim,

Thanks for the guidance.  I’m just learning how to execute a .py application in Windows.  I’d rather have it within Thetis but I get the hurdles within an SFR application.

Is that Steve Haynal?  

Thanks, Scott

Scott Massey | M +1.248.535.6510

(iPhone transmission)

On Feb 24, 2024, at 20:31, James Ahlstrom <jah...@gmail.com> wrote:

Hello Scott,

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/61b3d868-cf24-45a2-927c-1282d9b83921n%40googlegroups.com.

[James Ahlstrom]

Yes, Steve Haynal is the author of hermeslite.py.

Jim

N2ADR

[Scott Massey]

Thanks Jim.  I appreciate the guidance.

Hi Steve,

I am trying to use Jim's i2c_slave_handler code to read the forward and reverse voltages of a SWR bridge I have constructed.  I was originally thinking that the SDR program could use this data to feed a multi meter within Thetis but it would probably be better that I run a separate script and display this information outside Thetis.  Although that is less desirable, it is less complicated than a fully integrated solution.

Jim has suggested that I can use your hermeslite.py code to parse the I2C data from his process but I am a novice programmer and have little to no experience with Python.  If I get the process right, I condition and route the SWR voltages to the IO Board, run the i2c_slave_handler on the Pico and then run your script to display the SWR information.  My guess is there are important details I need to sort out before this will work but I am unsure how to accomplish this and was hoping for guidance.

I am running a Hermes Lit 2 on a Win10 machine (works great) and it would be great if I could get some more detailed instructions.

Thanks in advance, Scott KE8KYP

248 535-6510 

[Mike Lewis]

Scott, might I suggest you start off by modifying the IO board Control program.  It can already collect the values and display the adc results. Open up the code to modify the display.

The script has the interface to the i2c request but no UI.  

At this point answering the questions you are getting into is essentially asking someone to write a new UI for you.  

Starting with the Control Program at least you have a big head start.

Mike

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

---

From: herme...@googlegroups.com <herme...@googlegroups.com> on behalf of Scott Massey <jmass...@gmail.com>

Sent: Monday, February 26, 2024 7:05:46 AM

To: Hermes-Lite <herme...@googlegroups.com>
Subject: Re: Power / SWR Meter, Meter Display Calibration

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/2f9608b5-03e5-4249-a6e8-e84032f96e80n%40googlegroups.com.

[Scott Massey]

Hi Mike,

Thanks for guidance.  I’m not looking for someone to write the but I can see how my question seems that way.  I need to study it more closely as you suggest.

Thanks again,  Scott

Scott Massey | M +1.248.535.6510

(iPhone transmission)

On Feb 26, 2024, at 13:03, Mike Lewis <k7...@hotmail.com> wrote:



[Scott Massey]

Hi Jim,

I am gaining on it.  I had to figure out how loading programs into the Pico works (never did it before).  I've got the IO Board configured with jumpers DB9 Pin6 to Pico ADC0 (FORWARD SWR).  DB9 Pin7 to Pico ADC1 (Reverse SWR).  DB9 Pin1 to Pico AGND (GND SWR).   FOR and REV voltages do not exceed 3.0VDC. I can build a schematic if needed.  I have not connected the SWR Bridge to the IO Board yet.

I loaded I2C_Slave_Handler as main.py and copied in hl2ioboard.h and i2c_registers.h to the Pico.  I can run n2adr_ioboard.pyw and get the dashboard but here's my question?

I assume this is right but I am getting "I/O Board: Fault Code 255" when I launch Thetis.  If I de-select IO Board in setup, no fault code.  What is fault code 255?  Is this a RPi Pico fault?

Thanks Scott

[John Williams]

Scott,

It would be good to create a github account so you can post your progress there. It would make it easier for us to follow along. Plus, your work would be saved in the event of a local data loss. 

I would be interested to see your bridge design and perhaps a pic or 2 for the layout. 

John W9JSW

---

From: herme...@googlegroups.com <herme...@googlegroups.com> on behalf of Scott Massey <jmass...@gmail.com>

Sent: Saturday, March 2, 2024 10:13 AM

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/d915203e-6917-4b5b-9d91-7f72dd2e298fn%40googlegroups.com.

[Scott Massey]

Hi John,

I've not used a github account before but if I can learn how to write Python programs for the RPi Pico, I'm sure I'll pick it up.  More on that later.

In the meantime, here are a few pictures of this SWR bridge, etc..  I originally applied this circuit for a sBitx DE machine.  The 60dbm.com 100watt SWR bridge is a common design.  At 100 watts it produces a 7VDC on both FWD and REV outputs.  Since the Pico ADC inputs have a 3VDC limit, I added a potentiometer to set the maximum output.

  

I used the same concept in the sBitx with the Tiny85 design above.  The sBitx Tiny85 circuit is used to convert SWR voltages to I2C data for the sBitx V2.  I have a DE or V1 machine.  The V2 has additional hardware and code to measure SWR.  Since all it needed was the bridge and some signal conditioning to update my V1 machine to the V2 hardware, I cobbled in this bridge/circuit and updated the code to V2.    It works well.

The same kind of circuit is needed for the HL2 to monitor an external PA SWR.  With the IO Board and it's ADC functionality, it replaces the Tiny85.  I put the same bridge and signal condition/limit circuit in a box for my Micro PA50+ amplifier output.  My plan is to use the IO board to parse the SWR data.  Eventually, I hope to build or modify an existing multi-meter graphic for display on the computer.  

That's where I am and hopefully I've not bricked anything.  I am worried that while I was figuring out how to transfer programs to the Pico, I might have screwed something up and maybe that's why I'm getting the IO Board fault alarm.

Any help would be appreciated.

Thanks, Scott KE8KYP

[Mike Lewis]

Scott, from your description below you tried to rename, compile and load just the i2c_slave_handler.   You want to compile main.c from the n2adr_basic folder.  That include4s i2c_slave_handler.  Run the cmake and make commands per this section

HL2IOBoard/n2adr_basic at main · jimahlstrom/HL2IOBoard (github.com)

 

Then drop the compiled app onto the pico usb drive.  Watch for the correct flash fast flashing rate of the pico LED to verify it is talking (over i2c) when you start the SDR app or IO I0 board control program.

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/d915203e-6917-4b5b-9d91-7f72dd2e298fn%40googlegroups.com.

[Reid Campbell]

Hi Scott,

The error you are getting is because the fault register, in the I/O Board protocol is not 0. 255 would suggest that it has 0xff in it.

Cheers 

Reid
Gi8TME/Mi0BOT

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/d915203e-6917-4b5b-9d91-7f72dd2e298fn%40googlegroups.com.

[Scott Massey]

Hi All,

Wow!  I had no idea how different the RPi Pico is to the Arduino products.  I have been learning the differences, making Visual Code and Python mistakes left and right but I finally got it basically working as a stand-alone operation using the IO Board Control Software.  I can see the FWD and REV voltages of my SWR bridge in the tool.  I think that was the easy part.

Now I get to figure out how to use the data, do the math and present it in a more usable form.  It would be nice if the cross meter in the multi-meter Appearance section could be made to run in it's own window.  Got to have a goal, right?

Cheers, Scott KE8KYP

[Scott Massey]

Hey Guys,

I am still working on this project, making progress but I keep getting an intermittent "I/O Board Fault Code: 157" while running the IO Board Control Software on my PC.  It typically occurs after a transmission or when there is a lot of activity on the waterfall.  It clears on it's own after several seconds but I'm not exactly sure what this is or how to adjust it.  If I had to guess, I'd think it has to do with the I2C interrupt schedule and/or processor loading but that's a flat out guess.  If I de-select the HL2 I/O Board Hardware Option in Setup\General\H/W Select, unsurprisingly, the problem never occurs.

What do you guys think?

Scott KE8KYP

[Scott Massey]

Hi Jim,

Reid has been working with me to bring in I2C SWR data to Thetis from your HL2 IO Board from an external amplifier via a Stockton bridge.  Your software works well and I have worked out a scaling factor that "dials in" the ADC0 and ADC1 (FWD and REV readings) into fairly accurate indications via the N2ADR HL2 IO Board Control program.  Reid has asked that I make some modifications to the Pico program so that FWD and REV readings are available via registers 33 and 34, respectively.

If I read this correctly, registers 33 and 34 are unused within the Pico and should (might) be available for this feature.  Reid is asking that the data be converted to "counts" using the following code:

(((LOG(watts*1000)10)-12)*5  #forward power

and

(((LOG(watts*1000)10)-6)*5   #reverse power

I'm not exactly sure how to take the data from the MSB and LSB registers for each reading (FWD and REV) and combine it into one value and then execute Reid's code to put the results into registers 33 and 34.  I am also a bit concerned that this code addition might cause I2C timing issues (based on your caution in the Read Me file).  Can you please let me know what you think?

Thanks in advance, Scott KE8KYP     

[James Ahlstrom]

Hello Scott,

The value of ADC0 and ADC1 can be read from Thetis or any other SDR software by reading register 25. The ADC measures voltages from zero to 3.00 volts, and your bridge should provide a voltage that uses this full range so you have the most accuracy. With this data Thetis can use the above formulas if it wants.

If Thetis wants a different design then it is a Thetis specific usage and must use registers 200 and up. Or is this a general purpose feature and I am missing something?

Jim

N2ADR

[Scott Massey]

Hi Jim,

Thanks for the information.  You are correct that my bridge is zero to 3 volts which corresponds to zero to 50 watts.  You are not missing anything.

I thought that ADC0 and ADC1 registers were read from 25, 26, 27 and 28 individually and it was the SDR that combined them. Is it a four-step sequence to poll the results from register 25?  Six-step if ADC2 is also read?  I think I saw something on that but I'm not sure.

I'll converse with Reid and see if he can accommodate this polling and math needs.  Otherwise, I fear, a rewrite of the Pico code might be needed.  I wonder if he can pull the needed code from the IO Board Control program?  Hmm...

Thanks again.  I have having a blast with this but I really appreciate your help.

Cheers, Scott KE8KYP  

[Reid Campbell]

Hi Scott, Jim,

One of the headlines for the I/O Board was "Don't ask the SDR authors to modify their code", all the changes and new software should be in the Pico on the I/O Board. That's a hard ask, as you need to have a UI to control or display information going and coming from the I/O Board.

I think the headline should be changed to "Only ask the SDR software authors to modify their code once". To facilitate that, the I/O Board I2C protocol should be define in a way to make the information passed across it be as universal as possible. This is what I have been trying to do with an update to the I2C protocol to pass forward and reverse power, current and temperature back to the SDR software for display.

What I propose is that register 33, 34, 35 and 36 be forward power, reverse power, current and temperature. As all these registers are 8 bit, I also propose the following formulas to convert the linear values to logarithmic for power. Current still need to be defined and temperature would just be a scaling with offset.

Forward power would be (((LOG(watts*1000)10)-12)*5 = count for register 33. This gives 0.02W (12dBm) to 1995W (63dBm)

Reverse power would be (((LOG(watts*1000)10)-6)*5 = count for register 34. This gives 0.004W (dBm) to 501W (57dBm)

So that is what I have been working on with Thetis to display this information. Thetis will not be reading raw ADC values and doing some conversion on them, that is what the Pico is for. How the Pico gets the raw values is of no consideration to Thetis, it will just display what ever values come across the I2C protocol base on the formulas above.

This is all at an early stage, so I welcome comments, as it good to get different inputs.

Cheers

Reid
Gi8TME/Mi0BOT

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/fcc6bc2f-6b3a-4b14-8a5c-50f52733bcb2n%40googlegroups.com.

[Scott Massey]

Hi Reid and Jim,

I sort of feel like the Magdeburg experiment where two teams of horses attempted to pull apart two hemispheres containing a vacuum.  Eventually both teams gave up.  I am hoping to avoid giving up.

In this situation, I'm not sure which "team" is right but I tend to think the best solution would be to edit the program that would least affect the overall project to add this feature.  What I hadn't realized is that the IO Board is operating under multiple SDR platforms.  Thus, I suppose, is the reason for Jim to put forth registers 200 and above for this external PA monitoring scheme.

Reid, Can you work with registers 200 and above for this feature?  You mentioned that registers 33, 34, 35 and 36 where 8 bit registers.  Are all registers 8 bit?

Jim, I did not completely understand your "Thetis specific usage..." comment.  After reflection, it probably is a Thetis specific addition.  Are other SDR programs using Reid's proposed registers?  Assuming so, do you think the Pico can handle the requested code additions without impacting the Pico's overall operation by adding code to convert the ADC results to counts and copy those results to registers 200 and 201?  

My thinking is making a code change to the Pico is easier than the SDR program.  I guess that means I am picking one "team" over the other but I'm hoping to keep the experiment going.

Thoughts?

Scott KE8KYP

[James Ahlstrom]

I can certainly understand the motivation for a simple scheme to return the values for the SDR software to display rather than the raw data. Then the calculations to convert raw data to display values can be done in the Pico and the SDR software need only be modified once if at all. But Quisk has no use for this feature. Quisk users can write their own calculations in Python and include it easily. 

So I would like some discussion from other SDR authors.  Does this design work for other SDR programs or should it be modified?

Jim

N2ADR

[John Williams]

Here is what Thetis currently sees for data from the N2ADR ADC. Why can't the current Pico ADC values be mapped to these locations in Thetis with a checkbox to switch? Seems like Thetis is doing the mapping here and there is scaling capability as well. I used to use the N2ADR connector with my own bridge design and it worked with my 50W amp at the time. My bridge was not well laid out and was a bit too erratic, so I quit using it. Seems like the I/O board is a natural way to do this for external amps. Then with a checkbox, you can see driving wattage as well as output wattage.

---

From: herme...@googlegroups.com <herme...@googlegroups.com> on behalf of James Ahlstrom <jah...@gmail.com>
Sent: Thursday, March 28, 2024 10:42 AM

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/66890556-d465-4cc2-a588-a2ba1a6cd1dfn%40googlegroups.com.

[Reid Campbell]

John has brought up a good point about the hidden settings in Thetis, I had for gotten about them. I will have a look at connecting the I/O board with those and that might full fills Scott's current requirements.

But, I'm trying to define a general solution. The determination of power, current or temperature may not come from the direct reading of analogues values. The I/O Board has serial inputs, so variables could be read direct from amps, tuners or power meters via RS232 protocols. Even I2C could be used, as there is a spare interface in the Pico for that.

Based on the above, I still think we should be looking at definitions for power, current and temperature, within the protocol, for future use by all SDR software.

Cheers

Reid
Gi8TME/Mi0BOT 

[Scott Massey]

Hi John,

Hidden settings?  Interesting.  How did you make that work in the first place?

Hi Reid,

I assume that if this works, once this is set up, the calibration for the PA Gain and Watt Meter will be for the external PA only, right?

Thanks again for your assistance, Scott KE8KYP

[Mike Lewis]

Just hit the PA values button seen in the screen shot.

--

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/f7a2a931-a60d-4aae-a941-98ee18baf69cn%40googlegroups.com.

[Scott Massey]

Hi Guys,

I've seen that setup page before but doesn't that only look at the internal amplifier in the HL2?

[John Williams]

Scott,

The point I was making is that all of the raw data is already being processed by Thetis for the ADC from the N2ADR bridge. The suggestion is to add a HL2 specific checkbox to tell Thetis to get the data from the I/O board ADC instead. That way all of the locations that rely on that data for downstream metering will hopefully remain unchanged, at least in theory. Have not looked at the code. 

John

---

From: herme...@googlegroups.com <herme...@googlegroups.com> on behalf of Scott Massey <jmass...@gmail.com>
Sent: Friday, March 29, 2024 9:57 AM

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/c48f6c83-d9b1-4089-a0a8-c56a54ca1a88n%40googlegroups.com.

[Scott Massey]

Hi John,

Please forgive me for missing your earlier point (I re-read your earlier messages).  I also inquired if the Thetis program could acquire and process the IO Board data but I asked that SWR data from the IO Board be processed independently.  An internal and separate external PA Settings scheme was what I was envisioning.  My thought was to be able to monitor both the 0-5 watt internal amplifier and a 0-X watt external amplifier to possibly recognize problems between amplifiers.  It's likely not needed to have such visibility but guys can dream, right?

 
Hopefully, Reid can sort out some future magic and it won't require a lot of work.

Thanks for your thoughts and ideas.  I really appreciate it.

Cheers, Scott KE8KYP

[John Williams]

I think this is a huge ask to have both instantiated at the same time. That causes dual meters for everything from acquisition to UI. My suggestion is a switch on the acquisition. Much easier. Uses existing UI. 

Sent from my iPhone

On Mar 29, 2024, at 3:53 PM, Scott Massey <jmass...@gmail.com> wrote:

Hi John,

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/01cae1cb-012a-481c-90e6-45f5c4e77cecn%40googlegroups.com.

[Scott Massey]

Yes, I agree.  It took a while but I am fully on board.

[James Ahlstrom]

A better solution to all this is an independent program to monitor and display power and SWR from the IO board. Then no modification of Thetis is required, and data from the HL2 and the power amp is available simultaneously. Such a program can be derived from n2adr_ioboard.pyw.

Jim

N2ADR

[Scott Massey]

Hi Jim,

I tried that.  It does work but unfortunately, it is not an integrated solution.  In my opinion if the source of the data can be selected between the internal HL2 hardware and the external I2C source, it makes external monitoring a setup feature.

I am still working on the N2ADR_IOBoard.pyw as a work around but there are no graphics that make the presentation desirable.  I’d have to figure that out and it just seems like an integrated solution would be better. There is also the fault error 157 deal which I believe we discussed earlier but I’ve slept since then.

Scott Massey | M +1.248.535.6510

(iPhone transmission)

On Mar 30, 2024, at 12:24, James Ahlstrom <jah...@gmail.com> wrote:

A better solution to all this is an independent program to monitor and display power and SWR from the IO board. Then no modification of Thetis is required, and data from the HL2 and the power amp is available simultaneously. Such a program can be derived from n2adr_ioboard.pyw.

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/ec257290-08c9-4e5f-b966-b2442c11db20n%40googlegroups.com.

[James Ahlstrom]

Perhaps I wasn't clear. I meant a completely different external program that displayed power and SWR in its own window.

Jim

N2ADR

[Scott Massey]

 Hi Jim,

I get what you mean: use a stand-alone program to monitor the I2C data from the IO board.  I am looking at that.  Not much success, yet, but still playing with it.

Cheers, Scott KE8KYP

iPad transmission

On Mar 31, 2024, at 09:11, James Ahlstrom <jah...@gmail.com> wrote:

Perhaps I wasn't clear. I meant a completely different external program that displayed power and SWR in its own window.

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/b5d3da52-9afc-459b-a5eb-2f36cdfb088cn%40googlegroups.com.

[Reid Campbell]

Hi Scott, Jim,

The stand-alone approach won't work unless the FPGA is updated to control access to the I2C. I have to turn off my polling thread while other functions access the I2C, or they trip over each other.

Scott, I'll send you a link to a version of Thetis which can reads the Pico ADCs and uses those for the power meters.

Cheers

Reid
Gi8TME/Mi0BOT

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/B85F7BE6-EDEC-474B-9226-BEC2F7D460A1%40gmail.com.

[Scott Massey]

Awesome!  I look forward to it.

Thanks, Scott KE8KYP

[Scott Massey]

Hi Reid,

I know good software takes time but any idea when that link will be available?

No pressure, just curious if you can speculate on a timeline.  

Thanks again, Scott KE8KYP