l shems's blog View Details
Posted by l shems | Yesterday @ 10:40 AM | 424 Views
As the developers of OpenTX do not always have time to fix BUGS, I opened this thread to inform people about which bugs are in which version.

This in order to prevent hours and hours of breaking your head on why something doesn't work as expected.

feel free to add.
Posted by l shems | Nov 25, 2018 @ 03:39 PM | 1,282 Views

after some research on the mixer scripts I have decided I will use them for flight critical functions. Why? Because they are so powerfull that they clean up complex mixer lines, and make the models readable again. Also, they make space for other stuff to be done in the normal mixers.

There are still some drawbacks, like no being able to change the parameters with LUA, but they can be overcome.

But, hey, they explicitly say you shouldn't use them for critical functions?

Well, they are loaded at model startup. Some voice alerting can be done if it crashes. But they crash nicely, that is to say, if one crashes, that doesn't crash another one running.

So as long as you do stupid simple mix actions, the risk can be taken, in my opinion.

Let's go!
Posted by l shems | Sep 06, 2018 @ 12:11 PM | 18,252 Views
With read and write access in LUA on opentx, it is tempting to use a settings file to persist certain user choices for some scripts. However, though writing a settings table to a file is easy, retrieving it by reading the file content string per string is tricky. Formatting, nested structures, etc.

The solution to this is to write the table to a settings file in a format that is lua interpretable, and will return a table on using the lua loadfile() command.

In this way, you use the lua interpreter to parse the structure from the save table.

The following script, to be saved under the name "saveTable.lua", can be used to dump a table to a file, that is then retrievable using loadfile().

local table,fileName=...

local indent = ""

local function outputTable (tbl)
  if not (type(tbl)=="table") then 
    return tbl
  indent=indent .. "   "
  local res= "\n" .. indent .. "{\n" 
  for k, v in pairs(tbl) do
    if type(k) == "number" then
      k="[" .. k .. "]"
    if type(v) == "table" then
      res=res .. indent .. k .. " = " .. outputTable(v) .. ",\n" 
    elseif type(v) == "function" then
    elseif type(v) == "string" then
      res=res .. indent .. k .. " = '" .. v .. "',\n" 
    elseif type(v) == "boolean" then
      if v then res=res .. indent .. k
...Continue Reading
Posted by l shems | Dec 08, 2017 @ 01:00 PM | 3,818 Views
Make sure you open the post en click on the read more to see the all pages. Otherwise you will see page 8 as last page, and not page 16.

O previously posted some analysis on DLG design in this Blog. After some discussions about smaller than 1.5 meter wing span DLG's possibly outperforming the full size ones on the last WC in the Ukraine, I dug up my old analysis, and worked on it a little to find out if I could derive the theoretical optimum span for a DLG. That is to say: optimum for maximum airtime in still air at a fixed launch speed.

It turns out that actually the current launch speed determines the optimum terminal velocity to design the plane for. So making the plane faster or slower with respect to this terminal velocity would lower the total airtime for this launch speed. A terminal velocity of only 60% of the launch speed would be the optimum design speed for obtaining maximum airtime.

Secondly, the maximum airtime itself can be expressed in the L/D ratio and the launch speed only! So, basically speaking, just optimise L/D and you will optimise maximum airtime (for the optimum design speed that is). The expression is quite simple:

t_(flight,max) ≈ 2 / 3g ∙ (L/D)_optimum ∙ √((L/D)_optimum ) ∙ v_launch

When entering an L/D of 12 to 20, and a v_launch of 40 m/s, the still air time will be between 115 and 245, with an average 180 seconds.

Finally, the question I started with. The expression for terminal velocity that you...Continue Reading
Posted by l shems | Nov 14, 2017 @ 02:45 PM | 4,501 Views
OK, last topic to cover in this series.

We have succesfully made a graph showing some source value with a 'One-time' script, and used some library functions to get it loaded as a widget.

Now I want to use it on the Taranis as well. Let's first just run it and see what happens:

Script error: /Scripts/TELEM/Graph.lua:68: bad argument #6 to 'drawLine' (number expected, got nil)
So what's on line 68:
    lcd.drawLine(0          ,P.y0    ,LCD_W-1    ,P.y0      ,DOTTED ,CURVE_AXIS_COLOR)
Well, something must be provided here, but this global is not known on the Taranis, so it get's a nil value.
Let's add it at the first line of the script, and give it some value we DO know in the Taranis. And at the same time define the other colors:
Well, it's running (either use the standard "go.lua" script we wrote in the other post, or add the 'background()' call to the first line of the 'run' command.)

Name: screenshot_x9d+_17-11-14_20-41-16.png
Views: 55
Size: 1.4 KB

Posted by l shems | Nov 05, 2017 @ 08:09 AM | 3,952 Views
We are going to create a graphing script from scratch, using the widget framework to support Horus as well . Main requirements:
  1. Any source, selectable as option
  2. Fully scalable to support different lcd and widget sizes
  3. First-In-First-Out fixed timeframe drawing buffer
  4. Adjustable timeframe width with 'plus' and 'minus'
  5. Autoscale on height
  6. Reset on 'exit' and restart on 'enter'

Name: screenshot_x12s_17-11-15_19-01-22.png
Views: 175
Size: 35.3 KB

Well, that sounds nice, no?

Let's start .....
Posted by l shems | Oct 29, 2017 @ 05:46 AM | 6,229 Views
OK, new blog entry.
I will share some of my experiences and solutions to problems I encountered using the LUA scripting on openTX. Please feel free to comment. It is meant to become a help to anyone wanting to create, adapt or migrate any LUA script for OpenTX. Tutorial files are added in this first post, and in the last of this thread.

It is assumed that you have read and at least partially understood the OpenTX LUA reference guide. I will assume OpenTX 2.2, OpenTX 2.1 should work as well for all examples, unless stated otherwise, but OpenTX 2.0 is not going to work without extra lines managing the lcd.lock() functionality. Some special article will covering the OpenTX 2.0 specialties, to allow creating interoperability.

Also, if you intend to use or change the scripts, or follow some instructions on this site, I will assume you have ZeroBrane installed. This helps enourmously in developing and testing LUA scripts.

The on-line LUA manual is used as a reference as well. We use the LUA 5.2 version, as OpenTX is build around this.

Be aware that OpenTX is not designed to be LUA friendly! ! !

OpenTX has a LUA API, but that is about it. The people behind OpenTX probably didn't imagine how powerful LUA can be, and that it opens the possibilities for completely different approaches towards using an OpenTX radio. They probably don't even have any interest in the possibilities it opens, and is for them just an add-on provided to complete their framework.
Be...Continue Reading
Posted by l shems | May 07, 2016 @ 04:42 AM | 7,530 Views
We proudy inform you that the JustFly.solutions website is now online.

All development done has finally turned into a product.

Check the links below:

Transform your Taranis into a "normal" transmitter

JustFly.solutions supplies Apps for the Taranis

Full support for ALL FrSky OpenTX radios!!

Name: screenshot_x10_18-02-06_23-14-35.png
Views: 35
Size: 33.6 KB

have fun and
Just Fly!

Posted by l shems | May 05, 2015 @ 12:03 PM | 10,476 Views
I will publish my DLG design analysis here to share it with others and get feedback. So please feel free to do so