Cross check CPPM operation on IO v1.3 with FrSky receivers

[LorenzMeier]

Some users with FrSky receivers had issues. We need to work out if something particular about the D4R-II is an issue or if there is something on our side that would need to be addressed. There are no reports of issues with that receiver on Pixhawk (IO v2.3/2.4).

[TickTock-]

Sorry not much help here except I can say that I do not see any issues with a FlySky TH9X (OpenTX) feeding EZUHF radio transmitting 12 channels on the latest master.

[Kynos]

On a FMU-v1 & IO 1.3? If so, where did you connect CPPM - to J4 on the IO board or to J1 on the FMU board?

I had serious trouble some time back using the 3DR CPPM converter and a Spektrum Rx: frequent RC signal loss conditions and nonsense RC channel values. This was completely fixed by adding a 1K0 in series with the CPPM signal (just like what you get when you connect CPPM to J1 on the FMU board). Pixhawk uses a (different value) series resistor for the CPPM signal, too.

The FrSky D4R-II Rx works fine here, although with the 1K0 fix. Haven't tried a direct connection yet and won't be able to do so soon cause I first have to rebuild my stuff after a crash.

[TickTock-]

Not sure what CPPM is, but I am connecting my radio PPM output to the PX4IO PPM input next to the eight servo outputs.

[Kynos]

In an RC context, PPM by default denotes a single channel signal, so CPPM (= Combined PPM) is often used for marking the difference. Graupner called it "Summensignal" long time ago.

[tstellanova]

Yep, we connect the FrSky D4R-II to the PX4IO (v1.x) PPM input to the far right of the eight servo outputs. I've confirmed this works very smoothly with git commit 6dce571 running on multiple PX4 1.x boards, with multiple D4R-IIs (fresh from factory, not reflashed, not running all 8 channels at max at any time). With the current "continuous" build we see throttle spikes after arming on one PX4FMU+PX4IO combo, which can cause a quad to flip on the ground if props are on. My next step is to try swapping in a different PX4IO to see if that IO is bad.

[tstellanova]

Tried exchanging PX4IO with another and result is the same: 6dce571 shows no RC2 (throttle) spikes, whereas running latest CONTINUOUS build shows occasional full RC2/throttle spikes and throttle shutdown after arming.

[LorenzMeier]

This seems to be related to #930.

[LorenzMeier]

I've created #943 to track the I2C issues - if we cannot reproduce CPPM issues with current NuttX master (where the change is reverted) we can close this card and focus on the I2C aspects.

[R-Lefebvre]

I went through a lot of problems with the CPPM signal using Arducopter on 2 different PX4's in November. I would get input glitching on multiple/all channels simultaneously. The RCInput in logs would show Zero values, even though there was code that should never have allowed values of less than 900 (IIRC) to be returned. These were single frame errors.

On one of the machines, an RC Helicopter with a belt drive, I discovered the root cause was static buildup and discharge from the belt drive. Not a lot. And not enough to cause problems with other electronic systems on this model of helicopter, the problem seemed unique to PX4 and/or my particular helicopter. I installed extensive ground wiring to eliminate the buildup, and the problem went away.

The other machine however was a quadcopter. I never found the cause, there was no source of static. I eventually replaced the PX4 with a Pixhawk with no other changes, and the problem went away.

I now have PX4's running on two other helicopters with no issues. Neither of these have belt drives so no static buildup.

I wish I had more conclusive evidence. But I spent something approaching 100 hours on the problem, and once I solved it I didn't circle back to find out exactly what the problem was.

[LorenzMeier]

Ok Rob, thanks. I think the problem is essentially noise and I'm currently looking into improving noise immunity. What I hadn't realised earlier but noticed today is that we actually use a more resilient implementation of the FMU <-> IO communication on FMUv2. Bringing some of that to FMUv1 will likely put this to rest, even in very noisy environments.

[R-Lefebvre]

Are those noise immunity differences in software or hardware?

[px4dev]

There's a link integrity check on the v2 boards that isn't currently implemented for the i2c interface on the v1 systems. I sent Lorenz a prototype that adds similar checking to the i2c link today; it will probably require some tweaking before it's ready to deploy.

Note however that this is a band-aid; it will reduce the likelihood of data corruption between IO and FMU passing un-noticed, but it won't do anything about the root cause of the corruption.

The edge detector in the STM32 that is used to decode the PPM signal has several clocks (my recollection is 3 @ 24MHz) of debounce filtering. If you are seeing noise glitches longer than a microsecond or so, they may be recognized as false transitions in the stream.

The IO-side decoder is edge-direction sensitive, so for a short glitch it will drop the next two edges, meaning that you will normally see corruption of one or two adjacent channels. The FMU-side decoder is edge-direction agnostic, so in many cases you will lose the entire remaining PPM sequence (the channel hit by the glitch and all higher-numbered channels).

