UAV receiver mode

Unmanned Aerial Vehicles require a device that allows the onboard computer to take control of the servos. The same device also provides a way of overriding the onboard computer and taking manual control of the model. Typically the way this is done is feeding all receiver servo signals as well at the computer generated servo signals into an electronic switch which will select one of the two signal sources. This switch in most cases is controlled by channel 9. This allow the UAV operator to take control by changing the state of channel 9.

My proposal for the UAV receiver mode is as follows… The receiver produces all servo pulses CH1 to CH10 in normal mode. In UAV mode the pins for CH9 and CH10 are reconfigured and become an RS232 port.

When the receiver is configured for UAV mode, it internally checks the state of the received channel 9 and determines which data source will be used to generate the servo signals. If channel 9 is off then the PCM data will be used to generate the servo pulses for CH1 to Ch8. If channel 9 is on then RS232 data will be used instead. This RS232 data are generated by the onboard UAV computer and are fed directly into the receiver. Thus no additional devices are required between the receiver and the servos. As a bonus the receiver also produces RS232 data from the incoming PCM signal which can be read by the onboard computer. This also means that the receiver could be connected to your home PC to provide controls for a flight simulator. This could be done wirelessly since the receiver will pick up the transmitter signal, or you could have a DSC cord between the TX and the RX.

Angelos,

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 few weeks ago I posted on RCGroups:
"The price of a computer radio is highly dictated by features that are mainly just software. I own a Futaba FC-16 witch has average features but I find them rather limiting. Here are a few examples of what I would like to have:
- For a motor-glider I would like the upper half of the
throttle to control the motor speed while the lower half the flaps.
- I would like the landing gear to move slowly
- I would like an "arming switch" for the throttle
- ....
Of course, one could install circuits in the plane that do all that. But
should I be not possible and more sensible to do this on the emitter side?
I was thinking of picking up the PCM signal just before it goes to the RF
circuit, feed it to a processor and let it generate a new PCM signal.
I would be surprised I am the first to think about this, do you know of such a project described somewhere?"

Some people thought it was a good idea, others told me it would be better to buy multiplex that has these features "a decade ago"

I did some more research and found your project. So on top of the of-the-shelf product there will be soon your solution...

I am not sure what I will do, but for the time being I am interested in
finding out how PCM1024Z works.

When it comes to hobby stuff I allow myself to suffer heavily form the
not-invented-here-syndrome. In fact I believe this is the very basis of our
hobby; almost everything can be bought, but it is just fun to be creative
and make things.

Frederic

Yesterday I connected my radio to the line-in of my sound-card. I could see that a signal comes in but the downloaded dll happily crashes.
Recompiling the source seemed not so straightforward as it seem to come from a C++ builder project. This evening I will see if I can make an application that takes the signal and dump it to a file.

Frederic

Frederic

Nice to try to get that running.
I'm busy figuring out how this all fits together, as it looks now Rother must be mistaken or he is talking about another (old??) Futaba protocol. Then the developer's code, the quote you found quote plus Angelos' should bring us quite far.

Frederic

Angelos is talking about a computer inside the helicopter, that is BEHIND the receiver, completely taking over control. I don't think he is aiming at putting more control code inside receiver for fancy channel behaviour, he just uses an existing switch to toggle the channel 9.

The mail you quoted is excellent! This is the only place so far that details the structure of the packets. And even more, it describes how the ECC is created, what the values are for every bit. It even contains a note on the location of channel 9 although that one seems buggy.

I'm working on a nice figure that puts all values we found so far together in a nice overview. Most data is there now, and things fall together nicely. Only the source from the autonomous helicopter site has still to be reverse engineered.

I think we're getting close to checking all we found and figuring out the last bits. There the propro program or something similar might come to good use. Unfortunately I don't have a C compiler on windows, but maybe I will try to compile the code on my macintosh. The only thing I need to figure out is how I read out the mic input, the PC code obviously won't work for that!

I forgot to post this, but here is the improved version of the annotated propro code. I think I have all comments in place but I did not check everything over again, so maybe there's still some inconsistency in my comments. In my head it's clear now so I go further

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

// The SmartPropo project is concerned with reading out the
// transmitter via the trainer port to a computer.
[Edited, some stupid remark was left here..]

// 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 (408us) is sync
sync = 1;
bit = 0;
bitstream = 0;
bitcount = 0;
datacount = 0;
return;
// NOTE apparently we can trigger both on 408us LOW as 408us HIGH pulse
// but the sync will fail on the second half.
}

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;
// weird, they are flipping all bits, but they also shift them.
// this goes right (all 1's or all 0's at the rightmost bits
// because they shift always >=22 bits to the right, clearing
// enough bits in the top end to stay out of trouble next round.
bitcount += width;

// I first thought they were preventing buffer overflow here but it seems something else. // apparently they are checking the first 6 bits of the header.
if (sync == 1)
{
if (bitcount >= 6)
{
bitcount -= 6;
if (((bitstream >> bitcount) & 0x3F) == 0x03) {
// first 6 bits are 000011 then odd frame
sync = 2;
datacount = 0; // odd frames put data at head of data block
} else if (((bitstream >> bitcount) & 0x3F) == 0x00) {
// first 6 bits are 000000 then even frame
sync = 2;
datacount = 16; //even frames put data halfway the datablock.
bitcount -= 2; // AND we drop two bits ???
} else {
sync = 0;
}
}
return;
}

