Great job Pavel.
I would like to buy PCBs for the tandem match. You saved me loads of work.
Regards
Paweł EI9HEB.

@EI9HEB, no problem, I have answered your email already.

@ALL - guys, I understand your interest, but lets keep this thread for techical info and questions.
Please keep in mind that this is EE forum. Any questions outside technical discussion - please email me (you can easily find my email in qrz.com page under either VK6NX or VK3XNX).

Remote ATU "phase 1" is approaching its final, and here are the questions "where we are at?" and "what is next?".

Lets start with brief for the first one.
ATU 8x8x8 HW design is currently with version 0.5. We believe it is final HW tuning (as the result of intensive testing and measurements). What is new in 0.5:

- AD8310 embedded, with Tandem based on BN43-3312 (20:1)

vk6nx.net//images/remoteATU/Tand8310.JPG

- ATU HW mode selector embedded. I like this feature - it alows to convert 8x8x8 C1-L-C2 T-match into Li-match with C1-L configuration, or into L-match L-C2 configuration. This is done by embedding two extra relays into latest HW and code. The generic schematics is below:

vk6nx.net//images/remoteATU/ATU-mode.JPG

The default (K25 and K26 are OFF) is T-match mode. K25 and K26 are programmably switchable in ATUconnect. Hence - no need in separate L-match and T-match HW anymore. Single "universal" device will do the job.

- Control part is slightly redesigned (some adjustments done with SN754410, separating VCC1 and VCC2 circuits) and looks like this in KiCad :

vk6nx.net//images/remoteATU/Control-KiCad.JPG

Here are the PCBs pics:
vk6nx.net//images/remoteATU/ATUv05-1.JPG
vk6nx.net//images/remoteATU/ATUv05-2.JPG

ATUconnect is updated:
With new interface:

vk6nx.net//images/remoteATU/ATUconnect1.JPG

and new feature set:
1. Added Antennas database with presets. This section allows to pre-calibrate antenna to the frequency and binded initial parameters. Start values are defining the relays switched ON by default for given antenna at given frequency. In this below screenshot 64 means "step 64 out of 255" (equals 330pf) for C1 and C2 and "step 4 out of 255" (equals 0.2uH) for L for the MFJ-1796 antenna at frequency 7010 KHz. The Algorithm initial step parameters are instructing ATU the initial step count and step direction while tuning.

vk6nx.net//images/remoteATU/ATUconnect2.JPG

2. More sufisticated setup

vk6nx.net//images/remoteATU/ATUconnect3.JPG

3. Added supported ATU modes and corelated tuning algorithms

vk6nx.net//images/remoteATU/ATUconnect4.JPG

4. Added debug mode, which allows relays manual override.

vk6nx.net//images/remoteATU/ATUconnect5.JPG

TCI-MQTT-Gateway was developed, giving us much more flexibility for future TCI library release.

vk6nx.net//images/remoteATU/TCI-MQTT-GW.JPG
With all respect to the job, which Enzo had done developing his Arduino library, we had to drop it from our project and move to TCI-MQTT-Gateway. TCI-MQTT-Gateway gives us huge advantage moving forward, when EE will be expanding available TCI commands with new versions of ESDR3. With TCI-MQTT-Gateway the new commands will become immediately awailable for ATU with no need to update the library on our end. It is the step toward full automation, yes.

As I have mentioned earlier, we are at final stage of testing now. Once completed (targeting mid June this year), the current private repositories at Github will be opened for public with KiCad, Gerber and source codes. TCI-MQTT-Gateway is released and available now github.com/dkaukov/tci-mqtt-gateway

Brief on what is next:
1. We are refactoring software. Making it more and more universal and allowing quick features add and potential support of different ATU HW types.
2. We are going to create a separate fearure set for Remote ATU-TX and Remote ATU-RX. As we all know, TX antenna is not always the best for RX. For those of you, who have dedicated RX antennas (like active loop, or beverage, or whatever) connected to second Ant input of SunSDR2, we are going to add the capability to automated tuning to the best available SNR value, while using both: external mechanism like antenna rotators, plus TCI operated commands of SunSDR2 preamp, NR, DSE, etc. It means we will be sending more TCI feature resuest to Roman

