|
Hello, people
Tom Court developed a new algorithm for us based on deep mathematic analyse
you can find his job here?
Also, as you can know, I wanted to implement more efficient algorithm from ATU-10 to ATU-100
Now you have? a great opportunity to compare both of them and choose what is better.
The winner will be implemented to new firmware for ATU-100.
Plese write your notices here.
Thank you.
|
Thanks for the build DF. ?This first algorithm is really a proof of concept of the GitHub project testing platform I created. ?The test platform allows easy testing of tuning algorithms and comparisons of their performance to another tuning algorithm or the best possible tuning.?
The attached algorithm did perform better than yours in theory, but I believe a lot more improvement is still possible. Still worth trying seeing if theory meets practice.?
BTW, some of my tuning for starting tuning depends on LC, vs CL. I think I¡¯ve got the simulation correct for relay settings correct for this but it might be nice if somebody doubles check. NOTE - The naming for the functions for the circuit simulation have been reversed from the python code (the code that draws the colored smith charts), because we are going in the opposite direction
|
Hi, Tom I tried your algorithm on my ATU-10 and my resistive load.  With 200 Ohm load your algorithm goes by cycle continiously. I see on the transceiver display that SWR goes to near 1 but the algo dont stop. sources in the attachment
|
One possible reason is in the routine:
int testSwLC(char sw, char l, char c)
{
? ?SW = sw;
? ?ind = l;
? ?cap = c;
? ?Relay_set(ind, cap, SW);
? ?Delay_ms(5);
? ?get_SWR();
? ?return SWR;
}
The SW and sw variables are seen as the same.? Change the sw to swx and recompile.? What this bug does is swap SW to the other "side" incorrectly.
|
Hi, David
Thank you, but it is not a reasot to run it continiously. Technically SWR goes to near 1 as I can see on the transceiver, the question why the alogorythm doesnt wanna stop.
With other load values the algo stop and even matching the load. the problem only with 200Ohm load.
|
Have you tried changing the code and recompiling? I had a similar issue but luckily I found the sw vs SW issue which the compiler does not flag.? Until I changed the sw variable to another name it was going through the tune, finding a reasonable SWR value but then stopping with the wrong SW side set.
I see that Tom has corrected the sw/SW code in his latest github release.
|
A word of caution. One can find the fastest match or one can find the best match. I suspect the two are not the same. It is possible for a tuner to have multiple combinations of L and C where a low SWR is produced. However, only one of these solutions is likely to be the most efficient. K6JCA did a lot of work creating his own 500 watt tuner. In Part 9 of his 10-part article he discusses finding the best return loss (lowest SWR) while obtaining a reasonably efficient match. His entire article is a trove of information about how an antenna tuner should be designed. One part I found particularly interesting was the section on inductor and capacitor selection.
Fortunately he defines his search algorithm in detail. One of my (many) complaints about "free" software is that it is poorly documented. I'm not complaining, but it is unfortunate that the ATU firmware archive does not include documentation on how it works. A flow chart would be very useful in order to quickly see how the algorithm works. It's simply not possible to compare dozens of pages of programming code to easily see how two different systems work!
Perhaps, someday, I'll sit down and struggle through the C code and convert it to an easy-to-understand specification.
My main point is that the efficiency of the final match needs to be considered, otherwise we are probably best sticking with what seems to work reasonably well. One last point. Poor efficency means that the power is going somewhere, just not into the antenna. That usually means higher voltages and currents within the tuner which then dissipates energy in the form of hot components.
73,
Chris, K9EQ
|
Hi, Chris, I don't think the §¤ shaped matching has multiple minimum SWR combinations. I think there is only one in ideal condition.
|
I've developed an extensive test framework for comparing both how fast and how well algorithms perform using a simulated matching circuit. I've commented the code for my newest algorithm to some extent. It's actually fairly straightforward except for the derivations of the WAGs (wild a$$ guesses). You can see it and the framework at?
The algorithm in the extensive article from k6jca you mentioned is not much different than my last iteration (the one posted on the group previously).
|
Hi, Tom
Your algorithm has the disadvantage of unconditional 73 point checks. This causes SWR goes to very large value and a TRX reduces a power to almost zero.
If you wanna build really practically working algorithm you must resolve this problem.
Only one tester tried your algorithm and in the most cases it works slower than original one.
I see very little interest in new algorithms. I think the old one works well and users just don¡¯t need it.
|
I was a little surprised when you put the code built code out there to try. The algorithm was really just a first iteration at it was only about 20% improved over the existing algorith. I've got a much improved algorithm (with regards to the hill climbing) currently checked in to github, its more at 70%s. I'm still working on a better method for locating the hills to start climbing (the initial 73 points), until thats done I'm not sure if it will be completely practical.
There is a bug somewhere in the 'battleship' mode that I can't quite pin down, so I'm not sure if I'm getting the best values to begin with. Despite that, in emulation it does quite well. But I still do want to get rid of a fixed table for starting points anyways.
Was the report of the slower tuning something on this board or a private communication? I did see your reference to getting stuck tuning.
Regarding the porting issue due to SW = sw being misinterpreted. I'm wondering if there are other porting issues with the target compiler if the actual performance doesn't seem to match the emulated performance.
|
I converted my ATU100 firmware 3.2 to use Tom Court's latest algorithm that is available from??see tune2.c and tried it on my usually problematic doublet antenna.? It works a treat on my usual bands (40/60/80) and achieves a sub 1.25 tune in just a few seconds.? Certainly the best algorithm I have tried. I understand this is work in progress and there is potentially better to come. This is science ()?being applied by a good software engineer, thanks Tom Court. In my view David N7DDC did a good job with the hardware design and this software will take it to the next stage! 73's David M0TGC
?
|
Correct, there is only one "ideal" matching point. The problem is finding it. The article I referenced was for an L-type tuner. The article also had a design of a search algorithm which is worth, at least, looking at. It looks pretty well thought out. Unfortunately I can't determine if the existing algorithm is well thought out as it is not documented.
73,
Chris, K9EQ
|
Is the Github code pointed to for the
ATU-100 or ATU-10?
Seems to be? a conflict here, nATU-100
in the post and ATU-10 at Github.
glenn
|
Could be either.? I used the code in tune2.c to replace the
tune() routine in the ATU100 3.2 firmware
On 20/02/2024 21:58, Glenn via
groups.io wrote:
toggle quoted message
Show quoted text
Is the Github code pointed to for
the ATU-100 or ATU-10?
Seems to be? a conflict here,
nATU-100 in the post and ATU-10 at Github.
glenn
|
Chris, my tuning algorithm isn¡¯t too different than the article you referenced, but I think you will find that the tuning algorithm in the article results in a lot more switches to find a solution. ?It is certainly thorough, but without a way to re-use tunes by frequency matching, it might not be an ideal trade off.
I start out using an optimal table to find a point to start hill climbing, going from the most likely to least likely, rather than running through all the Ls and Cs by 8
Then rather than look in all 8 directions, I only look in 2 directions along one axis and then the other. But identical to the article, I keep reducing by a factor of 2.
I only start walking the diagonals if I haven¡¯t gotten a good match by this point in my 8 way search function.?
I have seen the ¡®false¡¯ peek problem with my test points mentioned in the article, but it is very very rare. ?I doubt it¡¯s happening much in the field when you look at all the data. ?I believe it might be related to the component step size bing closer to 3 so sometimes a couple of inductor steps is better than one capacitor step or visa versa. Going to binary component values would fix this problem, but introduced the problem that imprecise components or parasitics on the board would result in reversals values with binary steps of 1. ?
|
Hi,
I've been looking at adding frequency monitoring to the ATU-100 HW.? I have it mainly working (current front end gain is wrong above about 24MHz), so need to tweak some of the network values to get the right voltages and offsets. As part of this I've been wondering about better algorithms, I'll have an experiment with the tune2.c once I've got the freq monitoring sorted.
As part of my research I've been looking at the Icom-AH4, LDG IT-100, MFJ 939.
Interesting, you should mention the steps.? For the inductors, you can measure and tweak, to get them power of 2.
For the capacitors, the AH-4 (and I think the MFJ) uses the same value (so probably same batch, so similar capacitance) 2 in series, as a single, and two in parallel for the smallest 3 settings.? So this should give pretty good binary steps for the bottom 3 bits.? I wondered if it was a temperature thing (for the AH-4) as they would all drift together.
But with what you mentioned, it's an easy way to get pretty good power of 2 values for the bottom 3 bits.
The AH-4 (and SG-237 which I've looked at by don't own, so can't do much checking with) are both remote tuners, and they have separate input and output capacitor banks.
Looking at the schematics, they use fewer bits of smaller capacitors on the antenna side than the input side (as a PI rather than an L).
The SG-237 has 7 bits on the input (51pF...3200pF) but only 4 bits on the output side (12.5pF...100pF) - With 8 bits of inductors.
(Not fully traced the AH-4 board, looks like 8 bits + 3 bits of capacitors + 9 bits of inductors)
Given the limited range on the output, I wonder if the SW=output side range could be significantly restricted.
I started looking at the LDG relay patterns and can already see ways to optimise it (they use bipolar relays, and wait after both the +ve and -ve switching, even if no relays are changing on one phase).? But I only have a 16 channel analyser, so looking to piggy back a monitoring PIC on top of the current one (they use a 28-pin 0.3" DIP PIC, so easy), with this I can output the frequency, relay pattern and Fwd, Rev voltages to a serial port when things change.
Keep up the good work,
Following with interest,
Roger.
|
Just been looking at the tune2.c, and seen the LRU list.
While looking at the LDG and MFJ relay patterns I see several repeats, given that the code tracks the best found so far, there seems no point in testing something that's already been tried.
For the 7x7 + SW it's 15-bits = 32K combinations, but using 1 bit per (instead of a list that needs searching) that's 4K Bytes (so too much for the internal RAM).
|
Oooo, the ATU100 has the capability of measuring frequency???
It sounds like it might take significant development work, but adding stored tuning information to make later tuning instant on the same antenna would definitely be a worthy feature¡
|
I've got the basics working. ?Just doing spice sims to work out some component values. ?Basically the 74AC14 at the front end needs a 1V...4V signal. ?Over the whole frequency range, from 5W...100W. my first guess worked to about 20MHz. ?This was using 16kHz resolution. 
|
RogerW/GW6HRU
Joshua K1MI