I/O Board Transverter Programming

[K7MDL]

I received a pair of I/O boards yesterday.  Came with pins as others noted, nice.  

Loaded up one of the boards with the test program and put an oscope on it, all looked proper.  Used the Python test program, worked great.

I have a vacuum desoldering tool so I removed the long header easily and removed one of the 2 spacers.  Reinstalled the header and now it sits level.  Clears the case top fine.

I have a 5-band VHF transverter that covers 144/222/432/902/1296 bands.  I built a DB-9 to DB15 cable and assigned pins 1-4 for Band Data 0-3, and pin 5 for PTT, Pin 9 for ground.  I installed wire jumpers from the DB9 header to the J6 pins 1-5.  The pin pattern is inverted to make the Xvtr change bands correctly, ie, set to I/O pin to value=1 to close the MOSFET switch to ground, representing a 0 input as desired.  I can use the Python test program and change bands and operate PTT. All good so far.  

I got my VS Code and command line compile setup on Win 11 OK.  I use VS Code with Arduino and Teensy 4 for my Teensy SDR development but have never tried it with a Pico before.  There is a Windows installer that makes things easier.  Raspberry Pi Pico Windows Installer - Raspberry Pi

YOU can compile and attempt to run in VS Code but it fails, needs more setup.  I had to manually add paths to my env for the Toolchain and SDK.  The cmd line cmake/make approach worked after the path were setup.

I modified n2adr_basic configure_pins.c and main.c, compiled successfully.  I redefined the example HF bands in switch(band) section of main.c to operate my 4 I/O pins for 6M and 144-1296 bands.  

After some playing around with the latest Quisk and Thetis HL2 builds which support the IO board I noted some things were not as I expected.  I modified the code to force things to work but I think something is amiss.  Now to figure out if the error is mine or if the problem is external.  

Here is what I saw:

1. The RX frequency does not appear to be sent and/or read. My band outputs did not change as I changed bands while in RX.  If I changed bands then pressed PTT, the band did change implying the logic is ignoring RX, or the RX change detection never kicked in (because there was no new I2C RX freq data?).  It was using TX freq OK.

When I initially added code to force the changes, it would change to the correct band on TX only, then pop back to one single band, 432MHz in my case which might suggest it actually read 1 frequency in RX - not sure what yet.  

Finally I bypassed the rx_freq_changed test (with "if (1)" per below). The RX band changes then worked. I suspect this is causing a lot of extra work as a result. 

