I've been reading up on interfacing the SunSDR2DX to an SPE 1.3K-FA and see that the normal way would be to use the BAND-DATA mode in conjunction with the SPE's own frequency counter for sub-band tuning. I was wondering if anyone has considered a CAT approach with the SunSDR2DX. The idea is to use a small microcontroller, an ESP32 or even a Raspberry Pi to act as a TCI client to the radio, and then converting the frequency data into an appropriate serial CAT protocol before pushing it out to the amplifier's CAT port. Has anyone attempted this or foresee problems with such an approach? Thanks.

Before you venture into your project, you may check out how SDC (sdc.qrz.ru) can be used to control an Amp via TCI/CAT. If you are not acquainted with SDC, you can download a PDF-manual at SDC site download area.

73 de LB2EG Richard

Thanks Richard. I had looked at the SDC but because I am thinking of a remote application, that would require an additional PC running at the remote site with SDC. I was actually hoping to have something like SDC running on a small dedicated SBC like a Raspberry Pi. That would be just perfect.

Major things you'll have to solve are:
1. RFI suppression for chosen media/protocol type
2. Conversion of SPE's feedback data into chosen UI type
3. Selection of websockets libraries under chosen framework.

Anything else is easily solvable: either use TX_FREQUENCY or VFO within current TCI v1.6. In following TCI versions the BAND command may become available sooner or later (was requested some time ago, is in a queue for further enhancements).

If the ESP32 or SBC (Raspberry?) is connected via Wi-Fi, that cuts down some potential RFI on cables. The SBC talks to the SunSDR2DX over the Wi-Fi network to the TCI server using standard TCI libraries. It takes that data and translates it into one of the CAT protocols such as Kenwood's or ICOM's and pushing this out a serial port to the SPE. In this case, RFI should not be much of an issue. Coding CAT protocols is not that difficult and the TCI library already exists so there is no need to code it from scratch.

Hi,

maybe you are looking for something like this.



I did it in late 2019 and up today I can say it works very well. I built an automatic antenna switch on ESP32-Tci libs.
The library implements a very basic serial CAT protocol out of the box and can recover by itself wifi connection or rig connection when any of them is missing..
For your purpose you just need a Esp32 and two TTL-232 converter, one for each receiver. You also need a step down converter (any voltage to 5V) or better a LM7805 circuit .
The library provide two PTT lines but I suggest you don't use it because network delay could fault your power amplifier. For the PTT line I suggest you still use the pin 8 on EXT-CTRL connector.
Give a look at my web page iw7dmh.jimdofree.com/sunsdr2-pro-pages/tci-esp32s-arduino-libraries/
Last but not least you have to consider that the library connect the TCI endpoint that is provided by the EESDR program: this indirectly means that the ESP32 and EESDR have to be reachable one each other. You can achieve it by a VPN (TAP protocol) or configuring in some way your routers.
Another last clarification: I have no idea how things should work when the cloud remote system will be released, but it is the problem #2000 while we are facing the problem #10

I hope it can help
73' Enzo
iw7dmh

Hi Enzo, thanks! That looks very much like what I had in mind. I've been giving this some thought and am glad that I don't have to start from scratch.

One of the things I'm wondering about is whether latency will be a problem if I am operating remote. So the SunSDR is at a remote LAN into which I am creating a VPN tunnel. The EESDR runs on the local machine and the bridge device sits on the remote LAN with the SunSDR but talks to EESDR on the local machine, and sends the CAT data to the SPE 1.3K-FA.

Meanwhile I've also been thinking that I could just use SDC to generate the CAT data and route it to a remote COM port running on a PC which then outputs it via a USB COM port to the SPE 1.3K-FA.

In more than two years I never experienced issues with the TCI protocol.
Using SDC in local installation and sending the serial data over the net will add two additional "hops" between EESDR and the SPE; this probably will add latency or jitter issues in respect with a plain TCI connection.
In addition, using the VPN connection and EESDR2 I had to reduce sampling rate to 39KHz, while with EESDR3 I can go at 150Khz without any issue.