Improving IO<->FMU link integrity will do nothing for either of these issues. It would help if anyone experiencing problems with PPM input glitching could try some specific interference suppression techniques.

1. A 10nF capacitor from the PPM input to ground, as close to the connector as possible (on the pins on the bottom of the board would be ideal). If this helps but not enough, increase to 0.1uF (but remove any series resistor if you do this).

2. Shielded cable for the PPM signal from your receiver to the PX4. One half of a stereo cable, or cable from an old pair of headphones will do. At a pinch, use discrete wires and twist them around each other; try to get at least one twist per inch. You can buy pre-twisted servo cables, which may also help.

Combining both techniques may help further, and we would appreciate feedback from anyone that has an opportunity to try this.

[tstellanova]

Per suggestion from @LorenzMeier I tried this:

cd Firmware/NuttX
git checkout ed45e813aff84f5646ea7ad1d7ab50f597bdebb9
cd ..
make distclean && make archives && make upload px4fmu-v1_default -j12

I first tried bench tests and could confirm that the throttle spikes and throttle shutdown/disarm problems we were seeing vanished. I then tried flying and was able to perform some very smooth flights with F450, px4fmu+io 1.x

This was with main PX4 firmware commit 15e65fd

[TickTock-]

Ah. Good to know that the hours I spent crimping my own custom shielded
coax PWM wires (
http://pixhawk.org/platforms/multicopters/mantis_x8/frame_assembly) paid
off. @todd: I noticed in your image of your wiring you didn't have the
ground wires connected on the servo outputs. This creates a large ground
loop that can contribute to noise. You might be able to improve your
robustness by giving reach ESC it's own ground return line. Would be
interesting to see if this fixes the problem (without the software fix).
On May 14, 2014 10:01 AM, "px4dev" notifications@github.com wrote:

There's a link integrity check on the v2 boards that isn't currently
implemented for the i2c interface on the v1 systems. I sent Lorenz a
prototype that adds similar checking to the i2c link today; it will
probably require some tweaking before it's ready to deploy.

Note however that this is a band-aid; it will reduce the likelihood of
data corruption between IO and FMU passing un-noticed, but it won't do
anything about the root cause of the corruption.

The edge detector in the STM32 that is used to decode the PPM signal has
several clocks (my recollection is 3 @ 24MHz) of debounce filtering. If you
are seeing noise glitches longer than a microsecond or so, they may be
recognized as false transitions in the stream.

The IO-side decoder is edge-direction sensitive, so for a short glitch it
will drop the next two edges, meaning that you will normally see
corruption of one or two adjacent channels. The FMU-side decoder is
edge-direction agnostic, so in many cases you will lose the entire
remaining PPM sequence (the channel hit by the glitch and all
higher-numbered channels).

Improving IO<->FMU link integrity will do nothing for either of these
issues. It would help if anyone experiencing problems with PPM input
glitching could try some specific interference suppression techniques.

1. A 10nF capacitor from the PPM input to ground, as close to the
   connector as possible (on the pins on the bottom of the board would be
   ideal). If this helps but not enough, increase to 0.1uF (but remove any
   series resistor if you do this).

2. Shielded cable for the PPM signal from your receiver to the PX4. One
   half of a stereo cable, or cable from an old pair of headphones will do. At
   a pinch, use discrete wires and twist them around each other; try to get at
   least one twist per inch. You can buy pre-twisted servo cables, which may
   also help.

Combining both techniques may help further, and we would appreciate
feedback from anyone that has an opportunity to try this.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/921#issuecomment-43107902
.

[LorenzMeier]

So what Robert was seeing looked like this: The first pulse looks like an I2C transfer fail (the zero decoded values would not have been returned by the decoder and I was able to reproduce this with I2C bus errors), the 2nd pulse is not entirely clear - this could very well be a decoder error, as its trivial to generate this outlier by moving / falsely detecting an edge while its not so easy to generate the opposite change on two channels with noise / software errors on the bus.

[R-Lefebvre]

Is that from my logs?

On 15 May 2014 10:30, Lorenz Meier notifications@github.com wrote:

So what Robert was seeing looked like this: The first pulse looks like an
I2C transfer fail, the 2nd pulse is not entirely clear - this could very
well be a decoder error.

[image: glitches_robert_3]https://cloud.githubusercontent.com/assets/1208119/2985647/6c2636ba-dc3d-11e3-86b9-94fe606a0f85.png

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/921#issuecomment-43216536
.

[LorenzMeier]

Yes, and I also downloaded the rest of the data from your PC 8).

[tstellanova]

