|Anonymous | Login||2017-07-20 14:51 EDT|
|My View | View Issues | Change Log | Roadmap | Repositories|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000525||Deviation||[All Projects] General||public||2014-02-26 15:30||2016-09-19 16:55|
|Summary||0000525: Devo telemetry gets random results|
|Description||When reading telemetry from the Rx, it is easy to get corrupted frames (move the stick, and the voltage, RPM, and Temp will all get random values occasionally)|
|Tags||No tags attached.|
Could you please check, if bad telemetry data are handled in a save way.
We may have to deal with buggy RX's that might send garbage to the TX.
The issue is in some way related to signal strength.
At a distance RX<>TX of 20cm I can't see any unusual values.
My observations suggest, that this issue could interrupt transmission of the TX. The more corrupted data the more likely is loss of control.
See: http://www.deviationtx.com/forum/6-general-discussions/2722-v120d02s-v2-lost-binding-mid-flight#21247 [^]
|This should be fixed in 3f3c0aab8de7|
The issue seems to be related to a defective CYRF6936 module.
see: http://deviationtx.com/forum/6-general-discussions/2722-v120d02s-v2-lost-binding-mid-flight?start=20#21524 [^]
Here a log of 4.0.1 with MiniCP and new "telemetry module".
Surprisingly now the only bogus data are at "Latitude" and "Longitude" and one at RPM2. Note that MiniCP only supports "Temp1" and "Volt2"
00:00,0.0,3.4,0.0,25,0,0,0,0,0,000 00 00.000,000 00 00.000,0.000,0.000,00:00:00 2000-00-00
113:53,0.0,3.4,0.0,28,0,0,0,0,2640,000 00 00.000,159 58 18.144,0.000,0.000,00:00:00 2000-00-00
126:53,0.0,3.4,0.0,28,0,0,0,0,0,000 00 00.000,121 52 03.296,0.000,0.000,00:00:00 2000-00-00
127:53,0.0,3.4,0.0,28,0,0,0,0,0,661 49 27.328,201 30 16.944,0.000,0.000,00:00:00 2000-00-00
I think this could be closed as resolved:
This code http://www.deviationtx.com/forum/protocol-development/896-support-for-walkera-telemetry?start=240#30974 [^]
"CYRF_Reset" http://www.deviationtx.com/forum/protocol-development/896-support-for-walkera-telemetry?start=280#31333 [^]
should have fixed the issue
|Indigo's code hasn't been merged yet. Once he submits a pull-request, we can close this ticket|
edited on: 2016-09-19 06:27
What is the status of bogus DEVO telemetry?
Has Vlad_vy's commit 4.0.1-nightly-build 4b3dc91 resolved the issue?
How about Indigos commits and merges from 2015-04-25 to 2015-05-01?
Anyone with DEVO equipment could re-test on release 5.0.0 / >= 4.0.1-nightly-build 4b3dc91 so we may be able to close the ticket? :-)
My open DSM telemetry questions on bogus telemetry packets still apply (to DSM telemetry):
AFAIK Indigos test-build DSM + DEVO protocol code (re-write) was not accepted.
It would be quite interesting for some telemetry testers (like me) to hear / read a "short summary" on a higher level on forum what code parts of his test-build code are actually included in Vlad_vy commit without having to step into C and CYRF register programming too deep ;)
|2014-02-26 15:30||PhracturedBlue||New Issue|
|2014-02-28 06:52||linux-user||Note Added: 0000001|
|2014-03-06 21:51||PhracturedBlue||Note Added: 0000001|
|2014-03-23 11:16||linux-user||Note Added: 0000001|
|2015-03-08 05:46||Indigo||Assigned To||PhracturedBlue => Indigo|
|2015-03-08 05:46||Indigo||Status||new => assigned|
|2015-04-21 04:43||linux-user||Note Added: 0001287|
|2015-04-21 09:59||PhracturedBlue||Note Added: 0001288|
|2016-09-19 06:24||Thomas.Heiss||Note Added: 0001629|
|2016-09-19 06:27||Thomas.Heiss||Note Edited: 0001629||View Revisions|
|Copyright © 2000 - 2017 MantisBT Team|