Servo buffer/ level shifting

[kd7ost]

We've talked about this in other threads but I thought I would take some pictures and try to consolidate it here for reference.

Please excuse my drawings, I can't find my good crayons. :o

There are times where interfacing certain equipment causes grief. Some receivers have 3.3 volt pulses and some put them out in parallel. In a servo that's never an issue. But when interfacing with devices using TTL level PIC chips, like UNAV UAV devices etc, or connecting up to a co-pilot where it won't take pulses in parallel causes problems. There are ways to fix it.

Servo buffers provide a variety of functions but it depends on the brand and what parts they use. This particular unit uses a single IC chip that does both Pulse delay and level shifting. If you roll your own with this part you can't go wrong. This is cheap and very robust.

Dan

[kd7ost]

Next pictures

[kd7ost]

More pictures

[LukeZ]

Great tutorial Dan - thanks for putting it together for us.

Luke

[vector_vortex]

Great tutorial,
However the data sheet that I have for the 4049 indicates that the minimum high voltage for a 5V supply is 3.5V which is higher than the 3.3V max that is put out by the receiver/autopilot. would it be better to use a 74HCT04 which has 3.3V compatible inputs with 2.0V minimum input high voltage.

[MX]

I was thinking of using something like an HCF40109 on WPS-2 to buffer up the outputs to 5v. Any comments on the suitability of that chip?

MX

[kd7ost]

I've never used that one but it looks like it would certainly do the job. It seems like you need to do a few more things with the tri-state outputs. Maybe just tie the enable lines to high to keep them enabled.

In the 4049 if you're only going for a level shift and aren't worried about propogation delay, you can use just two gates for each signal for up to three signals shifted to the level of the applied voltage.

Something I haven't tried but would work in some applications where you need to shift up to 6 channels is the CD4050. It's the compliment of the 4049 but the output of each gate is not inverted. Just put the 3.3 in any input and get a non inverted signal out at the applied voltage.

Dan

[MX]

That looks like it might work too. What are the implications of a 140ns propogation delay? Are there some mixers that might not like it?

MX

[kd7ost]

That looks like it might work too. What are the implications of a 140ns propogation delay? Are there some mixers that might not like it?

MX

Uh oh,

If you're asking me lectronical questions I think that hot place just froze over. :D You and Mr RCCam are the real aces.

I don't do any mixing with software or what have you. I'm just a hardware guy. I'll continue on the descriptions but this is all I know. I don't think I'm going to help you with the question. (This is for other folks and just to add to the information pool in this thread.)

In this diagram it shows what a buffer/servo amp was designed for. A pulse on a long wire gets boosted or amplified if you will so it doesn’t decay on the way to that servo way in the tail section. Additionally, I drew some noise spikes to the right side of the buffer. These can come from RF noise or a failing servo. These spikes will cause glitching in your system. The buffer acts like a valve if you’ll excuse the term and prevent that noise from feeding all the ay back to the receiver where it can wreak havoc with all the other servos.

These buffer/amps can be made from different chips. I use the 4049 but the 4069 is another common one. They both put in a slight delay and do the buffering. But the 4049 will level shift low voltage pulses where as the 4069 will not.

Dan

[kd7ost]

In this diagram, this is about what it looks like to have a 6 channel receiver putting out pulses in normal time span. First goes pulse 1, then 2 then 3 etc. Once the last pulse is generated a synch pulse from the transmitter signals the receiver to start over again. Pulses move at about 55 to 60 per second. They are typically (In almost all RC systems) at 4.8 to 5.2 volts.

Dan

[kd7ost]

I use a Futaba PCM receiver. I favor the ergonomic layout over all other brands. But it has some quirks to work with. If you’re just powering servos, this is a non issue. The receiver puts out 3.3 vdc pulses but look at how they are timed out.

First goes pulse 1 and 2 together.
Then goes 7 and 8 together.
Then goes 3 and 4 together.
Finally 5 and 6 go together.

Again, a servo doesn’t care about this. It’s only concerned with the duration or length of that pulse. But once you start connecting up to other devices you might have trouble.

