Miami Mike's blog archive for March, 2017 - RC Groups
Miami Mike's blog View Details
Archive for March, 2017
Posted by Miami Mike | Mar 26, 2017 @ 12:25 PM | 7,195 Views
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.
  • 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)
...Continue Reading
Posted by Miami Mike | Mar 18, 2017 @ 09:11 AM | 7,600 Views
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.

...Continue Reading
Posted by Miami Mike | Mar 13, 2017 @ 06:40 PM | 7,841 Views
This is a continuation of What happens when an offset is applied to a stick-controlled channel, where I'll describe how to implement optimizing of offsets to prevent clipping and stopping short. It's also an example of deriving a method with algebra and then translating it into OpenTX code. For another example, I recommend Differential without GVARs, posted today by Mike Shellim.

To recap, the principle of what I'm calling Optimized Outputs is to maintain access to both Min and Max limits even when the center position is offset. It's equivalent to what happens with off-center subtrims on the Outputs page if subtrims are set to "normal", but not if they're set to "linear." The desired behavior is represented by the green line in this graph:



The red line represents an offset that's not optimized, so that if full stick travel is used with 100% weight, the result is clipping at one end and stopping short at the other end.

The blue line represents an input without any offset.

My algorithm is to compute the distance the stick is from the end of its travel and reduce the weight of the offset accordingly, so that by the time the stick has reached the end of its travel the offset has been reduced to zero and the output has arrived exactly at its limit, just as it does when no offset is applied.

For any position (P) that a stick can be in within the range of -100% to +100%, the distance from the nearest endpoint (D) equals one minus the...Continue Reading
Posted by Miami Mike | Mar 09, 2017 @ 12:42 PM | 7,567 Views
If you program a switch to operate a motor you'll find that the way switches work seems upside-down. Using SE as an example, SE↑ = -100% and SE↓ = +100%.

The simplest way to correct that is to read the switch with a mix that has a negative weight, like this:
Code:
CH07 (ESC) SE Weight(-100%) [Motor]
But here's the pitfall: Suppose you want the motor to come on slowly but turn off immediately. You would probably expect this to work:
Code:
CH07 (ESC) SE Weight(-100%) Slow(u1.0:d0) [Motor]
This looks like it would take one second to slowly increase the throttle to full power when SE is switched to SE↑, but immediately turn the motor off when SE is switched to SE↓. However, it works exactly the opposite way. The mix above causes the throttle to jump to full power immediately with SE↑ but slowly decrease to off over the course of one second with SE↓.

This is what works:
Code:
CH07 (ESC) SE Weight(-100%) Slow(u0: d1.0) [Motor]
The reason for this is that, contrary to data flow diagrams that were promised to be corrected over two months ago , the Delay and Slow functions are processed at the beginning of a mix, not at the end.
Posted by Miami Mike | Mar 04, 2017 @ 10:36 PM | 7,764 Views
In a glider setup there are many cases where offsets are applied to stick-controlled channels. The flaps and ailerons are offset upward for reflex and downward for camber. The elevator is offset downward for flap compensation. The rudder is offset left or right when aileron-to-rudder mixing is applied. On top of that, when trim is added to any stick it results in an offset. What happens when an offset is applied?



The control surface moves to the desired offset position when its stick is centered, but when the stick is moved away from center and nears the limit of its travel in either direction, bad things can happen.

When the stick is moved in the same direction that the offset is applied, and the stick input plus the offset reaches or exceeds the -100% to +100% limit, no further movement of the stick in that direction will do anything. As long as you've set up your Outputs screen properly it won't result in any damage or stress, but you still have a region of stick travel that's essentially dead. That's Clipping.

When the stick is moved in the direction opposite the direction the offset is applied, and the stick reaches the limit of its travel, the output will stop short of it's limit and a portion of the output range will be unavailable no matter how you move the stick. That's Stopping Short.

The solution is to handle offsets a little differently by giving stick input priority over them. Compute the distance the stick is from the end of its travel and...Continue Reading
Posted by Miami Mike | Mar 03, 2017 @ 10:13 AM | 7,711 Views
Mixes are for mixing, inputs are for selecting.

It may be that you're performing operations on your Mixes page that could be done instead on your Inputs page. The Inputs page isn't just good for selecting rates and exponential for your sticks, you can move virtually any operation that consist solely of selecting, rather than mixing, to the Inputs page. This can be useful for removing clutter from your Mixes page and more evenly distributing your setup across the two pages, which both limit their number of lines to 64.

Here's an example from my glider setup, where I use TrmT to adjust reflex and camber in four different flight modes. It started out on the Mixes page:

Code:
CH10(RfxCam)  TrmT Weight(+50%) Flight mode(Zoom) Offset(50%) [Zoom]
           += TrmT Weight(+25%) Flight mode(Speed) Offset(25%) [Speed]
           += TrmT Weight(+25%) Flight mode(Thermal) Offset(-25%) [Thermal]
           += TrmT Weight(+50%) Flight mode(Launch) Offset(-50%) [Launch]
Channel 10 was being read by the aileron and flap output channels with mix lines similar to this one (this is not exact):

Code:
CH01 (RtAil) CH10 Weight(+100%)
This worked fine but my mix lines were starting to run short and I wanted to clean up the page, so I moved the operation to the Inputs page and added a "catchall" at the end to make sure that the input explicitly contributes a value of zero when not in a flight mode that incorporates reflex or camber:

Code:
[I4]RxCm TrmT Weight(+50%) Flight mode(Zoom) Offset(50%) [Zoom]
         TrmT Weight(+25%) Flight mode(Speed) Offset(25%) [Speed]
         TrmT Weight(+25%) Flight mode(Thermal) Offset(-25%) [Thermal]
         TrmT Weight(+50%) Flight mode(Launch) Offset(-50%) [Launch]
         MAX Weight(0%) [Default]
Now, on the Mixes page I read the input with lines similar to this:

Code:
 [I4]RxCm Weight(+100%)
With this technique I've relocated quite a few of my mix lines to my Inputs page, and now I have plenty of space open for new mixes.