My maiden with the Gyro went from BAD to even worse < does seem at this point in the investigation...to be pilot error..with a tad of NO directions >

installed unit in my funcub...unit UP / plugs facing back towards Tail.

1. reversed AUX dip switch...so my aux swich could turn it on/off.
Used the Left ail. plug as the RT Ail. plug reversed my actual ailerons

2. very careful ground check..and pots set to aprox 3 o'clock position..seemed very snappy/Good.

3. Maiden #1- with gyro off..check controls again, all workd perfect...Take off...small trim adjustment...flying fine.
Climb to safe alt. .......switch gyro on...imediate plane inverted and in a inverted spin nose down <VERY bad place for plane to be>...Switch OFF...saved plane.

4. After recovery...gyro off still...flew a circut...then landed no issue. <Whoosh..sweat mild>

5. Groung checked AGAIN....this time discovered the ailerons were GYROwise reversed
Seems after I switched the RT Ail plug...to the L Aileron plug..it did MAKE my transmiter work in the right direction..BUT the gyro aileron function was reversed. so I switched the ail switch on the gyro...it DID GYROwise correct the direction i need the gyro to go.

6. checked gyro direction again on ground...looked good.
Maiden #2 - gyro OFF till i get to a 2 mistake high Altitude.
Take off roll as normal..began climb...again roll over//inverted...10 feet off ground...correction with stick ineffective ...plane crash aprox 60 degree angle nose down and rt. wing tip...happened so fast power was still on too.

7. did quick check to see if perhaps i took off with the gyro engaged..NOT Engaged.
Plane was dammaged gear bent bad/scuffs deep on nose-cowl area/compression marks all over nose to approx. mid wing on the fueslage\ crack-brake in 1 wing aprox. 4 inched from the saddle area\ motor will not turn..shaft is still straight..but either a rock in it..or a magnet is loose/broke etc. not removed it yet so not sure what failed.

8. got it home ..quite disgusted...but wanted to check somthing again...i plugged lipo back in...turned the gyro OFF...and did a normal control check....my Ailerons were REVERSED!!!
So when i fixed the GYRO being reversed useing the dip switch IT also reversed my REULAR aileron travel. !!!! ARRRRGGGG...< but honestly I should have re-checked that and caught it>

Morel of story......check once...check twice....CRASH...and check it again!!

Atleast i belive I found the problem...and that is somewhat comforting....I will fix it..and fly again...still not sure what the ORANGE GYRO really will do for me...but DO know...CHECK IT WELL..on and off..then CHECK IT AGAIN!!

Pat

Originally Posted by Weed89

Morel of story......check once...check twice....CRASH...and check it again!!

Atleast i belive I found the problem...and that is somewhat comforting....I will fix it..and fly again...still not sure what the ORANGE GYRO really will do for me...but DO know...CHECK IT WELL..on and off..then CHECK IT AGAIN!!

Pat

Happened to me once without any gyro. Checked three or fours time at home during setup. Toss, throttle, and found reversed ailerions. I was able to mentally correct a little, but end up nose in. Went home reversed ailerions and slapped head. Picked it back up again later to double check and reversed again. Not sure what the heck was wrong me that day. I actually wondered if the dx8 was playing games with me. But was probably my brain.

Probably a bit tmi. To me, it looks like the sw pwm update order is Ail-L, Elev, Rud, Ail-R. I base this on the evidence that one goes high exactly as prior goes low in progressive order. So they are making blocking calls on pwm writes and walking list in sync calls. Strange, as I would expect the programmer would have kept both ailerons as close as possible. Maybe they assumed most people would use a Y and did not want to delay 22ms on second ail in most common cases.

I flew with my gyro again today, this time with the video camera (#16) running. The proof, if any needed, is in the videos. Guess which one doesn't make me seasick? Too bad it does nothing to help me stay in the thermals. I have the rates dialed down way low, at about 10 o-clock, so that I can see the plane indicate lift or sink. At these slow speeds it works like a charm. I'll do some editing magic and post some videos later.

Weed:

My guess is one of two issues:

1) (less likely) - when you say that the plugs are towards the rear and th eunit is facing up, I assume it is not oriented such that the axes are all mixed up. If this was the case, your plane would behave erratically when the gyro is engaged. That would explain some of the issue.