Has this been fixed in the current PX4/NuttX master? I see a revert related to stm32_i2c

[jdsaund]

Hey guys, hope this is useful to somebody out there. I just had a bunch of issues with my PX4 glitching with FrSky D4R-II w/ 27ms firmware. PX4 is being powered by external BEC. I was having glitches every 4 seconds or so, very random and severe. Tried uploading latest PX4 firmware, tried ferrite rings on power cables, tried a different RX, none worked, still glitching.

Changed BEC voltage from 6.0V to 7.5V and there is no more glitching!!! Well, at least I am yet to experience a glitch. I will write back if I see any glitches.

[jdsaund]

A bit of additional info:

• L1 was removed from the PX4IO for high power servos. The PX4IO power input is then supplied by the servo rail with a custom made cable so that the PX4 and servos are powered together
• The PX4IO is being powered by the BEC because the machine is running on 6s. The helicopter is very small, so does not have space for a separate BEC to power the PX4
• The BEC is internal to the main ESC (HobbyWing Platinum Pro 50A)
• 5.2V on the BEC yields very occasional glitches, 6.0V is extremely bad, and 7.5V has no issues. I suspect the BEC is nosier at the lower voltage ranges which was causing my glitches
• The results were identical on 4s and 6s batteries powering the BEC. This machine will normally run off 6s

[LorenzMeier]

Thanks for the report. If you check the IO docs, you'll find that the minimum input voltage for the power port is 6.4V - hence your outcome is expected, as it can't work with the lower voltages.

[R-Lefebvre]

Joly, if you need, I can tell you how to supply the PX4 with down to 5.2V
and still have 5.0V on the Vcc. :) Just need to replace the onboard
regulator.

On 18 October 2014 08:59, Lorenz Meier notifications@github.com wrote:

Thanks for the report. If you check the IO docs, you'll find that the
minimum input voltage for the power port is 6.4V - hence your outcome is
expected, as it can't work with the lower voltages.

—
Reply to this email directly or view it on GitHub
#921 (comment).

[jdsaund]

Lorenz, perfect. I was going off thePX4IO schematic on the pixhawk website, says 6-18v. The actual web page seems to have the correct info though. It seems that other people are referring to the I put as the "6-18v input" instead of "7-18v" which is confusing. E.g 3DR online store:

https://store.3drobotics.com/products/px4-fmu-flight-management-unit-plus-io-input-slash-output-kit

It would help a lot if these websites can somehow be updated. It makes a quick google search on the input voltage range very misleading.

What's more, I was even more confused because 5.2v was giving less issues than 6.0v, I was thinking to myself, "according to the schematic it's within range!!"

Rob, thanks I might do that one day in the future, but this heli uses HV servos :D I actually needed 7.5V but was starting off with lower voltages during the setup process. Luckily I won't have to modify anything. Thanks again.

[R-Lefebvre]

Yes, I use HV servos as well. But my concern is what happens when the 2S
lipo gets down to 6.5V, and then there is a current spike from the servos
which drag the battery voltage down below 6.0V. I didn't want the Vreg to
be the thing to let me down if I can help it.

You won't have that problem with a regulator, but note there is some risk
powering it that way. Many BEC's allow momentary voltage dips well below
target voltage when the servos move. I'd suggest installing a 4700uF cap
on the servo rail at the very least. I don't power any of my setups that
way. Either 2S direct, which is "bolder" than a BEC. Or I use 2 BECs, one
for the Pixhawk, and another for the servos.

On 18 October 2014 15:38, Jolyon Saunders notifications@github.com wrote:

Lorenz, perfect. I was going off thePX4IO schematic on the pixhawk
website, says 6-18v. The actual web page seems to have the correct info
though. It seems that other people are referring to the I put as the "6-18v
input" instead of "7-18v" which is confusing. E.g 3DR online store:

https://store.3drobotics.com/products/px4-fmu-flight-management-unit-plus-io-input-slash-output-kit

It would help a lot if these websites can somehow be updated. It makes a
quick google search on the input voltage range very misleading.

What's more, I was even more confused because 5.2v was giving less issues
than 6.0v, I was thinking to myself, "according to the schematic it's
within range!!"

Rob, thanks I might do that one day in the future, but this heli uses HV
servos :D I actually needed 7.5V but was starting off with lower voltages
during the setup process. Luckily I won't have to modify anything. Thanks
again.

—
Reply to this email directly or view it on GitHub
#921 (comment).

[jdsaund]

Good advice, appreciated. This BEC is rated to 7A continuous, 15A peak. Should be up to the job as the servos are only micro servos. I can stall one of the servos (takes much manly force) and the rail voltage doesn't budge :)

I'll heed your advice and add a cap though.