A bit of preface.
Below project is all about situations in HAM radio, when requirements such as "remote control of ATU", "remote control of PA", "antenna remote tuning automation" and "additional management and monitoring for ATU and PA" are in place. If this is what you are looking for, then, fortunately, explanations "why" (those above may ever needed) are not nesessary and this project may give you some ideas.
A bit of warning: below is the area of programming. And the prerequisite is basic level of C++ (familiar or willing to learn).
How it works together in a nut shell?
Very simple. Here is the generic diagram to the home setup:
Every device (in my case it is ATU, homebrew PA, SunSDR2 and PC with running ESDR app) is connected to WiFi access point and to PC-based MQTT server (by the way MQTT is cross-platform and can run on pretty much any PC OS).
So, what is happening, when I am working from field, say, IOTA island? Nothing special, the above setup is pretty much valid. Just using PC or Phone as WiFi access point for every device.
What is basic functionality?
Remote ATU (the device is instaled on antenna mast between antenna feed and cable):
- Automated tuning.
- Antenna feed input FWD power monitoring.
- SWR monitoring, based on FWD and REV voltage monitoring.
- Step values for ATU's L, C1 and C2 motors monitoring.
- Actual values for L (in uH) and C1/C2 (in pF) monitoring.
- ATU status display (i.e. “Ready”, “Tuned”, etc).
- All above values displayed on computer in remote shack. It may be same computer, which runs SDR programm.
- PA temperature (based on data from BME380 sensor) with automated and operations of PA Liquid Cooling system.
- PA output of FWD and REV voltage and calculated SWR.
- Calculated FWD power (based on FWD voltage value).
ATU principal components and why those?
1. ESP32 dev board it is an alternative to Arduino for small automation projects. Small size, low cost, low power consumption, in-build WiFi capability and quite powerfull 2-core CPU. WiFi makes it possible to get rid of wires and RS-485/RS-232 for command telemetry between ATU unit and PC. Stable on high PA outputs.
Within ATU, the ESP32 is, practically, all in one: motor and tuning driver, CWR reader/calculator, and communication (MQTT) client. It mounted in ATU's PVC box together with motors, drivers, coil, capacitors, and Tandem-Match. Because ESP32 requires dedicated max +5V to run, it is powered from simple LM7905 5V 1A regulator power supply.
2. 16-bit ADC ADS1115. In earlier remote ATU versions the internal ESP32's ADC was used. However, because internal is 12-bit only, it much less precise that 16-bit. ADS1115 step is 1 mV. With that precision of FWD/REV voltage measurements ATU can be tuned with less then 1W of power (as soon as Tandem Match devider can sense anything above "default zero" volrage). And, of course, you can tune devider itself to desired minumum voltage.
3. Tandem-Match - mounted in ATU PVC box as the output to antenna. There are few different concepts on the market. I have tested few and prefer to use the obe from EB104, due to its precision.
4. Communication protocol. Not Serial. It is not just because Serial is 1960 standard, old, feature poor and outdated. It is also because Serial will require at least two wires (or better, four). And those wires with the length of coax, passing through antenna's active zone - those are, no doubt, perfect source of interference. In previous ATU versions I was using RS-485 - it suffers less from interference, but still does.
Hence. If it is not Serial, then what? Answer is MQTT - IP-based, flexible, powerfull enough, low traffic communication protocol. It uses Client-Server model. Server is cross-platform and very lightweight. And Client can run on PC (Mac/Win/Linux), ESP32, Android or iOS device.
5. TCI. This is API-like, Transceiver Control Interface - proprietary communication protocol developed by Expert Electronics for their rigs (like SunSDR). It is unlikely at this stage other known vendors will adopt it. If you would like to re-create this project for your environment without EE rig, then there will be no TCI and you better to be prepared to modify comminication protocol code to match you rig's protocol.
6. Control devices (PC, phone, tablet).
MQTT Dashboard is the software and one option for control devices. The thing about it - that is only runs on Android and there is no clone (or software with similar feature set) for iPhone. (Well ... at the moment, at least and until someone will erite one. Might me I will do it myself later). I am using MQTT Dashboard installed on old Asus Nexus 7 for testing and visualisation purposes. There are heaps of MQTT alternatives for Mac/Win/Linux (like MQTT Explorer or MQTT Box, etc.).
However, another option (which is more in use for my setup) came from beauty of home programming: MQTT commands are embedded in my homebrew OCLog. Then ATU is easily controlled from same PC, where ESDR runs with small add-on programm.
7. Coil - no need to explain, I guess. I am using 1kW variable from Soviet P-140. Mounted in ATU PVC box with two variable capacitors.
8. Nema 17 Step Motors - to rotate coil and capacitors and A4988 Stepper Motor Drivers to operate with motors.
9. TCST2103 Photo-interrupters - those are controlling "zero calibration point" for coil and capacitors.
PA principal components
In earlier versions ATU and PA have been two separate things. Nowdays those two are becoming more and more software integrated and monitored through single piece of software. PA runs with ESP32 too. There are few additional components needed:
1. 1.8" 128x128 LCD TFT display based on ST7745. Embedded into PA's front panel. Any ideas why I need it? :)
2. BME280 or BMP280 sensor. It monitors the PA temperature and automates On/Off of the PA's Liquid Cooling system.
3. Simple relay for Arduino/ESP32.
Schematics (due to picture size opens in new window):
Remote ATU box generic schematics
Remote ATU 2-motor logical schematics
Remote ATU 3-motor logical schematics
PA ESP32 logical schematics
All software is open stack and can be used under common GitHub license.
Source code for Remote ATU ESP32 . PlatformIO folder format. (please note - code is not actial, I am preparing current code upload to GitHub)
Source code for PA ESP32. PlatformIO folder format. (please note - code is not actial, I am preparing current code upload to GitHub)
Source code for OCLog can be found here. It is Qt based and under constant development. Please make sure you read README to define if this software for you. It was built for specific purpose for field operations with main idea of minimalistic design, low power consumption and maximum integration.
Desktop screenshot with OCLog-controlled tuning process
T-match ATU physical construction Large photo in new window.
Parts and components links:
|1. P-140 variable coil|
|2. Two variable capacitors 15-700 pF (any, which will survive with PA output)|
3. Espressif ESP32-DevKit - 2 pieces
Any compatible ESP32-DevKit can be used, just look around Ebay to find one you like.
4. A4988 Stepper Motor Driver - 3 pieces
5. Nema 17 Step Motor - 3 pieces
6. TCST2103 Photo-interrupter - 3 pieces
7. 1.8" 128x128 LCD TFT ST7745
Display is used only in PA to provide visual information. Any type of TFT display can be used. If it is not ST7745-compatible, then library has to be changed in the code.
Some "catchas" and fair warnings.
Nema 17 Step-Motor information:
Nema 17 have 200 steps for full turn. A4988 driver allows reducing 1 step to 1/2, 1/4, 1/8 и 1/16. This gives you good control of what minimum angle you want coil and capcitors to turn, to fit intended tuning protocol. It was found that 1/8 is optimal for A4988 driver and Nema 17 with current planetary gear, providing 2964 steps for full turn. If your motors are different model or using different gear - number of steps has to calculated and corrections done in source code. Please note that motors require dedicated +12...+18V to run, completely separate from ESP32/A4988. Intention to use, say, single +18 power source for motors and feed ESP32/A4988 +5V from it via voltage adapter (like LM7905) will result in (surprise!) nice ESP32/A4988 burn-n-smell.
Coil and capacitors have to be measured to map 1 motor step to value. Those values will be coil-specific and capacitor-specific. Even you are using same variable capacitor-types for hot and cold in T-match, it is still recommended to measure and map those. This is because precision of tuning algorythm is directly dependent of precision of L and C values per motor turn. I am using AA-600 to measure L and C. This is not the only way, of course.
ATU tuning algorithm based on comparing "desired" SWR 1 : 1.01 and "actual" SWR. When "desired" is not equal "actual" - tuning occurs.
The tuning sequence is typical for T-match:
Step 1. Set C1 and С2 to 95% capacity
Step 2. Set L to 1.5 turn.
Step 3. Enables "Tune" on transceiver and start turing L till minimum available SWR reached
Step 4. Turn C1 till minimum available SWR reached
Step 5. Turn C2 till minimum available SWR reached
For L-match ATU step 5 is removed.
It was found that on most frequencies the algorithm reaches 1 : 1.1 from first attempt.
VK6NX overall concept, physical construct, initial programming, testing - and using :)
VK3FDMI SW concept, programming, customisation and optimisation.
Warm thanks to Dmitry RV9CX and Serge RA9DM for their support and suggestions.