Recoder - advice needed

[arneansper]

Hi!

First some background. I put together small setup that helps to visualize the flight of the plane: http://home.cyber.ee/arne/flyhow/flyhow.html. It works well, but has two shortcomings:

1) The TX must be connected to the camera. Doing a proper discus launch while connected is almost impossible.

2) The resolution of the PPM decoding is not so great. The signal is encoded at 48kHz and measuring the position of signal edges requires some interpolation that might not be very precise.

Now I have spare RX and crystal for my channel. Whilst it might be possible to tap the RX and get the undecoded PPM signal out from RX, I would not like to hack the precious Schulze 835 receiver :)

Instead I would like to build a small circuit that will be connected to receiver outputs, will measure the servo positions, will encode them using some digital encoding scheme (not PPM) that can be safely recorded using 48kHz digital audio recorder and easily decoded on PC and will output the signal so that it can be recorder using camcoder.

I was thinking to use some small and cheap microcontroller with minimal extra hardware. Precision is important - if possible I would like to get more than 1024 steps. Minimum number of channels is four. Seven would be nice - it will then cover full-house electric gliders too. Encoding scheme does not have to be standard - I will write the decoder too.

So, I'm looking for suggestions to what uP to use (existing code for decoding multiple PPM inputs is big pluss :)), what digital encoding scheme to use, and any other things that you could think off.

regards,
Arne

[arneansper]

Did some research. Simplest solution seems to be to use the PIC based smart PPM decoder: http://www.rcgroups.com/forums/showthread.php?t=298197.

I hope that Schulze updates the servos not at the same time but one-by-one. Then I can just OR all the signals together to restore the original undecoded PPM signal and then feed it into PIC.

I will replace the output routine of the decoder and just output the values of channels in binary form. Seems that about 6 channels can be fitted into the sync cap.

regards,
Arne

[vintage1]

Of all receivers I would not rely on the schulze to output stuff serially.

Its got a lot of smart decoding...

why not get a simpler receiver and pick up the clock signal going into the shift register?

Essentially all the PIC has to do then is have a high speed counter, whose output is gated by and transferred through to a memory location on every negative transition of the clock pulseunder interrupt. These values will be the pulse widths of each servo in turn, and a bigger one for the sync pause.

Then the processor can sort them out into channels in the main loop, and do whatever else is needed.

As far as the Schulze outputs go, I'd pull in an 8bit wide word from the whole suite of outputs, using an exclusive or setup on all of them to provide an interrupt-on-any-change function.

Then you can use the changing bit to decide what has happened where, in conjunction with a high speed clock to work out the taime between transitions...

That will work whether the outputs are one after the other or all together.

[arneansper]

Of all receivers I would not rely on the schulze to output stuff serially.

Its got a lot of smart decoding...


Good point. I brought the receiver to work and cheked the output with two beam oscilloscope. It does not output them at the same time (that would be really bad for battery too if all servos would start moving at the same time and create unneccesary current peak), but there is also no delay between them. As soon as one channel is processed it starts outputing next one. So my idea about OR-ing them together does not work. And XOR-ing them together does not work too because two changes that happen at the same time cancel each other.

But now, when I'm sure that they are not output sequentially I can just poll them one by one jumping from the one that went down to next that went up. During the sync pause after last channel I will output the digital code and start the scanning from first input.

Thanks for thinking along.

Arne

[vintage1]

Good point. I brought the receiver to work and cheked the output with two beam oscilloscope. It does not output them at the same time (that would be really bad for battery too if all servos would start moving at the same time and create unneccesary current peak), but there is also no delay between them. As soon as one channel is processed it starts outputing next one. So my idea about OR-ing them together does not work. And XOR-ing them together does not work too because two changes that happen at the same time cancel each other.

That is what a normal shift register decoder does as well.

But you SHOULD get timing blips between them if you XOR them carefully and use propagation delays sensibly.

But now, when I'm sure that they are not output sequentially I can just poll them one by one jumping from the one that went down to next that went up. During the sync pause after last channel I will output the digital code and start the scanning from first input.

Thanks for thinking along.

Arne

Anoher possible way to treat this is to feed the channels. and a digital output into an 8 bit comparator and use ITS output and do 'interrupt on not equal' followed by timer store, restart, and a setting of the digital output to equal the new 'input'...this clearing down the interrupt.

You can then pick off the stored timer values in the main loop as your position codes.

Ive no idea whats in a modern PIC in terms of interrupt generation kit, or 8 bit comparators...;)

[arneansper]

I remembered a PIC based mixer that I made long time ago (source code of the mixer is available from http://www.eagleairaust.com.au/) It did something very similar to what I plan to do. Modifications were quite easy and I just finished testing the code under MPLAB simulator (nice piece of software, especially the virtual logic analyzer). I still have the now useless mixer, so I will just reprogramm it.

The code and test inputs are attached, if somebody would like to take a look at them.

BTW, my PIC is 16C84, but it was not listed under the devices in MPLAB. I selected 16F84 as a replacment, hopefully that ok.

regards,
Arne

[arneansper]

Ok, the recoder is working. Only decoder needs to be done. I will probably add some new visualization options too.

Bits are little bit distorted but I think there will be no problems decoding them.

Arne

[arneansper]

I encounter 8us jitter in measurements. Now when I think about it, it seems unavoidable when the inputs are polled. The code to detect that input goes from low to high looks like this:

loop btfss PORTB, 0
goto loop

btfss is 1 or 2 cycles and goto is 2. Signal can change during any of those cycles. And there are two tests like this - first for raising edge and second for falling.

8us is too much. The error is almost 1%!

Interrupt latency on the other hand has only one cycle of uncertainty - so the error will be only 2us. Brute force option would be to go from 4MHz to 16 or 20MHz - 2us is almost tolerable.

I looked at the datasheets more closely and seems that 16F627/628 is much better choice for my application - it has 16 bit timer and CCP module. It is possible to capture six channels using interrupts by using RB0 to drive external interrput, RB3 to drive timer1 capture and use RB4-RB7 interrupt-on-change feature.

I will give it a try.

Arne

[vintage1]

'Interrupt on change' is always the most predictable way to detect an edge.

As long as its a low level processor, and not some mighty mega pipelined cached Intel monstrosity...:D

I guess thats why we HAVE PICS - the bigger processors are too sluggish and variable in response..

[arneansper]

Went to 12F629 chip - it has 16 bit timer and can run at 20MHz (currently at 8MHz). I use 2x4 OR logic chip to OR all channels together into single PPM stream that is fed in via single pin - so if someone wants to feed the undecoded PPM signal from receiver it can be done. Using Schulze the space between channels is only 10us, but it is OK at 8MHz. Jitter is down to 3 clock cycles, which is as good as it gets :)

I also a wrote driver for Parallel Port Joystick, so you can connect your transmitter to PC without cables - it should be good if you do not have a trainer output - I think most of the pistol grip car transmitters come without.

I will now complete the FlyHow update and then publish the source and documentation. The PPM decoder is pretty generic and can be used on any PIC that has 16 bit timer and interrupt-on-change capability.

regards,
Arne