RunRyder - TX/RX eCCPM Output Test Results

rrTV-PHOTO

New HD TV

HOME rrTV-PHOTO GALLERIES MY GALLERY HELP-FAQ

myHOME PM pmRR MEMBERS 492 ONLINE 42 EVENTS SEARCH REGISTER START HERE

6 pages [ << < 1 2 ( 3 ) 4 5 NEXT >> ]

16016 views

POST REPLY

Midland Helicopters	.	HeliProz	.	ZoomsHobbies
	.		.

Radio - Servo - Gyro - Gov - Batt > TX/RX eCCPM Output Test Results

Micro-Maniac
Elite Veteran
Location: Pasco,Washington Formerly: Captain Chaos

I assume this is all done in eCCPM, hence the thread title.

07-07-2005 Over year old.

JKos
Elite Veteran
Location: City of California in the state of Maryland

Wolfgang,
> Pulse width IS time. You're plotting time against time ?

Yes, that is correct. Each pulse out of the receiver has a certain length (time) and occurs at a certain time (time). Thus, the new plots will show not only the pulse width for each pulse, but exactly when they occur.

> The nature of the system will never allow channels to update
> simultaneously since data is sent sequentially.

That is incorrect. Both Futaba PCM formats (PCM1024 and G3) and Airtronics PCM have simultaneous pulse outputs for various groups of channels. JR PCM rx outputs are sequential, but the data coming into the rx is certainly not sequential in nature.

> The above does not necessarily apply to pcm.

Almost all of these tests are with PCM. Those which are FM are labeled as such. PCM is of the most concern for this issue.

> see some strange pulse coincidences on the three trace plots where
> channels 1 and 2 have coincident pulses and channel 6 is down the
> line somewhere. My question is why are 1 and 2 coincident?

Because that is how the receiver is sending them out.

> The other graphs you show with pulse width versus frames are
> showing exactly what?

They show how the transmitter is updating the pulse widths on a frame-by-frame basis. The corresponding pulses may or may not come out of the receiver at the same time, but they are being sent within the same frame.

> Is that data the outputs from the RX?

Yes, all data presented here are from the receivers' servo channel outputs.

> If so, where are the stick inputs?

This is not a latency test and thus the "stick" input is not shown. The stick input is a fast collective change. The latency tests capture stick-to-receiver output timing.

> which of these test are done using e-CCPM

All of them.

> I would expect the dedicated channel operation has the least
> problems of latency and slew.

Yes, that is correct. These issues are not a problem for non-eCCPM machines since no interaction is created by individual channel behaviors. Latency is still an issue on non-eCCPM machines as it does directly effect the connection between the pilot and the machine.

A collective change was chosen for these tests since that is what seems to cause the most swashplate "dancing" issues.

Captain Chaos,
> I assume this is all done in eCCPM, hence the thread title.

Bingo!

- John

07-07-2005 Over year old.

JKos
Elite Veteran
Location: City of California in the state of Maryland

I have posted new plots in their appropriate places in this thread. The new plots show the pulse width versus time. This is what the servos really care about, not frames per say.

The pulse width "steps" are placed on the x-axis where the pulses ended.

- John

07-07-2005 Over year old.

SLO-Mike
Heliman
Location: Morro Bay & Hong Kong

Question about 14Mz in PPM mode

John, I've been trying to read all your threads to better understand this and are your taking the pulse readings at the RX? I was wounding if packet rejection was occurring which might be why its taking more frames to catch up, but I thought with PCM if it found an error it dumped the entire Tx servo/stick update data set and waited for the next one. If this is the case it would seem that the lag error is generated at the Tx which is odd that it performs differently in different modes. Sounds like a firmware problem at the Tx if this is the case.

Is it possible the Rx is taking what it can get out of each pulse data set and repeating/holding what's left of the original pulse until it gets a packet set it can fully accept? That would explain why the pulse takes longer to update/change the further down you get from ch1, but I don't think it can do this unless it stores and compares the last valid data set with the new incoming one. I have read that with PPM it does not do this and just skips the one channel it could not decode with DSP based PPM Rx's. The manufactures of these also claim that PPM is faster on the updates than PCM for this reason as even if one servo gets missed all the other valid packets are sent to the servos where PCM blocks the entire servo/stick position update packet set and must want for the next servo/stick position update.