// Poll for a change in one of the twelve Rx frequencies. The rx_freq_changed is set in the I2C handler.

        if (1) {   //rx_freq_changed) {

            rx_freq_changed = false;

            change_band = true;

            if (rx_freq_high == 0)

                rx_band = tx_band;

            else

                rx_band = fcode2band(rx_freq_high); // Convert the frequency code to a band code.

        }

        if (change_band) {

Feels like "rx_freq_changed" is not working for some reason.  After all was working good here I went back and restored that if (1) to original code and sure enough, no band change while in RX.  PTT works fine still.

2. Since band change is set to True for a change in RX/TX state, I call a small function  Xvtr_PTT(state) that sets my pin 5 (Xvtr PTT) to match the current TX/RX state.  Seemed easier than adding logic at the very end.  For RX band changes, probably added unnecessary extra work though.  Here is my Xvtr logic which happens to be the Elecraft K3 patterns (recall they are inverted).  Might need a bit of delay to ensure the Xvtr band change is settled.

            case BAND_125cm:

                gpio_put(GPIO02_RF3, 1);  // default REG_RF_INPUTS = 1 for Split IF

                gpio_put(GPIO03_INTTR, 1);   // default REG_RF_INPUTS = 1 for Split IF

                gpio_put(GPIO16_Out1, 0);

                gpio_put(GPIO19_Out2, 0);

                gpio_put(GPIO20_Out3, 1);

                gpio_put(GPIO11_Out4, 1);

                Xvtr_PTT(current_is_rx);

                break;

            case BAND_70cm:

3.  I set REG_RF_INPUTS = 1 for split IF.  I can do this via the Python test app fine.  IT is register 11 and GPIO2 and 3.  I am not sure yet the correct way to set these to the registers are updated properly.   If I write to the 2 GPIO pins I do not see the correct register value for register 11 in the test app.  Is there a way to write the register in C to emulate the I2C command process?    I am thinking I can call this as done in the IRQ handler, inserting REG_RF_INPUTS in place of i2c_regs_control.  Will test that next.

 Registers[i2c_regs_control] = data;

4. I verified the band volts changes with each band though it is undefined for most of my Xvtr bands as expected.

Overall, couple hours and it is working.  Now to spruce things up.

Nice job Jim and contributors!

Mike K7MDL

[K7MDL]

One other thing I noted about Thetis HL2 and transverters.  When using Transverters the band stack feature on the band buttons do not work.  They always default to the same value.  

For example, I have 144-148MHz defined for 2M. It always changes to 146.000 when I return to 2M band from elsewhere.  Same for every Xvtr band,  70cm = 432-434, returns to mmiddle value of 433MHz.  HF bands work fine.

[K7MDL]

Ignore the  Xvtr bandstack observation.  

I discovered you can click on the little numbers to the right of the Band Stack label located between the VFO A and B boxes to bring up the editor box, and click the < V > below to cycle through them.

In my notes on the i/O board testing I posted earlier, the scenario where TX was right and RX is ignored (changing bands in TX) still happens in Quisk despite my getting things to work in Thetis with the same firmware.  

For example, I select 144 band, 432 is then set on the Xvtr for RX for some reason.  Pressing PTT, it switches to 144 during TX then back to 432 on RX. Sometimes it stays on 144, but that is a random act and can behave that way on other bands.  For some reason 432 was set most often on RX no matter what the actual band chosen was. 

[K7MDL]

I cleaned things up and resolved how to handle the register update and can now easily flip between HF and my multi-band VHF+ transverter properly - meaning the REG_RF_INPUT is now updated and the associate GPIO2/3 pins are updated with it.  I can see the test app reflect the changes on band changes.  I use split IF on 28MHz at 1mW drive to my transverter.  HF is a common single connection.  Given the need for 1mW I do not intend to mix HF and CVHF usage on this, I have a 2nd HL2 for HF running the 10-band gateware loaded and monitoring over 19 FT-8 and WSPR channels with SparkSDR.

I reverted to the original configure_pins.c file so all my code is contained within the n2adr_basic/main.c file now.  

I added 3 new functions:

1. Split_IF()  - sets REG_RF_INPUTS = 1, called from any VHF transverter band (144-1296 in my case)

2. Common_IF() - sets REG_RF)INPUTS = 0; so all RF flows in and out the ANT SMA connector.

3. Xvtr_PTT(bool tx) - Operates GPIO pin 5 for my transverter PTT. 

Down in the band change logic section each VHF band looks like this now.

            case BAND_2:

                Split_IF();  //  REG_RF_INPUTS = 1 for Split IF

                gpio_put(GPIO16_Out1, 1);

                gpio_put(GPIO19_Out2, 0);

                gpio_put(GPIO20_Out3, 1);

                gpio_put(GPIO11_Out4, 1);

                Xvtr_PTT(current_is_rx);

                break;

My transverter uses PIN diodes and has internal sequencing so I do not think any delay is needed for the case of PTT occurring on band change (or the slow change in and out of FM mode in Thetis) if they happen at the same time.  Ideally the SDR app would make sure this does not happen but slower relay operated transverters and amps (like remote power up) might need more time.  More testing and work on that later. 

So that leaves 2 unresolved issues I am investigating:

1. I have to bypass the rx_freq_chaged variable test to get band change to work while in RX.  For now I do a if (1) and all works.

// Poll for a change in one of the twelve Rx frequencies. The rx_freq_changed is set in the I2C handler.

        if (1) {   //rx_freq_changed) {

            rx_freq_changed = false;

            change_band = true;

            if (rx_freq_high == 0)

                rx_band = tx_band;

            else

                rx_band = fcode2band(rx_freq_high); // Convert the frequency code to a band code.

        }

 

2. With the above changes all seems to work in Thetis HL2 v2.10.2.2 x64 (10/22/23) HL2 -Beta 1.

In Quisk the band changes mostly do not work.    I have defined bands for 50, 144, 222, 432, 902, and 1296 in the band table.  They look correct to me.

