APM MavLink to FrSky X8R S.Port converter

Replies

- - Paul Atherton > Luis Vale Gonçalves October 15, 2015 at 12:43pm
    
    Luis, I see the code:
    
    if lastarmed~=apmarmed then
    lastarmed=apmarmed
    if apmarmed==1 then
    model.setTimer(0,{ mode=1, start=0, value= SumFlight, countdownBeep=0, minuteBeep=1, persistent=1 })
    model.setTimer(1,{ mode=1, start=0, value= PersitentSumFlight, countdownBeep=0, minuteBeep=0, persistent=2 })
    playFile("/SOUNDS/en/TELEM/SARM.wav")
    playFile("/SOUNDS/en/TELEM/AVFM"..(FmodeNr-1).."A.wav")
    
    else
    
    SumFlight = model.getTimer(0).value
    model.setTimer(0,{ mode=0, start=0, value= model.getTimer(0).value, countdownBeep=0, minuteBeep=1, persistent=1 })
    model.setTimer(1,{ mode=0, start=0, value= model.getTimer(1).value, countdownBeep=0, minuteBeep=0, persistent=2 })
    
    playFile("/SOUNDS/en/TELEM/SDISAR.wav")
    end
    
    end
    
    This suggests that the minute call option is set to beep only against Timer 1 (minuteBeep=1 in the code set as an attribute against model.setTimer(0{... ), but on the Taranis Plus it gets enabled on both Timer 1 and Timer 2, and it voices the flight time, rather than beeping it, as the script is set to do. So I am I missing something else in the code which is enabling it for both timers and setting it to voice - this is why I am wondering if this script function is broken in OTx 2.1?
    
    I'm just reporting this as surely no one would want the minute call being shouted out twice at the start of each new minute of flight?
    - This reply was deleted.
      - Paul Atherton > Luis Vale Gonçalves October 15, 2015 at 1:46pm
        
        Yes, I can see in the code of telem1 that it is coded to only set minute beep on for T1, but this is not what happens in testing. This is what I have found in my tests:
        
        - If both timers are manually configured to set Minute call to off, then restart the Taranis:
        
        -Upon starting the Taranis, T1 has its minute beep enabled by telem1.lua
        
        - Then I arm the craft
        
        - As well as T1, the T2 minute beep also becomes enabled by the telem1.lua. So now both T1 and T2 have minute beep enabled.
        
        To prove its telem1.lua doing this:
        
        - I manually disable the minute beep for both T1 and T2, then remove telem1 from the first telemetry screen and restart the Taranis
        
        - the Minute beep options remain disabled after the restart
        
        - if I then arm/disarm
        
        - The minute beep stays disabled.
        
        - If I then add telem1.lua back as 1st telemetry screen
        
        - immediately T1 has its minute beep enabled by the lua
        
        - I then arm the craft
        
        - T2 minute beep also becomes enabled.
        
        So, somehow, even though the code does not call for it, Both timers have their minute beep enabled by telem1.lua
        
        This seems to me an issue with OpenTX 2.1.3 and its model.setTimer() function.
        
        If someone else is able to test the above actions, hopefully you will see the same results.
        
        Thanks, Paul
        
        Wolke > Paul Atherton October 16, 2015 at 9:05am
        
        this is an old opentx bug also in 2.0.13-17. minute beep settings are ignored and allays on.
        
        /g
        
        wolke
        
        Paul Atherton > Wolke October 18, 2015 at 8:28am
        
        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 http://pgl.yoyo.org/luai/i/lua_toboolean 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.
        
        Paul Atherton > Wolke October 18, 2015 at 11:38am
        
        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?
        
        Paul Atherton > Wolke October 17, 2015 at 2:29pm
        
        No worries, I realise you guys are busy. I raised an issue with OpenTX here for this issue: https://github.com/opentx/opentx/issues/2978
        
        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…
Paul Atherton October 10, 2015 at 12:15pm

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.
  - Paul Atherton October 10, 2015 at 12:34pm
    
    That's awesome advice. I will go buy a FrSky ID changer :-) Thanks again.
    - This reply was deleted.
      - Paul Atherton October 10, 2015 at 1:39pm
        
        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.
        
        Paul Atherton October 13, 2015 at 1:50pm
        
        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!

of 186

Discussions

APM MavLink to FrSky X8R S.Port converter

Replies

Activity