RunRyder RC
 4  Topic Subscribe
WATCH
 2 pages [ <<    <    ( 1 )     2     NEXT    >> ] 6019 views POST REPLY
Scorpion Power Scorpion Power
12-01-2003 09:40 PM  13 years agoPost 1
FredericG

rrNovice

Belgium

My Posts: All  Forum  Topic

This thread is a branch of the “PCM1024Z part II” thread that focuses on reverse engineering the PCM1024Z protocol.
In this thread we can discuss HW and SW issues regarding PCM coding and decoding.

Frederic

PM  EMAIL  HOMEPAGE  Attn:RR  Quote
12-01-2003 11:45 PM  13 years agoPost 2
E.Klinke

rrNovice

71088 Holzgerlingen, Germany

My Posts: All  Forum  Topic

Hi, is there anyone who is working on a micro controller implementation of Futaba PCM1024 decoding? I am working on a solution for an 8051 architecture micro in assembler.

PM  EMAIL  Attn:RR  Quote
12-02-2003 01:15 AM  13 years agoPost 3
E.Klinke

rrNovice

71088 Holzgerlingen, Germany

My Posts: All  Forum  Topic

Is there anyone out there interested in discussing implementation of PCM1024 decoding on an 8051 architecture platform?
I have a working implementation in assembler

PM  EMAIL  Attn:RR  Quote
12-02-2003 07:49 AM  13 years agoPost 4
Islander

rrNovice

San Jose, CA

My Posts: All  Forum  Topic

Hi:
I am trying to do this on a different CPU, e.g. MIPS. Besides, I am considering implemeting this decoder on a 8051 or PLD for not to disturb the computing power of my host CPU. The 8051 I chose would be a WINBOND W78E52 for easier availability. Actually I am also very interested in the RF front end stuff. Or other line coding skills to improve data throughput.


regards

PM  EMAIL  GALLERY  Attn:RR  Quote
12-02-2003 11:37 AM  13 years agoPost 5
FredericG

rrNovice

Belgium

My Posts: All  Forum  Topic

Hi Islander,
Now I really have a problem for my MIPS project with current sampling method. My MIPS cpu has only general purpose IO, not buffered anyway. If I would have to run a linux on it, I think I'll have serious sampling problem. Maybe I'll have to add a FIFO for this
I know that some processors have special IO port that can generate interrupts when something changes. Regarding the load on the processor at the IRQ rate, I am not sure. Also take into account that in the PCM protocol high and low bits never come alone.

Angelos has implementaions on a PIC controller if I am not mistaken.


Frederic

PM  EMAIL  HOMEPAGE  Attn:RR  Quote
12-02-2003 03:03 PM  13 years agoPost 6
E.Klinke

rrNovice

71088 Holzgerlingen, Germany

My Posts: All  Forum  Topic

Hi Islander,

I just took a look at the W78E52 and I think it should be suited for the decode job. If you wanted to use it airborne from 4.8V battery you would have to do something about the voltage tolerance. If that controller would not have much else to do but decode, then the internal256 byte ram might suffice, otherwise you would have to attach external ram.
If I saw it right, the W78e52 has capture cababilities. That comes in handy to offload the cpu from monitoring the RX input. The cpu I am using is a Cygnal C8051F20. I choose this one because it also has ADC and DAC onbord and other features I can take advantage of in my application. And, not to forget, I bought it as a development kit including code develipment tools.
My special interest is, to have an onbord controller automatically keep the speed of a model glider constant, as directed from remote. I also want to automatically coordinate the rudder and aileron function and maybe more.....

What is it that you want to do with the decoded PCM signal?

