• this is an old opentx bug also in 2.0.13-17. minute beep settings are ignored and allays on.



              • Wolke/Clooney,

                I got a reply from OpenTX. It appears that its not a bug at all - its just that 0/1 as used in the lua script is the incorrect value notation for minuteBeep. The correct values are true/false. 1 or 0 are both treated as true, hence both Minute Call options being set by the script. This is their exact response:

                The parameter minuteBeep is boolean type so the false and nil values are treated as FALSE, any other value (including 0) is treated as TRUE. That is the way Lua works, we use function.

                The same is true for parameter carryTrim in funciton model.insertMix(). It also uses boolean type.

                So just write minuteBeep=false.


                So, the script needs amending using minuteBeep=true/false instead of 0/1 (which are both true)

                Lua: Functions and Types: lua_toboolean
                • This reply was deleted.
                  • I tweaked the copy I have on my taranis and it does indeed resolve the minuteBeep issue. Clooney, I was wondering where the variable PersitentSumFlight gets its value from in telem1.lua. It only seems to be mentioned once in line 448 where that timer2 gets configured. The line (with my 'false' mod) is:

                    model.setTimer(1,{ mode=1, start=0, value= PersitentSumFlight, countdownBeep=0, minuteBeep=false, persistent=2 })

                    Is this some sort of global variable you're referencing or is something missing to assign a value to this variable elsewhere?

              • No worries, I realise you guys are busy. I raised an issue with OpenTX here for this issue:

                LUA issue - model.setTimer() minutebeep always enables regardless of 0 or 1 · Issue #2978 · opentx/…
                The model.setTimer() function (in 2.1 for Taranis Plus), regardless of the minutebeep value assigned (0 or 1), will always enable the minuteBeep opti…
  • Clooney, Need your advice! I just updated my hexa to 3.3 and my OpenTX to 2.1.3, so have been setting up the Teensy, OpenTX telemetry, LUA scripts most of the day today. On My setup I have 2 x FrSky FLVSS LiPo monitors employed as I run 2 LiPos on my hexa (in parallel). My first FLVSS is running the stock ID of 2 and the second FLVSS is using ID 8., now if I disconnect the teensy from my S.Port chain, then the 2 sensors report quite happily into my Taranis Plus, but if I connect the Teensy running the latest code, as soon as it boots, the output from the second FLVSS (on ID 8) stops (the telem screen shows the value in square brackets to suggest there is no update). I'm wondering what I need to comment out in the Teensy code to allow this second LiPo sensor to work. Can you please advise? Incidentally, this is my telemetry screen:


    Bat1 and Bat2 are the FLVSS voltages

    CMn1 and CMn2 are the minimum cell values from the 2 FLVSS, and CMin is the minimum of CMn1 and CMn2 which is what I believe your LUA needs to display the C-Min value.

    Any help would be gratefully received. Cheers, Paul

    edit - I should add that I checked the teensy code and by default it appears to allow the use of FrSky FLVSS - please correct me if my assertion here is incorrect and I need to change something to allow the sensor on ID 8 to work. Also note that I am not a newby with the scripts as have been using Wolke's old script for the last 6 months on APM3.2.1/OpenTx2.0.17 successfully (but just with one FLVSS).

    • This reply was deleted.
      • That's awesome advice. I will go buy a FrSky ID changer :-) Thanks again.

        • This reply was deleted.
          • Clooney - It worked a treat! Thanks again. I made one typo in my Telem setup also - I entered 'CMin' instead of 'Cmin' not realising it is case sensitive in LUA! Fixed and working now. Is the script fully APM3.3 compliant now or is there still some message definition work needed to reach that goal?

            On a completely different subject - you seeing any response from SWR in telem on OpenTX 2.1.3 ?

            • This reply was deleted.
              • I am now seeing a response on SWR also - Mine sits at zero mostly and occasionally goes to 1. I still have an issue with my Taranis Plus Tx board. Waiting for a new one to arrive from BoltRC. My Tx output appears to be quite low powered - max coverage is <200m for me with this faulty board. Hopefully the new board will fix that!

            • This reply was deleted.
              • Cloony,

                It was dark tonight when I got home so not able to test yet outside, but I did upgrade my Teensy code to the 'Next' code and also copy over the voice files to my Taranis. I have done some tests with the flight systems powered over the USB (so no flight batteries) and the telemetry does appear to be working OK. As I don't generally get any pre-arm messages on this hexa, I wasn't able to hear any warnings relating to pre-arm issues, but I do randomly hear other voice messages appear - numeric messages like, "Thirteen point zero", "Ten point zero" - I have no idea what they relate to! Does this info help any? Any thoughts on the numeric messages?

                Cheers, Paul

                • This reply was deleted.
                  • Issue #43 opened. Thanks Clooney.

This reply was deleted.


Hiroki Tanaka liked Hiroki Tanaka's profile
Oct 13
Derrick Davies liked lisa TDrones's profile
Sep 23