What lead me to your thread was I've been looking for information on how the 14Mz sends it PPM data. Can you remember if the pulses were identical to the 9C with the 9C using a conventional Xtal based module?

The reason I ask is I have several DSP based receivers in planes (not heli's), Berg/FMA, and have read over and over that these DSP based Rx's will NOT work with the 9Z in PPM mode because Futaba choose to modify the PPM pulse it sends out from the synthesized module unlike the 9c's Xtal based module. I guess its just enough of being off standard that DSP Rx's go nuts and the Futaba synthesized module that come on the 9Z are the only Tx to have this problem.

My problem is I waited and waited to upgrade from my trusty 9C and purchased a 9Z from Tower and 2 days after I ordered it the 14Mz came in and with Towers good return policy I deiced to go for the 14Mz knowing I would own it for a long long time. Being new to heli's the 14Mz is a dream come true for programming and backing up. However, I spend most of my time in Hong Kong and I'm getting ready to take the family back to California for our summer vacation so I ordered the new FMA CoPilot with the 8ch receiver to help with my kids learning to fly my back up eCCPM Evo. I used the older CoPilot when I was learning on a Shuttle and it was great so I figured I'd have them flying the Evo-50 with eCCPM in no time. Shortly after I made the order I learned that the 9Z's which use the synthesized module can't use FMA or Berg DSP based Rx's. Now I have 2 problems...

I only have the Berg-5 here in HK and I have tested it with the 14Mz in PPM mode with the antenna fully collapsed and at a distance of 108 feet it appeared to work fine. Even running the AXI motor with the prop removed. Unfortunately I have not yet heard from Futaba and am now wounding if I should go down and buy the parts to covert the eCCPM (Hirobo's SWM) back to a conventional HWM so my kids can enjoy flying where we have a real club and nice environment.

Any help is appreciated. PS: I'm not an electrical engineer so my apologies if my terminology is not correct or consistent.

07-07-2005 Over year old.

HOMEPAGE

JKos
Elite Veteran
Location: City of California in the state of Maryland

SLO-Mike,
> are your taking the pulse readings at the RX?

Yes, I have been collecting the actual output of the receiver right where you would plug a servo in.

> I was wounding if packet rejection was occurring which might be why
> its taking more frames to catch up

Well, most of these tests were done with a DSC connection so I sure hope there was no packet rejection. Also, the behaviors are 100% repeatable which would further suggest that everything was going fine.

> If this is the case it would seem that the lag error is generated at the
> Tx which is odd that it performs differently in different modes.

There are limitations placed on the tx based on the PCM format. The 14MZ is simply being constrained by the PCM1024 format in that mode. In PPM mode there are no constraints on how much the tx can change a pulse length between frames. Most of the tx behaved very well in PPM with one-frame, full changes of pulse length. The 9C Super and 7C still display their smoothing effect in PPM mode.

> Can you remember if the pulses were identical to the 9C with the 9C
> using a conventional Xtal based module?

My recollection is that the PPM signal from the 14MZ was the same as the PPM signal from any of the other transmitters. Now, that was looking at the output from the trainer port in PPM mode at the same time as the output of an FM receiver so I did not directly observe the RF signal being transmitted.

I'm surprised someone somewhere hasn't tried the 14MZ with the CoPilot and reported back here on RR. I believe it has been reported that it works just fine with the Berg receivers.

- John

07-07-2005 Over year old.

cdyckes
Veteran
Location: Nr. Yeovil, Somerset - UK

SLO-Mike,

I had the common problem of the 9Z synth TX module not working with some PPM receivers (Jeti for one). The 14MZ in PPM mode works perfectly with every PPM Rx I have but that doesn't include a Berg (don't seem to have those in the UK).

Colin

07-07-2005 Over year old.

AirWolfRC
Elite Veteran
Location: 42½ N, 83½ W

Without knowing the architecture used in the various computer transmitters, it's a bit like the blind men describing the elephant. Each has a different interpretation depending on which part each is examining.

I will assume that all test are in pcm mode and eccpm.
Which channels are produced when from output of the receiver?
Which channels have a coincident leading edge?
Are they, in fact, well behaved (updates happening in the same frame)?
Or do the delays show up in eccpm only?

Computer radios take stick inputs and convert to digital for all operations. Does the digital mixing required for eccpm bog down the processing so that some channels only get updated on subsequent frames? maybe the stick sampling is asynchronous from the processing? Which is asynchronous from the output register sampling and modulation data stream? Maybe a change in channel 6, for example, gets mixed with channel 2 (eccpm) and as such, channel 2 will only see the update on the next frame

I don't have the answers, only questions at this time.

Wolfgang

07-07-2005 Over year old.

HOMEPAGE

JKos
Elite Veteran
Location: City of California in the state of Maryland

> I will assume that all test are in pcm mode and eccpm.

Answered above when you asked before.

> Which channels are produced when from output of the receiver?
> Which channels have a coincident leading edge?

Answered by the graphs which look like this found in this thread:

> Are they, in fact, well behaved (updates happening in the same
> frame)?

On some radios, yes; on some radios, no. Answered by graphs which look like this found in this thread:

> Or do the delays show up in eccpm only?

Good question. I did not test for non-eccpm applications as these issues do not cause a problem for those machines (no control interaction is created).

> Does the digital mixing required for eccpm bog down the processing

On some radios this does appear to be possibly true.

> maybe the stick sampling is asynchronous from the processing?

I would think not.

- John

07-08-2005 Over year old.

AirWolfRC
Elite Veteran
Location: 42½ N, 83½ W

The pulse coincidence is like one of your other traces showed.

This is what had me going.

As for computer input, the systems should be able to sample the sticks and switches in a lot less than 50ms. Do they?

If not, then a number of compromises (like the problems detected) can be the case.

If so, then a lot of these problems should not exist.

Depends on how fast the A to D is. After that, depends on how fast the cpu is.

Today's technology allows operation much faster than needed here. Was it used? The skew and variable latency you detected seems to say no.

More questions, not enough answers.

Wolfgang

07-08-2005 Over year old.

HOMEPAGE

SLO-Mike
Heliman
Location: Morro Bay & Hong Kong

Hi guys, thanks for the feedback. I do have several Berg-5 II DSP Rx's and did test one of them

At 108 feet back with the 14Mz antenna fully collapsed it worked fine. It exhibited all the normal startup symptoms of when you power on the 14Mz then the Berg-5 Rx, there is that delay as it looks for the PPM signal on its set frequency and then WHAM the servos snap into position.

I gathered Futaba might have fixed this problem they had with the 9Z synthesized module, but was not sure.

Chris thanks for the feedback on the FMA. Seems FMA thinks the 14Mz is just like the 9Z as they told me it would not work after I had already purchased the FS8, not to mention my other FMA Rx's that possibly would not have worked. They don't even have a footnote on their website about this.

Futaba did respond today and slipped right around the point of the question:

Thank you for your recent e-mail.
The PPM mode is the same in all Futaba transmitters.
Sincerely,
John G.
Product Support Lead Technician
Futaba Programming Technician
Great Planes Model Distributors

That was not what I had asked by a long shot....

07-08-2005 Over year old.

HOMEPAGE

AirWolfRC
Elite Veteran
Location: 42½ N, 83½ W

I don't know if this will help any but I recall hearing something about FMA having problems with any RX that sends sumultaneous pulses out to it's servos.

Sumultaneous or coincident pulses is not something you expect in any FM (PPM) mode

Wolfgang

07-08-2005 Over year old.

HOMEPAGE

JKos
Elite Veteran
Location: City of California in the state of Maryland

> Sumultaneous or coincident pulses is not something you expect in
> any FM (PPM) mode

You are correct. It simply can't happen.

Wolfgang,
All but a few plots are for PCM. The one you posted just above is PCM.

- John

07-08-2005 Over year old.

JKos
Elite Veteran
Location: City of California in the state of Maryland

Wolfgang,
Here is a quick run down of how the various PCM rx output the pulses.

Code

Futaba G3

         1                  1          

         2                  2

         3                  3

                   4                 4

                   5                 5

                   6                 6

         7                  7

         8                  8

         9                  9

                  10                10

                  11                11

                  12                12

        13                 13

                  14                14



Futaba PCM1024

         1            1

         2            2

           3            3

           4            4

             5            5

             6            6

               7            7

               8            8

        (I don't remember where 9 is.)



JR SPCM

         1            1

          2            2

           3            3

            4            4

             5            5

              6            6

               7            7

                8            8

        (I don't remember where 9 is.)



Airtronics PCM

         1            1

           2            2

             3            3

               4            4

         5            5

           6            6

             7            7

               8            8



FM (Any brand)

         1            1

          2            2

           3            3

            4            4

             5            5

              6            6

               7            7

                8            8

                 etc.         etc.

Time is from left to right. Channel numbers in the same column represent channels with simultaneous leading edges.

- John

07-08-2005 Over year old.

AirWolfRC
Elite Veteran
Location: 42½ N, 83½ W

Since the manufacturers don't seem to be concerned about the three eCCPM servos getting updated at the same time, how about a delay circuit for elevator and aileron pulses which forwards the pulses to the servos when the pitch channel pulse comes through?

A nice litle STAMP project. Two 8-bit counters that clock at 2Mhz. Up for input and down for output when triggered by channel 6 aught to do it giving 3000 count resolution capabilities.

That would synchronize within a frame anyway.

Wolfgang

07-08-2005 Over year old.

HOMEPAGE

JKos
Elite Veteran
Location: City of California in the state of Maryland

> how about a delay circuit for elevator and aileron pulses which
> forwards the pulses to the servos when the pitch channel pulse
> comes through?

Already thought of that and done it.

It is not a perfect fix, however.

1) It causes increased control latency. Although, this would most likely be offset by having a swash that behaves properly.

2) The channels do not always change in the same order. Any way you pick to do the delay will not always be the right delay.

3) Aligning the pulses can cause problems with power dropouts. A few guys have had problems when using super-duper. high-speed. high-torque servos with the 14MZ and the Stylus. When all three servos start moving at the same time, it causes quite a load on the power system.

