Move configuration code from init to a one-time script

[chsw]

Having multiple telemetry screens adjusting the A1-A4 parameters seem to force a reboot! I think we should have a one-time script adjusting all the A1-A4 parameters. The user should be responsible for running that script, but we could add a warning to the telemetry screens if the parameters isn't set up correctly.

[lvale]

Strange issue. I would report it to the OpenTX guys.

on a telemetry single screen I'm adjusting A2 to A4 (I remember reading something about A1 not being available on the X8R - can that be your issue?)

for chn = 1, 3, 1 do 
local a1t = model.getTelemetryChannel(chn)
if a1t.unit ~= 3 or a1t.range ~=1024 or a1t.offset ~=0 
then
    a1t.unit = 3
    a1t.range = 1024
    a1t.offset = 0
    model.setTelemetryChannel(chn, a1t)
end
end

[chsw]

It seemed to happen when we set the range to different values. Screen 1 opened as expected, but when I pressed page to switch to screen 2, I got some kind of warning symbol, and shortly after it rebooted. But even if it is a little inconvenient for the user, I still think it might be the way to go. I think these screens should only display the values, not change the configurations silently.

If it's possible to ask the user (from the telemetry script) if we should change the configuration, it would be even better. Would that be possible?

[lvale]

I have seven telemetry lua scripts and didn't encounter that problem (yet?). Try to see if only changing from A2 to A4 leaving A1 alone, to see if it happens.

Telemetry scripts : take no inputs, run continuously return no outputs, but add a telemetry screen (but can use 'set' functions)

Model script : run continuously, take inputs and return outputs. Can be used as source of mixes. Cannot use screen

Function script : take no inputs return no outputs, are run according to settings on CF page (ie use to play a collection of sounds etc). Cannot use screen

One time script: run once when loaded from SD browser. Takes over lua interpreter, can use screen etc

[chsw]

To me it sounds like mixer scripts (model scripts) is the thing to use.

I moved the telemetry setup (A2) to a mixer-script called ApmTelem.lua. This needs to be installed as a mixer-script for the model receiving the telemetry. This script also publishes a couple of global functions for reading the telemetry values that are a bit special (Flightmode, arming status, gps lock, number of satellites, hdop...)

If the telemetry screens use these methods to fetch the the data, it would be a lot easier if we want to change the internal workings later on; Sending new parameters, changing which telemetry field contains which parameter and so on. It will also be a lot easier to understand and modify these screens.

I also moved all the code for vocalizing the current flightmode to it's own mixer-script (ApmSounds.lua). Telemetry screens should probably only display data and not play sounds. It would also be a lot easier for the user to replace the sound-script with another sound script, for example a script that compares the user-set mode with the telemetry received mode and sound the appropriate warnings.

[lvale]

Doesn't that approach imply that the user must execute the model scripts from the menu than go to the standard radio menu and finally from there invoke the telemetry script?

Wouldn't a separation between background and run on the telemetry script be enough? I was under the impression that on the current Lua implementation there was no sharing of variables between scripts.

[lvale]

Oh,

take a look at the script I've posted, I believe that the Course to Home in it could be used on your telem1 script.

[chsw]

Unfortunately the user can't just copy the script to the sd-card as with the telemetry screens. But I don't actually like the fact that the name of the scripts (telem1.lua and so on) both activates and determine its position.

But mixer scripts isn't that complicated. You just have to select the mixer script in one of the posts in the second to last model-page (custom scripts). Then it starts working directly.

The current lua model shares everything not marked as local, actually. I don't know if there are any planes to change this.

[chsw]

Yes, I saw that in your script. That is something that can be placed in the ApmTelem.lua, at least until the open-tx guys added it natively.

[lvale]

Today I copied your scripts, and got a different error. When on the menu I was trying to add the scripts on model menu screen 12/13 and the radio gave me an error "Too many scripts".

I only have one model defined and besides the 7 lua scripts under the model_name menu there's nothing else....

today I've managed to get some more work done on the presentation layer :)

Had to give up using a curved roll indicator, and only have a triple line that "rolls".

Some more work to do on the presentation layer, before I go to the Mavlink side to extract the roll, pitch angles.

[chsw]

Ok, some kind of limit in other words. I have two mixer-scripts (telemetry-script and sound-script), and two lua telemetry screens (yours and mine).

Your telemetry screen i starting to pretty good! I copied your images, and your code to show the arrow. I found it hard to see the arrow though, so I had to make it a lot darker. Might be due to the contrast setting on my display.

I setup the logic so the arrow should point straight up if going forward would bring my copter back to home. Unfortunately some orientation must have gotten mixed up. Front/back was correct, but right/left got reversed. Shouldn't be any problem to fix.

Then my bird did a flip and broke an arm. Very strange and kind of annoying, since I don't have all the replacement parts at home...

[lvale]

If you want I can redo the arrows darker or lighter.

Sorry about your bird.... My flights this morning were uneventful - well I got home with no "extra" parts :)

The reasoning on the arrow is pointing from the multicopter to the user like a Manual Return to Home. At first I wanted to superimpose another arrow corresponding to the Heading but with the problems with bmp's in lua it was ugly.

The left right issue is easy to fix :) Either rename the arrows, or look at this line local integHead, fracHead = math.modf(headtoh/45+.5)

[chsw]

If you have time, feel free to make new ones. I'm thinking 20x20 pixels, with no "border", ie using all the bitmap.

I'll suppose i have to go CSI on it and try to figure out what happened. About fixing the direction. I just have to take it outside again, and look at the actual numbers, to figure out which of them is wrong. The image-numbering seems logical to me, so I rather fix the math :)

My thinking with the arrow direction is that if i move my roll/pitch gimbal in the direction of the arrow, my bird would return home. The arrow would mimic what it would look like in my osd when flying fpv.

[lvale]

I tried 20x20 and it looks weird. They don't have a border. I superimposed all the arrows and the resulting image "contains" all orientations, so that they could look smoother even though they are only for every 45 degrees.

I don't use FPV :) although some things were "inspired by"

[lvale]

Hi. I was looking for some things on the OpenTX (frsky_sport.cpp) source and I don't know if these issues should be addressed on FrSkySport.h

define FR_ID_RPM 0x050F // Shouldn't it be 0x500 ?

define FR_ID_FUEL 0x0600

define FR_ID_CAP_USED 0x0600 // Repeated from FR_ID_FUEL ? Never used.

define FR_ID_HEADING 0x0840 // From OpenTX is GPS_COURS

[chsw]

The FR_ID_RPM should be 0x500 as you say. It works anyway, but right should be right :) I removed the FR_ID_CAP_USED. Didn't bother to rename FR_ID_HEADING, since it's actually the compass heading and not the gps-course that is sent (but received as gps-course).

[lvale]

:)

I just mentioned the FR_ID_HEADING for the sake of consistency :) as we have AP_COG - Course over ground from the GPS_RAW_INT

I haven't done nothing with it (yet) but if and when the OpenTX could "open" more telemetry data to be sent down, it would be ready :)

/ Message #24 GPS_RAW_INT uint16_t ap_hdop=0; // GPS HDOP horizontal dilution of position in cm (m_100). If unknown, set to: 65535 // uint16_t ap_vdop=0; // GPS VDOP horizontal dilution of position in cm (m_100). If unknown, set to: 65535 int32_t ap_latitude = 0; // 585522540; int32_t ap_longitude = 0; // 162344467; int32_t ap_gps_altitude = 0; // 1000 = 1m // uint16_t ap_cog = 0; // Course over ground (NOT heading, but direction of movement) in degrees * 100, 0.0..359.99 degrees. If unknown, set to: 65535