You said you were interested in radi frontend stuff... Does that also include other transmitters (and RX's) at other frequencies where higher transmission rates are allowed?

PM  EMAIL  Attn:RR  Quote
12-02-2003 03:09 PM  13 years agoPost 7
FredericG

rrNovice

Belgium

My Posts: All  Forum  Topic

Hi,

For the reverse engineering of PCM, we used the soundcard line-in to sample the PCM signal. From the soundcard we get a signal where the DC is filtered out. In SW we calculate the mean value of the latest samples. Values above the mean value indicate a 1, values below indicate 0.

I suppose it must be possible to GENERATE a PCM signal using the soundcard too. But here some additional HW will be needed to generate a digital signal from the AC that comes out of the speaker output. In analogy of what we have done is SW, an LPF and a comparator could to the trick I suppose.

Any thoughts?

Frederic

PM  EMAIL  HOMEPAGE  Attn:RR  Quote
12-03-2003 02:55 AM  13 years agoPost 8
Islander

rrNovice

San Jose, CA

My Posts: All  Forum  Topic

Hi Klinke:
I am planning to run a 8051@40MHz after I figured out the whole protocol. The reason for me to do this is to use this 8051 as a co-processor for a host processor to receive the radio data. The ultimate goal for me to make a flying robot/helicopter, much like what you are going to do.
To control a glider, you'll need sensor such as gyro, barometer, or GPS. Do you have qualified source in mind? Are you doing this for fun or for business purpose?
As for the radio stuff, I am more interested in reliability instead of data throughput. I can find some good source to replace the Futaba or JR RF frontend. These RF links run at ISM bands and can have much greater data rate than we have with a RC radio, say 100Kbit/sec. But they are not as reliable as the Fuataba/JR. I think narrow band frquency hopping can be a good thing to do within each 1 mega-hertz band available for RC use. This requires frequency synthesis and some simple FM radio circuits.

regards

PM  EMAIL  GALLERY  Attn:RR  Quote
WATCH
 2 pages [ <<    <    ( 1 )     2     NEXT    >> ] 6019 views POST REPLY
Scorpion Power Scorpion Power
12-03-2003 02:59 AM  13 years ago •• Post 9 ••
Islander

rrNovice

San Jose, CA

My Posts: All  Forum  Topic

Hi Frederic:
I am think exactly the same thing as you are!
I was thining that a simple comparator is enough. But where does this signal go? It seems useless though


regards

PM  EMAIL  GALLERY  Attn:RR  Quote
12-03-2003 05:41 AM  13 years agoPost 10
E.Klinke

rrNovice

71088 Holzgerlingen, Germany

My Posts: All  Forum  Topic

Hi Frederic,

first I must say that I know nothing about the sound card. I know Printer port and Com much better. Maybe I can find some info on the web. Until then I even do not really understand the question. Btw. what is an LPF?

Hi Islander,
when thinking of ISM TX/RX, do you actually think of a return path from the Heli or do you think of replacing the TX module in the Futaba/JR transmitter?
No I am doing this as a hobby. I must admit that I had also dreamt of selling the code to someone who puts it into a (maybe all-protocol) receiver.
My prime reason for PCM decoding is that I want reliable xmission of lots of control info like P(roportional), I(ntegral) and D(ifferentional) factors for 3 control functions in flight, plus digital control like automatic a,b and c on/off on top of the normal stuff necessary to fly. That is also why I implemented the Multiprop/Multiswitch decode function which, at the cost of channels 7 and 8 give me 16 slower (repetition about every 30 ms) extra channels.

I had started this a long time ago at a time when micro processor in the model was not available/affordable. So that was strictly analog. It worked real well but was much too sensitive to temperature and very difficult to modify. Then I got more involved with work and family and so I put it aside. Now, since I am on early retirement I have picked it up again.

Yes I have found excellent new solid state gyroes, pressure transducers, accelerometers plus the already mentioned Development kit for the Cygnal C8051F020.

My intention is to do the main function plus the PCM decode in one chip. But I thougt also about using a tiny Cygnal C8051F300 to do the PCM job.

PM  EMAIL  Attn:RR  Quote
12-03-2003 11:31 AM  13 years agoPost 11
FredericG

rrNovice

Belgium

My Posts: All  Forum  Topic

I was thining that a simple comparator is enough
Yes, probabely you are right...
Btw. what is an LPF?
Sorry, Low Pass Filter
first I must say that I know nothing about the sound card. I know Printer port and Com much better. Maybe I can find some info on the web. Until then I even do not really understand the question. Btw. what is an LPF?
But where does this signal go? It seems useless though
For decoding, reverse engineering and experimenting with PCM, the PC has proven to be an excellent tool. However precise sampling at this rate is difficult with a General Purpose OS. The sound card helps a lot because it can sample the PCM signal fast enough in HW, and route the data in bursts to the application. IMHO, this would not be possible with the serial or printer port.

I am now wondering if the same tools (PC and sound card) would not be useful to generate PCM. In SW you can generate the signal in bursts and rely on the HW to steam it out at the correct pace.

The signal could be injected to the RF part of the radio (instead of the PCM signal generated by the radio) and emitted.

Frederic

PM  EMAIL  HOMEPAGE  Attn:RR  Quote
12-03-2003 11:43 AM  13 years agoPost 12
Angelos

rrKey Veteran

nr Oxford, OX11, UK

My Posts: All  Forum  Topic

Fully working PCM decoder. Can rereceive analogue from rge RF front end or DSC input.

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

PM  EMAIL  GALLERY  Attn:RR  Quote
12-03-2003 02:19 PM  13 years agoPost 13
Islander

rrNovice

San Jose, CA

My Posts: All  Forum  Topic

Hi Klinke:
Yes the radio link can be bidirectional. And it is possible to use this kind of parts to replace the TX/RX RF part of our RC radio. I have some of these modules in hand but did not try to modify them. You can find info on these for example in http://www.radiometrix.com.
Are you a control engineer? you seem familiar with control. I also tried to modify one of my Raptor60 to flybarless and mounted three PI(heading hold) gyros on it to stabilize it. The result was very good, it flies like those with flybars.
I was also thinking about (oops, I am too ambitious, ain't I ) doing an AHRS with some solid state gyros and accelarometers.


regards

PM  EMAIL  GALLERY  Attn:RR  Quote
12-03-2003 02:51 PM  13 years agoPost 14
E.Klinke

rrNovice

71088 Holzgerlingen, Germany

My Posts: All  Forum  Topic

Hi Angelos,
so you have it all ready, and in a form that could be sold, even an RX frontend! But (did I overlook something?) you do not offer it as a 'Model gadget'. Why? Is it too new, not yet fully tested or are you afraid there isn't enough demand? Perhaps afraid of patent violations?

PM  EMAIL  Attn:RR  Quote
12-03-2003 03:08 PM  13 years agoPost 15
Angelos

rrKey Veteran

nr Oxford, OX11, UK

My Posts: All  Forum  Topic

E.Klinke,
I don't have an RF front-end yet. The front-end on the photo is taken out from a GWS PPM receiver but works nicely with my decoder. In fact it range checks better than an original Futaba receiver before CRC errors are detected. (in case you don't know the original Futaba decoder as a pin than pulses when CRC error is detected and also my decoder). GWS receivers are famous for being more sensitive than Futaba's, however they also pick up more glitches when used with electric models.

Anyway, a local company is looking at developing a front-end for me. I am not confident enough that I could produce a reliable RF circuit myself so I'll let the RF experts do it. If all goes according to our original conversations they will supply a ready RF PCB to me which will be stacked on top of my decoder PCB. I will redesign mine to save space. I am in fact a bit sceptical about patents on PCM. I think the way to go would be to preload the PIC with a firmware loader and PPM decoder. The firmware loader will allow anyone to charge the firmware to the firmware of their choice via RS232. Someone could perhaps write his own to decode PCM or PPM with failsafe or mixes build into the receiver. The crystal for the PIC is carefully selected to divide down to 150uS in hardware inside the PIC and also to provide correct servo pulses in the Futaba spec range 920usec to 2120usec using internal timers. This minimises software induced jitter on the servo outputs and guarantees precise 150usec bit reads. So the hardware will be "PCM friendly".

PM  EMAIL  GALLERY  Attn:RR  Quote
12-03-2003 04:56 PM  13 years agoPost 16
E.Klinke

rrNovice

71088 Holzgerlingen, Germany

My Posts: All  Forum  Topic

Angelos,
I see, nice trick, the preload/reload !!! But then it would probably narrow the community that dared do it, don't you think. The patent question then could possibly circumvented by making the code public. What do you think?
I think this would be a great idea, not for the sake of getting rich, rather then as chance for taking better advantage of the possibilities of micro assisted RX's. It was Peter Rother who, long time ago, published an article comparing the PPM and PCM implementations available at that time. He concluded that he would wish that the manufacturers would do that. In his article you may know or find it at http://www.aerodesign.de/peter/2000...CM_PPM_eng.html
you find the sentence:
What I consider a flaw in these systems is the missed opportunity of showing the quality of the transmission chain, eg. ....
and I think the situation hasn't changed much since then.

I have experimented with RX frontends, also to verify that the trainer output is identical to what is transmitted. First I used an old Robbe FMSS. Its LF section had too little bandwidth and I did not want to add a data slicer myself for that experiment. Then I worked with two ACT receivers. I was able to modify the Micro-8 DSQ moderately to get it working.
For my prime purpose (which I described to some extent earlier here), I think I will use my Futaba PCM Rx and use those servo outputs which I do not have to intercept from the Futaba directly, and feed the DSC into my controller. The DSC is actually also an output of the RX demodulator signal at about 150mV amplitude which is overridden if used as DSC input. This aproach saves a lot of wires and saves the oddyties of reconverting servo output into digital.
By the way: when experimenting with the non table driven CRC generation last night, I realized that the shift xor, shift xor takes only 960 processor cycles for all four CRC calculations every 28.5ms and that is only 0.3% of my processing power using 11.0592Mhz Sysclock rate. That tells me, that I could even go to 11MHz and yet only use 3% for the CRC checking. I think I will use it from now on although it isn' as elegant.

Another thing: Did you ever take a look at the Cygnal C8051F300 family?

PM  EMAIL  Attn:RR  Quote
12-03-2003 05:15 PM  13 years agoPost 17
Angelos

rrKey Veteran

nr Oxford, OX11, UK

My Posts: All  Forum  Topic

The DSC is actually also an output of the RX demodulator signal at about 150mV amplitude which is overridden if used as DSC input.
This is exactly what I do ;-)
shift xor takes only 960 processor ..... I think I will use it from now on although it isn' as elegant.
CRC was designed to work with shift/xor. It was in fact designed to be implemented in hardware! I think the 3% you mentioned is already too much. My code probably uses just 4-5 assemply instuctons for each bit received. I will look it up later and copy/paste that part here.