2) (more likely) - your gyro is mounted vertically flat facing upwards. No problem, but the aileron was probably reversed. no issue, except that if the compensation is NOT verified, then any inputs will be amplified and the unit will force instability.

#2 explains things better, but does not quite fully explain why the plane inverts on engagement of the gyros. If your gain was excessively high, it might, but not sure.

Not trying to insult your intelligence, but these things usually go awry when something is overlooked. The ONLY thing that makes sense to me is the over gain on the gyros and possible overcompensation on the ailerons.

SC

Originally Posted by Weed89

My maiden with the Gyro went from BAD to even worse < does seem at this point in the investigation...to be pilot error..with a tad of NO directions >

installed unit in my funcub...unit UP / plugs facing back towards Tail.

1. reversed AUX dip switch...so my aux swich could turn it on/off.
Used the Left ail. plug as the RT Ail. plug reversed my actual ailerons

2. very careful ground check..and pots set to aprox 3 o'clock position..seemed very snappy/Good.

3. Maiden #1- with gyro off..check controls again, all workd perfect...Take off...small trim adjustment...flying fine.
Climb to safe alt. .......switch gyro on...imediate plane inverted and in a inverted spin nose down <VERY bad place for plane to be>...Switch OFF...saved plane.

4. After recovery...gyro off still...flew a circut...then landed no issue. <Whoosh..sweat mild>

5. Groung checked AGAIN....this time discovered the ailerons were GYROwise reversed
Seems after I switched the RT Ail plug...to the L Aileron plug..it did MAKE my transmiter work in the right direction..BUT the gyro aileron function was reversed. so I switched the ail switch on the gyro...it DID GYROwise correct the direction i need the gyro to go.

6. checked gyro direction again on ground...looked good.
Maiden #2 - gyro OFF till i get to a 2 mistake high Altitude.
Take off roll as normal..began climb...again roll over//inverted...10 feet off ground...correction with stick ineffective ...plane crash aprox 60 degree angle nose down and rt. wing tip...happened so fast power was still on too.

7. did quick check to see if perhaps i took off with the gyro engaged..NOT Engaged.
Plane was dammaged gear bent bad/scuffs deep on nose-cowl area/compression marks all over nose to approx. mid wing on the fueslage\ crack-brake in 1 wing aprox. 4 inched from the saddle area\ motor will not turn..shaft is still straight..but either a rock in it..or a magnet is loose/broke etc. not removed it yet so not sure what failed.

8. got it home ..quite disgusted...but wanted to check somthing again...i plugged lipo back in...turned the gyro OFF...and did a normal control check....my Ailerons were REVERSED!!!
So when i fixed the GYRO being reversed useing the dip switch IT also reversed my REULAR aileron travel. !!!! ARRRRGGGG...< but honestly I should have re-checked that and caught it>

Morel of story......check once...check twice....CRASH...and check it again!!

Atleast i belive I found the problem...and that is somewhat comforting....I will fix it..and fly again...still not sure what the ORANGE GYRO really will do for me...but DO know...CHECK IT WELL..on and off..then CHECK IT AGAIN!!

Pat

Set point seems very high to me. Especially on a new and untested installation.
Ron

Sorry for you crash

As has been seen before on bothe V1 and V2 the setup of these units CAN and WILL cause some odd changes to the reactions of the servos.

My advice to anyone new to this is

DONT ASSUME ANYTHING.......

Install the unit and check for correct control movement

Turn Gyro on

Check and be sure of correct gyro reaction, be sure it compensates the correct way and use reverse switches to change.

Re check correct control movement as they can become corrupted by changes in gyro setup above.

Re check gyro compensation.

Make sure all is still ok with gyro on or off.

Pre flight as normal doing a last check of controls.

It may all sound obvious but its easy to forget, especially the step after setting gyro direction.

