Miami Mike's blog View Details
Posted by Miami Mike | Oct 26, 2021 @ 09:26 PM | 11,041 Views
Introduction



A full-scale sailplane pilot told me that the yaw string is the most important instrument in a sailplane. It's hard to believe that it's more important than the airspeed indicator, altimeter, or vario, but he was very clear that the yaw string is important, even though it's just a piece of yarn taped to the canopy. Apparently without a yaw string it's hard for a pilot to tell if his glider is making a coordinated turn, meaning that the fuselage is aligned for minimum drag as the plane turns or circles. So if it's difficult for a pilot sitting in the cockpit then it seems reasonable that it would be difficult for an R/C glider pilot on ground. The yaw sensor is meant to serve as the equivalent of a yaw string for radio-controlled sailplanes.

This is a project that I started a couple of years ago but didn't do much with it until recently. It works with OpenTX / EdgeTX radios and telemetry receivers. A voltage sensor is required, such as the AIN2 input that many FrSky receivers have. When working in conjunction with a Lua script it will produce beeps to indicate how far from center the fuselage is aligned and in which direction. An adjustable "window of silence" stops the beeps when the sensor is aligned with the fuselage.




Next: Building a Yaw Sensor

...Continue Reading
Posted by Miami Mike | Oct 01, 2021 @ 11:16 AM | 12,838 Views
Double centering is a problem where the center position of a control surface differs, depending upon which side of center the control surface was at before it returned. Using the rudder as an example, you move the rudder stick left and then back to center, and observe that the rudder has stopped slightly left of center. Then you move the rudder stick right and then back to center, and observe that the rudder has stopped slightly right of center.

Of course the first step in trying to correct this problem is to work on the model, tightening the linkage, changing its geometry, eliminating binding, replacing a worn or cheaply made servo, fixing a damaged hinge, etc. In general, you try to eliminate slop where you can.

But if all that fails and you still have some double centering that you'd like to reduce further, or perhaps even eliminate, and your radio runs on OpenTX, you may be able to reduce or eliminate the problem with radio programming. The idea is to program the servo to move the control surface from its extended position toward, and then slightly past center, just enough to compensate for the play so that it stops at the same position when coming from either direction.

Here's an example using the rudder:
  1. Choose a global variable to set the amount of extra travel past center. In this example I'll use GV1. It should be set to a minimum of zero, and for the maximum a value of 10 seems reasonable, although more may be needed in extreme cases. Make sure the GV is
...Continue Reading
Posted by Miami Mike | Aug 18, 2021 @ 11:23 AM | 23,492 Views
SD Card Version Editor
For OpenTX "Taranis"-style radios without color screens
(An updated version that also works with color screens may be coming, depending upon interest.)

Many OpenTX users have customized and contributed to the data on their SD cards with their own voice announcements, scripts, images, log files, and other additions and changes that they don't want to lose by updating their SD card contents when they upgrade to a newer version of OpenTX, especially when in most cases it's not really necessary. However, if you don't upgrade the SD card contents then when OpenTX powers up and reads the file named "opentx.sdcard.version" in the root directory of your SD card, it gives you an "SD CARD WARNING" message saying what the expected version is, and then your radio won't continue powering up until you press a key.


A popular workaround is to edit the opentx.sdcard.version file to say what OpenTX wants so that the warning message will go away, and here's a tool named "Edit SD Version" that makes it easy to do that with your radio. When you get the warning message after an OpenTX update, all you have to do is note what the expected version is, select the tool, edit the file with your up and down buttons or rotary knob, along with your enter button, and then select "Save and exit". If you then turn your radio off and back on you should see that the warning is gone.

Download Edit SD Version.lua and store it on your SD...Continue Reading
Posted by Miami Mike | Jul 22, 2021 @ 04:29 PM | 17,280 Views
Stair curves are used to divide analog input values into discrete steps. For example, the curve below, named "9st" (for "9 step"), will divide an analog source's output value into steps of -100%, -75%, -50%, -25%, 0%, +25%, +50%, +75%, and +100%.



Stair curves are useful during model setup to collect data for use in calibration of curves that are active during control of the model. Uses include calibrating and matching control surface positions, and calibrating elevator-flap compensation curves, which adjust elevator position for level flight at all flap positions. A compensation curve could also correct changes in pitch caused by changes in motor thrust.

The Ultimate Stair Curve

Curve "9st" above is a 16-point curve with 9 steps that can be used to obtain the data for calibrating a 9-point curve, but OpenTX supports curves with up to 17 points, and more points can mean greater precision when a curve is accurately calibrated. Single stair curves of up to 9 steps are possible, but I'll show here how to set up stair curves with any number of steps from 5 to 17, enabling precise pinpointing of the default X values for Custom X curves of up to 17 points. For stair curves of 10 to 17 steps, this is accomplished by combining two curves.

