I already had asked about this a few times in several threads, and FredericG proposed to make a separate thread of it. So here we go!
For those not knowing what PCM 1024Z is, it is about the data format of the radio signals that travel from the Futaba transmitters to the receiver. This is not only stick data but also fail safe information and error checking data. Furthermore some of the data is compressed. All this data is grouped digitally into packets called frames. The question is, how does PCM1024Z look like exactly, what compression and coding is used, etc?
I think the first step to take is to collect all data available. I will soon post the things I found already. (have to do shopping now, before they close )

Angelo claims to of decoded it and made a working reciever . Tells us what you know Angelo

Tony R.
Sceadu 50 SWM
Webra 52 AAR
9z,T9chp,401,601
Hirobo Bell 222
Webra75AAR

Two important sources of info are here

Rother, P. (2000). The million dollar question: PCM or PPM? Possibilities, performance? Translation Wim Hanssens.
http://www.aerodesign.de/peter/2000/PCM/PCM_PPM_eng.html
Futaba (2000). PCM 1024 System Info. www.futaba-rc.com/faq/faq-pcm1024.html

I did some latency measurements myself, and also describe the basics of PPM and PCM.
http://graphics.tudelft.nl/~wouter/publications/pasman03i.pdf

I heard about US patents on it, and checked it out. Didn't find PCM 1024Z yet but maybe it's there. What is there is

Patent 4,916,446, april 1990. http://www.uspto.gov/. "Remote Control Device". Not sure but this seems PCM 1024, the predecessor of 1024Z.

Patent 5,850,597, december 1998. uspto.gov. Radiofrequency module for radio control transmitter.

Ian Hirschsohn (2003). Everything You NEVER Wanted To Know About Radios. http://www.torreypinesgulls.org/Radios.htm

Earlier messages by Angelos
http://www.runryder.com/helicopter/t45470p1
Unfortunately Angelos only tells us that he did the decoding, but nowhere I found his results.

