Thanks Enzo. Very nice! So, basically the functions are all already built in and running the moment you instantiate TCI and run the tci.process(), Awesome - man, you did all the work and thought of everything already.

Hi Enzo, I've recompiled everything and looking at the RTX.cpp, it looks like you have set it up so that the ESP32 will only output something in response to polling from the SPE. Am I understanding the function correctly? Would it be beneficial if we output the frequency data any time there is a change like ICOM's CI-V tends to do? I'm not sure if the SPE will be able to handle that in Yaesu mode (which seems to be the default based on the CAT commands).

Hi,
the CAT protocol used in the lib is the standard Kenwood one.
Maybe you are referring to is the AI-Command: the radio will broadcast the VFO (A or B) frequency when changed.
At the moment it isn't implemente, but it is non difficult adding it to the libs.
73'

Yes, something like the auto-information (AI). In ICOM's CI-V, you do not need to poll for the frequency information (although you can.) Any time the VFO changes, it will automatically send out a CAT packet reflecting the new frequency. I was wondering if this would be a preferable arrangement since it does not rely on the SPE to poll the ESP32. My current understanding is that the SPE will poll the radio at some intervals. I don't know if the SPE will respond to unsolicited VFO update packets but it should since it supports the ICOM format.

As for implementation, I presume this would consist of modifying the relevant TCI method to include a doFA or doFB command followed by either Rig1.print or Rig2.print.

Yes it is something like that

When you connected the SPE TX/RX TTL to the ESP32, did you have any level conversions? I was looking at the SPE schematics, and I think the TX from the ESP32 should be okay but maybe the RX on the ESP32 needs a few diodes in line to drop the voltage a bit. Did you connect them directly or did you have something to drop the voltage to the ESP32 RX? Thanks.

BTW, I have added some code to turn on the SPE when the SunSDR2 DX is started.

Yes, you need a RS232-TTL converter.
They are very common in the Arduino world.

73'

I finally did it!! This is using the direct TTL TX and RX output from the SPE. The KENTTL line needs to be grounded for this to work. I was stumped for days and building all kinds of hardware and altering code because I realized that the SPE actually sends out and receives all the TTL serial data in inverted form. As a result, I had to change the serial initialization to invert the operation as well.

Separately, I have also added code to turn the amplifier on when I turn the radio on in EESDR. It will turn the SPE off, too, when I turn the radio off in EESDR or close the program.

The ESP32 controller is the OLIMEX ESP32-PoE-ISO board which needed additional modifications for it to work properly. I needed a bunch of diodes for level conversion from 5V to the 3.3V TTL of the ESP32. This is powered over PoE, which should reduce latency. I hope there won't be any stray RFI issues. Cables are all shielded but I may need some ferrite clips on them just to be safe.

Finally, after all that work - the SPE will change bands any time I change band or tune so that's a really nice thing. I am not sure if the SPE will register an IF packet that it did not specifically request. If it does, one could potentially reduce all the polling and just send change data when the radio changes frequency. In any case, all the work is offloaded to the ESP32 so none of the critical systems will be needing to do this extra work.

Thanks Enzo for all your prior work with the library and insights!!! I'm really happy now. The next thing I want to do is to try to write some auto-discovery function. I'm not too sure how to do this just yet. One could look at the callback broadcast function but that seems a little iffy and risky. Alternatively you can just traverse the subnet and test the ports to see if it is open. I'll have to look more into this to see how it can be done.

Hi Dan,
I'm glad you found the libraries useful, even though you went much further.
The best way to implement a discovery system is broadcasting ESP32 IPaddress and Port via udp.
It is the same behaviour used in Flexradio rigs: each device announces itself on the network and any clients know how to get a connection from it.

Best 73'
Enzo

Hi Enzo - I don't know if EESDR2 announces itself on the network though. EESDR3 appears to have an option to broadcast on certain ports but I do not see that option in EESDR2. In the meantime, I've implemented a scan of the subnet which manages to find the EESDR2 client machine. The problem is that this can be quite slow when using WiFi - reponse times can be up to 500ms, which makes scanning slow if the subnet is large. I will probably have to find a better way of doing this but this works for now.