73' Enzo

P.S.: VPN Tunnel (TUN protocol) can't work with EESDR. You should configure it with TAP protocol.

Hi Enzo - yes, I found out the hard way that I needed to use TAP for this to work properly. I am able to sample at the full 312kHz over my VPN so I'm happy about that.

You're right that the SDC approach does involve quite a few levels - TCI to SDC to CAT to COM to remote COM to SPE. I was thinking that maybe the ESP32 can wait for a callback to automatically link to to the TCI port and do it that way. I'd love to see your code if it is on GitHub. I'll probably end up doing the same except with PoE and LAN instead of Wi-Fi. The SPE takes TTL serial so that will hopefully talk directly to the ESP32 output - not sure if the 3.3V level will need conversion to 5V.

73 Daniel (9V1ZV)

Hi Enzo - I'm already starting work on the bridge. I am curious as to how you are managing the different possible TX configurations. For example, do you take care of split mode, RX2, and so on?

Right now my thinking is that I will need to keep track of VFOA and VFOB in both RX1 and RX2, and keep track on the transmit frequencies. At the same time, I may need to look at when Trx is enabled and output the correct CAT data to correspond with that transmit frequency. This, however, means that there is very little time to re-tune the ATU before transmission actually starts. How are you dealing with this problem?

danielwee wrote:
Hello Daniel,
the PoE lan solution solves the powering problem but on the other side the ethernet cable is a "great" antenna and the SPE is a great and big trasmitter. You should find yourself struggling with toroids and other anti-rfi solutions. WiFi is more reliable from this point of view.
Anyway you should do some test before go on with one or the other solution.

About your other questions:
danielwee wrote:
The ESP32 take care both of VFOA and VFOB on each receiver, RX1 and RX2.
When the PA polls the rig (actually the ESP32) usually send one of the following commands: FA, FB, FR, FT, MD and IF. The ESP32 TCI libs take care of the rig status ad answer almost instantly.

danielwee wrote:
Actually you don't need to care about any of the previous issues. It is already implemented in the library. The code is on my dropbox and can be freely downloaded https://www.dropbox.com/s/4dz1gf90yvgyec9/TCI-1.3-01.zip?dl=1

danielwee wrote:
If you are using the internal SPE ATU, tracking the frequency is enough to auto tune the amp.
If you are going to use another antenna tuner you need to key the rig with the tune function and read the swr level.

1- for the tune command you can use the tuneDrive() and setTune() methods in the library;
2- for the swr readings you have to handle the tx_swr_event(onDevice_tx_swr) event;

Both are already implemented in the library and can be used for an auto-tune logic development.
If you look inside the source code of TCI-ESP32 libs you can find a demo program in the example directory.

73' Enzo
iw7dmh

Ah, thanks. I see - so the SPE will poll for the frequency it needs. That's interesting. I was thinking of using the ICOM CI-V protocol which is mostly a one-way thing but it looks like you're using the Kenwood protocol. I assume this is being handled on Serial2 since Serial is being used for the diagnostic messages? Thanks - your library is very complete! Nice work.

The PoE in this case is galvanically isolated so I'm hoping that avoids the potential RFI issues.

Yes,
Serial is used for configuration purposes- Using a serial terminal program (like Termite) you can configure all parameters.
The library use both Serial2 and Serial1 respectively for RX1 and RX2. You need a little modification to the original official ESP32 libraries that is documented in the TCI.h file.

73' iw7dmh

Hi Enzo, I've been looking at the code but I don't see where you are invoking the Serial1 and Serial2. I am getting the TCI commands but don't see where in TciDemo.ino that the CAT stuff is handled. Is that built into the tci.process? Or do I need to initialize an instance of RTX? Thanks for any pointers.

Hi,

all the CAT stuff is hidden and handled in the RTX class (search getCatResponse(String cmd) in the RTX.cpp file).
You don't need to worry about it in the .ino file.
When you instantiate the TCI object, it will assign Serial1 and Serial2 to each receiver in its intializer method.