RunRyder - PCM1024: PART II

rrTV-PHOTO

New HD TV

HOME rrTV-PHOTO GALLERIES MY GALLERY HELP-FAQ

myHOME PM pmRR MEMBERS 636 ONLINE 19 EVENTS SEARCH REGISTER START HERE

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

8240 views

POST REPLY

3D Heli Depot	.	JR-Spektrum	.	Gyro Hobbies
	.		.

Radio - Servo - Gyro - Gov - Batt > PCM1024: PART II

FredericG
Heliman
Location: Belgium

Hi,

Quote
The transmitter might decide that some channel has priority in some cases and decide to put it somewhere else in the array

Ah, I see... You mean that, depending on the active mixers, the transmitter could decide to swap channels. I thought you meant that the radio wouldsignal the receiver that some mixing should still be performed in the receiver.

Quote
there is little or no advantage of one place in the frame over another.

However, suppose you activate the flapperon mixer. This means that the ailerons are driven by two servos. In this case, I suppose that it is beneficial to have the channels close to each other in the PCM frames.
One way could be to choose channels for the servos so that they are close to each other in the frames (for my tx at least, when you select the flapperon mixer, the channels for the two servos is fixed (1 and 5 if I am not mistaken)).
Another option could be to swap channels. This second option is only available for PCM, not for PPM...

Regarding latency issues in general, I wonder how important this is...

Quote
Strange thing is still that Angelos gave us another channel order, and again other channel orders were suggested in the propo code

The confusion on the channel positions is very strange.... When all mixers are off and you move a stick (or switch) labeled channel x on your TX, you expect a servo connected to channel x on the receiver to move. I suppose all futabla/robbe receivers work with all futaba/robbe radios and have a common channel definitions... , so how we can be mistaken?

Frederic

11-26-2003 Over year old.

HOMEPAGE

FredericG
Heliman
Location: Belgium

Hi Angelos,

How are your TX and RX projects?

Frederic

11-26-2003 Over year old.

HOMEPAGE

Angelos
Key Veteran
Location: nr Oxford, OX11, UK

Frederic,
Regarding the RX I am waiting a reply from a local company who are considering to design and build the RX front end for me. They specialize in telemetry and logging systems for racing cars. The PCM decoder is fully working including channel 9, 10, battery failsafe and DSC port. However, reading your last posts I now need to recheck if Delta values are sent by the TX in the same packet that contains an absolute failsafe value.

The TX project is on hold. Last weekend I had to design the PCB for an opto-coupled RC switch that is intended to trigger cameras for aerial photography. I also designed a PCB for the ToolPac interface. ToolPac is a very nice program for reading campac. Then on Monday I decided to learn Verilog to program FPGAs

I need to get back to the TX project soon and finalize a prototype PCB for analogue channel collection and amplification. (joysticks etc). Amplifiers are needed because the joystick pots don’t have full rotation and thus the produced signals are not in the max 0 to 3.3V range. Thus resolution is lost from the 10bit DACs. My prototype works well but it is contacted on ugly stripboard. I need some properly made PCBs for these so I can supply development hardware to a couple of friends who are willing to help with the software.

My the way, have you ever used GCC? I have trouble compiling it and running it under cygwin. The ADS compiler (ARM Development Suite) generates much more efficient code but the CPU I use for the TX it very powerful so there is no need to optimizations. I would rather stick with the free GNU compiler which would nicely fit with thsi open source project. Development hardware will be available for anyone who wants to help.

-Angelos

11-26-2003 Over year old.

w.pasman
Elite Veteran
Location: Netherlands

Frederic

Quote
The confusion on the channel positions is very strange.... When all mixers are off and you move a stick (or switch) labeled channel x on your TX, you expect a servo connected to channel x on the receiver to move. I suppose all futabla/robbe receivers work with all futaba/robbe radios and have a common channel definitions... , so how we can be mistaken?

Yes of course if we move a channel on the transmitter we want that channel to change. But under water they can do what they want, as long as they reverse everything before putting out the channel. If they want to send channel 1 last no problem, as long as they know it's channel 1. However I have never seen anything like that happen on my TX. But again that may be just the FF8 so we need more input on this.

11-26-2003 Over year old.

HOMEPAGE

w.pasman
Elite Veteran
Location: Netherlands

Interesting new results!
The delta as Frederic figured it out is not the full story, and my estimation of the assymetry is also not complete yet.

First, the assymetry is true, but not everywhere around the range. For instance a jump of +4 still gives D=8 while a jump of -4 gives a D=7. Jump of 5 gives D=9, -5 gives 7. Jump of 63 AND 64 both give D=13 while jump -63 gives D=3 and -64 gives D=2. So at that point the assymetry still holds.So far so good. But a jump of -87 gives D=2 and +87 gives D=14, and jump -88 gives D=1 and +88 gives D=15. So here we don't have assymetry anymore!! Wonder what's going on...

