Replies

  • Back again:

    with exchanging the confrun.lib and the mainrun.lib it is still not possible to enter values >250Wh.

    Maybe there is something other locking values >250?

  • Paul,

    I will try the 500Wh libs the next days, thanks!

    Sorry that I can´t provide you any support. I am only a user.

    I use this solution mainly in a large hexacopter (Tarot T960) with 2 x 8A 6S in parallel (80% about 290 Wh).

    At the moment on AC 3.44.

    On APM Plane I mostly use the 433 MHz telemetry with Android or Windows PC.

    For me personally, I use the solution manly to get instant feedback, if there are problems with the rig and the battery state.

    Crashes, especially with the camera gimbal are not cheap ;-(

    In general, this solution is still the best for my requirements, allthough with AC 3.3 and AC 3.4 with EKF there are some critical audio outputs missing.

    Maybe audio warnigs regarding gps quality would be most usefull in the first step.

    Many thanks for your ongoing dev in this solution, and sorry for my poor english ;-)

    CheersGregor

  • Gregor,

    This is your lucky day! I have amended the code to allow a Wh value of up to 500 to be selected - the change is just on the -dev branch for now, but feel free to replace your confrun.lib file with the one from here: https://github.com/athertop/MavLink_FrSkySPort/tree/Mav_Sport2.1-2....

    That must be a monster of a LiPo you are using there! I am guessing 6s 10000mAh ?

    As for your 2nd request - this could take some fixing, and I would likely need to get some help with it.

    As for your 3rd request, I am working on that fix now (significantly easier to fix that 2, but still quite a lot of donkey work to do it).

    Can I please ask which AP firmware you are running? Plane?/Copter? and version please?

    Gregmaan said:

    Hi Paul,

    I tested the version from your master repo today:

    Looks very good no memory issues and both scripts do their job very fine.

    Very good job Sir!

    There are 3 additional things which I would like to have in future versions:

    • Wh values >250 (290 is my calculated value)
    • MSG Screen corrupted messages (It would be fine if you will find a fix for this)
    • Audio output of critical AP messages (EKF, Vibes, Compass e.g.) 

    Many thanks for your work

    Cheers

    Gregor

    athertop/MavLink_FrSkySPort
    APM MavLink to FrSky S.Port converter. Contribute to athertop/MavLink_FrSkySPort development by creating an account on GitHub.
  • Hi Paul,

    I tested the version from your master repo today:

    Looks very good no memory issues and both scripts do their job very fine.

    Very good job Sir!

    There are 3 additional things which I would like to have in future versions:

    • Wh values >250 (290 is my calculated value)
    • MSG Screen corrupted messages (It would be fine if you will find a fix for this)
    • Audio output of critical AP messages (EKF, Vibes, Compass e.g.) 

    Many thanks for your work

    Cheers

    Gregor


    Paul Atherton said:


    @snowest, @Gregmaan - the memory issues are now resolved in the current RC1 version if you care to give it a go. You can install both telemetry screens (main.lua and txtmsg.lua) now alongside both celinf.lua and servce.lua mixer scripts without any memory issues.

    Cheers, Paul
    snowest said:

    If I deactivate servce.lua then it is working fine :-) otherwise I get also a memory error

    Thanks

    Gregmaan said:

    Paul,

    Many thanks for this tip. Without the celinf.lua it works again!

    Cheers Gregor

  • Cheers Fnoop! My thoughts about the text message reorganisation - would you be willing to chat about it to share some design thoughts possibly? I could put together a Telegram group if you are willing. Maybe see if I can get Luis and maybe Jochen on it also. Please let me know. Cheers


    Fnoop said:

    Great job Paul, thanks for the ongoing effort!  Haven't fired up my old pixhawk+teensy for a while so i'll blow off the cobwebs when I get a minute and try this :)

  • Great job Paul, thanks for the ongoing effort!  Haven't fired up my old pixhawk+teensy for a while so i'll blow off the cobwebs when I get a minute and try this :)

  • Quick note guys to advise that from v2 of the code I have switched to using my own repo here:

    http://github.com/athertop/MavLink_FrSkySPort

    There is now a release branch and a separate dev branch.

    I have now also ported in the wiki to my repo and have amended this specific to the v2 code. Wiki is here:

    http://github.com/athertop/MavLink_FrSkySPort/wiki

    As for future improvements - my initial efforts will be spent improving the voice message system. Given that the teensy is now often used ground side (in ULRS implementations which makes Mavlink data available at the Tx), and in this configuration a user could wish to fly many different models using this single teensy - some users may have a model with Pixhawk running AP3.3 or newer, with a second model still using an APM running AP3.2 - the current messaging system doesn't provide for this mix of versions, as it requires a definition to be changed in the teensy code to choose between 3.2 and 3.3, and in alignment with this choice the version specific set of voice files also need to be installed on the Taranis SD card (as they are different between 3.2 and 3.3). So my plan is to consolidate the messages to make one teensy fit all.

    I would like to encourage some conversation on this suggestion as to good design decisions to make this change happen so will hopefully get that chat going in future posts to hear ideas/thoughts. In the mean time enjoy the 2.0 release and once I get enough feedback I will take it out of its current rc1 status. Cheers, Paul


  • @snowest, @Gregmaan - the memory issues are now resolved in the current RC1 version if you care to give it a go. You can install both telemetry screens (main.lua and txtmsg.lua) now alongside both celinf.lua and servce.lua mixer scripts without any memory issues.

    Cheers, Paul
    snowest said:

    If I deactivate servce.lua then it is working fine :-) otherwise I get also a memory error

    Thanks

    Gregmaan said:

    Paul,

    Many thanks for this tip. Without the celinf.lua it works again!

    Cheers Gregor

  • v2.0-rc1 just released here: https://github.com/athertop/MavLink_FrSkySPort/releases/tag/v2.0-rc1

    Would be grateful if any testers out there are willing to give it a try and let me know how you get on. The teensy code remains unchanged from v1.8 (released early December 2016). If you have an earlier version, then please update the teensy with the included code located in the repo under /Teensy/

    Taranis LUA code is now compiled and the install files for the SD card should be copied from the repo path /Taranis/LUA_SD_Card

    Note - its important that you also include the /SCRIPTS/TELEMETRY/DATA folder included in the repo on your SD card as this is the folder required to store telem screen config files. Additionally please also ensure /SCRIPTS/TELEMETRY/LIBRARY is also copied as this contains all compiled LUA screen and support files.

    General instructions for setup should follow those on the original wiki here: https://github.com/Clooney82/MavLink_FrSkySPort/wiki

    The only differences for the installation of this rc1 release relate to the repository folder layout which is detailed in the release notes (hopefully far more intuitive now).

    athertop/MavLink_FrSkySPort
    APM MavLink to FrSky S.Port converter. Contribute to athertop/MavLink_FrSkySPort development by creating an account on GitHub.
  • Guys, I now have the new v2 of the "Mavlink_FrSkySPort (Clooney82) telemetry solution" completed and is in final testing by me before a rc1 will be released to testers from my own github repo.

    I have alleviated the memory issue by now using compiled LUA code on the Taranis. Also I have the lua code split into the main.lua and 4 library files which are loaded in/out as required to save memory. Alongside the compiled files (for the SD card) I will of course (given the nature of open source) provide the original source files in the github repo.

    Now, given that there has never really been an official name for this project - I thought I'd throw out the idea of coming up with a new name which would allow more instant recognition. So any thoughts from anyone regarding:

    1. changing the name?

    2. suggestions for names? Needs to be short but distinctive.

    ...answers on a postcard....

This reply was deleted.

Activity

Neville Rodrigues liked Neville Rodrigues's profile
Jun 30
Santiago Perez liked Santiago Perez's profile
Jun 21
More…