Algorithm for Tuner
Locked
 
|
I've always thought that the simple bubble algorithm was amazing. I mean,
if you weren't worried about wearing out the relays, and time weren't a factor, you could simply test every possible combination of L and C, and re-order them in pairs until the best combination bubbles to the top. This somewhat crude, but simple algorithm was used to alphabetize lists in Basic programs written since Basic was invented. It ought to be possible to program a variant which would use a simple sampling list of 50 combos to get a few "dips" , bubble them for best SWR, take that LC combo and then test the nearest, say 100 combinations, plus and minus these settings to maximize with a bubble test to find the best match. Explain to me, without telling me how dumb I am, why this won't work. Preston Douglas WJ2V _______________________________________________ Elecraft mailing list Post to: [hidden email] You must be a subscriber to post to the list. Subscriber Info (Addr. Change, sub, unsub etc.): http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/subscribers.htm Elecraft web page: http://www.elecraft.com |
|
|
> I've always thought that the simple bubble algorithm was amazing.
I don't understand the ins and outs of tuner algorithms, but I've always thought it was a shame that the first sort we teach people in Computer Programming 101 is the Bubble Sort. It's horribly inefficient (sort times are proportional to the square of the number of items) and is conceptually difficult for beginners because it doesn't match the way people sort things in real life. In this particular case, if you were to iterate over all possible combinations of L and C it's only necessary to store the best result so far and compare the current result to the best result. If the current result is better, it becomes the new best. Now you have no sorting at all and your time is order N instead of order N^2. OTOH it sounds like there are characteristics of the problem that would allow you to shortcut the process and not necessarily try every combination. That's where some knowledge of the way tuners work should pay off, as has been described by others. Craig NZ0R K1 #1966 K2/100 #4941 _______________________________________________ Elecraft mailing list Post to: [hidden email] You must be a subscriber to post to the list. Subscriber Info (Addr. Change, sub, unsub etc.): http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/subscribers.htm Elecraft web page: http://www.elecraft.com |
|
|
On Sep 15, 2005, at 11:22 AM, Craig Rairdin wrote: > In this particular case, if you were to iterate over all possible > combinations of L and C it's only necessary to store the best > result so far > and compare the current result to the best result. If the current > result is > better, it becomes the new best. Now you have no sorting at all and > your > time is order N instead of order N^2. The problem with the exhaustive search is there are 2^17 = 131,072 combinations to try. (256 cap and inductor values, plus reversing the whole L network) It takes a few ms for each relay to physically switch. If you can try 100 combinations a second (10 ms), that's still about 20 minutes to try them all. Even with 1 ms switching time, you're still looking at 2 minutes to find a match. A tough problem. Bill Coleman, AA4LR, PP-ASEL Mail: [hidden email] Quote: "Not within a thousand years will man ever fly!" -- Wilbur Wright, 1901 _______________________________________________ Elecraft mailing list Post to: [hidden email] You must be a subscriber to post to the list. Subscriber Info (Addr. Change, sub, unsub etc.): http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/subscribers.htm Elecraft web page: http://www.elecraft.com |
|
|
Bill,
It's worse than that. Even with my reed relays (very fast compared to conventional relays) I have to allow 10 mS for them to settle and the A/D requires a millisecond or so to read the forward and reflected power. A reiterative multilevel slope-sensing algorithm using decreasing granularity* is the answer. I have been slowely creeping up on a satisfactory solution and, depending on distractions, hope to have a fairly fast autotuner in a week or so. Suggestions from the list have been very helpful. * my term ... don't try to look it up! ;) Don K7FJ > > On Sep 15, 2005, at 11:22 AM, Craig Rairdin wrote: > >> In this particular case, if you were to iterate over all possible >> combinations of L and C it's only necessary to store the best result so >> far >> and compare the current result to the best result. If the current result >> is >> better, it becomes the new best. Now you have no sorting at all and your >> time is order N instead of order N^2. > > The problem with the exhaustive search is there are 2^17 = 131,072 > combinations to try. (256 cap and inductor values, plus reversing the > whole L network) > > It takes a few ms for each relay to physically switch. If you can try 100 > combinations a second (10 ms), that's still about 20 minutes to try them > all. Even with 1 ms switching time, you're still looking at 2 minutes to > find a match. > > A tough problem. > > Bill Coleman, AA4LR, PP-ASEL Mail: [hidden email] > Quote: "Not within a thousand years will man ever fly!" > -- Wilbur Wright, 1901 > _______________________________________________ Elecraft mailing list Post to: [hidden email] You must be a subscriber to post to the list. Subscriber Info (Addr. Change, sub, unsub etc.): http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/subscribers.htm Elecraft web page: http://www.elecraft.com |
«
Return to Elecraft
|
1 view|%1 views
| Free forum by Nabble | Edit this page |