I also heard on RR from Angelos (http://www.runryder.com/helicopter/t66907p5/) about the autopilot project, and they have source code there that is supposed to do the decoding. Not yet checked in detail, maybe they just use PPM. No manuals so this would need reverse engineering to find out the info we want.
http://cvs.sf.net/viewcvs.py/autopilot/onboard/rev2/pcm.c?rev=HEAD&content-type=text/vnd.viewcvs-markup

Coert also seems to know more, check http://www.runryder.com/helicopter/t66907p5/

Angelos also gives some info in this thread. He reports channel 1 and channel 2 pulses are generated simultaneously in PCM receiver.

Tony
Angelos seems not going to tell more, he wrote in the homebrew receiver

Quote

Since I am considering the possibility of manufacturing PCM receiver I don’t want to rush and publish the protocol, something which I could regret later. Once the information is on the internet it is just matter of time until it reaches the competition. Regarding the transmitter I don’t know how it will be implemented yet. If I use a second chip to encode the protocol, the process will be transparent to the main software which will not need to know how the protocol works. If the main CPU does the protocol encoding too, then it could be a BIOS function or a precompiled library. I may even publish the source code for both encoder and decoder if I decide not to go ahead with the receivers. -Angelos

I mailedPeter Rhoder for more info, earlier I already mailed with him and he did some private communications with Futaba for that excellent web page of him. I hope he has some detail info on the differential coding, CRC and extra-data block.

There is an interesting project here:

http://rcp.cside.tv/Rc_hp2/fms/SmartP_e/SmartPropo_Manual_e.html
(thanks Risto for the pointer)

It is a windows driver that uses the soundcard of a PC to sample a PCM signal from a Futaba radio. The decoded signal is afterwards fed to FMS. The decoding of the signal is very basic, I think, but perhaps this code can provide an easy was of recording signal samples. The source code is available and I was thinking about modifying it so that a sample of a few hundred frames could be stored in a file.
There is also a newsgroup available on this site, but I did not find the time to go to the posts yet.


Frederic

Hi Frederic

Nice link! I skimmed the software, it's poorly documented and will need some reverse engineering. The code is quite clean, short and straightforward.

I'll give some hints to get you going.

The official Futaba spec for servo pulses: 920usec (min), 1520usec (neutral), 2120usec (max). Since Futaba is the market leader I would recommend that everyone follows this spec if they are developing any type of servo signal generator (PCM decoder, gyro, governor, etc).

100% ATV produces 70% of the total servo movement and a pulse in the range 1098usec to 1941usec.

According to one of their service engineers, the service manual recommends that if the servo pulse is less than 919usec or 2121usec the decoder CPU crystal frequency must be measured and verified.

From the above I calculated that the pulse change is 2120-920=1200usec (1.2msec)

This 1.2msec is divided in 1024 positions thus 1.1718usec per step.

Here is another way to verify this…

Futaba uses a 3.4133MHz crystal for the PCM decoder CPU. This frequency I believe is internally divided by 4 and generates the clock for the hardware timers/counters that generate the servo pulses.

3.4133MHz / 4 = 853325 Hz, the period of this is 1 / 853325 = 1.1718usec

also this 3.4133MHz signal can be divided by 512 to give a 6.6666KHz clock. The period of this is 150uses which is the bit rate of PCM1024Z…

Isn’t it wonderful when numbers make sense!

For my PCM decoder I use a custom made crystal at 13.6532MHz which is 4 times higher than what Futaba uses. This higher speed is not required for computations, but because of the configuration of the timers inside the microcontroller that I use this was the lowest frequency that is suitable for generating servo pulse and timing the bit reads.

From what he posted to me , he broke down how the signal operates , How is telling you how the signal operates compromise his reciever design? You not asking for the schematic of his design ?

Dam ,Angelo you beat me too my post, good man

Tony R.
Sceadu 50 SWM
Webra 52 AAR
9z,T9chp,401,601
Hirobo Bell 222
Webra75AAR

Let me explain my position… I took me around 2-3 months starting from zero, to figuring out the 6b10b encoding, to understanding every single bit of the protocol including failsafe frames, differential corrections, battery failsafe control and the error checking algorithm which nobody has figured out yet. However, once the protocol was known I only needed two weeks to produce a working decoder. My problem is that RF is not my area and I can’t find someone to develop a reliable RF front-end for me and thus produce a complete RC receiver.

Now think about the other receiver manufacturers who are willing to produce PCM receivers. They have a ready design for RF front-end (any PPM receiver will do) and they only need to develop the PCM decoder. If I give out the PCM protocol they could have a product in the market within weeks.

I am happy to help out in this thread and let you figure out the details yourselves. This at least gives me some time to see where I am going. If I decide that manufacturing receivers is not feasible I will post all info I have on this thread.

For anyone who hasn’t seen the photos… here is the prototype PCM decoder

http://www.model-gadgets.com/tmp/pcm.htm

Angelos , Do you know if the information concerning the operation of futabas pcm1024 is available on the patent? If airtronic's has access to it the should it be available to us or someone in the field? Probably a stupid question.

Tony R.
Sceadu 50 SWM
Webra 52 AAR
9z,T9chp,401,601
Hirobo Bell 222
Webra75AAR

tonysrepair,
Coert mentioned once:

Quote
In the meantime I asked myself what the difference would be between PCM1024 (1988, US Patent 4,916,446) and the newer PCM1024Z?

You can download the full patent including figures from the website I mentioned.
I didn't read it in full detail yet but I checked their figures, and there is no failsafe and other bits in this part. Either it's a separate protocol (another patent or not available?) or I just missed it.
As I wrote the patent 4,916,446 is of april 1990. I also remember the year 1988 for this patent so maybe 1990 is the acceptance year. I have no idea how long a patent lasts.

Angelos, I completely understand your position and I don't mind if you don't tell us anything It's only unfortunate for you that we started digging here and that I like to put all results in the open. I can only recommend you to be quick to get to a manufacturer or to find someone able to build the rf part. Did you ask MarkF? He can at least give you the chip number you can use.

The 6b10b coding or whatever its name is seems not a big problem, both source codes mentioned so far make it clear (after reverse engineering which I mostly did already). I have to figure out the exact timings still and a way to write it down neatly. But that's running ahead, I think I will skim the patents first and search some more for info sources.

Quote
Angelos, I completely understand your position and I don't mind if you don't tell us anything

Quote

I have not completed the analysis about the error correction code when I wrote the program. But now I know almost all about the PCM1024 signal. Every 24bits data contains 2bits of auxilialy data, 4bits of difference data, 10bits of position data, and 8 bits of error correcting data. Hence, acutual correction code is ((data[2] << 6) | data[3]) & 0xFF, not data[3]. This code is related to first 16bits, and is generated by this function; -------- int dat = (data[0] << 10) | (data[1] << 4) | ((data[2] >> 2) & 0x0F); int ecc = ((data[2] << 6) | data[3]) & 0xFF; int matrix[16] = { 0x6B, 0xD6, 0xC7, 0xE5, 0xA1, 0x29, 0x52, 0xA4, 0x23, 0x46, 0x8C, 0x73, 0xE6, 0xA7, 0x25, 0x4A }; for (int k = 0; k < 16; k++) { if (dat & (1 << k)) ecc ^= matrix[k]; } -------- If you just want to check the error, you can simply check "ecc". When it is zero, "dat" may be true. If "ecc" is not zero, for example, if it is 0xA1, please compare the "ecc" with every elements of "matrix". In this case, 5th bit may be wrong. For the further error correcting, please refer the technical book about the coding theory. > Another question is , base on your code , your can get 8 channel value. But my > tansmitter is T9Z a 9 channel R/C system. How the chnnel 9 work??? The 9th channel is not proportional channel, it is switch channel (it consists of only "on" and "off"). This data is transmitted on the 18th bit of every frame.

Hi

I think I can resolve some of the confusion about the SmartPropo code and their findings about the "PCM1024" format. In short, they are decoding the TRAINER OUTPUT and not the radio wave format. So properly they are NOT talking about PCM1024 but about some receiver-internal signal.
To see how I come to this conclusion consider the comments I put in their code, to reverse engineer this.

INSERTED NOTE 6nov: I made a few interpretation mistakes. Working on better version, will post it below.



//---------------------------------------------------------------------------

// The SmartPropo project is concerned with reading out the
// transmitter via the trainer port to a computer.
// We found several weird things that seem to mismatch with what we know
// about PCM
// Therefore I conclude that the trainer port data format as decoded here
// is NOT PCM 1024Z.


// ProcessPulse is called for every high-low and low-high flank in the samples
// width is the length to the previous flank (#samples) and input is
// FALSE if the transition is low2high and TRUE if the transition is high2low.
// sampling rate is always 44.1kHz or T=22.6757us.

#ifdef FUTABA_PCM
static void __fastcall ProcessPulse(int width, BOOL input)
{
static int sync = 0;

static unsigned int bit = 0; // last received bit since sync.
// should be equal to input variable I think.
static unsigned int bitcount = 0;
static unsigned int bitstream = 0;

static int data[32]; // 6bit packets received. Don't know why this isn't just byte but int.
static int datacount = 0;

width = (int)floor(width / PW_FUTABA + 0.5);

if (sync == 0 && width == 18) { // more than 18 pulsewidths is sync
sync = 1;
bit = 0;
bitstream = 0;
bitcount = 0;
datacount = 0;
return;
}

if (!sync) return;

// now if width>1 we received more than 1 bit.
// add equal bits to right of the the bitstream
// bitcount keeps track of #bits in bitstream
bitstream = (bitstream << width) | (bit >> (32 - width));
bit ^= 0xFFFFFFFF;
bitcount += width;

// bitstream is an int and so it could overflow if not emptied in time
// so they gonna check if enough bits gathered to continue processing
// bitcount will be lowered as bits are taken out.
if (sync == 1)
{
if (bitcount >= 6)
{
bitcount -= 6;
if (((bitstream >> bitcount) & 0x3F) == 0x03) {
sync = 2;
datacount = 0;
} else if (((bitstream >> bitcount) & 0x3F) == 0x00) {
sync = 2;
datacount = 16;
bitcount -= 2;
} else {
sync = 0;
}
}
return;
}

// if we have 10 bits we have received a new symbol.
// This is a 6B10B block code as they call it,
// which means every 10 bits encode a 6 bit value.
// Why this is useful is still to be figured out.
if (bitcount >= 10)
{
bitcount -= 10;
// look up the corresponding symbol from the table and store it in data array.
if ((data[datacount++] = futaba_symbol[(bitstream >> bitcount) & 0x3FF]) < 0)
{
// only 2^6 out of the 2^10 symbols are valid.
// If we get here we received an illegal symbol and cancel processing.
sync = 0;
return;
}
}

// check if we can calculate some channel positions.
// To do that we join parts of two 6-bit values to make a 10 bit number.
// Today (5nov2003) FredericG found the contents for this data
//

Quote
Every 24bits data contains 2bits of auxilialy data, // 4bits of difference data, 10bits ofposition data, and 8 bits of error correcting data.

Good progress here tonight!
I read patent 4,916,446.
It is a Futaba patent on differential coding only. They talk about 10 bit digital values and 4 bit difference codes. The difference codes are suggested to be allowed to follow an exponential curve, but stupidly the curve goes the wrong direction suggesting even unused values in the 4-bit range (!). I suppose this is one of the blunt errors here. Only 2 channels in decription but they say "However, it is matter of course that it may be applied to a three or more channel systems." Bad English, but I assume they mean that the system can be extended for more channels. It's amazing how bad english they use and how many even totally wrong explanations are done.... No mention of failsafe or CRC.

Please note... once the radio signal is recovered from the RF front-end and fed through the data slicer it is identical to what you get out from the trainer port. Well, the voltage levels will be different, the signal will be a bit more jittery and will have a small phase delay due to the RF conversion and recovery, but it will be the same bit string you get from the trainer port.

Also, although it will be helpful to look at the autopilot and SmartPropo projects do not take everything you read for granted. There are lots of mistakes there. Also none of these projects has any information (well, not correct at least) about failsafe, error detection algorithm, channels 9 and 10, battery failsafe control, and most importantly they don’t make use of the differential correction data.

One question for everyone… why do you want to decode PCM1024Z? Just to say you have done it or do you have a particular use in mind? A PCM simulator interface would be nice and I am working on that.

Here is what I have in mind... I use a spare pin of the decoder microcontroller to select normal mode or UAV mode. In UAV mode the servo pulses for CH9 and CH10 are lost and these pins become RS232 in and out. The decoder produces RS232 data for all channels (including 9 and 10). When CH9 is off the servo channels 1 to 8 are controlled from the incoming PCM signal. When CH9 is on the servo channels 1 to 8 are controlled from incoming RS232 data. This configuration is great for UAV applications and you can also make wireless (or wired though the DSC input) interface with a flight simulator. If you just need a preprogrammed decoder chip for your UAV or simulator interface I will be soon able to supply them cheap.

Hi Angelos

Thanks that you still want to help us Great hints.

> Please note... once the radio signal is
> recovered from the RF front-end and fed
> through the data slicer it is identical to what
> you get out from the trainer port. Well, the
>voltage levels will be different, the signal will
>be a bit more jittery and will have a small
>phase delay due to the RF conversion and
>recovery, but it will be the same bit string you
>get from the trainer port.

Mmm that 's what I thought before reading the SmartPropo code.... If they are right, the Rother reference can't be right at the same time. I will look in the other source code, that makes three. Otherwise we indeed have to measure for ourselves... Thanks for this, this is really useful info! Means we dont' have to check out the receiver in detail, we can also put the trainer port on the scope if necessary.

> Also, although it will be helpful to look at
> the autopilot and SmartPropo projects do
> not take everything you read for granted.
> There are lots of mistakes there. Also none
> of these projects has any information (well,
> not correct at least) about failsafe, error
> detection algorithm, channels 9 and 10,
> battery failsafe control, and most
> importantly they don’t make use of the
> differential correction data.

For the Propro code yes that's clear... Maybe the other project gives more info.



> One question for everyone… why do you
> want to decode PCM1024Z? Just to say
> you have done it or do you have a
> particular use in mind? A PCM simulator
> interface would be nice and I am working
> on that.

I was looking into the latency of the system and got weird results. Now I want to figure out what they are doing under water.
Maybe we get good ideas on where the latency problem is, and then we can think about solving it. Then we (you?!) might build a low latency futaba compatible PCM receiver. I already have suggested numerous ways to improve the receiver but most were probably bypassing the Futaba mechanism. Now if we know the Futaba mechanism we can fit our ideas to the existing system and combine them !


> Here is what I have in mind... I use a spare
> pin of the decoder microcontroller to select
> normal mode or UAV mode. In UAV mode
> the servo pulses for CH9 and CH10 are lost
> and these pins become RS232 in and out.
> The decoder produces RS232 data for all
> channels (including 9 and 10). When CH9
> is off the servo channels 1 to 8 are
> controlled from the incoming PCM signal.
> When CH9 is on the servo channels 1 to 8
> are controlled from incoming RS232 data.
> This configuration is great for UAV
> applications and you can also make
> wireless (or wired though the DSC input)
> interface with a flight simulator. If you just
> need a preprogrammed decoder chip for
> your UAV or simulator interface I will be
> soon able to supply them cheap.

Mmmmm UAV unmanned areal Vehicle? Whatever ... you mean you send rs232 to the transmitter? And how about the return signal from receiver to transmitter? Or is it one-way rs232?. I still dont see where you're heading for. I can see rs232 is nice for controlling a computer in the heli but then you want two-way communication I guess.
For this moment I was looking into latency, not into UAVs. Maybe you have a more specific plan or goal?

Leaving the latency generated from the computations in the TX aside here are the figures for the protocol latency…

Futaba gave priority to channels 5 and 6 followed by 1 and 2. I think this choice is related to CCPM swashplate control.

Each frame lasts either 28.2msec or 28.8msec depending on the sync type which defined the data it carries. However the servos are updated every 14.2ms aprox which means that every servo receives two pulse within the period of one data frame.

The first servo pulse for channels 5 and 6 is produced 7.120ms after the start of first data bit of the frame. The first servo pulse for channels 1 and 2 is produced after 9.480msec from the start of the first data bit. (Note that this is the first data bit, not the start of the sync). The second pulse which is of identical width is produced 14.16ms after the first pulse.

Channels 3and 4 get their data from the third subframe and thus they have latency similar to 5 and 6 if it measured from the first bit of the subframe. Since each subframe has it’s own error detection data, the radio could produce the data for this subframe just in time to be transmitted. However, if we assume that the radio computes all channels before the frame starts we need to ass 12ms to this latency figure.

This leaves channels 7 and 8 which are generated 8.4ms after the first bit of the 4th subframe. Again we can assume that the radio computes the data for this subfrmae just in time to be transmitted so no additional delay is present. Otherwise there is an additional 18msec from the start of the frame.

I bet I have now confused you even more, but let me put it this way… as a protocol PCM1024Z is not slow at all as long as the transmitter calculates the channel data just in time to be fed into the corresponding subframe. However you get only 35 possition updates per second.