I never used Cygnal C8051F300 but I will have a look tonight since you mentioned that.

I don't know why way I will go with the PCM firmware yet. I am still waiting for a reply about the RF front-ends.

PM  EMAIL  GALLERY  Attn:RR  Quote
12-03-2003 05:55 PM  13 years agoPost 18
E.Klinke

rrNovice

71088 Holzgerlingen, Germany

My Posts: All  Forum  Topic

Angelos,
when investigating RX frontend, do you try to be state of the art, I mean double conversion plus frequency synthesizer (learning)?

The 3% are probably realy a little much. But that was just to stress that it would be even bearable at 1MHz (I just realized I had a typo in the last reply)

Table vs. shift...: it depends! If you were real tight with performance or had high enough data rates to cover in SW, the table driven method would be the better choice. My shift.. implementation takes 240 cycles for seting up the loop counter and getting the data into registers and then loop 16 times. The table version takes only 13 cycles for the same job. That means 18 times faster! -- This is on my C8051F020.
Here are the two code fragments:

first the shift.....
mov r0,#010h
mov a,RxInData
mov b,RxInData+1

loop: clr c
xch a,b
rlc a
xch a,b
rlc a
jnc skip
xrl a,#06bh
skip: djnz r0,loop

and now the table version
mov DPTR,#CRCTable
mov a,RxInData
movc a,@a+DPTR
xrl a,RxInData+1
movc a,@a+DPTR