Here are the two curves used to create a 17-step stair curve. The first one is named "17P". The "P" indicates that it's applied to the positive half of stick travel:



And this one is named...Continue Reading
Posted by Miami Mike | Jul 05, 2021 @ 03:42 PM | 9,027 Views
The Problem With Setting Up Failsafe

The problem with setting up failsafe is that it's hard to know whether the settings you choose will put your model into the best configuration for cases where you lose radio control. A good solution should include these features:
  • You should be able to fly your model and make adjustments in flight so that you can monitor how your model reacts to your adjustments. For failsafe you would probably want to circle in a stable glide and gently descend.
  • While making these in-flight adjustments you should be able to quickly recover full control when necessary.
  • When you're finished, the settings should be preserved in your radio's memory so that after you land you can make them your new failsafe settings.
A Safe and Easy Solution

This is a revised version of the SetFail Flight Mode that I first introduced in 2016. It can be added to virtually any OpenTX model setup so long as it has an unused flight mode available, and it'll make it safe and easy to set up and test failsafe. Here's how it works:
  1. Fly your model to a safe high altitude and make sure it's trimmed for a level, unpowered, hands-off glide.
  2. Let go of the sticks and use one of your radio's momentary switches to select SetFail mode. In SetFail mode the trims are used to adjust control surface positions, and those trim settings will only be in effect while you're in SetFail mode. They won't affect regular flight.
  3. Use the elevator trim to adjust the elevator, the aileron trim to adjust
...Continue Reading
Posted by Miami Mike | Jun 14, 2021 @ 11:53 AM | 28,261 Views
The LiPo Fuel Gauge can't be set up in OpenTX version 2.3.10 or 2.3.11 due to an OpenTX bug that omitted the option of using telemetry sensors as input sources, but I'm happy to announce that's now fixed in OpenTX version 2.3.12.


Posted by Miami Mike | Apr 29, 2021 @ 05:36 PM | 8,741 Views
The OpenTX Mixes and Outputs pages should have been done like this:

Mixes



Outputs



If it were done this way then:
  1. Complex "aggregator" mixes that are read by other mixes could be grouped together with their final output mixes anywhere on the Mixes page instead of needing to be separated and located on high channels. It would be easier to construct and follow the program flow.
     
  2. Outputs would not have to come from the Mixes page when no mix functions were involved. They could also come directly from inputs, hardware switches, or logical switches.
     
  3. Mixes would have labels like "MIX1", "MIX2", instead of channel numbers, avoiding confusion with the actual channel numbers assigned on the Outputs page.
     
  4. Alternate mixing schemes could be added to the Mixes page and tested simply by changing the sources on the Outputs page, while keeping the original mixes intact.
     
  5. Rearranging channel assignments would be easy.