Another nice thing, they DO use D=0. So there we are assymetric again. So all positive jumps above 88 go to D=15 (still to check if this is really true but seems upto now), [balancing against jumps below -88 goign to D=1] but D=-149 gives D=0! Probably lower jumps eg D=-130 also give D=0, I expect the switchpoint to be at 112 but still to check.

11-26-2003 Over year old.

HOMEPAGE

w.pasman
Elite Veteran
Location: Netherlands

Angelos

Quote

My the way, have you ever used GCC? I have trouble compiling it and running it under cygwin. The ADS compiler (ARM Development Suite) generates much more efficient code but the CPU I use for the TX it very powerful so there is no need to optimizations. I would rather stick with the free GNU compiler which would nicely fit with thsi open source project. Development hardware will be available for anyone who wants to help.

have used gcc and g++ all the time, it's default on linux and on macosx. Source code for this project is all gcc. At my job we currently use java though.
But I dont think anyone should use our software for hardware development. This is reverse-engineering support software, not optimized at all for hardware etc.

11-26-2003 Over year old.

HOMEPAGE

Angelos
Key Veteran
Location: nr Oxford, OX11, UK

I use GCC at work too but under linux and everything works fine. Compiling GCC under cygwin is my problem. I keep getting errors while compiling the compiler.

I have already written code for generating PCM and transmitting it. However, I would like to carry on delopment under windown/cygwin instead of linux as I need to use other tools at the same which run under windows.

11-26-2003 Over year old.

FredericG
Heliman
Location: Belgium

Hi Angelos,

Quote
However, reading your last posts I now need to recheck if Delta values are sent by the TX in the same packet that contains an absolute failsafe value.

Have you seen that for my TX, the order of the 4 fs frames can vary ? This might be important for your RX if you want it be fully compatible…

Quote
Then on Monday I decided to learn Verilog to program FPGAs

All very fun project you are working on !

Quote
Amplifiers are needed because the joystick pots don’t have full rotation and thus the produced signals are not in the max 0 to 3.3V range.

I see, interesting

Quote
to a couple of friends who are willing to help with the software.

I might be interested as well, but I suppose you already have enough people to help you…

Quote
My the way, have you ever used GCC? I have trouble compiling it and running it under cygwin.

Yes, but I do not have any experience compiling it. Can't you find a precompiled one for cygwin?

Frederic

11-27-2003 Over year old.

HOMEPAGE

Angelos
Key Veteran
Location: nr Oxford, OX11, UK

Quote
Have you seen that for my TX, the order of the 4 fs frames can vary ? This might be important for your RX if you want it be fully compatible…

My receiver software does not care about the order. It can figure out which frame it is using the aux bits.

Quote
I might be interested as well, but I suppose you already have enough people to help you…

It will be an open source software so you are wellcome to join. You seem to be good with C. The dev kit will cost you around US$200. This consists of an GP32 games console which I curently use for as a CPU board. It has the ARM chip, LCD, smartmedia interface etc. http://www.cdworld.co.uk/mmcd/gbcd/#gp32 The remaining hardware is the 160x100mm PCB that I am designing which includes the 8 switces, slider and know pots, TX module socket and connections for the joysticks. You will also need an old TX to remove the joysticks. This PCB plugs on the expansion connetor of the GP32.

As soon as the basic functions of the software are completed I will let the software guys delevop the rest and I will design a new set of PCBs that will include the ARM chip and all other required hardware.

11-27-2003 Over year old.

FredericG
Heliman
Location: Belgium

Hi Angelos,

So, currently you are working on a development platform where you continue to use the game console. Later you plan to make a complete PCB that can replace the digital part of an TX. Correct?

Frederic

11-27-2003 Over year old.

HOMEPAGE

Phil Cole
Veteran
Location: Redwood City CA

PCM Decoder Working

I made up a cable, plugged it in and ran Frederic's DOS programs. They just worked.

I couldn't find any resistors around at home, so I just wired the DSC output directly to the audio line input on my computer. Just set the gain low on the mixer utility and it will work fine.

I guess the dump file is just a binary dump of the incoming data?

I would like to write or modify a decoder so I can filter out specific events.

Frederic, what does the "check" that I see in the decoder output mean?

The only result I have so far is that channel 10 appears to work by changing the ECC in one of the PCM packets. Ch 9 probably does the same thing. This means you have to be aware of the settings of these channels when trying to figure out the ECC. This might be a little tricky. Ch 10 on the 9Z is undocumented, so unless I had seen it on Angelos' web site I would not have known to keep switch D in a known position while analysing the ECC.

