External module support

[wilco1967]

Hi Jonathan

Great little project..... Just experimenting, and seems to work.
I appreciate this is still very experimental, but I can see this is opening up nice possibilities.

I noticed, it does work with internal module (Radiomaster TX16S), but it doesn't give any data when using an R9M external module (which also provides S-port data).
However, if I set the radio Serial port in the system menu from Lua to Telem Mirror (i.e. bypassing the Lua script), I do get raw S-port data from the BT module. But then telem mirror only seems to work with external modules, not the build-in..... But I guess that is OpenTx related, not your Lua script.
I'm pretty sure, that will get resolved in upcoming releases of openTx (currently running 2.3.9)

Thanks a lot !

[stronnag]

Hi,

Just updated the script for a large performance improvement (lower CPU usage). Neophyte lua programmer!

With the TX16S, if you use the internal module with "Telem Mirror" you get "MPM (MultiProtocol Module) Telemetry" rather than S-Port, which I decided is a protocol too far.

Not idea (yet) why it doesn't work with the external module; the OTX lua documentation is somewhat outdated.

As with #1 we'll see where this goes.

[stronnag]

Could you please record a short OpenTX SDCard log (i.e. in /LOGS/) of a short flight with GPS telemetry. Including a number of different flight modes (e.g. Acro, PH, RTH, 3CRS, WP); don't need them all, just a few. Either post it here or PM me.

That would be a help in deciding on the required telemetry Ids needed.

[wilco1967]

Sent you an email.....

[stronnag]

Thanks. As discussed in the PM:

The OpenTX "companion" application has a function to replay CSV logs; this will stimulate the LUA APIs and my LTM script. If I replay your log (the simulator does not care whether it's the internal or external module), then the correct LTM is generated by the LUA script.

So my conclusion is that the problem is how OpenTX handles the internal / external modules, rather than the ltm.lua script not understanding the telemetry.

[wx4cb]

Just as an FYI, I do know that if you use a cross fire module and use telemetry mirror, the output for that is CRSF on the serial port for telemetry mirror.

[stronnag]

I understand it goes something like this.
If you set the serial UART to "Telemetry" then you get the "native" telemetry from the device:

• For the internal modules "MPM" you get "MPM telemetry" (which is only 'documented' in the MPM source code).
• For the external module you get the native telemetry for the module (CRSF for a CRSF module, S.Port for a FrSky module etc).

As I didn't want to deal with multiple raw telemetry protocols, it was easiest for me to transpose the OpenTX unified view of telemetry into LTM.

[wx4cb]

that makes sense and it totally makes sense to go the way you do. i guess there's no way to read them from the telemetry screen i guess ?

[stronnag]

that makes sense and it totally makes sense to go the way you do. i guess there's no way to read them from the telemetry screen i guess ?

Not sure I get the significance the above?

The internal OpenTX API getValue allows you to access all the sensors available on the telemetry screen, which is what the LTM-lua script does (at least for the values that can be translated into LTM stanzas).

[wx4cb]

@stronnag that's what I thought. my thinking was well if you can read them like you can for the telemetry screen i don't see how whether it's an MPM module or external module would make a difference.

IE, if you use (lets say) RSSI.getvalue it shouldn't matter what module is generating that number/sensor all you care about is the number so you can put it into an LTM structure.

Unless i'm misunderstanding something.

NB i'm not a lua programmer :D

[stronnag]

Your understanding is correct. I'm not a Lua programmer either!

[wx4cb]

I havent yet got it to work with crossfire yet lol. but it seems to me there shouldn't be any difference between internal or external.

Just having a look at the script code it doesn't seem like you're doing anything special.

Did you think at looking at how teckel did the inav script ?

[stronnag]

Did you think at looking at how teckel did the inav script ?

Extensively, Tom Lehrer's "Lobachevsky" is my bible:

Plagiarize!
Let no one else's work evade your eyes
Remember why the good Lord made your eyes
So don't shade your eyes
But plagiarize, plagiarize, plagiarize
Only be sure always to call it please "research"

Don't think there is any significant difference (between the CRSF bit of LTM-Lua and teckel's script).

[wx4cb]

hey... if it good for presidential candidates it's good for us right lol

i don't see though where it's sending it out of the serial port. unless i'm missing something. but that's for another issue.

[wx4cb]

20210115181450.txt
20210115182146.txt

[stronnag]

OK, so you're probably not in Nevada, and there may have more than 0 satellites. It would be useful to also have a OpenTX log matching the LTM.

[wx4cb]

no but I have it sitting outside at the minute capturing some logs and i'll send them in a few

[wx4cb]

try this. itll probably be the latter half of the csv,

Skywalker-2021-01-15.csv.txt

[wx4cb]

20210116163106.txt
Skywalker-2021-01-16.csv.txt

ok here you go... a couple minutes of it sitting on the bench with it armed and in different modes.

[stronnag]

Thanks, I'll have a look in the morning.

[stronnag]

Damn that. let's look now. I replay the LTM; looks like some bloke in suburban Daytona Beach walking around with between 5 - 7 satellites and c. 15.7V on Vbat. A couple of flight mode changes in the mix. Does this mean it's working?

Toto, I've a feeling we're not in Nevada anymore ... or something like that.

[wx4cb]

hahaha yea that would be correct, but im not getting anything out of the serial port like i said

[wx4cb]

and just think i nearly thought about doing an airforce phallic logo LOL

[stronnag]

hahaha yea that would be correct, but im not getting anything out of the serial port like i said

You're assuming I can keep up ....

So the CSV comes of the radio, the LTM is from ?

[wx4cb]

