Replies

      • Hi Glenn,

        that what i imagine, something like that, but i don't have skills in coding :-(

        i can confirm that you can access to the Storm3 param via MP ( parameter tree), as say OlliW you can make change, but not stored by the end,that should change in next future, if i well understand.

        i'll have a look on the idea of same System ID and different component ID, i saw that on the ardu code but not sure about the storm (there's no reasons)

        thanks for you answer and investigation! naturally, i'm volunteer for test.

        @Luis:

        don't have to much flight with the last rc4 (none, to be honest) but with the rc3 some, and i don't see any difference on my Taranis.i could be wrong, i don't really have the time, in this moment, to fly :-(

        Do you really think that the Mavlink on 3.3(final or 3.4) and the OpenTX2.1 are going at light years of the present? candid question, don't have time to follow the OpenTX dev, but crazy about to use it ;-)

        • @Vic 33

          The changes on OpenTX 2.1 are very significant regarding the telemetry (complete refactoring), and break everything :). 


          a few notes about the telemetry

          A few keypoints of the result:

          • Each value sent down is treated as a separate "sensor" with its own properties (unit, decimal precision, ratio/offset) and options (auto offset, filtering, persistent storage at power off, logging enabled). Each sensor has its own user-defined name and keeps track of its own min/max value.
          • In the case of the FrSky system, these sensors are auto-discovered anytime the radio and receiver/sensors are powered up.
          • Sensors can be duplicated, so for example a given value e.g. altitude from the same vario sensor can be displayed/announced/logged simultaneously in different units, or with different options (absolute altitude and altitude above start point with auto or manual offset,...)
          • Multiple physical sensors returning the same value are supported as long as there is a way to differentiate them. With the FrSky S-port system it means you can connect any number of identical sensors as long as you make sure to change the IDs of sensors with the FrSky SBUS servo channel changer (SCC) as required so each ID is unique in the smart port chain (explained in the sensor's and SCC's manuals). If you want to measure individual motor currents of your octocopter with 8 FCS-40A sensors, no problem. 
          • "Calculated" virtual sensors can be manually created to combine values or extract extra data. Values can be added, averaged or multiplied, the minimum or maximum of a set of up to 4 values van be extracted. This also takes care of "special cases" like calculating GPS distance (2D or 3D), getting the value of a particular cell of a lipo cell sensor, calculating mAh consumption etc. For example Power can be calculated easily by multiplying the related voltage and current, total voltages of multiple lipo cell sensors can be added to get the total voltage of series-wired packs, the minimum cell of each of them can be extracted and the lowest of all can be found using the Minimum function.
          • Each sensor can be reset individually with a special function, so no more losing all your min/max values when you just want to reset altitude offset to start point.

          http://openrcforums.com/forum/viewtopic.php?f=45&t=6887

          • waahou!

            ok thanks for the informations.

            I'm going to cry a little, and back again.

      • The Teensy parsing code must be revised for the 3.3 release (3.3 is still Release Candidate). But considering that also OpenTX 2.1 is near completion and changes the telemetry system, I believe is best to wait....

        Luis

        • The teensy/lua code (I'm using the wolke branch) works perfectly for me on 3.3rc code except for the storm32 issue.

          Looking forward to seeing the new opentx 2.1 telemetry.

          • You think it does, and it appears it does, but it doesn't :)

            Just a small example. There is a new flight mode on 3.3 which is not captured (yet) by the parser....

            • Yes granted it won't support the new features, error message formats etc, but it works just great for basic usage.  The rapidly switching flight mode is a real PITA - I've had to rename the sounds directory to shut it up for now and it makes the direction arrow unuseable as well - if someone can make a quick patch to filter a single system ID that would be great.

              Thanks to everyone who has contributed to this teensy/frsky system, it really is awesome.

              • The error codes.... ah.... that's another issue :)

                Have you tried to "manipulate" the Storm32 SystemID ?

                Luis

                • I just tried setting the systemid to 1 (in the storm32 config) instead of 71 and kept the component id as 67, but it didn't help the teensy telemetry, I still get flashing mode changes on the tx screen, and then the pixhawk couldn't control the gimbal anymore - it must be hardcoded to talk to systemid 71 maybe.

                  wolke pretty please, could you possibly put a filter in your code to just listen to a single systemid?

  • you do not have to buy this adapter. you need to google up APM code adjustment - you can reflash UART chip in the APM to understand SBUS. It can work directly with no issues.

This reply was deleted.

Activity