Last thing - if we are going to make "ready devices"? We do not know as yet. It is possible. All depends on combined interest. Let's return to this question later.

Quick update.

HW ver 0.6 is the current/latest. Schematics and Gerber are all published here with description.

Software and Firmware links, are all on Github. I am still working on ATUconnect app. At this stage it only available for Win x64 and macOS. You can download and run it now. Not much value without ATU itself but at least may give an overview what is inside.

I am waiting for my DX to arrive to complete the tests. On combinations SunSDR2 + KXPA100 and SunSDR2 + EB104 the whole set runs really well.

Cannot say I am entirely happy , it is more bulky in size than I have expected. Still - very comparable in sizes with alternatives and definitely three times less in weight than my P-140 based one.

From now I am going to catch some days to do field testing with different antennas. Shortened vertical dipole (MFJ-1796) on 40 meters it does lovely. I have even tested it on 20 meters (where I do not have capacity hats now, so I am guessing it was tuned from 40 meter set) - UE1FA got from second call, 100W on 14MHz, which is really surprising given my location and current propagation.

Current feature set highlight:
- T-match and 2x L-match configuration (all in one)
- 0.01W (tested) to 200W (tested) tuning power and from 0.01W to 400W (tested) / 2KW limit operational power
- ATU type presets (unlimited) and Antenna presets (unlimited)
- TCI based "Follow VFO" function (reads active VFO and automatically switches between predefined Antenna presets)
- Automated and Manual tuning modes
- all 5V
- WiFi required. CAN bus in development.

I am going to order set of current boards in a few weeks time. Let me know if you are interested. The only problem for now that the shipping cost is currently ridiculous from AU to anywhere as out snail-mail seems trying to cover their covid-losses.
I am going to make two sets for myself, the rest of PCB are free to go (minimal order from AllPCB is 5, hence I have at least three extra sets). I am not expecting HW changes anymore, from now all is going to be about SW and FW. Latest (0.6) HW version has embedded support for either ESP32U (38 pin) or ESP32D (30 pin) devboards and CAN (protocol itself still under development).

Pavel,
I have small question why did you chose CAN bus instead of RS485?
I find the CAN bus to be an absoultly pain in the b...
Regards
Pawel EI9HEB

There are few reasons, mate.

I was using RS485 in ATU v.0.0.1 (P140 variable coil based). And I am currently using CAN in Flatpack2 rectifier control. Hence, there is practical experience - usage and programming - on both.

My reasons:
1. RS485 uses Serial, which will have limited speed on longer distance. We had to write special RF-protected protocol for RS485, while using it with ATU v.0.0.1 and max speed we have acheved for 100 meter distance was 9600. Also RS485 uses one interrupt per message - this causes delay on motor-based solutions and requires special care in collision avoidance mechanisms. One of the reasons I have moved from Arduino to ESP32 was exactly that (with ESP32 is was possible to use 2 cores to implement interrupt avoidance). CAN potentially has capability to go over 320000 speed, but I am targeting 96000 for now.

2. There is no reliability mechanism in RS485. Not even collision detection. All reliability has to be programmed (time and maintenance again). CAN has embedded collision avoidance, tx failure detection and auto-retransmit of failed messages.

3. CAN has data frame structure, which simplifies programming for different tasks (based on message ID). CAN also has message prioritasation mechamism, hence when there is a "simultaneous TX" collision, the message with higher priority will pass through. Not possible with RS485, unless we write it into protocol "from zero".

4. On personal experience, available RS485 modules are very "fragile". Through 3 years time I have swapped 3 or 4 modules, because of their high sensitivity to static and non-tolerance to voltage variations of more than 1.5V. Perhaps I was using cheap and badly designed modules, but this is what we can get from market.

5. RS485 is L1 and CAN is L2. Hence, for CAN to be able to integrate with IP, we need to write only L2-to-L3 interpretation, when for RS485 we need to write L1-to-L2 and then L2-to-L3. Not a drama, so far, just time and maintenance reasons.

---