The Co-pilot is a case in point. The co-pilot doesn’t care if the pulses are 3.3 volt or 5 volt logic. It will interface fine with either. But here’s the co-pilot problem.

It needs channel 1 and channel 2 for aileron and elevator. Since the Futaba PCM sends them at the same time, that doesn’t work for the code in the co-pilot. It needs first 1 pulse then the other. It doesn’t even matter which of the two are first, they just can’t arrive at the same time. The buffer serves as a residual benefit by adding delay, (through propagation) that’s the time it takes for a pulse on a gates input to make the output state change. Throw 6 of these gates in line like I did with the buffer above and you get enough delay so that the servo channel you put the buffer on is now delayed compared to the other one. It still gets there at the same frequency but now the co-pilot gets first one pulse then the other like it needs.

See the second diagram to illustrate that.

Dan

[kd7ost]

Last, there is another reason to use the 4049. Level shifting. Many PIC devices like the UNAV parts I use can't use the 3.3 vdc pulse. It's ambiguous. It needs a full 5 volt pulse. (Or a close proximity of)

I'll use the 4049 and only two gates on one set of servo wires, then two more gates with another set of servo wires to get my 3.3 volts up to 5 volts for those Versions of PIC chips that need it.

I'll include a picture of a single chip used to convert two 3.3 volt pulse channels to 5 volts. This goes to a Pico Nav unit for the elevator signal and enable line both. It allows me to level shift two channels in a single package.

Dan

[kd7ost]

That looks like it might work too. What are the implications of a 140ns propogation delay? Are there some mixers that might not like it?

MX

I can't imagine that 140ns delay would hurt much, except you said it was for a mixing process. 140ns is nothing but a tiny spike in a standard RC system running at the slow speeds (VF speeds) with huge pulses that are used.

But in you mixing application, if it's to determine a center position of a servo when eabled on or off, I can't imagine that amount would even move the servo enough for the human to detect it. Most standard servo's won't see a difference and I don't even know if the high resolution digitals would see it. If they did, and reacted to it, I think it would still be too small to make even any minor deflection changes.

If it's for something else for use in high speed code, you're way over my head and suspect it could be a problem depending on the application.

Dan

I don't know what the 140ns delay is used for in your reference. But a servo works from between 1ms to 2ms to hit each extreme in normal operations. 140ns = .00014 ms.

[MX]

I knew about the copilot problem, but I'm not seeing how you get over 2 msec of delay with 6 hex inverters that spec a worst case propogation of 140 nsec each.

MX

[kd7ost]

Ah,

Now I understand. I don't know the answer. I'll need to put a dual trace scope on the signals and see what there is as far as delay. All I ever did was read the Co-pilot recommendations on using a buffer or two on one signal line in the event of a futaba PCM with this issue. After making one and putting it in, all the interface problems I had cleared right up. It just glitches without it but have flown many hours with a buffer on one line without a hint of an issue.

I'll bring a scope home from work, (My techtronics unit has lost it's ability to sync) and get some numbers and have a look. I'll report back.

Dan

[kd7ost]

I just had a thought.

Would it be enough that one pulses PGT is finished before the other one starts? Maybe they don't come in completely separate from each other in a time span, but they still arrive at a different time? The PGT of the first one sets that code part to work and the processor can look for the next one?

Just thinking out loud.

Dan

[MX]

I just had a thought.

Would it be enough that one pulses PGT is finished before the other one starts? Maybe they don't come in completely separate from each other in a time span, but they still arrive at a different time? The PGT of the first one sets that code part to work and the processor can look for the next one?

Just thinking out loud.

Dan

Could be that the copilot microcontroller uses an interrupt to detect the rising edge of the pulses. If they happen at the same time, one edge will be missed. I suspect you are delaying it by only about 600 nsec, but maybe that's enough for it to see both edges.

MX

[kd7ost]

