I've been reading through some of the messaging for the ATU project and reading the code. Concern for reliable tuning is often expressed. I gave some thoughts on how to test this and I came up with the following test code. Likely it still needs work, but it seems a good starting off point.

I started by looking at the python smith charts with its LC basic complex impedance simulation. I took that code and put it into a C module and then combined it with tuning algorithm from the ATU-10. I also added a way to view the results from many test points.

It starts by finding the ideal impedances for a logrithmatic distribution of points from 5 to 500 ohms and -500j to +500j. It then runs the tuning algorithm on all of those points, while tuning the resulting complex impedance is calculated through simulation to determine the SWR and thats fed back into the tuning algorithm. Finally a basic user interface lets you walk through the results. It lets you change the scaling of the 0-9 results, switch frequencies and view ideal vs. differences from tuned and ideal impedances.

Currently the code runs on a Mac, it should be easy enough to modify it to run on other platforms.

Hi, Thomas
your work is very valuable, but the original tuner algorithm does not see a frequency of signal, only SWR and power level .

开云体育

Yep, the doesn’t show the tune algorithm the frequency. It only interfaces with the algorithm by presenting the current SWR, and the tune algorithm feeds back using the relay command. Power is ignored in this section as I assume I’ve got enough power for a good tune signal. The file tune.c is simply the tune portion of the original main.c, I just removed everything else for clarity. My impdeance.c file implements stubs for testing the functions called in the tune algorithm. But it never touches frequency (except to simulate the resulting hardware behind the scenes).

This updated impedance.c (attached) fixes the bad test results showing up in the original code. It shows which test points give a worse impedance result than possible. It also shows how a count of how many 'tunes' it took to get the final result. To switch between 'differences', 'ideal-swr' and 'count-to-tune', press g or G to step through the options. Need to move this to github.

With test code like this it should be possible to optimize the tune algorithm. A few things I noticed as possible issues are:

• Rough tuning walks binary tunes, but seems to skip 64 (< 64 check).
• Fine tuning might skip over a big E3 jump due to component spacing. Seems like a conversion to pF or nH is needed and then a smaller jump used based on nearer component (rather than index value) is available
• When a <1.2 match isn't available, I'm missing where it jumps back to closest match it could find. (Could have missed this somewhere in the code).
• Possibly bigger algorithm changes. I don't see a walk in all 4 directions for hill climbing to best SWR.

Hi, Tom
Yes, practically E3 row works much better and provides higher max value.
Unfortunatelly I dont have any MAC and I dont know how to use your code. Would be better you wrote it using Python, but probably? is? exist some solution how to run the code on Windows.

• Rough tuning skip 64, that's right, fine tune will reach the result anyway, but we can fix it, I agree.
• Yes, I will think how to make a step more smoothly using lower bits. It would be helpful only if the current value is large enough , and useless when the value less than 10.
• That is a reasonable minimum, to decrease a time for tuning
• 4 directions ? 2 directions on each sharp_xxx(), up and down, and also 2 ways with C before L or after in tune(), 4 ways in total.

I checked in another update into github here:?

It has two copies of your tune algorithm, one in a file called tune1.c another called tune2.c. To allow this to link I had to add static keyword to most of the functions after tune. The re-use of the tune name was fixed with a rename provided a #define.

This allows comparing the performance change between your original code and any modifications or improvements. You can still compare to a best tune as well.?

I can port the PC if you'd like as well, just let me know your development environment an I'll try to make it happen.

Here is a screenshot of the UI:

Hi, Tom
I can install MinGW 64 or VS2019 on your choice, I am not a C programmer on Windows, prefer Python.
I still don't understand how to recognize those numbers but I wanna do it.
I guess the algorithm in ATU-10 works perfect but if there's a possibility to improve it, why not ?
I have made a battery of no inductive resistors, switching 25,25,50,50,100,200,200 oHm, so I can set up resistance from 12.5 to 200 OHM and check the tuner on it.
Practically, matching of resistive load much more difficult then mixed reactance. You can use this to create more efficient test bench.
You told before, heard about bad experience with ATU 10 working, it's connected with bad Chinese manufacturing.
Old burned or stacked relays, not soldered relays pins, randomly soldered capacitors, not RF grade capacitors dielectric, bad cloned amidon cores with high loss. This makes a tuner particularly or totally non worked.