The csv is open tx logs the other is from the script with logging on

[stronnag]

As far as the serial port is concerned, opentx uses the port that is set to LUA. The data is written to the port using serialWrite(). OpenTX gives you zero control over the port. You don't even open the port; opentx just uses the LUA port.

It may be that there is a limitation / bug in OpenTX that this only works when the internal module is active; it worked just fine last time I tested it with the internal module (and I have no external module). Since then I've updated to 2.3.11, so I'll try that tomorrow.

[wx4cb]

Ok. Makes sense, i have uart 1 set to lua and in global functions i have lua/lrm set and its on "ON" so its running all the time while im testing.

I dont see where in the script (unless im blind) you are actually opening the serial port unless thats handled by otx on write.

The other thing i thought of just glancing through the code on my phone.

You are using the d.fm variable to tell whether its crossfire or not. Im assuming that "WAIT" is a value of -1? Or is it a string value (comparing to what you are using in crsf.lua).

[stronnag]

As described in the previous message, there is no API to open the serial port, the port set to "LUA" is used.

Anyway, I just get junk from the internal module as well, so something has changed in openTX. I've asked on the RCG forum if anything's changed. There is nothing pertainent in the release note or git log.

[stronnag]

We have a prime suspect ... https://www.rcgroups.com/forums/showpost.php?p=46337621&postcount=4280

[wx4cb]

So much for release notes lol

[stronnag]

related openTX PR opentx/opentx#8228

[wx4cb]

here's some logs for todays 2 flights. both with inav 2.6 and the latest tbs nightly and the latest alpha of the module firmware

logs.zip

[stronnag]

Thanks for the logs.

The LUA serial issue is fixed in OpenTX nightly 2.3.12N420, tested with the internal module / UART1

[wx4cb]

@stronnag with the release of the "official" 2.3.12 is there any way to find out if the fix for this got merged (i assume so if it was in the nightlies) but there was no mention of it in the release notes that i could find. just an RSSI thing and a new memory "command"

[stronnag]

@stronnag with the release of the "official" 2.3.12 is there any way to find out if the fix for this got merged (i assume so if it was in the nightlies) but there was no mention of it in the release notes that i could find. just an RSSI thing and a new memory "command"

I haven't tested the released 2.3.12, but as it was merged into the 2.3 branch for N420, I would be surprised if it somehow got lost again. Looking at the source code, the fix is there. I can test it again over the weekend. Don't expect the RN to have every small tweak.

[wx4cb]

ok great... not planning on upgrading the day before I go flying to say the least :D but was planning on doing it next week. if only for the supposed touch support if it's in there :D

[stronnag]

Just tested LUA-ltm over AUX1 on OpenTX 2.3.12 (internal module, as I have no externals).
Working perfectly with the last commit here.

[avsaase]

Has anyone got this working with an external module?

I'm working on an ESP32-based antenna tracker but am running into the problem that the telemetry stream is too much data for the BT connection (I think, I get a lot of [E][BluetoothSerial.cpp:373] esp_spp_cb(): RX Full! Discarding 12 bytes warnings). This Lua script seems like a perfect solution but I can't get it to work.

I have placed the Lua files in the correct folders and have set up a special function on a switch. What do I need to set Serial port (TTL) in the OpenTX system menu to? I only get data over bluetooth with "Telem Mirror" and the data rate doesn't seem to be affected by the special function switch. With any of the other settings I get nothing.

I am using a TX16S on 2.3.15N562 with an external ExpressLRS module. ExpressLRS handles the telemetry a bit differently from Crossfire but once it gets to OpenTX it should be pretty similar.

[stronnag]

You need to set the port to LUA (not telemetry, that will be full speed module format telemetry). I upgraded my TX to Edge, so I can't tell you exactly what the option is on OTX.
And the baud rate needs to be set to match the BT module.
I don't have a external module to test.
It is also the case that having a version of OTX with both working CRSF and serial ports have been a bit hit and miss, but should have been fixed from 2.3.14.

[wx4cb]

in open tx go into the system menu and then croll to thebottom of the list and set the serial port to "LUA" and then page across to global special functions and put a special function to "ON" and set itt o lua and the script and then turn on the little tick mark.

[wx4cb]

i must admit, i need to update my OTX to the latest one, but also, if you're using crossfire, make sure you are on the latest 6.10 release and 2.04 for the wifi else it might not work as there as a bug with 6.09 and below (in the 6.x range) where they had telemetry issues.

I ended up having to use telemetry mirror and CRSF to the mfd tracker bt i havent updated to the latest one yet as im in the UK

[avsaase]

Turns out I did make a mistake, I had a 20ms delay in my program. After removing that it seems I can receive the normal CRSF telemetry mirror data.

With the serial port set to 'LUA and the Lua script on a special function with a switch I don't get any data. I'll try a global function later today.

[wx4cb]

not sure... might need to be armed first maybe? i beleive OTTOMH you can turn on a flag for script logging but i could be wrong.

[avsaase]

Not sure what is the problem with the LTM-lua script but the following Lua works with an external ExpressLRS module in my TX16S:

local function init()
    setSerialBaudrate(115200)
end

local function run()
    local gps = getValue('GPS')
    local lat = gps.lat
    local lon = gps.lon

    serialWrite('Latitude: '..lat..'\n')
    serialWrite('Longitude: '..lon..'\n')
    serialWrite('Altitude: '..getValue('Alt')..'\n')
    serialWrite('Ground speed: '..getValue('GSPd')..'\n')
    serialWrite('Heading: '..getValue('Hdg')..'\n')
end

return {init=init, run=run}

(I know this is hugely inefficient)