Great tutorial,
However the data sheet that I have for the 4049 indicates that the minimum high voltage for a 5V supply is 3.5V which is higher than the 3.3V max that is put out by the receiver/autopilot. would it be better to use a 74HCT04 which has 3.3V compatible inputs with 2.0V minimum input high voltage.

My sincere apologies Vector,

I missed your question.

I'm sure there are different manufacturers of the 4049 and they may vary slightly between them in specs. I've always used what had on hand. I use chips from Motorola. Specifically it's the MC14049UBCP. The specs on mine state that at 5 volts at 25C the minimun input voltage for a logic 1 is 2.5 vdc.

Anyway, I'm sure I've used chips from Harris and TI over the years and never even had a hint of ambiguous operation in any level shifting or delay capacity. And I fly the Heck out of them. Some of them may not have spec's out like this one I currently have on hand.

Dan

[kd7ost]

It occures to me that a person could also use something like the 4N28 or similar opto isolator for level shifting. The problem there is you have to have a different power source on the output than what drives the input pulse. It would take a dual supply. These devices do it from the originating pack and require no additional power source.

Maybe someone knows of a level shifting option, like MX mentioned, that features broader specs.

Dan

[Dan_Jones]

First, I try not to plug a product because it isn't right and that's what advertising is for. But in this case, there is a change that could be made to an existing product to possibly help this fairly unique need.

Our latest product uses a 74F07D inverter chip with a 4.5ns prop delay. So the entire delay for each signal will be 9ns. We call it a voltage isolator because it allows higher voltages to go to the servos than what the reciever is running at. However, it can be modified to run off of 5v and accept inputs as low as 2 volts, according to the datasheet. I am actually using a modified one on my control board project in another thread to read the Futaba 3.3v signals on a 5v microprocessor. I also have bare boards (no wires) if people want a cheaper solution ($13).

http://www.dionysusdesign.com/product_info.php?products_id=171&osCsid=5c926ba13cb806cab5d09287b072ff06

[kd7ost]

First, I try not to plug a product because it isn't right and that's what advertising is for. But in this case, there is a change that could be made to an existing product to possibly help this fairly unique need.

Our latest product uses a 74F07D inverter chip with a 4.5ns prop delay. So the entire delay for each signal will be 9ns. We call it a voltage isolator because it allows higher voltages to go to the servos than what the reciever is running at. However, it can be modified to run off of 5v and accept inputs as low as 2 volts, according to the datasheet. I am actually using a modified one on my control board project in another thread to read the Futaba 3.3v signals on a 5v microprocessor. I also have bare boards (no wires) if people want a cheaper solution ($13).

http://www.dionysusdesign.com/product_info.php?products_id=171&osCsid=5c926ba13cb806cab5d09287b072ff06


Excellent. I'm glad you did plug that in. It's good to have options to resolve the interface anomolies that show up in some cases. It makes it easier for builders to integrate the systems when they find out there's differences, and that there are ways to interface them.

Dan

[kbosak]

I tried making this buffer using FUTABA RF-138DP.
It merely attenuates glitching (this for sure) but significant amount of undersired behavior persists. I use Texas Instruments CD4049UB.
total propagation time typical 60ns, max 120ns. Probably the chip I've bought was 'too good = too fast' for the task.

Second thing, all this is useless as making channel 7 a 100% slave of channel 1 eliminated all racing condition on the inputs of FMA Co-Pilot {edited} and glitching vanished without using any buffers.

However, once again, after connecting any of my Futaba S3001 servos to FMA Co-Pilot {edited} _outputs_, I still see some glitching even when using slave channel!
To my total surprise Airtronics and several Hitec servos are fine, or maybe there are some marginal problems I cannot hear.

So there's more than a simple level conversion. putting FMA Co-Pilot {edited} in the middle of way to your servos need serious investigation. Not good for an end-user product, particularly that shipping this damn servo buffer from US will take another month plus a month or so in polish customs.
Whatever we say, there is an american toy syndrome here: fantastic marketing, brilliant idea, hi-tech and hi quality components,on top of that huge incompatibilities and :censored: (poor) finishing.

