Replies

    • I had an issue on my Cmin value initially and figured it was that my telemetry sensor for Cmin had a typo. Make sure on the telem page of your model that Cmin is entered exactly like the telemetry setup page in the wiki. The sensor name in my case was entered as CMin and should have been Cmin (note the case of the 'm' character in the name, as the lua script is case sensitive with sensor names). Also on the telemetry page of your model you should see the voltage reading against Cmin if it's set correctly and sensor data is coming through from your Rx.
    • Open an issue on the Github site, and provide more details such as OpenTX version, and telemetry config on OpenTx

      thanks

  • hi luis

    wonder if you made any progress on your code to work with ac 3.3 and new opentx ?

    I just finished my project using pixhawk and your perfect code and about to preform test flight

    should I proceed or wait  for the new code  to upgrade ?

    I am so grateful  for your time and hard work .

    • Hi

      You should try this

      https://github.com/Clooney82/MavLink_FrSkySPort

      I'm also giving an hand on this project

      Clooney82/MavLink_FrSkySPort
      This MavLink_FrSkySPort repository is discontinued! The development is moved to athertop/MavLink_FrSkySPort. Please do not use this repo, and follow…
  • Is it worth Starting a new thread now this project has progressed on so far from the original.  Means the initial topic can be kept up to date and relevant information can be transferred across ... 

    I'm finding it a bit of a bugger trawling between all the different versions just now.

    • Hopefully I can clear some confusion. There were several different projects, all individuals working on different forks of the original code (not sure who started the code in the first place tbh - maybe Rolf Blomgren, or Luis, or Wolke - sorry, I don't go back in the hobby that far!) and all of them using forks in github as far as I know - but recently all these guys got their heads together to work on a single consolidated codebase. This codebase covers both OpenTx 2.0 (for APM version 3.2) here: https://github.com/Clooney82/MavLink_FrSkySPort/tree/s-c-l-v-rc , and OpenTx v2.1 (which now includes support for both APM 3.2 and 3.3) here: https://github.com/Clooney82/MavLink_FrSkySPort/tree/s-c-l-v-rc-ope...

      The Wiki pages can be found here: https://github.com/Clooney82/MavLink_FrSkySPort/wiki

      I for one (not being a programmer myself) am eternally grateful to these guys for putting in the time to produce some really awesome code which I have become reliant upon in my flying.

      The idea of a new thread sounds like a good idea (tbh as much as I love the level of participation in the diy drones and the awesome community in these threads, I hate the software which provides these threads - its impossible to find anything in here without a lot of trawling). Maybe a new thread would therefore be beneficial - but it's up to the project contributors I guess, as to if/how that will happen.

      Clooney82/MavLink_FrSkySPort
      This MavLink_FrSkySPort repository is discontinued! The development is moved to athertop/MavLink_FrSkySPort. Please do not use this repo, and follow…
      • The code has move on significantly from its original Rolf

        As suggested maybe a new thread for open tx 2.1 

    • Ewan,

      very good Idea!

      I would suggest one thread for opentx 2.1 and one for 2.0.

      I´m also very confused if I´m not reading every day.

  • Cloony - have possibly found another bug, but not sure if its a bug caused by LUA or OpenTX2.1 - If I switch off the 'Minute Call' option on both  (or even just one or the other of the) Timer1/2, then I arm the craft, both Minute call options get turned back on. Then, whilst the craft is armed, if I again switch off the Minute Call options for both timers, then disarm, they get turned back on again! This is a pain as it calls out the flight time every minute, twice!

    Regarding the minute call voicing the values as "ten point zero", "eleven point zero" etc (I mentioned this a few posts back). This was indeed the minute call being voiced out, but it was reading it with the point zero suffix because I had not updated my system voices with the new 2.1 system voices. Now I have the correct wav files for 2.1 system, the call sounds correctly I.e "one minute", "two minutes" etc.

    • The timers are managed by the script. You must change the script to change the behavior, or disable the script handling of the timers entirely.

This reply was deleted.

Activity