Closed GoogleCodeExporter closed 8 years ago
[deleted comment]
This is a real problem since it affects servo values sampled by Radio modules,
however it can usually be worked around by changing ppm polarity.
Original comment by khau...@gmail.com
on 11 Aug 2013 at 6:02
Confirmed. It's a big problem as the fix will screw up model settings for
everybody...
Original comment by bernet.a...@gmail.com
on 11 Aug 2013 at 7:49
Well not everybody, just for people who accepted the offset and changed
subtrims to fix it.
The problen only appears if rf module samples leading edges of ppm thus
swapping polarity hides the problem.
Original comment by khau...@gmail.com
on 12 Aug 2013 at 4:25
From my observations on the scope with current release version on a 9x the
first servo position (distance between the first and 3rd edge of the PPM
signal) is shortened from a displayed value of 1500 to about 1440. This is with
both positive and negative polarity...
Original comment by bernet.a...@gmail.com
on 12 Aug 2013 at 7:03
Yes this is what I am referring to, measure between 1st and 2nd edge and
compare to 3rd and 4th. you see the 300us (by default) pulse is responsible for
this.
Basically the first edge is delayed by the setupPulses routine by ~60us, This
will depend on channel count and with 16ch PPM the difference is almost double.
Original comment by khau...@gmail.com
on 12 Aug 2013 at 7:19
Yes but pulse enough would not have any influence, unless the module is buggy.
Pulse duration is not significant, what is important is only the time between
the rising edges in positive mode, resp. falling edges in negative polarity.
http://api.ning.com/files/WmjViE3faLYy73Ry7eTzn4XMryr8qlAMeb*edCbrzW1BVUPtR1iXBI
GgsS93iG1x5roVRkAWHqg7V3FAhK*o8NYsajr5nW7G/RC_Receiver_Timing_Diagram1.jpg
Most modern modules simply ignore polarity and record the times between even
edges stating from the one after the pause (1-3, 3-5, 5-7 etc) regardless from
whether they're rising or falling.
So if pulse duration was wrong but without changing the time between edges 1
and 3 it would not matter. Unfortunately it does change it.
Original comment by bernet.a...@gmail.com
on 12 Aug 2013 at 7:46
LOL, you just linked a picture which shows a case that the bug will affect
output. So receiver modules acting based on the linked picture are buggy?
It is a clear bug in openTX code, just bite the bullet and fix it.
The bug will cause an offset to first channel if the leading edges are measured
(as the leading pulse is included in measurement). If the trailing edge is used
for measurement it will include the pulse after the changing period (i.e. the
first pulse is included into sync period) the bug will not show up.
Original comment by khau...@gmail.com
on 12 Aug 2013 at 8:01
Why has this got medium priority only? It is a real issue and bug, even more
bad if it happens for the Taranis too. The total pulse length of the first
channel is to short! I noticed this while attaching a Turnigy 9XR mainboard
flashed with openTX to a simulator input where all input channels have been
calibrated to accept 1000-1500-2000us pulse length. As I verified with an
oscilloscope the first channel is out of center about 78us for 10ch PPM.
Changing the PPM polarity does not fix this! The first shorten sync pulse is
part of the timing measurement for the first channel. Ususally it should be no
problem programmig a AVR 16 bit timer in a correct way. I will have a look into
the source because I already had to compile it due to some LCD display issues
and I can't use this radio while this issue is not fixed.
Original comment by wol...@gmail.com
on 13 Aug 2013 at 3:26
I'll give the fix mentioned in the forum (link provided in additional
information) to move the setupPulses() call a try.
Original comment by wol...@gmail.com
on 13 Aug 2013 at 3:44
The bug wont affect taranis nor boards using timer for waveform generatiom.
Original comment by khau...@gmail.com
on 13 Aug 2013 at 4:11
This issue has high priority, don't worry. I already sent 2 versions of
potential patches. If the second is good (it keeps the original idea of Fox) it
will be commited ASAP.
Original comment by bson...@gmail.com
on 13 Aug 2013 at 8:27
Original comment by bson...@gmail.com
on 13 Aug 2013 at 8:27
My patch was already tested by André this morning, but would you give some
more tests as well before we release? Thanks!
Original comment by bson...@gmail.com
on 16 Aug 2013 at 8:37
Patch works as expected. Good work, the solution is quite elegant too.
Original comment by khau...@gmail.com
on 16 Aug 2013 at 10:07
Original issue reported on code.google.com by
khau...@gmail.com
on 11 Aug 2013 at 4:41Attachments: