search

joeylamb / opentx

Automatically exported from code.google.com/p/opentx
0 stars 0 forks source link

first pulse truncated on PPM output #100

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
Which board (stock / gruvin9x / sky9x / Taranis) are you using?

  Stock, others using bitbang PPM.

What is your openTx FW version?

  Trunk as of 10.8.2013

What is your openTx EEPROM version?

  N/A

What steps will reproduce the problem?

1. N/A

What is the expected output? What do you see instead?

PPM output should have equal length pulses, now first pulse if 30-70us shorter 
than rest.

Please provide any additional information below.

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

Patch provided.

Original issue reported on code.google.com by khau...@gmail.com on 11 Aug 2013 at 4:41

Attachments:

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago

Original comment by bson...@gmail.com on 13 Aug 2013 at 8:27

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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