Hi all,
I just bought an FrSky Taranis for my quad copter and needed to get the Mavlink data up on the Taranis LCD telemetry display. So here is my solution using a Teensy3.1 as a converter between MavLink and the S.Port on FrSky X8R.
See attached file below...
Replies
Unfortunately it seems like the the resolution of A2 is only 8 bits.
The current implementation is sending hdop /4. If you configure A2 with a range of 1024, you should get a close enough value of the actual hdop.
You don't need the scripts if you configure the A2 range yourself, but some of the values are packed together to enable more values to be sent. The scripts is used to make these values easier to handle for the telemetry screens.
Thanks, I'll try that.
HDOP seems more important to me in assessing the stability of GPS position, so I trust low HDOP as being ready to fly more so than Sats count. Maybe that's not the best way but it seems more reliable so far.
I send my hdop as fuel. works for me even though there is no decimal point.
I assume fuel can only range from 0-100 numerically on Taranis ?
So do you take a HDOP value of say 2.30 and multiply by ten and send that ? (Taranis would show 23 on the fuel %).
nope, I d o not change anything except the container variable (fuel).
hdop 2.4 taranis shows as 240
You can change how the A2(Hdop) value is sent be changing on the code running on the teensy (FrSkySport.ino)
The choice of the Lua scripts to present the data has to do with the versatility that the script provide.
The HDop values on the Taranis on mine are the same as in APM Planner.
Luis
OK, are you sure HDOP on the Taranis and Planner read identically at the same time ?
When I checked it was out by one full digit most of the time (Taranis said 3.XX while Mission Planner said 2.XX or lower).
If your sure then I have a problem some place...
Maybe somebody else can check it (with no Lua script running).
According to Mavlink Inspector window yes both values are the same...
Screen Shot 2014-09-02 at 01.35.45 copy.png
Sorry you lost me, but I do follow the comment below. Value HDOP/4 is sent possibly.
There was a small discussion today with Mike Blandford about the implementation with the Teensy, and he mentioned on a thread at RCGroups, that the code for telemetry packets is not 100% correct. Apparently the code has been incorrect for quite some time and the error just keeps getting repeated over and over. Here is the quote from Mike
"The SPort protocol is NOT correct, there is no "byte stuffing" implemented.
It looks like the code has been copied from the diydrones site where it is also wrong, and that was copied from a googlecode site which is also wrong!
Mike."
And then later an explanation of the specific byte stuffing:
"Byte stuffing is used to prevent the value 0x7E (used as the first byte of a SPort frame) appearing in the middle of a frame. FrSky used this method in the the original HUB data.
In the middle of a frame, 0x7E is sent as 0x7D followed by 0x5E, and 0x7D is sent as 0X7D followed by 0x5D.
Mike."
When I looked at Christian's code it did not appear that this special case is being handled and the packet is just a raw byte stream that could inadvertently send a 0x7E in the middle of the packet. Since I am no programmer, it would sure be nice if someone could check this out.
Bud
-
129
-
130
-
131
-
132
-
133
of 186 Next