So, periscope down, oscilloscope up. Stay tuned.

[kd7ost]

That sounds strange but thanks for the feedback. Maybe there is a few obscure things that haven't been discovered yet and you are the first to report it.

How many of the gates did you put each signal through?

Also, what is an FMS?

And what battery voltage are you using? Is it a 5 cell pack?

Dan

[kbosak]

That sounds strange but thanks for the feedback. Maybe there is a few obscure things that haven't been discovered yet and you are the first to report it.



How many of the gates did you put each signal through?

6 inversions, as in your case. (I have exactly replicated your design).


Also, what is an FMS?

Lots of typos here, thank you, corrected.


And what battery voltage are you using? Is it a 5 cell pack?

I have big standard servos that always make some 1.2v local voltage drops no matter that I use high quality cabling and high output current lipo accus (Flight power 2170 3S or 1800 2S, all rated 25C and this is not just a marketing as verified on helicopters).

Tried 3 voltage stabilisers:
-one from 3S to 6.2 or 5.2v selectable, some not-very-brand-name-yet-competent Polish switched mode with lots of inductors and capacitors
-LM7805CV with all decouplings etc soldered on table
-LM317T with all decouplings in high ripple rejection schema on 6V

watching on the oscilloscope I can say that:
feeding the buffer with red wire shared with servos is not cool.
there is a lot of noise coming from the servos even if you put inductor rings on their plugs, 1000uF + few low ESR ceramic capacitors on power source side etc.
Vcc on this design really deserves separate regulator (so we will have one reg for servos and one for <receiver, FMA Co-pilot, gyros> etc).
I tried playing with inductors and capacitor to heal the Futaba S3001 on the output of FMA. This is for sure nothing with levels, which seem fine, and enhancing them to 5V using this buffer didnt helped. some 10uH inductor helped marginally but introduced another type of oscillations at the ends of travel (with FMS the servos tend to glitch around center positions). I am to weak to solve this so I say NO to cheaper model Futaba servos, even if I believe this is the Co-pilot that is making sometimes dirty (those 3 futabas I have worked under at least 5 configurations and platforms, PCM/PPM jeti rex, 4 voltage regs without a single problem etc).
So the bottom line is that I am very confident about quality of power source here. No electric motor was running during the trials.

My impression is that any digital switching electronics is introducing a lots of noise it you omit decoupling capacitor at digital signal output - I wonder if FMA board has some on the output, but good receivers have them.