When I set my first unit up I spent some time scratching my head as I had lots of reversal issues that I had to work thru to get it working right. On my second install there was no adjustment needed and it was fine as it came from HK.

Check check check........if in any doubt dont fly.....

Dave

I think you'll like it once you get it dialed in Pat. I let a couple of experienced fliers try it yesterday and they were impressed. One is the chief flight instructor and thought it would be a boon for students.

Gord.

I have crashed three airplanes due to gyro gain adjustments being way too high. That was twenty years ago on balsa planes so the pain was significant, but the lesson is set up low and very carefully go higher on the gain. Gyros can be your friend, but at high gain who needs friends like that. Three o'clock sounds on the high side. Mine are more like 1:45pm

Deleted incompleted post, proper post follows

Originally Posted by noobee

since the rx3s connect the 4 rx channels (A, E, R, AUX) though different pins, the interrupt routine on the rx3s will be capturing the rising and falling edge of each pulse individually. i believe most rx implementations will emit the group of 4-5 pulses sequentially, but without delay, between any two channels (determined by the tx as you indicated). for example, assuming all 4 rx (from the tx) are 2ms pulse width and the rx frame period is 20ms, then the timeline could be

0ms: A rise
2ms: A fall, E rise
4ms: E fall, R rise
6 ms: R fall, AUX rise
8 ms: AUX fall
...nothing happens for 12ms till 20ms mark
20ms: A rise
...and repeat

(i'm ignoring the T channel here, which will probably be somewhere in the middle of the group).

ideally, i would like to perform the compute on AUX fall (8 ms mark). if i performed the compute on E fall (just pick one for example), then the R and AUX signals would be "20ms stale". different rxes (jr, futaba, airtronics, frsky) use different order in their serial ppm stream and hence leading to a different order at the rx as well. i could also wait 3-4ms for no change in any pins to determine the end of the frame, as you also indicated.

if the end of the frame is used to trigger the compute (18ms from ail in to ail out), then i have to scale up/down the i and d multipliers for each frame based on the interval since the last compute. i wonder if that's happening here. alternatively, suppose the input frame from the rx exceeds 22ms, will the rx3s still hold the 22ms output period? if so, then how would that work (ail in -> ail out)?

in any case, i think all these issues probably don't really matter much anyways the delay is just a couple of ms.

Well it turns our assumptions about pulses is wrong. My history and early looks at DX5e transmitter clouded things for me.

When digital RC was first being worked on in the 60's the transmitters were simply a ring of single shots back to back with the number of shingle shots being the number of channels plus 1. The potentiometer on the stick or control varied the width of the output pulse between 1-2ms. The last single shot was set at around 3ms to allow the end of frame to be detected. The trailing edge of each single shot triggered the one that followed it and the trailing edge of the last single shot started everything all over again.

The frame rate would vary slightly depending on the setting of all of the controls. When all controls were set to minimum pulse width the frame rate would be quicker. The RF was almost always on and the leading edge of each single shot would briefly turn off the RF. The decoder in the receiver would reconstruct the pulses in the order they were generated and send them to the proper servo.
All pulses were always in the same order and the end of one was also the start of the next.

I left RC in 1975 as I had too many other interests and no where near enough time. My youngest granddaughter became interest in airplanes at a very young age and interested in RC airplanes around 2011. That is when I got back into the hobby to encourage and help her.

My first TX was a DX5e that came with the Phoenix Flight simulator that my granddaughter uses for practice. I scoped the output of a clone Spektrum receiver and things looked like I remembered 35 years before.

I got to thinking yesterday that since the transmitters and receivers are now digital and sending Ethernet type frames via Cypress Wi-Fi chips (at least that is how Spektrum does it), all of the necessary information about each channel can be in the data packet - including the channel number so things could be transmitted in any order and output pulses could overlap.

This morning I got my AR8000 receiver and bound it to my DX8 and used the logic analyzer channels in my scope to capture all 8 channels. Much to my surprise I learned the following:
- Frame Rate is fixed at 22ms, regardless of channel pulse widths.
- Channel output pulses can and do overlap.
- The trailing edge of one pulse does not start the next.
- The trailing edges of the pulses seem fixed relative to the frame and the
leading edge moves.

I powered on/off both the transmitter and receiver multiple times to see if the pulse order changed but it did not seem to. It is possible that the pulse order is random and configured when you do the bind. Don't know for sure yet.

I then decided to use the same receiver setup with my DX18. The channel pulse order changed and once again did not change with power on off.

I have attached screen shots for both the DX8 and DX18.

Thus it appears that:
- Pulse widths must be measured from leading to trailing edge.
- Can not depend on relationship to previous or following pulses.
- It is possible for pulses to overlap. I have not see this happen with the three
channels that need stabilization so far.

All of the above is specific to Spektrum. I have no idea what other digital systems might do.

Thanks everyone for your help/input...I strongly feel it was the DUELING reverse controls I was not mentally prepared in advance to Look out for.

It did not seem to occur to me at the time..that reversing the gyro dip would also reverse my ailerons even when the gyro was turned off.

So I do hope that a NEW gyro person reads My experience and checks the directions much better than I did. OFF & ON ...gyro throw Direction & regular aileron throw Direction.
Lol and the elevator/rudder too.

The Cub WILL fly again...and I am POSITIVE the setup will be correct this time

Again Thanks.
Pat

Thats the spirit.....way to go

Dave

Originally Posted by JohnRB

Thus it appears that:
- Pulse widths must be measured from leading to trailing edge.
- Can not depend on relationship to previous or following pulses.
- It is possible for pulses to overlap. I have not see this happen with the three
channels that need stabilization so far.

Hi John. Just trying to clear in my brain what your saying.
1) "Pulse widths must be measured LE to TE". I am missing some key idea to your observation. How else would one measure a pulse? TMK, you have to have a LE and TE to know what the length in ms is. Could you expand a bit. tia

