RunRyder RC
 9  Topic Subscribe
WATCH
 10 pages [ <<    <     1      2     ( 3 )     4      5     NEXT    >> ] 15805 views
11-26-2003 06:29 PM  14 years agoPost 41
FredericG

rrNovice

Belgium

My Posts: All  Forum  Topic

Hi,
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.
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...
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

PM  EMAIL  HOMEPAGE  Attn:RR  Quote
11-26-2003 06:35 PM  14 years agoPost 42
FredericG

rrNovice

Belgium

My Posts: All  Forum  Topic

Hi Angelos,

How are your TX and RX projects?

Frederic

PM  EMAIL  HOMEPAGE  Attn:RR  Quote
11-26-2003 06:57 PM  14 years agoPost 43
Angelos

rrKey Veteran

nr Oxford, OX11, UK

My Posts: All  Forum  Topic

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

PM  EMAIL  GALLERY  Attn:RR  Quote
11-26-2003 09:12 PM  14 years agoPost 44
w.pasman

rrElite Veteran

Netherlands

My Posts: All  Forum  Topic

Frederic
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.

PM  EMAIL  HOMEPAGE  GALLERY  Attn:RR  Quote
11-26-2003 09:17 PM  14 years agoPost 45
w.pasman

rrElite Veteran

Netherlands

My Posts: All  Forum  Topic

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.

PM  EMAIL  HOMEPAGE  GALLERY  Attn:RR  Quote
11-26-2003 09:24 PM  14 years agoPost 46
w.pasman

rrElite Veteran

Netherlands

My Posts: All  Forum  Topic

Angelos
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.

PM  EMAIL  HOMEPAGE  GALLERY  Attn:RR  Quote
11-26-2003 09:53 PM  14 years agoPost 47
Angelos

rrKey Veteran

nr Oxford, OX11, UK

My Posts: All  Forum  Topic

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.

PM  EMAIL  GALLERY  Attn:RR  Quote
11-27-2003 12:34 PM  14 years agoPost 48
FredericG

rrNovice

Belgium

My Posts: All  Forum  Topic

Hi Angelos,
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…
Then on Monday I decided to learn Verilog to program FPGAs
All very fun project you are working on !
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
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…
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

PM  EMAIL  HOMEPAGE  Attn:RR  Quote
11-27-2003 12:55 PM  14 years agoPost 49
Angelos

rrKey Veteran

nr Oxford, OX11, UK

My Posts: All  Forum  Topic

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.
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.

PM  EMAIL  GALLERY  Attn:RR  Quote
11-27-2003 05:21 PM  14 years agoPost 50
FredericG

rrNovice

Belgium

My Posts: All  Forum  Topic

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

PM  EMAIL  HOMEPAGE  Attn:RR  Quote
11-27-2003 06:31 PM  14 years agoPost 51
Phil Cole

rrVeteran

Menlo Park CA

My Posts: All  Forum  Topic

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.

PM  EMAIL  Attn:RR  Quote
11-27-2003 10:09 PM  14 years agoPost 52
FredericG

rrNovice

Belgium

My Posts: All  Forum  Topic

Hi Phil,
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.
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.
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

PM  EMAIL  HOMEPAGE  Attn:RR  Quote
11-27-2003 10:17 PM  14 years agoPost 53
FredericG

rrNovice

Belgium

My Posts: All  Forum  Topic

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

PM  EMAIL  HOMEPAGE  Attn:RR  Quote
11-28-2003 10:59 AM  14 years agoPost 54
Angelos

rrKey Veteran

nr Oxford, OX11, UK

My Posts: All  Forum  Topic

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.

PM  EMAIL  GALLERY  Attn:RR  Quote
11-28-2003 04:59 PM  14 years agoPost 55
w.pasman

rrElite Veteran

Netherlands

My Posts: All  Forum  Topic

Hi Phil!

Great you joined us.
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.
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?

PM  EMAIL  HOMEPAGE  GALLERY  Attn:RR  Quote
11-28-2003 07:30 PM  14 years agoPost 56
Phil Cole

rrVeteran

Menlo Park CA

My Posts: All  Forum  Topic

Easy questions first:
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

PM  EMAIL  Attn:RR  Quote
11-28-2003 07:37 PM  14 years agoPost 57
w.pasman

rrElite Veteran

Netherlands

My Posts: All  Forum  Topic

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.

PM  EMAIL  HOMEPAGE  GALLERY  Attn:RR  Quote
11-28-2003 07:43 PM  14 years agoPost 58
w.pasman

rrElite Veteran

Netherlands

My Posts: All  Forum  Topic

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.

PM  EMAIL  HOMEPAGE  GALLERY  Attn:RR  Quote
11-28-2003 07:52 PM  14 years agoPost 59
w.pasman

rrElite Veteran

Netherlands

My Posts: All  Forum  Topic

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.

PM  EMAIL  HOMEPAGE  GALLERY  Attn:RR  Quote
11-28-2003 08:10 PM  14 years agoPost 60
Phil Cole

rrVeteran

Menlo Park CA

My Posts: All  Forum  Topic

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.

PM  EMAIL  Attn:RR  Quote
WATCH
 10 pages [ <<    <     1      2     ( 3 )     4      5     NEXT    >> ] 15805 views
 Print TOPIC  Make Suggestion 

 9  Topic Subscribe

Thursday, December 14 - 2:41 am - Copyright © 2000-2017 RunRyder   EMAILEnable Cookies

Login Here
 New Subscriptions 
 Buddies Online