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
It not only works with the Taranis X9D, X9D+, and X9E...
it also works with the Q X7...
...Continue Reading
Comments (5)
Add Comment
...
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.
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:
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}
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:
- Download circle.txt, rename it to circle.lua, and store it in SCRIPTS/MIXES.
- 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
I like the Castle Creations Phoenix Edge ESC's auxiliary input with the white wire. For my ALES sailplanes I programmed mine in the RX ARM LOCK mode so that Channel 8 on my receiver operates the motor safety lockout. It plays a little tune through the motor when I arm it and a different tune when I disarm it. 
I also have ALES CAM limiters installed, which I leave active at all times, even for practicing and sport flying. Since the recommended CAM Limiter hookup routes the entire plane's electrical power through the limiter, its cables, and connectors, which is an arrangement that I don't like, I instead swapped the orange and white wires on my ESC so that the orange throttle signal wire is alone on one plug and the white aux wire, red (+) wire, and brown (-) wire are together on the other plug.
Change this:
To this:
...Continue Reading
I also have ALES CAM limiters installed, which I leave active at all times, even for practicing and sport flying. Since the recommended CAM Limiter hookup routes the entire plane's electrical power through the limiter, its cables, and connectors, which is an arrangement that I don't like, I instead swapped the orange and white wires on my ESC so that the orange throttle signal wire is alone on one plug and the white aux wire, red (+) wire, and brown (-) wire are together on the other plug.
Change this:
To this:
...Continue Reading
There may be some interest springing up in Germany in the Shepard Tone Vario setup that I developed for OpenTX earlier this year. See my Shepard Tone Vario for OpenTX and Shepard Tone Vario testers wanted posts from February and March of 2018.
Here's the complete package with setup instructions.
Demo video :
Edit: According to this post, the RC Soaring Digest has released its final issue.
My Shepard Tone Vario setup was inspired by an article by Helmut Stettmaier in the March 2018 issue of the RC Soaring Digest, titled An Innovative Method for Acoustically Rendering Climb Data for Model Gliders Using Shepard Tones, so if you're interested in reading it download it now, just in case the site goes offline.
Here's the complete package with setup instructions.
Demo video :
| Shepard Tone Vario Demo (5 min 54 sec) |
Edit: According to this post, the RC Soaring Digest has released its final issue.
My Shepard Tone Vario setup was inspired by an article by Helmut Stettmaier in the March 2018 issue of the RC Soaring Digest, titled An Innovative Method for Acoustically Rendering Climb Data for Model Gliders Using Shepard Tones, so if you're interested in reading it download it now, just in case the site goes offline.
Please post any additions or corrections below.
- "FAA reauthorization act" in forum Model Aircraft & Drone Advocacy (Thread closed.)
- "FAA Reauthorization Act of 2018, HR 302" in forum Model Aircraft & Drone Advocacy (Thread closed.)
- "Take Action Now! Tell Congress to Vote “NO” on FAA Reauthorization" in forum Electric Plane Talk
- "FAA Authorization for Recreational Regulations Update" in forum Electric Plane Talk
- "FAA reauthorization bill?" in forum Sailplane Talk
- "400’ limit. Real this time." in forum Cross Country Soaring
- "400’ limit. Real this time." in forum Scale Sailplanes
- "FAA Re-Authorization and DLGs/F3K" in forum Hand Launch
- "Please click and vote NO" in forum Hand Launch
- "400’ limit. Real this time." in forum Multi Task F3X
- "400’ limit. Real this time." in forum Sailplane Events
- "400’ limit. Real this time." in forum Scale Sailplanes
- "400’ limit. Real this time." in forum Thermal
- "Attn: Thermal Forum - Could HR 302 & the FAA bring an end to R/C Soaring in the USA?" in forum Thermal
Links
- A link can be a web page URL by itself, such as http://www.rcgroups.com/forums/member.php?u=15789. In that case you can simply enter the URL in your post and tags will be automatically added when previewing or posting (unless you've already added them yourself). They'll look like this:
[url]http://www.rcgroups.com/forums/member.php?u=15789[/url]
It's customary to precede this type of link with a description of where the link will take you.
- A link can contain text that appears in place of the URL, like this:
Miami Mike's Blog
The tags for a link with text look like this:
[url=http://www.rcgroups.com/forums/member.php?u=15789]Miami Mike's Blog[/url]
- It's possible to use an image in place of text in a link:
← This is a clickable link.
The tags for a link that includes an image look like this:
[url=http://www.rcgroups.com/forums/member.php?u=15789][img]https://static.rcgroups.net/forums/attachments/1/5/7/8/9/a9525461-136-link%20image.png[/img][/url]
- Beware of adding a link to your post that includes a page number because posts per page is a configurable option for RCGroups users, so a link with a page number won't necessarily take others to the same place it takes you. This is a problem that Google has when returning a link to an RCGroups post. If you've increased your Number of Posts to Show Per Page in Thread Display Options on your Edit Options page then a link from Google will
Here's a Lua script and custom set of WAV files for OpenTX version 2.1 or 2.2 to speak the time of day in a natural-sounding format, such as "twelve o'clock PM" or "nine oh two AM."
The WAV files are in a folder in the root directory named SAYTIME, and saytim.lua is stored in /SCRIPTS/FUNCTIONS/.
On your Special Functions page, set saytim to be played with the Play Script function whenever a hardware or logical switch of your choice is true. For example, this will play the time of day when SA is switched to position SA↑:
Beginning with OpenTX version 2.2.1, saytim.lua can alternately be called with a Global Function.
The script and set of WAV files were revised on July 3, 2018 to allow for times from 12:00 AM to 12:59 AM. The revised script looks like this:
Instructions are included in a file named readme.txt. Please post any problems or special requests below.
The WAV files are in a folder in the root directory named SAYTIME, and saytim.lua is stored in /SCRIPTS/FUNCTIONS/.
On your Special Functions page, set saytim to be played with the Play Script function whenever a hardware or logical switch of your choice is true. For example, this will play the time of day when SA is switched to position SA↑:
Beginning with OpenTX version 2.2.1, saytim.lua can alternately be called with a Global Function.
The script and set of WAV files were revised on July 3, 2018 to allow for times from 12:00 AM to 12:59 AM. The revised script looks like this:
Code:
-- Function script saytim.lua by Miami Mike, July 3rd, 2018
local path, lastcall = "/SAYTIME/", 0
local function run_func()
local newcall = false
local time = getTime()
if time > lastcall then
newcall = true
end
lastcall = time + 10
if newcall then
local datetime = getDateTime()
local hour, minute, ampm = datetime.hour, datetime.min, "am"
if hour >= 12 then
ampm = "pm"
if hour >= 13 then
hour = hour - 12
end
end
playFile(path .. "timeis.wav")
playFile(path .. hour .. "h.wav")
playFile(path .. minute .. ".wav")
playFile(path .. ampm .. ".wav")
end
end
return {run=run_func}
In November of 2016 I described my SetFail flight mode, which allows you to experimentally determine your best Custom failsafe settings for each of your models, but it's a bit involved and some might consider it adequate to just set the failsafe option to Custom and set all your controls to neutral, except the throttle, which should be fully closed.
I just want to point out that if you decide to do it that way then you shouldn't assume that this will work, because it won't:
It's not as simple as that.
The values you enter on your Setup page for Custom failsafe are the actual values that will be sent to your servos and do not take into account any Subtrim, Min, or Max settings on your Outputs page, or any mixing, or flight mode-specific trim settings, etc. that occur when your sticks are in their neutral positions. To know what those Custom failsafe values really need to be for neutral control surface positions, or whatever positions you want them to take when control is lost, you have to read them from your Channels Monitor.
On a Taranis X9D+, before you begin setting up your model, it looks like this:
But after you've set up the model, with the sticks neutral and the throttle off, it'll probably look more like in this random example:
...Continue Reading
I just want to point out that if you decide to do it that way then you shouldn't assume that this will work, because it won't:
It's not as simple as that.
The values you enter on your Setup page for Custom failsafe are the actual values that will be sent to your servos and do not take into account any Subtrim, Min, or Max settings on your Outputs page, or any mixing, or flight mode-specific trim settings, etc. that occur when your sticks are in their neutral positions. To know what those Custom failsafe values really need to be for neutral control surface positions, or whatever positions you want them to take when control is lost, you have to read them from your Channels Monitor.
On a Taranis X9D+, before you begin setting up your model, it looks like this:
But after you've set up the model, with the sticks neutral and the throttle off, it'll probably look more like in this random example:
...Continue Reading
Because I have several full-house sailplanes that use exactly the same basic setup, I've recently adopted a policy of leaving everything on the Outputs page at default values except for the six curves for the six servo channels. My flaps and ailerons are all controlled by 9-point curves with the flaps adjusted to be
To do these settings I use digital helicopter pitch gauges...
... and a 16-point "stair" curve that's part of my Calibration mode.
(Actually, I use different flap/crow elevator compensation curves for each model as well, but aside from those differences the setups are the same.)
The "stair" curve is an expansion of an idea inspired by Mike Shellim.
As an example, here are my two Shadow 2 electric-powered gliders:
...Continue Reading
- at their least common physical upper limit at +100%,
- 7.5° up at +75%,
- even with the trailing edge at +50%,
- 7.5° down at +25%,
- and from there to their least common physical lower limit in five steps of equal degrees, ending at -100%.
- 30° up at +100%,
- 22.5° up at +75%,
- 15° up at +50%,
- 7.5° up at +25%,
- even with the trailing edge at +0%,
- 7.5° down at -25%,
- 15° down at -50%,
- 22.5° down at -75%,
- 30° down at -100%.
To do these settings I use digital helicopter pitch gauges...
... and a 16-point "stair" curve that's part of my Calibration mode.
(Actually, I use different flap/crow elevator compensation curves for each model as well, but aside from those differences the setups are the same.)
The "stair" curve is an expansion of an idea inspired by Mike Shellim.
As an example, here are my two Shadow 2 electric-powered gliders:
...Continue Reading
Here's a simple improvement to the volume control setup I described in my previous blog post, which is a way to put your volume control on one of your potentiometers and confine its range to within your chosen upper and lower limits. The need to do arithmetic is now gone, plus there's a way to set the detent center position of the control to the "perfect" volume setting that's not too loud and not too soft.
If you haven't already guessed, the solution is to use a 3-point curve.
The first step is to create the curve. In this example I'm using Curve 32 and initially setting the three points to -100%, 0%, +100%:
The Special Function used is the same as in the previous setup:
But you can use a mix instead of an input if you like:
...Continue Reading
If you haven't already guessed, the solution is to use a 3-point curve.
The first step is to create the curve. In this example I'm using Curve 32 and initially setting the three points to -100%, 0%, +100%:
The Special Function used is the same as in the previous setup:
But you can use a mix instead of an input if you like:
...Continue Reading
If you're controlling your Taranis volume with one of your potentiometers ("sliders") you might be annoyed that the volume can be accidentally adjusted so high that you get bad distortion, or so low that you can't hear it and you miss important alarms and messages. If the maximum is louder than you want, or the minimum is lower than you want, or both, here's how to confine your volume range within upper and lower limits of your choice.
In this example I'll use RS as the volume control, but it could also be LS, S1, or S2.
You probably have your volume set up like this on your Special Functions page:
That's pretty simple, but to restrict the range you'll need to make it slightly more complicated.
Create an input like this:
It'll look like this on your Inputs page:
...Continue Reading
In this example I'll use RS as the volume control, but it could also be LS, S1, or S2.
You probably have your volume set up like this on your Special Functions page:
That's pretty simple, but to restrict the range you'll need to make it slightly more complicated.
Create an input like this:
It'll look like this on your Inputs page:
...Continue Reading
Sticky:
Taranis: LiPo Fuel Gauge!
A "fuel gauge" for your telemetry screen to display your LiPo pack's charge state as a percentage of full charge.
For OpenTX Versions 2.1 and 2.2
Update, 11/27/2017: Permission was requested by and granted to Martin Phillips ("thebriars") to include this in the Version 2.2 update of his OpenTX Documentation.
Introduction
Here's a "fuel gauge" setup for your Taranis to display your flight battery's state of charge as a percentage, beginning at 100% for a fully-charged pack and decreasing as you consume battery power. It requires a current sensor, such as a FrSky SP-40A - Smart Port 40 Amp Sensor or FrSky SP-150A - Smart Port 150 Amp Sensor.
You'll be able to add alarms and voice announcements that trigger at specific charge states, or at regular time intervals, or each time the charge state decreases by a certain amount so that you'll get announcements at, for example, 100%, 90%, 80%, etc. You'll also be able to bring up announcements whenever you like by flipping a switch.
The battery state will be retained between flights even if the radio is turned off, so a switch is provided to reset the charge state to 100% when the battery is replaced or recharged.
This setup is known to be compatible with OpenTX Versions 2.1 and 2.2.
If you have questions, suggestions, requests, or problems, please post in the comment section below.
Begin by configuring the sensor on the Telemetry page.
The Curr line should be created automatically with...Continue Reading
For OpenTX Versions 2.1 and 2.2
Update, 11/27/2017: Permission was requested by and granted to Martin Phillips ("thebriars") to include this in the Version 2.2 update of his OpenTX Documentation.
Introduction
Here's a "fuel gauge" setup for your Taranis to display your flight battery's state of charge as a percentage, beginning at 100% for a fully-charged pack and decreasing as you consume battery power. It requires a current sensor, such as a FrSky SP-40A - Smart Port 40 Amp Sensor or FrSky SP-150A - Smart Port 150 Amp Sensor.
You'll be able to add alarms and voice announcements that trigger at specific charge states, or at regular time intervals, or each time the charge state decreases by a certain amount so that you'll get announcements at, for example, 100%, 90%, 80%, etc. You'll also be able to bring up announcements whenever you like by flipping a switch.
The battery state will be retained between flights even if the radio is turned off, so a switch is provided to reset the charge state to 100% when the battery is replaced or recharged.
This setup is known to be compatible with OpenTX Versions 2.1 and 2.2.
If you have questions, suggestions, requests, or problems, please post in the comment section below.
Begin by configuring the sensor on the Telemetry page.
The Curr line should be created automatically with...Continue Reading
Taranis: A Volume Control That Doesn't Take Up Any Pots or Switches
for OpenTX version 2.1.9
Like my other scripts so far, volume.lua is implemented like a telemetry script but doesn't actually provide telemetry. (But in this case it could with modification.) What it does is provide a way to adjust volume and store the setting without using any of the switches, knobs, or sliders that are otherwise used to control your model. Instead, the buttons next to the display are used.
The script needs one global variable ("GV"), which you can name "Volume." It can be any one of the nine global variables in each of your model memories and can even be a different GV for each model, although that would require multiple copies of volume.lua with minor changes to each copy and different filenames. I'm using GV1 in my radio and in the examples that follow.
There are installation instructions embedded in the script but I'll post more detailed instructions here.
for OpenTX version 2.1.9
Like my other scripts so far, volume.lua is implemented like a telemetry script but doesn't actually provide telemetry. (But in this case it could with modification.) What it does is provide a way to adjust volume and store the setting without using any of the switches, knobs, or sliders that are otherwise used to control your model. Instead, the buttons next to the display are used.
The script needs one global variable ("GV"), which you can name "Volume." It can be any one of the nine global variables in each of your model memories and can even be a different GV for each model, although that would require multiple copies of volume.lua with minor changes to each copy and different filenames. I'm using GV1 in my radio and in the examples that follow.
There are installation instructions embedded in the script but I'll post more detailed instructions here.
- Download volume.txt from the link below, edit it as needed, rename it to volume.lua, and store it in SCRIPTS/TELEMETRY on your SD card. A follow-up post will display the script so that you can copy and paste it into a text editor if you wish.
- The GV that you use for volume control needs to be set to "Flight mode 0 value" in flight modes FM1 through FM8.
- On the Inputs page, create an input to read the volume global variable. In this example I use [I7]:
Code:[I7]Vol MAX Weight(GV1) [Volume]
gimbtest.lua is designed to run as a telemetry screen, although it doesn't actually provide telemetry. It checks each of the four stick functions, throttle, aileron, elevator, and rudder, for the 2049 possible stick values recognized by OpenTX, which range from -1024 to +1024. When each stick value is detected the corresponding screen pixel is set, and slow, careful movement of the sticks will eventually produce a display of which positions are detectable and which are not.
Pressing MINUS (-) will clear the screen and restart the test, and long-pressing EXIT will exit the screen.
When gimbtest.lua is run in Companion simulator the result is not impressive because the values obtained from mouse movement by Companion are very coarse compared to the values obtained from the Taranis gimbals:
The vertical lines in the display each consist of four line segments, one for Thr, one for Ail, one for Ele, and one for Rud. The left segments indicates that the value of -1024 was reached, the center segments indicates that zero was reached, and the right segments indicates that +1024 was reached. All other positions are indicated by individual pixels, with the negative values represented on the left side of center and the positive values represented on the right side.
You can see in the image above that when the script was run on Companion simulator the center segment for Thr did not appear, indicating that a zero reading from the throttle stick could not be obtained.
The number...Continue Reading
Pressing MINUS (-) will clear the screen and restart the test, and long-pressing EXIT will exit the screen.
When gimbtest.lua is run in Companion simulator the result is not impressive because the values obtained from mouse movement by Companion are very coarse compared to the values obtained from the Taranis gimbals:
The vertical lines in the display each consist of four line segments, one for Thr, one for Ail, one for Ele, and one for Rud. The left segments indicates that the value of -1024 was reached, the center segments indicates that zero was reached, and the right segments indicates that +1024 was reached. All other positions are indicated by individual pixels, with the negative values represented on the left side of center and the positive values represented on the right side.
You can see in the image above that when the script was run on Companion simulator the center segment for Thr did not appear, indicating that a zero reading from the throttle stick could not be obtained.
The number...Continue Reading