Add On
@Pawel, if you are using RS485, I can join you to our project at Github, so you can have a look at the protocol, which we had to write for RS485 earlier days. This one was specifically designed for RFI protection.

Thank you for the information.
Soon as you mention Flatpack2 it was clear for me.
I have one of them too, and the first thing on my mind was how to get the real-time voltage and current from the flatpac2 on the EB500 display and on the Node-red dashboard.
I have the CAN bus module but now I have to write a library for it from scratch.
for the last 20 years, I write in Basic for AVR's, so C++ or Java scripting is painful for me.

I never had any issue with RS 485 but I always use it in full-duplex configuration and with good protection like gas discharge tubes etc.
For my rotator, mast, and compressor control, I use LAN with a small module USR TCP-232-E45.
I like your idea about ESP32 for the PA I will look into that when I get a bit of time.
Band decoding, bypass for tunning would be a great idea.
VK6NX пишет: If you could that would be very helpful.
Best Regards
Pawel EI9HEB/SP9DR

EI9HEB пишет: No worries, just PM me your email for Github and I will add you.

EI9HEB пишет: Hmm... no need, mate
Same as above.

Just note that I step away from MCP2517xxx (there was a reason) and use CJMCU-1051

Main problem with Flatpack2 (and the answer for the question why most of libraries on Github are either not working or incomplete) - we are dealing with proprietary ELTEK solution. Surely, ELTEK is fortifying their protocol against hacks and changing it with every new hardware version. Hence most working libraries are not distributed freely - no one wants the problem.

EI9HEB пишет: Band decoding is already done, as it was needed for "follow VFO" function. I am just using TCI VFO conversion. However, it will be more easier in future, as there was the TCI addon request lodged some time ago and it might be added already to first or second instance of TCI 1.5. We will see it soon.
PA bypass is what we certainly have to wait for TCI, but I think this is in TCI 1.5 already.

BTW, there are plans to expand my current PA control. Again, nothing wrong with in-build DB9 and current ESDR2 feature set for LPF control. It just short distance. If I will need to move PA 50-100 meters away from SunSDR, then I need another solution, which I am about to start programming

Back to ATU.

Please remember, that what I am building is build with DXpedition's mind. With primary targets to reduce weight/size/power consumption. Power is self explainable for everyone, who operates on field. Weight/size would become valuable after first disembarking to the island in rough waters

I have nothing against RS485, it is good option, specifically when you can build full duplex solution. CAN just gives an opportunity (both timely and programmatically) to reduce the cost and various footprints. In most cases it can do on half duplex what RS485 can only on full duplex - this brings us to 2 wires against 4 with CAN - a direct implication to wire cost/weight, when it comes to 100meter+ wires.

And on my IOTA practice I often came across the need of distance >100m between shack and antenna.

As for T-base Ether - it has two main issues for field operations: distance and RFI.

10/100/1000Base-T are all sharing the same issue (in terms of RFI): 125MHz clock. There is a lot of information on web how it is related, for example here.

Certainly, there is Ethernet RFI protection in ESDR2/ESDR3. However, every protection has its limit. Longer the T-base cable - more chance we will hit this limit.

1000Base-LX is very good option, but up until now there is no feasible (in terms of cost) solutions for Arduino/ESP32 on pure LX. The best we can do now, perhaps - use something like this. BTW, it has own feedback - when optic is great with static applications (like using it at home to operate mast motor), in field operations (like DXpedition) optical cable is certainly represents some issues (handling and physical protection).

However, with all above in mind, I am trying to fit my code to support every media. Whatever we did on CAN - easily might be ported to IP.

Current HW ver 0.6 version of PCBs are on the way from manufacturer with ETA 05 of August. This PCB version has embedded support for 30-pin and 38-pin ESP32 dev boards and space for CAN board. There are no plans at this stage to update PCB design, it is intended to stay for a while.

I have majority of PCBs already reserved, only two sets available. Please contact me if you want them. PCBs are TG-150 material, 2oz copper, HASL, 1.6mm thick.
Further details are at vk6nx.net/RATU_T_v0.6-en.html

For contact email please use one displayed at VK6NX at QRZ.com