a. Monitoring the test app GPIO pins, in RX, 432 and 1296 both set the pins for 432 band.  

b. On any band, during PTT the pins are activated for 144 band + the proper PTT pin (pin5).  All pins are 0 otherwise. The IO board Rx input setting (REG_RF_INPUTS) works only on 432 and 1296. 

I will take a look around the Quisk code.   I see the new IOBoard class in the hermeslite.py, maybe something is going on in there.  I would guess it is related to handling transverter band TX frequency sent out to the IOBoard.

Mike

[K7MDL]

I think I have things sorted out best they can at this stage of development.  I cruised parts of the code for Quisk and Thetis looking for how RX and TX frequency and code conversion was handled, or if they are yet.   There is a lot of code there I have not looked into yet though.  Early days I know.

From what I can see so far, I think Quisk and Thetis both are not yet sending RX frequencies out, only the current TX frequency.  The IOBoard is ready to accept multiple rx_freq codes (up to 12) but so far they is not sent out from the apps as far as I can see.  Would I be correct?  

The only code I see writing to the I2C is for tx frequency today.   In the IOBoard code (main.c) if I set rx_band = tx_band just before the if (change_band) section (faking the missing rx_band data) then it all works for both apps.  

I see code in Thetis for setIOBoardAerial which will configure the REG_RF_INPUTS register.  I am guessing the intent is for the 3 radio button columns on Antenna tab in Thetis to equate to 0, 1 or 2?  

One code snip only set it to 0 or 2 for RX only mode.  I have not found who is calling the setIOBoardAerial function.  In Quick it is on the config hardware tab at the 'IO board Rx input' field.  In my case I am overriding that setting in the c code since I wanted to support a mix, though that may be not needed in the end.

[Reid Campbell]

Hi Mike,

On 26/10/2023 04:19, K7MDL wrote:

I think I have things sorted out best they can at this stage of development.  I cruised parts of the code for Quisk and Thetis looking for how RX and TX frequency and code conversion was handled, or if they are yet.   There is a lot of code there I have not looked into yet though.  Early days I know.

From what I can see so far, I think Quisk and Thetis both are not yet sending RX frequencies out, only the current TX frequency.  The IOBoard is ready to accept multiple rx_freq codes (up to 12) but so far they is not sent out from the apps as far as I can see.  Would I be correct? 

That would be correct for Thetis. Getting the current Tx frequency is easy but Rx is a bit more tricky especially for split operation across bands. Is there an issue with using Tx frequency to select the required transverter?

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/8b6f22ae-9593-42d6-ac28-3674d0e5be73n%40googlegroups.com.

[Mike Lewis]

No need for RX freq here today.  There is a behavior difference between Thetis and Quisk around this with the IOBoard code as of today that I was trying to understand and resolve.

 

Quisk will not change bands in RX, changes only after pressing the PTT.  I think Thetis did change in RX without my code changes, certainly that was the case after my inintial changes.  I was trying to find out why that was, if it was something I did, and made code changes in the IOBoard main.c to force it to use the TX band in all cases for now. Quisk now works as well, and likely any SDR app.   Will try it with SDR Console and other apps I have next.  

 

• Mike

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/8e3fa1df-6416-4e6d-8ced-f927e0549895%40gmail.com.

[James Ahlstrom]

Hello Mike,

Thank you for sharing your experience with the IO board with the group. It will help other users. I just have a couple comments.

It should never be necessary to change any IO board functions except main.c. In particular, configure_pins() just sets the IO pins to input or output. If you want to change something, call configure_pins() in main.c and then reconfigure the pins after that.

You seem to be using n2adr_basic/main.c with few changes. This main.c was mainly meant as an example, not a real useful program. In particular, it is oriented toward HF operation, not transverters. The Rx frequencies are scanned and rx_band is set to the highest band. The tx_band is set from the Tx frequency. Then rx_band is used for Rx and tx_band is used to Tx. This makes sense for HF operation where low pass filters would be set to the highest band, but the correct lower filter frequency would be used for Tx.

This is not what you want, so throw out most of the code in main.c and just set your band according to the Tx frequency.

Jim

N2ADR