PM  EMAIL  Attn:RR  Quote
12-03-2003 06:26 PM  13 years agoPost 19
w.pasman

rrElite Veteran

Netherlands

My Posts: All  Forum  Topic

I didn't read this all, but let me add a few remarks

1. The PCM format has NO DC component. The reason they invert all bits after every two frames is one of the ways to accomplish that.

2. You should be able to use an interrupt instead of an audio sampler, and use the system clock to time the distance from the previous PCM pulse. The rest of the code could be as we published. Of course our code is optimized for reverse engineering, and not for speed. (no need for that on 1GHz PowerPC )

PM  EMAIL  HOMEPAGE  GALLERY  Attn:RR  Quote
12-03-2003 07:29 PM  13 years agoPost 20
E.Klinke

rrNovice

71088 Holzgerlingen, Germany

My Posts: All  Forum  Topic

1. The PCM format has NO DC component
Wouter, I fully agree and I also understand the reason why this is a good decision. As a consequence my decoder also does not look at polarities. I do exactly as you suggest.
You should be able to use an interrupt instead of an audio sampler, and use the system clock to time the distance from the previous PCM pulse
I use a capture facility of my micro which generates an interrupt whenever it sees a polarity change. In the interrupt service routine I can read the time since the last change. I translate this into bit times and note the fact that I had seen so many bits of the 'current' value (0's or 1's). Now my code inverts 'current' and waits for the next interrupt and so on....
But there is a point where you have to decide how you start. Otherwise your data is inverted until you throw the dices again. You can make this decision in many ways, but you have to make it and it better be consistent with what you do afterwards and also consistent with the Futaba built in rule. I decided to consider the 18 consecutive bits of same polarity after code startup or after synchronization loss always a logical 1. If I then continue as described above, I have to use my 6B10B table. If I had decided to consider the 18 bits a logical 0 I have to use Angelos's table. In both cases I get CRC error-free and meaningful results and there is no revesal of servo direction between them. If I use the wrong polarity/table pair I get inverted data (I am not speeking of physical polarity) and they fail CRC checking. (The CRC is not symetrical in this sense) If I use the data anyways, The two select bits are inverted, the delta code for no change as well (no change between consecutive absolutes gets a delta code of 7), the code for center moves only by one (from 512 to 511) and the servo travel is inverted.

PM  EMAIL  Attn:RR  Quote
WATCH
 2 pages [ <<    <    ( 1 )     2     NEXT    >> ] 6019 views POST REPLY
Scorpion Power Scorpion Power
 Print TOPIC  Make Suggestion 

 4  Topic Subscribe

Tuesday, October 24 - 6:38 am - Copyright © 2000-2017 RunRyder   EMAILEnable Cookies

Login Here
 New Subscriptions 
 Buddies Online