11-27-2003 Over year old.

FredericG
Heliman
Location: Belgium

Hi Phil,

Quote
I guess the dump file is just a binary dump of the incoming data

The file consists of 4byte long integers indicqting the length of the pulses.

Quote
would like to write or modify a decoder so I can filter out specific events.

Send me a mail at fredericgoddeeris at hotmail.com and I will send you the code. I never published the code because it is not clean enough; I have very little time and go for results.

Quote
Frederic, what does the "check" that I see in the decoder output mean?

I introduced this for finding the FS frames. Each time uncommon values are detected, "check" is printed; for example when the aux values are not 2020. I steam the output to a .txtx file and with a text editor I can easily find the packets I need to look at.

Frederic

11-27-2003 Over year old.

HOMEPAGE

FredericG
Heliman
Location: Belgium

Hi Wouter,

I wanted to check your findings on the diff values and realized that it is indeed handy to see real-time results. One possibility was to port your code... but I thought it would be faster to modified my tools so that PCMRead can stream the data to stdout and PCMDecode so that it reads the data from stdin. So I can do:
ReadPCM SO | decodePCM SI 1
This gives best of both worlds…

I took me more time that foreseen, so this evening I only worked on tools, no progress unfortunately…

Frederic

11-27-2003 Over year old.

HOMEPAGE

Angelos
Key Veteran
Location: nr Oxford, OX11, UK

Quote
So, currently you are working on a development platform where you continue to use the game console. Later you plan to make a complete PCB that can replace the digital part of an TX. Correct?

Correct! The GP32 uses an ARM based “system on chip”. This one chip has all hardware on it, including USB controller, LCD controller, memory controller, sound, I2C, ISS, GPIO, etc. The only external parts are flash memory to boot, RAM if you require more than the 16K internal and a sync generator for the LCD if the LCD needs that. Some LCD’s don’t. The other circuitry in the GP32 is just audio ADC and amplifiers and power supply regulation. As you see GP32 makes a perfect development environment.

11-28-2003 Over year old.

w.pasman
Elite Veteran
Location: Netherlands

Hi Phil!

Great you joined us.

Quote
I couldn't find any resistors around at home, so I just wired the DSC output directly to the audio line input on my computer. Just set the gain low on the mixer utility and it will work fine.

Wow. I think you're lucky that you don't just blow out your audio input. I really recommend bringing down the voltage a bit, audio line level is 1VPP max, and there easily comes out 8V from your transmitter.

Quote

The only result I have so far is that channel 10 appears to work by changing the ECC in one of the PCM packets. Ch 9 probably does the same thing. This means you have to be aware of the settings of these channels when trying to figure out the ECC. This might be a little tricky. Ch 10 on the 9Z is undocumented, so unless I had seen it on Angelos' web site I would not have known to keep switch D in a known position while analysing the ECC.

Great you have the first ch9/ch10 info so far!