The screenshot may look like garbage if viewed in some proportional fonts. Looks OK for me on my browser

Basically anything with a 0 is within 0.1 of the ideal SWR match possible. Tuned using your tuner algorithm minus the best possible match available.
The legend on the right shows this but in a very abbreviated manner
- = ? ? ? SWR difference < 0
0 = ? ? ?SWR difference >= 0 and < 0.1
1 = ? ? ?SWR difference >= 0.1 and < 0.2
etc
+ = ? ? ? SWR difference >= 1.0

The numbers are a little harder to interpret than pretty graphics. But it is workable once you get use to it. Similar how they did it all the way up to the 1970s.?

I'm working on adding a way to view a particular tune attempt to see what is happening when a less than ideal tune happens. You'll be able to select a single tune attempt and it will show a big scrollable array of L,C space with the SWRs for all the points. Also you will be able to see where the tune algorithm actually looked when trying to tune. This will answer the question I have, is there a single climbable hill for best SWR or is the search surface more complex.

Finished the test code and checked it in at?

I'd tried to port it to Visual Studio, no complex data time so I tried to roll my own. Way too slow. So I ported it to MinGW (gcc). It took minimal changes.

The github project has a reasonable writeup, but likely I'd forgotten something. Let me know if you have any questions or needed improvements.

I think I've discovered a tuning bug. For some of my test points, a relay_set of -128 will occur. During the fine tuning, a char overflows at the start of a for loop in the code below.

My current checkin on github has assert's that will trigger at this point.

Hi, Tom
I think we can remove the step size correction in for(), try this
I also fixed under 64 limit

Just checked in an update that adds a mode that I'm calling 'battleship' to find a close to optimal search pattern to begin the hill climbing.?

I think the search pattern suggested is a little more chaotic than a planned one. Because it tries to get the best first match, it tends to make holes for the next few matches in the search space. My idea is to tweak it to make the first 20 or so searches be along the near zero C line, with a wider spread of L's, for both LC and CL configurations. From there, the search should be effective at finding holes to fill.

Worked out to 65 tries to get all the test points to work.

Tom, my algorithm do almost the same but stop after find the best value, it is faster then try all the 65 tries with no stop.
Why you think this will work better ?

When I ran your algorithm, I found a number of times where it just didn’t tune. Most of those were where it missed finding any hills in a wide plains of 9.99 SWRs. ?Please excuse the geographical analogy, but I find it helpful.?

When I browsed around using the test framework, for some test points of frequency and complex impedance, the hills were quite large, other times they were fairly small. That’s why I added the feature to try to find the best points to search for a hill in the plains.?

I’ll admit the search might not be perfect, there might be some stacking of the values due to the math of the regular complex impedances and the frequencies having common fundamentals. So these test values might not entirely reflect reality ?

Any luck in getting my code to run? A little experience with it might be more instructive than I can easily explain.?

Also, feel free to contact me via email or message if you’d like.?

Also, to be clear, I’d think the best strategy would be to run through a set of fixed wild a$$ guesses roughly corresponding to the ones determined by my algorithm until a non 9.99 SWR is found, the switching to hill climbing. Most of these would end in a handful of switches

Still a little rough, but here is a prototype (also checked into github) for a new tuning algorithm using the optimized starting points. There's still some bugs that need to be knocked out and the tables need to be simplified and/or optimized.

Should be a little clearer what I have in mind.

Notice how it tries the list of guesses before starting the hill climbing algorithm. The hill climbing is simplified as well.

Hi, Tom. The original algorithm will try all the 64 steps for L and C when the initial SWR more then 9.99.
It is not important actually, because an antenna with 9.99 SWR it's not an antenna so no any sense to match it?

Hi, Tom

I have tried to implement your code to ATU-100, but not enough RAM unfortunately.

But I did it for ATU-10 so everyone can try your algorithm and compare it with mine.

You could probably save 200 bytes of RAM by adding the keyword const before the wag arrays.?