I am now working on a new function. I'm not completely sure of this yet but the idea is that once I click TUNE on EESDR2, the ESP32 will recognize this and begin monitoring the SWR and if it is too high, it will disable the TUNE. Additionally, if TUNE is activated for more than a period of time, it will automatically disable TUNE. I'm not sure how this will work yet or if the SPE's ATU will reflect the SWR through to the radio when in bypass mode. Ideally, I can tap into the SPE's serial control and activate the SPE TUNE at the same time but that means I would lose the ability to monitor the amp using their remote software since the port will now be used by the ESP32. I'll have to think this through a bit more.

Additionally, I have also made it so it will wait for a valid local IP before starting anything. If Ethernet is available, it will take priority over WiFi. If it is not available, it will use WiFi and if that is not available, it will just wait until they become available.

It appears that EESDR2 does not UDP broadcast for discovery. EESDR3 does so that is easy but EESDR2 requires you to monitor for UDP traffic on 50001 or 50002 between the client and the radio. In this case, it looks like it might be easier to just scan the ports since I sometimes use EESDR2 and at other times I use EESDR3. Furthermore, I use these from different machines.

Hello!
I have been reading with great interest about your project to get CAT control having the SunSDR DX plus amplifier using the ESP32.
I think this will be useful for many stations with similar remote setup.

Is it possible for me to get a copy of the code so I can make a solution for my SunSDR DX with my OM Power amplifier (the amplifier has a RS232 port for Kenwood CAT control).

73 de Erik SM0JCA

Hi Erik, I'll be happy to but I'm still finishing up the discovery code. Now I can run EESDR2 or EESDR3 from several different machines and the ESP32 will auto discover them using a combination of UDP discovery and port scanning. This means I no longer have to just rely on one IP for the client machine (although you can still do that if you manually enter the IP through the command line.)

Additionally, there's also a bunch of external hardware that you may want to build - namely the serial 3.3V_TTL level conversion to the amp's 5V_TTL. This particular version assumes that the SPE amplifier will poll (by sending a series of "IF;" commands to the ESP32 via the serial port). If your amplifier also does this polling, then it should be quite easy to adapt. Otherwise, there may need to be some other code modifications to suit the behaviour of your amplifier's CAT behaviour.

I should add that the primary goal on my side is to get the ATU in the SPE to track the frequency of the radio automatically. If your amplifier does not have an ATU, I suppose the functionality would be simpler perhaps. If you can describe to me what it is that you would like to achieve, I might be able to better advise as to the feasibility.

Hi,
Thank you for your kind suggestion. First of all I must confess that I am completely ilitterate as dealing with software computer code. My limits are "copy and paste" when it comes to html, aurdino or php.

My SunSDR DX radio will be located at a large contest radio station with remote control of radio, amplifier and antenna selections. The heart of the control system is a custom made Antenna System Control switch using CAT frequency input from the radio as well as PTT control and then forwarding that to all other units (a.o. OM Power amplifier). In total we have over 20 antennas covering all bands from 160-10 m. The plan is to have up to six radio stations in Multi/Multi contests.
The remote side of the station will be running ESDR RS remote program on PC with TCI plus loggbook with CW keying, DX cluster and with automated PTT and band/frequency control. Maybe SDC will be useful as well.

We are fortunate to have several highly professional software programmers and internet specialists in our ham radio club and I see them every week at our club meetings. The SunSDR DX radio is getting increased attention for the excellent CW performance during crowded contest conditions. It is seen as equal or slightly better in comparision to other major SDR brands. The Sun radio is also a very cost competitive radio.

As you can understand it will be necessary the get band/frequency information from the radio as input to this radio station system. The band information and PTT information can be had from the radio EXT. CTRL pins but not CAT. Your solutuion with a dedicated ESP32/Aurdino controller feeding CAT is very slick avoiding a PC computer at the radio.

Another item is produced by RemoteQTH called IPControl. It is a remote antenna switch system using the ESP32-Gateway at the radio end. The code is open source and perhaps you can get some idea about the discovery from that. It is able to be configured for the major CAT protocols.
Here is a link: github.com/ok1hra/band_decoder_2

73 de Erik SM0JCA

Hi Erik, I will have to look at it once I find some time. Right now I'm trying to finish off the project so that I can deploy it remotely as well. One problem I'm running into is that the SPE can be turned one remotely using the ESP32 but when it is activated this way, it doesn't seem to respond to CAT commands or keypad inputs, for some unknown reason. I will have to do a bit of investigation to find out why this is so.