...Continue Reading
Posted by Miami Mike | Feb 16, 2021 @ 04:36 PM | 20,324 Views
If you haven't flown for a while and are having trouble remembering what each switch does on your Taranis X9D, X9D+, or X9D+ 2019, here's a telemetry script (that doesn't actually display any telemetry) that will show what each switch does in its current position, once you've edited the script to match your model setup.


The first lines of the script are meant to be configured by the user:
Code:
local max, min = 8.0, 6.0 -- max = fully charged radio voltage, min = lowest safe radio voltage.
local byrow = true -- Remove this to order switches down and across instead of across and down.

local slot = { -- There's room on the screen for a maximum of 16 characters for each switch position label.
	{type = "sw", id = "sa", up = "FM1: Crash", mid = "FM0: Cruise", down = "FM2: Burn"},
	{type = "sw", id = "sb", up = "aileron high", mid = "aileron medium", down = "aileron low"},
	{type = "sw", id = "sc", up = "elevator high", mid = "elevator medium", down = "elevator low"},
	{type = "sw", id = "sd", up = "rudder high", mid = "rudder medium", down = "rudder low"},
	{type = "sw", id = "se", up = "up is unassigned", mid = "md is unassigned", down = "dn is unassigned"},
	{type = "sw", id = "sf", up = &
...Continue Reading
Posted by Miami Mike | Feb 06, 2021 @ 11:52 AM | 17,091 Views
When setting up the LiPo Fuel Gauge with OpenTX Companion 2.3.11, 2.3.12 nightlies, and possibly 2.3.10, a problem has come up where telemetry sensors won't show up as selectable input sources.

When you use Companion to set up a new input for a model that has telemetry sensors listed on its Telemetry page, the sensors normally appear among the list of possible sources, like this:



... and when you choose one of those sensors as the source, the Scale field normally appears, like this:



However, in recent versions of Companion, telemetry sensors don't show up in the list.

The issue was reported on GitHub and a fix is in the works, and will probably be included in the release of OpenTX Companion version 2.3.12.

Also on GitHub, see this post and this post for updates.

...Continue Reading
Posted by Miami Mike | Apr 16, 2020 @ 01:52 PM | 23,007 Views
"You'll be glad when this it what? You didn't finish your sentence! Over."

Brian and Stewie Over (0 min 59 sec)

Posted by Miami Mike | Mar 19, 2020 @ 11:08 AM | 22,166 Views
The COVID-19 pandemic is real. Learn as much as you can about it from reliable sources and accept that you'll have to deal with it, because it's going to be with us for a long time and will get much worse before it starts getting better.
Posted by Miami Mike | Nov 30, 2019 @ 01:02 PM | 20,937 Views
Early in 2019 I won a Taranis Q X7 in a raffle at a club fun-fly. At first I thought I'd have no use for it because it doesn't have enough switches for my sailplane setups, but then I realized that an OpenTX radio can be useful for other applications beside controlling a model.

Presenting the OpenTX ALES Flight Group Launching System




...Continue Reading
Posted by Miami Mike | Oct 09, 2019 @ 08:06 PM | 21,436 Views
My Taranis X9D Control Assignments for Sailplanes
 
  • LS is replaced with a push-button that activates the Kapow function.
    • When the button is pushed the ailerons go up to their extreme limits, followed by the flaps after a 0.1 second delay to prevent flap-aileron collisions due to the wing's polyhedral break.
    • When the button is released the flaps return to their neutral positions regardless of the flap stick position, in order to prevent them from digging into the ground.
    • If the flap stick was down when the button was pushed, normal flap stick function is restored when the stick is returned to its up position.
    • Down elevator can also be part of the Kapow function and can be varied between the extremes of no down elevator (plane simply drops) to full down elevator (plane dives into the ground). TrmT (the throttle trim switch) is used to adjust the elevator position for Kapow while the Kapow button is held in.

  • SE has different functions for winch-launched gliders and electric-powered gliders.
    • When winch-launching a pure gilder,
      • SE↓ selects FM4-Launch mode. When in Launch mode, TrmT adjusts the amount of camber in that flight mode only, and TrmE (the elevator trim switch) adjusts the elevator position in that flight mode only. The flight mode is announced when it is selected.
      • SE↑ selects FM5-Zoom mode. When in Zoom mode, TrmT adjusts the amount of reflex in that flight mode only, and TrmE adjusts the elevator position in that flight mode only. The flight
...Continue Reading
Posted by Miami Mike | Sep 17, 2019 @ 08:45 AM | 22,221 Views
Reports are appearing of a recent Windows 10 update disabling and replacing the driver that enables use of an FrSky radio as a USB flight simulator controller.

Here's the first report I saw, along with a fix:
Quote:
Originally Posted by filago
Hello folks, I frequently use my Taranis (X9D, using OTX 2.1.9) as the controller for PicaSim flight simulator on a Windows 10 PC, and yesterday it suddenly wouldn't work for that.

In case it helps anyone else, here is a quick summary of how I got it working again.

Symptom: After a Windows update, the game controller functions (joysticks, switches) no longer do anything in Windows.

Cause: Windows update installed a new driver "libusb0.sys" in "C:\windows\system32\drivers" which was now being used for the Taranis USB inputs.

Solution: Revert back to the previous Windows driver.
  • Turn Taranis ON, and attach to PC via USB as normal for using flight simulator.
  • Go to Control Panel > Devices and Printers. Right click on item "FrSKY Taranis…" Select Properites > Hardware > USB Input Device > Properties > Change Settings > Driver > Update Driver > "Browse my computer…" > "Let me pick…"
  • Windows had switched mine to "BETTER_USB_HS" (which in this case was NOT better!)
  • I switched it back to "USB Input Device" and all is good again.
It is once again using the driver "hidusb.sys" in the same directory as above, and the game controller functions are working as before.

Cheers,
- John
I found that in my case the procedure to get to those settings was different than what was described by John, so it's not necessarily the same for everybody.

Here are some other reports that I've spotted so far:

Dcchr - https://www.rcgroups.com/forums/show...45&postcount=1

Griggs2121 - https://www.rcgroups.com/forums/show...postcount=9957

David Galati - https://www.rcgroups.com/forums/show...ostcount=33271

Please post below with any questions, comments, corrections, alternate procedures, videos, additional resources, etc.
Posted by Miami Mike | Aug 29, 2019 @ 07:01 PM | 19,892 Views
Helmut Stettmaier in Bavaria, Germany, originally described the Shepard Tone Vario concept in the March 2018 issue of the now-defunct Radio Controlled Soaring Digest. It's the first article in that issue and the title is "An Innovative Method for Acoustically Rendering Climb Data for Model Gliders Using Shepard Tones."

The idea is that when your glider is circling in and out of lift and alternating between rising and falling, all you'll hear from a conventional variometer are high-pitched beeps while you're rising and lower tones while you're descending. The problem is that it won't tell you whether you're achieving a net profit or loss in altitude with each circle. Helmut offered a solution for that, which I call the Shepard Tone Vario.

The Shepard Tone vario isn't technically a variometer because it doesn't directly indicate vertical speed. Instead it produces a tone with a pitch that varies directly with altitude. It's a sort of audible altimeter that produces rising and falling tones instead of numbers. If you're circling in and out of lift you'll hear the tone rise and fall as you go around and your glider rises and falls, and you'll be able to hear whether the highest pitch you reach during a circle is higher, lower, or the same as the highest pitch you reached during the previous circle.

But the magic is in the Shepard tones. Shepard tones are auditory illusions. They can seem to continuously rise or fall yet never go beyond your range of hearing....Continue Reading
Posted by Miami Mike | Aug 14, 2019 @ 01:47 PM | 19,438 Views
Looking back at the 2019 MidSouth ALES and F5J competitions and comparing them to the same contests at the 2019 Soaring NATS, it occurred to me that there was an unexpected benefit in the way it was done at the MidSouth, which was to interleave rounds in the two events and allow participation in one or the other but not both. At the Soaring NATS, ALES was held on Saturday and Sunday while F5J was held on the following Monday and Tuesday, allowing fliers to enter both contests.

At the MidSouth there were 17 in ALES and 15 in F5J, which was almost an even split. As I see it, the serious competitors who prefer strict rules, practice hard and often, and strive to master complex strategies, were separated from the less serious who were there mostly to enjoy soaring and socializing with those who share their hobby. In other words, the MidSouth one-contest-or-the-other structure separated the FAI crowd from the AMA crowd and, I suspect, made the event more appealing and enjoyable for everyone.

I'd like to see this format catch on, at least in major events, and perhaps it could even be extended to Thermal Duration vs. F3J.
Posted by Miami Mike | Jun 29, 2019 @ 01:58 PM | 27,740 Views
I'd like to get a discussion going here about tent camping, or "primitive camping", during the 2019 Soaring NATS. I've never done this before so hopefully I'll hear from people who have and we can all share thoughts and ideas.

Here are some links and images:I was told that there are showers at Site #3 and at the back of the museum. Here's a Google Maps aerial view of the layout as I understand it. Please let me know if it's wrong:



If an access code is required for the showers, what time do you have to arrive to get the code? If the office is closed, can someone else get you in?

What's a good time to arrive so that you'll have plenty of time to set up and relax?

Also, I'd appreciate any advice on what to bring, what to do about meals, etc.

Thanks!
Posted by Miami Mike | Apr 04, 2019 @ 06:15 PM | 24,277 Views
I've updated my gldsim.lua Glider Simulator script with a new look, a new feature, and compatibility with all of the "Taranis" line of FrSky/OpenTX radios running OpenTX version 2.2, while maintaining compatibility with OpenTX version 2.1.



It not only works with the Taranis X9D, X9D+, and X9E...



it also works with the Q X7...

...Continue Reading
Posted by Miami Mike | Mar 10, 2019 @ 03:26 PM | 23,934 Views
This is an extension of a discussion that started somewhere around here. It's a mix script that will convert a horizontal output and a vertical output into a pair of outputs that are confined within the boundary of a circle. Stick input that falls outside of the circle will be clipped.
Code:
--[[ circle.lua - a mix script to confine horizontal and vertical sources within a circle. By Miami Mike, 3/10/2019 ]]
local input = {{"Horz", SOURCE}, {"Vert", SOURCE}}
local output = {"newH", "newV"}
local function run_func(X, Y)
	X = X / 1024
	Y = Y / 1024
	local angle = math.atan2(Y,  X)
 	local R = math.sqrt(X ^ 2 + Y ^ 2)
	if R > 1 then -- clip.
		R = 1
	end
	newH = R * math.cos(angle)
	newV = R * math.sin(angle)
	return 1024 * newH, 1024 * newV
end
return {input=input, output=output, run=run_func}
 
 
If you're working on a way to accomplish this without Lua then this is what you're trying to duplicate. I don't think it can be done but I could be wrong.

When monitored with the mon ch.lua Taranis X9D+ telemetry script included below, circle.lua produces an output like this when the stick is moved around, with the original output displayed on the left and the processed output displayed on the right:



To set it up:
  1. Download circle.txt, rename it to circle.lua, and store it in SCRIPTS/MIXES.
  2. Set up a model memory for testing with the horizontal and vertical stick outputs on channels 1 and 2, respectively. Leave channels 3 and 4 empty
...Continue Reading