2) Overlaping pulses. I assume your not talking about pulses on same channel that overlap. But pulses from other channels overlaping each other. Pulses from other channels overlapping would not seem to be a problem (In my mind) and would tend to be expected depending on implementation. The pulses from the 3X appear to be syncronous blocking writes. While the RXs seem to be async implementation.

3) You dog. You got a dx18qq. I want to pull the trigger on one. But can't mentally justify it - yet. :-)
Please let us know. Thanks much.

Originally Posted by wjs

Hi John. Just trying to clear in my brain what your saying.
1) "Pulse widths must be measured LE to TE". I am missing some key idea to your observation. How else would one measure a pulse? TMK, you have to have a LE and TE to know what the length in ms is. Could you expand a bit. tia

The point I was trying to make was that you cannot measure from the fall of the previous pulse to the fall of this pulse to measure the time. In the old analog systems the fall of the previous pulse and the rise of the current pulse were virtually the same time (small logic delay).

Originally Posted by wjs

2) Overlaping pulses. I assume your not talking about pulses on same channel that overlap. But pulses from other channels overlaping each other. Pulses from other channels overlapping would not seem to be a problem (In my mind) and would tend to be expected depending on implementation. The pulses from the 3X appear to be syncronous blocking writes. While the RXs seem to be async implementation.

Again in the old analog systems, pulses going to different channels could not happen at the same time (overlapped). In the Spektrum system this can happen. If channels that require stabilization overlap, it could place too much burden of the Atmel processor to get the job done. The limited testing I have done never displayed overlapping of the channels that require stabilization so that should not be a problem.

Originally Posted by wjs

3) You dog. You got a dx18qq. I want to pull the trigger on one. But can't mentally justify it - yet. :-)
Please let us know. Thanks much.

No, not a QQ, just a plain DX18. I did a firmware update to my DX8 and it crashed during the update and I had to send it in for repair (under warranty, they had to replace the encoder board). I had been looking at the DX18 and since I was going to be without a transmitter for a couple of weeks I got a DX18. This was just after the DX18 hit the market - before the QQ was announced. I am happy with it and don't regret not getting a QQ. It does everything I need and at a much lower cost than the QQ.