Hi everyone,

I've been thinking about the process of setting up programmable timers for control line flying, especially when trying to find the "sweet spot" in the settings.

I'm curious how you approach this, so I wanted to ask a few questions:

• What is your typical process for finding the right timer settings for a model?
• How many flights does it usually take you to reach a configuration that works well?
• Between flights, how often do you end up landing just to adjust a timer parameter?
• Do you usually adjust the timer settings based on weather conditions—for example, on windy days—or do you typically leave them as is once you've set them?
• Which part of the timer setup process do you find the most frustrating or time-consuming?

I'm not asking about any specific brand—just interested in hearing how people actually go through the process of tuning their timers.

Thanks, I'd really like to hear how others approach this.

A lot depends on the timer for me.
The newer timers are Bluetooth enabled so it is quick and easy to adjust.
I start with an ~2 minute flight to get the desired lap time. Once established every thing else is adjustable. Boost, brake and landing cut off.

Quote from: Carlos Diaz on March 19, 2026, 06:33:15 AMWhat is your typical process for finding the right timer settings for a model?

This does get brand-specific.  I use Tim's Universal Timer (TUT) for the first seven seconds of the flight and for the loop kill and approach burst of speed and an Igor timer for the middle part of the flight. 

Most TUT parameters can be set a priori and stay that way forever.  TUT takeoff and approach-speed-burst settings vary with propeller and can be set relative to the other timer's target speed.

The first thing to do with an "active" timer is to adjust its orientation in the airplane such that fore-aft (x axis) and sideways (y axis) acceleration sensors read zero when the airplane is level.  From there, my process is:

1. Call somebody with the same system I'm using and ask him what settings he uses, then iterate around those settings.  When that doesn't work,

2. Ensure that there is plenty of headroom in ESC settings and that there are no known limits set in the timer.  I am theologically opposed to nonlinearities in general and limiters in particular.  Then set gains to zero and creep up on them, avoiding asymmetry until last. Then,

3. Heed advice from wise men when they see how crazy my settings are.

Quote from: Carlos Diaz on March 19, 2026, 06:33:15 AMHow many flights does it usually take you to reach a configuration that works well?

100 or so.  It's like trimming.  It might take fewer if I knew what the timer's control law is.

Quote from: Carlos Diaz on March 19, 2026, 06:33:15 AMBetween flights, how often do you end up landing just to adjust a timer parameter?

I don't understand the question.  Each flight is full-length.

Quote from: Carlos Diaz on March 19, 2026, 06:33:15 AMDo you usually adjust the timer settings based on weather conditions—for example, on windy days—or do you typically leave them as is once you've set them?

I set TUT takeoff speed as a function of wind and terrain.  I reduce the gain in Igor's old timer 20% in windy weather.  I don't have enough experience with his new timer to know what to change. 

Quote from: Carlos Diaz on March 19, 2026, 06:33:15 AMWhich part of the timer setup process do you find the most frustrating or time-consuming?

Guessing what the timer is doing.  If you want to make a transparent timer for which I can set my own gains, you got a customer. 

The Climb_and_Dive timer is open source and easy to program. Customize it to your hearts content.

I looked at the Climb and Dive documentation.  Impressive features. I didn't see a block diagram or formulas for how you calculate stuff.  Are those only in the code?

Do you have 3 accelerometer axes and 3 angular rate axes or a way to input those things from a separate inertial doodad?

The details are in the program code. It's written in CircuitPython which is a subset of the official Python programming language. It's fairly easy to read if you can get past my not so professional brute force programming style.

The backpack PCB utilizes a 3 axis accelerometer. All three axis are input to the microcontroller. No gyroscopes or other IMU devices are used.  There are some spare GPIO pins available on the microcontroller if you wanted to interface with additional hardware.

Quote from: CircuitFlyer on March 21, 2026, 06:27:54 PMThe details are in the program code. It's written in CircuitPython which is a subset of the official Python programming language. It's fairly easy to read if you can get past my not so professional brute force programming style.

The backpack PCB utilizes a 3 axis accelerometer. All three axis are input to the microcontroller. No gyroscopes or other IMU devices are used.  There are some spare GPIO pins available on the microcontroller if you wanted to interface with additional hardware.

Paul sent me the line item to edit for the speed up blip at the end of the flight. If I can edit it any one can.
And his documentation is rock solid!👍🏼