The best answer I can come up with is an on-board eCCPM mixer. Now, you may say, "Hey, that already exists with the Helitronix mixer." Yeah, it does, but look how big it is, it's expensive, and I bet it has a good bit of latency too. Such a device could be made much smaller and work really fast. It could easily fit in a small case like the current TJ Pro.

An on-board device would have the following advantages:
1) It doesn't matter how the channels from the receiver come in or are updated since the mix would be done on whatever comes in and each channel that comes in is independent of the other channels. (You would set the tx to a standard swash setting.)

2) Whether to have the output pulses occur simultaneously or immediately after one another could be configurable.

The only downsides I can see are adding another point of failure on the heil itself and slightly more latency.

- John

07-08-2005 Over year old.

AirWolfRC
Elite Veteran
Location: 42½ N, 83½ W

Doing a programmable on-board eCCPM mixer sounds like a STAMP project.

Yes, latency will allways be there but variable slew sounds like the real problem which this kind of device will address.

Wolfgang

07-08-2005 Over year old.

HOMEPAGE

JKos
Elite Veteran
Location: City of California in the state of Maryland

> sounds like a STAMP project

I admit that I haven't kept up with STAMP progress in the last year or so, but last I knew, they were pretty slow compared to other options such as PICs.

You know, the other answer is... Get a 14MZ.