I will try adding another servo buffer (increasing delay time, hope will be enough this time) in serial at FMA input (let's say at elevator channel) so this will save me one channel (no need to slave 1 to remote 5, 6, 7 or 8), Futaba S3001 servos are out, now working on full servo firewall using 4050 and 2 voltage regulators.

All trials performed on isolated system, cables twisted, oscillo HP 54501A 100MHz so maybe I were not able to see all noise that FMA created in the way to servos. I think I will disassemble FMA to see what's going on there.

[kd7ost]

It sounds like something different is going on. Help us understand your setup. There are some interface qualities that need to be looked at for making it work.

First of all try this.

Put the buffer you made on the output of the desired receiver channel and hook a servo directly into the output of the buffer. Operate the stick and see if the servo behaves normally. If it does, your buffer is good. If it does not behave normally, try the servo directly into the receiver servo channel of choice and operate it. If it behaves normal from the receiver, but not through the buffer, there is something wrong with the buffer. But, if the servo works properly through the receiver and buffer, the buffer is good and we can move on to the next part.

Next, the FMA co-pilot does not need the level shifted. It can work with a 3 volt pulse or a standard TTL 5 volt pulse. So we don't need to level shift to the co-pilot to make it work.

The problem in that case can still go back to the receiver and the way Futaba creates pulses in the PCM 138 receiver. It should work the same as my Futaba PCM 148 receiver. Futaba uses a processor and code that creates each pulse in pairs. First it sends out pulse 1 and 2 at the same time. These go to the throttle and rudder. Then it creates pulses 7 and 8, then 3 and 4, and finally 5 and 6 and starts over. To a servo, this is no big deal as they are single ended devices. Here is where the problem comes in with the Co-pilot.

The co-pilot uses pulses 1 and 2 from the receiver for pitch and roll control to elevator and ailerons. As I described above, pulse 1 and 2 are being created by the Futaba PCM receiver at the same time. The co-pilot cannot process both pulses when they arrive at the same time. It is looking for first one pulse, then the other. Again, it doesn't care what logic level they are. Only that it gets fist one, then the other. This is unique to the Futaba PCM system. 3 volt logic in pairs.

So, what you do is make a buffer and put it on either channel 1 or 2 between the receiver and the corresponding co-pilot input. But you must ensure it is to only one of those receiver/servo channels. The buffer in this case does both level shifting, (Which doesn't matter) but it also puts a delay on that one pulse due to propagation delay through the chip. FMA says that sometimes you need to use two buffers in a chain on one channel to increase the delay to ensure you get enough separation of time through further increase propagation delay. The propogation delay is the quality we are looking for in this case. I have never had to use two when I make my own because I use all six gates from the 4049. Some buffer manfacturers may only use 2 or 4 and the level shifting occurs, but the delay isn't very much. You should be OK with one buffer since you too used all 6 gates.

The 3 volt logic is a good idea. It allows things to stay operational in a safe manner as the 4.8 to 6 volt battery voltage takes dips during operation.

In your set up you need to ensure the following to get reliable operation.

1. Test the buffer(s) with a servo first to make sure it (they) operates normally.
2. Test the two receiver channel outputs with a servo directly connected to ensure the receiver works normally.
3. Put one buffer on only one servo channel, 1 or 2, (It doesn’t matter which one) and connect them up to the co-pilot. Only channel 1 or 2 should have a buffer between the receiver and the co-pilot. The other servo channel and your spare enable channel can go directly into the co-pilot. If you buffer both channel 1 and 2, you are doing level shifting which again, the co-pilot doesn't need. But you are delaying both pulses by equal amounts and not fixing the interface problem.
4. With the enable channel disabled, you should observe very near normal operation with the aileron and elevator channel with this set up.
5. This next part is pretty key. When you enable the co-pilot, things won’t look normal to you anymore. This is because the co-pilot is sensing IR heat signature differences and is starting to come into play in manipulating pulse duration to the servos. How much it does this depends largely on how much gain you have set in. The more gain, the more the effect. If you stay away from your plane and don’t move around, it is normal to hear some servo growling as the IR heat sensors detect tiny local variations and change the servo pulse duration. Again, this is normal and is how the co-pilot works. As long as you get the normal/reverse set up like the book talks you through, then do the calibration you should be OK. When you take your plane or helicopter outside and power things up, it is normal to hear the servos growl a little as the co-pilot works them ever so slightly around center.

Give all this a try and report back your findings if you don’t mind.

Dan

Look over the information in post 11.
http://www.rcgroups.com/forums/showpost.php?p=7246263&postcount=11

[kbosak]

1. Test the buffer(s) with a servo first to make sure it (they) operates normally.

tested just after solderiung. perfect with any servos, osilloscope says cool squared signal to 5 or 6 V depending on power supply.

2. Test the two receiver channel outputs with a servo directly connected to ensure the receiver works normally.

tested, retested, pairing of channels 1,2 observed, delay between 2 and 3 observed on oscilloscope. OK

3. Put one buffer on only one servo channel, 1 or 2, (It doesn’t matter which one) and connect them up to the co-pilot. Only channel 1 or 2 should have a buffer between the receiver and the co-pilot. The other servo channel and your spare enable channel can go directly into the co-pilot. If you buffer both channel 1 and 2, you are doing level shifting which again, the co-pilot doesn't need. But you are delaying both pulses by equal amounts and not fixing the interface problem.

of course I did tried both scenarios (delay only ch 1 or delay only ch 2).

4. With the enable channel disabled, you should observe very near normal operation with the aileron and elevator channel with this set up.

the glitching has only attenuated.

5. This next part is pretty key. When you enable the co-pilot, things won’t look normal to you anymore. This is because the co-pilot is sensing IR heat signature differences and is starting to come into play in manipulating pulse duration to the servos. How much it does this depends largely on how much gain you have set in. The more gain, the more the effect. If you stay away from your plane and don’t move around, it is normal to hear some servo growling as the IR heat sensors detect tiny local variations and change the servo pulse duration. Again, this is normal and is how the co-pilot works. As long as you get the normal/reverse set up like the book talks you through, then do the calibration you should be OK. When you take your plane or helicopter outside and power things up, it is normal to hear the servos growl a little as the co-pilot works them ever so slightly around center.

Glitching is still there.
*If using futaba servos:
{
-Tons of glitching using ch 1+2 without delay buffer.
-A lot of glitching using ch 1+2 and delay buffer on either 1 or 2.
-Same glitching behaviour regardless:
+A. IR sensor connected to FMA or not
+B. FMA sensitivity high or low (set by ch 5 and 6)
+C. Sensitivity adjustment is functional, confirmed
/
-Still some minor glitching when using slave channel 7 and no buffer
}

*If using hitec or airtronics servos (excluding HS-81 that is glitching like
futabas * above)
{
-Tons of glitching using ch 1+2 without delay buffer.
-A lot of glitching using ch 1+2 and delay buffer on either 1 or 2.
/
-Completely not glitching when using slave channel 7 and no buffer
}

I am afraid I have garbage in/garbage out problem here.


Look over the information in post 11.
http://www.rcgroups.com/forums/showpost.php?p=7246263&postcount=11
[/QUOTE]
Thank you I have already read most of rcgroups posts on servo buffer, including this one. I think I understand them very well.

[kbosak]

BTW shouldn't we ground unused pins in CMOS IC instead of cutting them? this will remove the possibility of damaging them due to internal static electricity buildup. Or am I wrong? (I have read this tip somewhere on electroforum).

[kd7ost]

BTW shouldn't we ground unused pins in CMOS IC instead of cutting them? this will remove the possibility of damaging them due to internal static electricity buildup. Or am I wrong? (I have read this tip somewhere on electroforum).

That is correct. The unused ones need to be tied to an appropriate logic level.

However in this case there is no need. If you used every gate there are no unused logic portions in the chip. Pins 13 and 16 have leads and I don't know why the manufacturer provides them there. They just take up space. They are not connected inside of the chip to any of the CMOS circuitry so they don't need to be tied high or low.

Dan

[kd7ost]

tested just after solderiung. perfect with any servos, osilloscope says cool squared signal to 5 or 6 V depending on power supply.

tested, retested, pairing of channels 1,2 observed, delay between 2 and 3 observed on oscilloscope. OK

of course I did tried both scenarios (delay only ch 1 or delay only ch 2).

the glitching has only attenuated.

Glitching is still there.
*If using futaba servos:
{
-Tons of glitching using ch 1+2 without delay buffer.
-A lot of glitching using ch 1+2 and delay buffer on either 1 or 2.
-Same glitching behaviour regardless:
+A. IR sensor connected to FMA or not
+B. FMA sensitivity high or low (set by ch 5 and 6)
+C. Sensitivity adjustment is functional, confirmed
/
-Still some minor glitching when using slave channel 7 and no buffer
}

*If using hitec or airtronics servos (excluding HS-81 that is glitching like
futabas * above)
{
-Tons of glitching using ch 1+2 without delay buffer.
-A lot of glitching using ch 1+2 and delay buffer on either 1 or 2.
/
-Completely not glitching when using slave channel 7 and no buffer
}

I am afraid I have garbage in/garbage out problem here.



Thank you I have already read most of rcgroups posts on servo buffer, including this one. I think I understand them very well.[/QUOTE]


I hope my detailed description didn't insult you. I didn't mean to if I did. I just get a little anxious when I explain things and become redundant at times. My apologies if it sounded like I was insulting you. I know the integration process can be frustrating at times.

I don’t know what to tell you at this point with the symptoms you are having. It sounds to me like the receiver and buffer are working fine. Some servo’s might be more prone to showing a problem but they should all be compatible so I don’t think it’s a servo manufacturer problem, a buffer problem or a receiver problem as I read your description. It sounds like something is wrong with the Co-pilot. It’s the one piece where things seem to fall apart when you put it into the system. I have several CPD4 Co-pilots and they all run correctly with my Futaba PCM receivers and my home made buffers.

What happens if you run first one channel by itself, 1 or 2, through the co-pilot and get it set up to work? Then unplug that one and then run the second one through the co-pilot on it’s channel? Will they work by themselves?

Dan

[kbosak]

I have just added second 4049 70ns buffer in serial. No further improvement achieved.
.

[kd7ost]

Well it's not a hoax. I don't sell any products and am just reporting what I do and what FMA recommends. I post it for free and spend my time to try to be helpful. As I said, the integration process can be frustrating especialy if the work arounds don't work for you.

Anyway, good luck.

Dan

[kbosak]

Well it's not a hoax. I don't sell any products and am just reporting what I do and what FMA recommends. I post it for free and spend my time to try to be helpful. As I said, the integration process can be frustrating especialy if the work arounds don't work for you.

Anyway, good luck.

Dan
I made a mistake in calculation.
The buffer is delaying enough for interrupt routine... to do the job.
There is something more inside.

[kbosak]

There is something very interesting:
upper half of the plot show original ch 1 from R-138DP
0 to 3.33V

lower half is delayed signal using 2x 4049 buffers
0 to 5V

what we see that the propagadtion time is 1.5us.
On the other handbecause there are capacitors at signal line in futaba, and there are none at 4049 outputs, the level triggered around 3V inside FMA occurs practically at the same time.
Solution:
1. add buffer like 4050 at aileron to square up the signal
2. add capacitor to 4049 output.
3. find something that puts much more delay than a pair of 4049

[kbosak]

I have just tried to square up both signals (with 4050) and delaying them both (with 1uF capacitor at signal line). Whatever I do, ~1.5us delay is introduced as planned, everything is fine on oscilloscope, but this delay is NOT enought to behave FMA anywhere close to the setup with slave channel.
My investigation ends here.
I believe nothing can be done until I use a buffer that will add 2ms delay to prevent temporal collision on ch1 and ch2 when using Futaba PCM receivers.
My opinion that is that while Futaba's PCM design is lazily done, the input stage of FMA Co-pilot is crap.

I have read on another thread that somebody proposed taking HAL2100 electronics and superior IR Co-pilot sensor to choose the best quality components... Totally capitalist greedy consumer approach but describes well the problem.

[kbosak]

I have just succeeded to filter FMS Co-pilot glitching. No time to post it now but delaying one of the signals by as much as 2ms works. The trick is that at the falling signal interrupt the FMS must have time to do some calculus, when it is unable to detect failing slope of the other channel within time budget, causing artificially elongated detected signal on the other channel. This is why 2ms.
Required components:
4xceramic 105 capacitor (1uF)
1x4050 to bring levels up to be accepted by schmitt buffer
1x40106 schmitt buffer
implementation:
push signal through a single gate of 4050, wire the result to 40106 input, then at each output of each stage of 40106 put 1uF capacitor connecting it to ground (vss) (will add 0.5ms delay each). Use all inputs/ouputs of 40106.
the use of LM2940 or similar low-drop linear voltage regulator 5V suggested.
Becaus the low level and high level are assymetric in 40106, you must use pairs of one charged and one discharged capacitor, and because you have to delay a signal that takes min. 1ms by 2ms you need a '2-level delay machine', what gives 4 capacitors and 5 schmidt gates. the 6th gate must be used just to adjeust teh signal from inverted to regular form again.
Move your brain and enjoy. Success guaranteed.
at the end you will have 5 more gates at 4050 useful for signal boosting to 5 V for the remaining servos. Might be useful if you want to connect TeleBee ALIGN gyro after FMA copilot output.