Hi Pavel,
I'm back in Ireland, so I should have more time for projects ( I hope).
my GitHub ID: EI9HEB and email Этот адрес электронной почты защищен от спам-ботов. У вас должен быть включен JavaScript для просмотра.
Regards
Pawel

Added to both projects and emailed additional quick info.

I am working on websockets now. The idea is to embed TCI-MQTT-GW into ATUconnect for cleaner deployment and maintenance. But requires some "drum dance" around.

Looking at what Qt has (finally) in 6.2.0-beta2 for websockets - it is "a disaster". Seems old Qt4 lib just punched into current code. The QML integration level is a joke too. I have to go back to my initial plan to deploy QTCPsockets lib for websockets and integrate it into QML.

Current HW ver 0.6 version of PCBs arrived.

I found two cosmetic issues on B-side of L-C1 board. Nothing what should affect functionality, but if you are after "perfect look" of PCB , then please hold downloading Gerber. I am about to update it.

Myself, I am going to use current 0.6 boards. As I said, nothing what should affect functionality.

Over last two weekends there was intensive field testing of the 8x8x8 HW v0.6 under 500W load.

The antennas I have used were: AV-640, Spiderbeam and MFJ-1795(modified).First two were intentionally left without fine tuning, to see how 8x8x8 can handle it. MFJ did not require that "interference", as it is narrowband/untuned by nature

It was also the comparison for current HW v0.6 with variable cool based ATU (P-140) to see what is real difference in tuning time and (if any) operations.

The overall results:
40m band (confirmed with CW skimmers and QSOs)
30m band (confirmed with CW skimmers and QSOs)
20m band (confirmed with CW skimmers and QSOs)

Due to current solar/prop conditions I could not fully test it on upper bands. Workbench tests with dummy load are OK, but for field ones we have to wait, I guess.

Meantime, due to the above, HW ver 0.6 + SW will be moving to 1.0 release. I will update Github and site with latest descriptions and details within 1 week from now.

For those of you who are interested in PCB - I have few sets left from last arrival and I can easily order more (or you can do it yourself, as actual Gerber is openly available).
I also have full BoM and calculation - for materials cost it comes under USD $300 in total, including PCB, assuming ordering capacitors/resistors from Mouser or Element14, chip-based electronics from AliExpress/Ebay and toroids from your local distributor. I also have spoken with PCB manufacturer regarding partially assembling PCBs - the price they come up is questioanble (from $80 to $210 dependent on number of soldered elements), hence from my point of view this would be feasible with lower price only in case of bulk order.

The SW versions are pretty much in release mode already, I am using them all time. Both - Firmware and ATUconnect are now entering release mode with common updates for ATU functionality from time ti time.

In some future (perhaps September) I am going to make a video, comparing two my constructions P140- var coil ATU and 8x8x8 (current relay one), so you can see and hear all relay "clicks" and motors movements But I need some good weather for that to capture video on antenna (and currently it is a bloody cold winder in Down under, thanks to global warming enthusiasts).

Any questions about construction/elements/details/functionality of 8x8x8 - please do not hesitate to contact me.

For our dev team it is the time we move to our new project...

Finally ... I have managed to record the video about ATU in action

However ... This time it is about variable-coil based (which is the source for relay-based one).

Hi res 1080p (download the file): mega.nz/file/GEoCHDwA#6a2FKN4T8PV8xqHrtYswP-_QrboZLcVmj9fMJsNX1S8
Low resolution Vimeo link: vimeo.com/manage/videos/660187639

Nothing really special, just a walk-through and quick about generic functions.

The video about "relay-based 8x8x8" will be a bit later. Hopefully in next week.

P.S. For those who are interested - I am not saying that what you will see at the end of this video, is something I would recommend. Obviously, not. This is all about this ATU capability. With some imagination you can extrapolate how it will operate with common antenna, which requires tuning for some reason.

P.S.S. Let me know if you need further information about this project or its components.

That was really impressive Pavel!
Looking forward to seeing the next video using the relay based 8 x 8 x 8 ATU, as I also have one of these (from a guy in Ukraine)
73
Ray G3XLG