(Oh, and you need a G3 rx for each heli or you won't get the benefits of G3.)

- John

07-08-2005 Over year old.

AirWolfRC
Elite Veteran
Location: 42½ N, 83½ W

A STAMP is just a PIC with an OS. If you like the PIC then use it instead. Still cheaper than a 14MZ.

Wolfgang

07-08-2005 Over year old.

HOMEPAGE

JKos
Elite Veteran
Location: City of California in the state of Maryland

Hey, you're right. I was just looking at the Parallax web site and they do have versions using a PIC. They have other versions using other processors which are much faster (up to 4.75 x). Hmm...

I know how to program PICs, though, so I really don't need the STAMP aspect of it.

> Still cheaper than a 14MZ.

That's for sure!

Another answer is that perhaps we are over analyzing the issue. Obviously there are pilots doing freakin' amazing things with all these radios and I don't hear them complaining.

- John

07-08-2005 Over year old.

JKos
Elite Veteran
Location: City of California in the state of Maryland

You know, with an on-board device, one could even completely compensate for servo variations. For example, each servo could have its own, say, 10-point curve for correcting non-linearities.

I foresee a small on-board device (again, about the size of a TJ Pro) with a seperate programming unit.

- John

07-08-2005 Over year old.

6 pages [ << < 1 2 ( 3 ) 4 5 NEXT >> ]

16016 views

POST REPLY

HeliHobby	.	Ron’s HeliProz South	.	Century Helicopter
	.		.

Radio - Servo - Gyro - Gov - Batt > TX/RX eCCPM Output Test Results

UPDATE SCREEN PRINT TOPIC

Advertisers

Subscribe to This Topic