However, I can hardly believe the ECC (error correcting code, kind of checksum) is being modified. The ECC is supposed to check the preceeding bits, not to be altered. I never did fully check the ECC field, so I might have missed something there but that would be quite bizarre. Maybe you wrote something wrong or I understand this completely wrong. Maybe this is just a terminology problem, did you check out my report on the format so far, from my website? (http://graphics.tudelft.nl/~wouter [go to publications] and go to the private projects in 2003) This might help getting our terms straight, so that it's clear what we are talking about.
I could not find the switch D info on Angelos' webpage, on which page is that? Maybe you have a full link?

11-28-2003 Over year old.

HOMEPAGE

Phil Cole
Veteran
Location: Redwood City CA

Easy questions first:

Quote
I could not find the switch D info on Angelos' webpage, on which page is that?

It's on the "Tweaking the 9Z" page. Get to it from the "Futaba Service Menu" link on the first page. The Ch10 information is towards the bottom.

Regarding the Ch 10 encoding:

I had another look at my data. It looks like the aux bits may do the job.

The two captures below were taken with Sw. D in different positions.
You can see that the servo data is pretty much the same in both cases - some channels are dithering a bit. However, A4 is staying constant, but the aux value does change between the two samples.

This is a frame from my capture with Sw. D up.
Below is a frame with Sw. D down.

== SYNC = POS == Time:134.55ms == #Frames:0004 ================================
000000 FrameType: EVEN
11 Meaning unknown (yet)
0011001100 => PCM byte 101000
1110001100 => PCM byte 011110
1100011000 => PCM byte 101101
0001111111 => PCM byte 001001
aux= 2 ecc= 73 A2= 491 D1= 8
0011111111 => PCM byte 001000
0011000111 => PCM byte 100000
1100001111 => PCM byte 001101
1100011100 => PCM byte 011100
aux= 0 ecc= 92 A4= 515 D3= 8
0011001100 => PCM byte 101000
1111000011 => PCM byte 001111
1100000011 => PCM byte 101111
1100111111 => PCM byte 001011
aux= 2 ecc=203 A6= 251 D5= 8
0011111111 => PCM byte 001000
0000111100 => PCM byte 110000
1111100111 => PCM byte 000011
1111100011 => PCM byte 000010
aux= 0 ecc=194 A8= 768 D7= 8
------ Time=159.75

====================================================
Frame with Sw. D down.
====================================================

== SYNC = NEG == Time:113.55ms == #Frames:0003 ================================
000000 FrameType: EVEN
11 Meaning unknown (yet)
0011001100 => PCM byte 101000
1110001100 => PCM byte 011110
0000111100 => PCM byte 110000
0011100000 => PCM byte 110011
aux= 2 ecc= 51 A2= 492 D1= 8
1111110000 => PCM byte 011000
0011000111 => PCM byte 100000
1100001111 => PCM byte 001101
0001110000 => PCM byte 111001
aux= 1 ecc=121 A4= 515 D3= 8*****CHECK****
0011001100 => PCM byte 101000
1111000011 => PCM byte 001111
0011110000 => PCM byte 110010
0001111000 => PCM byte 110001
aux= 2 ecc=177 A6= 252 D5= 8
0011111111 => PCM byte 001000
1100000011 => PCM byte 101111
0000011000 => PCM byte 111100
1111111000 => PCM byte 000000
aux= 0 ecc= 0 A8= 767 D7= 8
------ Time=139.05

11-28-2003 Over year old.

w.pasman
Elite Veteran
Location: Netherlands

Hi Phil

Ha thanks, I now realize that his page on the "service menu" is really on tweaking, I see even soldering tips

. I didn't look at it better yet.

11-28-2003 Over year old.

HOMEPAGE

w.pasman
Elite Veteran
Location: Netherlands

I checked the delta codes thoroughly, I think I have every jump between 0 and 202 down now.

D: jumps represented by this D
0: -116- .... -202
1: -88 ... -115
2: -64 ... -87
3: -44 ... -63
4: -28 ... -43
5 -16... -27,
6 : -8... -15
7: -4 ... -7
8: -3 ... 4
9: 5 ... 8
10: 9, 16
11: 17 ... 28
12: 29 ... 44
13: 45 ... 64
14: 65 ... 87
15: 88 ... 202

Note that this is not symmetric, maybe someone made a typo at Futaba?? Esp the 88 at D=15 is weird I think.

11-28-2003 Over year old.

HOMEPAGE

w.pasman
Elite Veteran
Location: Netherlands

Phil

This is exactly the bit that goes to 1 on my transmitter if the throttle goes below 40%: this is aux bit 4.
Are you sure that this "D" switch is not set up as throttle hold or do you have a mixer from switch D to throttle? This could explain this effect too. I 'm pretty sure that this 'throttle low' bit is not channel 9 or 10, because the receiver really needs to know when you have throttle low in order to reset battery failsafe.

Maybe you can give us the odd frames as well that were just before and next to it, then we can see the throttle position.

11-28-2003 Over year old.

HOMEPAGE

Phil Cole
Veteran
Location: Redwood City CA

The ch10 stuff is about a quarter of the way down, not at the bottom, like I previously indicated. There is a lot of stuff on that page!

Regarding the deltas:

If you think of the delta as something for the receiver to get the servo moving in the right direction before it gets the next absolute update then what Futaba did is probably correct.

The D8 code will cause no servo position change, and is necessary to avoid continually buzzing servos. Since there are only 15 codes left for everything else, plus and minus deltas can't be evenly distributed.

I am guessing that the receiver will add/subtract either the middle or the lowest absolute value of the delta range to the current servo position. The main value of the deltas would be for small changes, where the servo transit speed won't have much effect on the perceived response. A 0.2 S/60° servo is going to need several complete frames to get from one end of its travel to the other (including acceleration).

Whether the change is 88 or 202, a servo from five or ten years ago is going to be in much the same position by the time the next absolute value update arrives. Modern high speed digital servos might be able to show up the deciencies in the encoding scheme.

Servos will be able track small deltas in real time, so they are encoded more or less symmetrically.

11-28-2003 Over year old.

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

8240 views

POST REPLY

E-flite	.	Next D	.	Fast Lad Performance
	.		.

Radio - Servo - Gyro - Gov - Batt > PCM1024: PART II

PRINT TOPIC

Advertisers

Subscribe to This Topic