// we passed the header, and we're now in sync mode 2
// 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.
// FredericG found more accurate contents for the data array
// Every 24bits data contains 2bits of auxilialy data,
// 4bits of difference data, 10bits ofposition data,
//and 8 bits of error correcting data.
// NOTE that they ignore the differnce data here, they only use the
// absolute bits. and they also ignore the error checking.
// Therefore they wait two frames, as each frame has only one half of the
// absolute data.
switch (datacount) {
case 3: if ((data[0] >> 4) != 0) Position[2] = (data[1] << 4) | (data[2] >> 2); break;
case 7: Position[3] = (data[5] << 4) | (data[6] >> 2); break;
case 11: if ((data[0] >> 4) != 0) Position[4] = (data[9] << 4) | (data[10] >> 2); break;
case 15: sync = 0;
case 19: Position[1] = (data[17] << 4) | (data[18] >> 2); break;
case 23: if ((data[16] >> 4) != 1) Position[0] = (data[21] << 4) | (data[22] >> 2); break;
case 27: Position[5] = (data[25] << 4) | (data[26] >> 2); break;
case 31: break;
case 32: sync = 0;
}
}

I have compiled a win application that should read the input on the line-in or mic input (check with audio recorder to see if something comes in) and dump it in a file.
It is readable text and shows the transitions times, ready to feed to the
ProcessPulse() function. The first transition is from High to Low. Pass as parameters the number of transitions to log and the file where to dump.
WARNING: this is still a quick-and-dirty version and I did not have the time to check whether the PCM can be read from it. If you try it, let me know. Probably, this weekend I will have more time.

Question is: how do I add attachments to send it to you?

Frederic

Hi

I posted a first version of a report on the PCM1024Z format on my website

http://graphics.tudelft.nl/~wouter/pcm1024z.pdf

I think this nicely lines out what knowledge is available on the web now, and what we have to figure out.

I'm waiting on your comments!
Mmmm one extra section could be a summarization of the things to figure out...

Hi Frederic

Sorry for the late reply, was too busy We PM-ed already on this.
Great that you got that working, that may become very handy. For the moment I think I prefer to see samples instead of pulse times, I need to visualize things and pulse times are hard to read. I will try using my audio sampler, should work straight away on my macintosh.

Hi Wouter,

Very nice document, I will study it closely...

For the moment I think I prefer to see samples instead of pulse times, I need to visualize things and pulse times are hard to read.

Sure, pulsetimes are what SmartPropo takes as an input, but are not handy when analyzing a sample manually.

I will try using my audio sampler, should work straight away on my macintosh.

What does your “radio sampler” look like?

Frederic

I'd be happy to decode the manual let alone the signal

Don't Email me as I wont reply - PM Only (spam countermeasures)

This might give some interesting problems to the servos, as smooth interpolation would be hampered by such 'fake' pulses.

Perhaps! But servos need to be updated frequently. If they were updated only every 28ms they would loose torque compared to the standard 20ms PPM frame time. Since a new position update is not available within 14ms the receiver can only repeat the existing one.

new position=old position + pcm_delta - 8

I disagree with the above.

new position=old position + diff_array[pcm_delta]

what's inside diff_array is for you to work out

I have the impression you are pretty close; I suppose analyzing real samples can easily fill the blanks.

I disagree with the above.

I am not surprised about that; Angelos mentioned that he spent quite some time finding out how the differential information was encoded.

Here you could perhaps use your setup that you used to measure latencies. You could apply a step to one of the channels. With some luck, this gets first reflected in a differential value. In the next frame the absolute value will be available. Different step amplitudes should give you different points in the "diff_array". Perhaps when the step is too big there is longer a relationship like "new position=old position + diff_array[pcm_delta]" ...

Frederic

FredericG,

The differential corrections were the hardest bit to do. If they are not right the servos move jittery. I worked out the values with a 35000GBP (US$58000) LeCroy scope that we have at work. There are cheaper ways doing it but since the scope was available it was the simplest option for me. I wrote a few simple scripts for the scope (yes it has a build in win2000 PC in it) so that it simultaneously measures the pulse from an original PCM receiver and from my decoder. The scope plotted on the screen the error between the two pulse widths as I was moving the joysticks. Then the graph was level at zero, I knew I had the right values.

Hi all

Thanks for all the comments on my report so far. I'm gonna check them in detail

One answer is easy
> What does your “radio sampler” look like?

DUHHH don't they support tiff's here I had to convert above image to jpg to get it working

Hi Angelos

Ha great to hear that, I was already amazed by this and had a note on that in the doc.

About figuring out the values, yes maybe we have to go your way... I prefer another way because I don't like comparing analog values and trial and error. Let's rethink the options.

I prefer another way because I don't like comparing analog values and trial and error. Let's rethink the options.

I’m afraid you have no options here. These are internal values in the receiver (they are never transmitted from the TX to the RX) and unless you have access to the read protected firmware measuring the pulse width is the only way. The pulses are generated locally at the receiver and they are very sharp and clean. If your sample sufficiently faster that the period of one step then you can work out the exact values for the table.

By the way… it is not really trial and error. All you need is a microcontroller to measure and hold the pulse width of two consecutive pulses and also keep a record of the 4bit differential data. I know it is a lot of effort to do that but who said decoding PCM1024Z was easy!

Hi Angelos, Wouter,

I still feel that my proposal could provide an easy way to find out an important part of the “diff-array”. Am I terribly wrong?

Suppose we have 3 successive frames, 1, 2 and 3. A (small) step was applied between the generation of frame 1 and 2 for a given channel. For that channel frame 1 and 3 contain the absolute values A1 and A3 and frame 2 contains the differential value D2. Then should A3 = A1 + diff_array[D2]

Frederic