RunRyder RC
 9  Topic Subscribe
WATCH
 10 pages [ <<    <     1     ( 2 )     3      4     NEXT    >> ] 15665 views POST REPLY
Scorpion Power Scorpion Power
11-19-2003 08:28 PM  13 years agoPost 21
w.pasman

rrElite Veteran

Netherlands

My Posts: All  Forum  Topic

I found a last bit in the aux field: the snap switch is auxbit 8 in all frames.

I think I have now depleted the aux bits in use. I tried all switches, different swash settings, gliders, airplane modes. Never saw any new aux bit flip.

So there are quite some unused aux bits. Maybe someone who has a PCM9 can check where the aux bit for channel 9 (and 10?) is?

I also re-checked the delta codes. I found a minor different result, maybe Frederic you can recheck this:

5 [-16,-28> = -16..-27
6 [-8,-16> = -8..-15
7 [-4,-8> = -4..-7
8 <-4,4] = -3..4
9 <4,8]? = 5..8
10 <8,16] = 9..16
11 <16,28] = 17..28

Note the differnt start and end poitns for the positive and negative deltas, I alleviated this by using inclusive ']' and exclusive '>' start/end points. Probabaly you only checked positive jumps?

PM  EMAIL  HOMEPAGE  GALLERY  Attn:RR  Quote
11-19-2003 08:37 PM  13 years agoPost 22
w.pasman

rrElite Veteran

Netherlands

My Posts: All  Forum  Topic

Frederic

I rechecked your results.
In one case you have for the four failsafe frames for the sync NEG,POS,POS, NEG. The next time you have POS,NEG,NEG,POS. Is that really true?

I have the four frames always on S1.1 S1.2 S0.1 and S0.2, in your terms that would be POS,POS,NEG,NEG I guess. (POS=high sync pulse, NEG=low sync pulse?).

Finally what I find strange is that the default aux value for S1.2 (even frame with high sync) is 0000, both for normal and failsafe frame. That means that it can only be recognised because it's after another failsafe frame. Is that also true for your transmitter? BTW What transmitter do you have? I have FF8S.

PM  EMAIL  HOMEPAGE  GALLERY  Attn:RR  Quote
11-20-2003 11:03 AM  13 years agoPost 23
FredericG

rrNovice

Belgium

My Posts: All  Forum  Topic

Hi,

Very nice work !

Last days have been a bit hectic… I will check your results and the “POS,NEG issue”, but it can take a few days.

My TX is an FC-16

Frederic

PM  EMAIL  HOMEPAGE  Attn:RR  Quote
11-23-2003 01:31 PM  13 years agoPost 24
FredericG

rrNovice

Belgium

My Posts: All  Forum  Topic

Hi,

About the placement of the channel absolute and differential data in the frame, I think we agree. Correct?

About the differential values: I concentrated on the positive steps and I had the impression that the deltas where symmetric. BUT I also have seen sporadic exceptions. We could investigate this further. Could there be a filter before the ADC increasing the rise time of the step? In this case it could easily happen that when the delta value is generated, the full step has not reached the converted. How did you perform the tests?


About the FS, I have been wondering, should I first continue with my current tools or should I first port your tools to the PC.
I decided first to have a quick look at the POS/NEG issue. My previous measurement showed the following packets and aux values (P=POS, N=NEG, E=Even, O=Odd):
PE 1010
NO 0200
NE 0200
PO 1010

I performed one long measurement and this is what I got:

4 s
NO 0200
NE 0200
PO 1010
PE 1010

68 s
PO 1010
PE 1010
NO 0200
NE 0200

132 s
PE 1010
NO 0200
NE 0200
PO 1010

196 s
NE 0200
PO 1010
PE 1010
NO 0200

All measurements are with FS on channel 1 and 2 configured

I conclude:
- Also my TX sends the first FS info after +/-4 sec, after that every +/-60s
- My TX always sends 4 FS frames
- The type of frame (POS, EVEN, …) is related to the aux-values, I think this confirms that the measurements are correct
- For my TX, the type of the first frame can differ
Finally what I find strange is that the default aux value for S1.2 (even frame with high sync) is 0000, both for normal and failsafe frame.
There is something I do not understand; in my view all normal (not FS) frames have aux 2020. In all examples I have seen so far, from the first aux, the receiver can see that this is the first FS frame.


Frederic

PM  EMAIL  HOMEPAGE  Attn:RR  Quote
11-23-2003 02:48 PM  13 years agoPost 25
w.pasman

rrElite Veteran

Netherlands

My Posts: All  Forum  Topic

Hi Frederic. Thanks for the checkup!
About the placement of the channel absolute and differential data in the frame, I think we agree. Correct?
Mmmm let me see. You concluded
I think that the FS position for channel 1 can be found in the first packet of the 4th frame.".
So that's not the correct...

Let's try again.Comparing our results, we both have two 0x0x and two 1x1x aux fields during failsafe. Apparently this must be combined with the odd/even frame number to give the exact failsafe frame (1..4). From my data I would conclude:

Odd 0x0x => FS for 1 and 5
Even 0x0x => FS for 2 and 6
Odd 1x1x => FS for 3 and 7
Even 1x1x => FS for 4 and 8

Rechecking your data --> you said you have FS for channel 1 in the frame with aux 0200. This was an odd frame. Yes that fits with above decoding scheme :-)

Checking your next result
FS on channel 1 and 2. Now the aux are: 1010, 0200, 0200,1010. I think that the FS position for channel 1 is in packet 1 of frame 2 and FS for channel 2 in packet 1 of frame 3
.
However now you start with an EVEN sync; the second frame is ODD, and ODD 0x0x would be FS for frame 1 according to above. Again it fits!. For frame 3 you have EVEN, and EVEN 0x0x is for frame 2. Seems to be allright! I think we cracked it again
How did you perform the tests?
I set up the delay values for switching between idle-up1 and idleup2. idleup1 is set to 120% and idleup2 to -120%. That means that switching doesnot happen at once but slowly. For the max delay value of 100% I get steps of 6 every next frame. Of course I can see only the absolute value every second frame, and there I see jumps of 12 then. For some delays you get an odd total jump between two frames and I assume no half steps are done. This implies that apparently this delay loop runs independent of the transmitter syncs.
With very small delays I run into problems. For instance delay 21 gives steps of 29, and delay 20 gives steps of 32. So I can't check accurately in that range and larger steps. For that range we seem to need your throw-the-switch with mixer method.

I never checked what happens with the delta field during failsafe, I assume this data is just ignored.


Do you still find only even position data? Or was that a bug somewhere?
About the FS, I have been wondering, should I first continue with my current tools or should I first port your tools to the PC.
Mmm noone else jumped in, so I would not work further on the code, just use what you have.
There is something I do not understand; in my view all normal (not FS) frames have aux 2020.
Re-checked, yes always 2020 during non-failsafe. Must be error in my notes... Had 0000 at even headers, no idea how it got there

PM  EMAIL  HOMEPAGE  GALLERY  Attn:RR  Quote
11-23-2003 02:54 PM  13 years agoPost 26
w.pasman

rrElite Veteran

Netherlands

My Posts: All  Forum  Topic

Frederic

Can you confirm that auxbit 8 goes on in every frame if you pull the trainer/snap switch?

And that you get auxbit 4 in odd frames if throttle is below 40%?We still have to measure the exact point. I think this is to reset the battery-failsafe mode where throttle is closed to indicate low batt. If you pull the stick in that situation, the batt-failsafe mode should reset giving you 30seconds to land.

What could the auxbit 8 be for? Why would the receiver need to know I pull the snap/trainer switch???

PM  EMAIL  HOMEPAGE  GALLERY  Attn:RR  Quote
11-24-2003 05:19 PM  13 years agoPost 27
FredericG

rrNovice

Belgium

My Posts: All  Forum  Topic

Hi,

We are out-of-sync…
[QUOTE]About the placement of the channel absolute and differential data in the frame, I think we agree. [\QUOTE]
I was talking about the NON-FS, the regular, frames.

Regarding the situation of the FS information for the different channels, I did not put more effort into this, yet. But for the two first channels we seem to agree.

FS frames come in bursts of 4 frames. If I am not mistaken, the aux-fields tell us exactly what frame of the 4 FS frames we have. Is this correct?
A big difference between my findings and yours is that you always seem to have the 4 FS frames in the same order, while I do not. Correct?

About the differential values, we need to take a closer look at it.

About the even data; also for this issue it would be nice if I could port your code. When I also only get even values, it proves that my TX does this, when I have odd values however, it shows there is a problem with my code.

About your last question about, I will take a look at it.

Unfortunately, hobby-time is very limited lately….

Frederic

PM  EMAIL  HOMEPAGE  Attn:RR  Quote
11-24-2003 05:26 PM  13 years agoPost 28
FredericG

rrNovice

Belgium

My Posts: All  Forum  Topic

Is there nobody who would like to participate?

Don’t think that all work is done…

In addition, it is obvious that different radios can have different behavior. I am afraid with data from only two radio's we could easily jump to the wrong conclusions…

Frederic

PM  EMAIL  HOMEPAGE  Attn:RR  Quote
11-24-2003 08:01 PM  13 years agoPost 29
w.pasman

rrElite Veteran

Netherlands

My Posts: All  Forum  Topic

Hi Frederic
I was talking about the NON-FS, the regular, frames.
Oops. But I posted the details of normal frames already in post 14 here? Maybe you can recheck that if you didn't yet? It's the table with 8 channels from top to bottom, frame 1 and 2 are odd resp even fframes as usual.

For the FS the aux fields are NOT enough. The odd/even bit is also needed. That's what I just posted. Yes I always have the four frames in same order, so it's good that you don't have that, otherwise I would never thought that aux fields are necessary. Just the order might be sufficient (unless of course a frame is dropped)
About the even data; also for this issue it would be nice if I could port your code. When I also only get even values, it proves that my TX does this, when I have odd values however, it shows there is a problem with my code.
That's quite a hassle just to check this oddity. You dont happen to know someone with a macintosh just to check this? Furthermore, there is nothing special about this position data, it's just coming straight from the 10to6 decoder. So I can hardly believe it's a bug in the code... I would not bother too much about it, and it doesn't matter for the format anyway.

PM  EMAIL  HOMEPAGE  GALLERY  Attn:RR  Quote
11-24-2003 09:59 PM  13 years agoPost 30
Phil Cole

rrVeteran

Menlo Park CA

My Posts: All  Forum  Topic

I was thinking about giving it a go.

I thought I saw mention of a windows program somewhere in the thread?

I'd be using a 9Z-WC. While scoping the DSC output one day a few years ago I saw that the channel positions in the frames were not constant, but varied according to demand. E.g. if the flapperon mix was on, then ch6 popped up in the frame I was synced to, in place of the normal aileron channel.

PM  EMAIL  Attn:RR  Quote
11-25-2003 11:24 AM  13 years agoPost 31
FredericG

rrNovice

Belgium

My Posts: All  Forum  Topic

Hi Phil,
I was thinking about giving it a go.
Great
I thought I saw mention of a windows program somewhere in the thread?
Yes, this is the code I currently use...
if the flapperon mix was on, then ch6 popped up in the frame I was synced to, in place of the normal aileron channel.
Yes, in my understanding of the responsibilities of TX and RX, I am not surprised... Are you?

Frederic

PM  EMAIL  HOMEPAGE  Attn:RR  Quote
11-25-2003 11:30 AM  13 years agoPost 32
FredericG

rrNovice

Belgium

My Posts: All  Forum  Topic

Hi Wouter,
It's the table with 8 channels from top to bottom, frame 1 and 2 are odd resp even fframes as usual.
Yes, this is in fact the data I was talking about. I never formally listed where I thought the channels could be found in the non-FS frames. Sorry for the confusion caused.
For the FS the aux fields are NOT enough.
Yes, it is possible I am wrong.
That's quite a hassle just to check this oddity.
You choose your words carefully

I suppose I should not check if I completely agree with your FS findings.

Do we make a list of what remains to be checked?

Frederic

Frederic

PM  EMAIL  HOMEPAGE  Attn:RR  Quote
11-25-2003 01:57 PM  13 years agoPost 33
w.pasman

rrElite Veteran

Netherlands

My Posts: All  Forum  Topic

Phil

Great, I think we might find the meaning of some of the remaining aux bits, and find the position of channel 9 and 10 if you want to share your results!

The software is on the link I gave above. It's my website but Frederic wrote the windows software.

You already gave an interesting new thing, I never checked what happens with flaperon mix, I did go through the airplane and glider setups but didn't try all mixing options. Will try that tonight

As far as I can see we have most things figured out now. We have to check on other transmitters if everything we found so far is holding up.

We are still missing the meaning of auxbit 8, connected to the trainer switch on my transmitter.

We still have to check if delta is always 8 (no delta) in failsafe frames

And there quite a few aux bits that we don't know about yet. I will make an overview

PM  EMAIL  HOMEPAGE  GALLERY  Attn:RR  Quote
11-25-2003 04:39 PM  13 years agoPost 34
Angelos

rrKey Veteran

nr Oxford, OX11, UK

My Posts: All  Forum  Topic

I am a bit confused about which bit you call "auxbit 8".

PM  EMAIL  GALLERY  Attn:RR  Quote
11-25-2003 05:00 PM  13 years agoPost 35
FredericG

rrNovice

Belgium

My Posts: All  Forum  Topic

Hi,
, I never checked what happens with flaperon mix, I did go through the airplane and glider setups but didn't try all mixing options.
IMHO, the receiver routes the channel positions it receives from the TX to the servo's without any manipulation. Features like mixing are implemented by the transmitter. (The emitted FS positions are also the positions after mixing) So, I would be surprised that the state of mixers influences anything other than the channel positions.
Am I mistaken?
We still have to check if delta is always 8 (no delta) in failsafe frames
I would have a tendency to think that they contain real delta values… Might be difficult to verify

Frederic

PM  EMAIL  HOMEPAGE  Attn:RR  Quote
11-25-2003 08:30 PM  13 years agoPost 36
w.pasman

rrElite Veteran

Netherlands

My Posts: All  Forum  Topic

Hi

I checked the delta-behaviour during failsafe. Look at this

A S0.1: < P=560 D= 8 A=2 ECC= 35> < P=786 D= 8 A=1 ECC=144> < P= 40 D= 8 A=2 ECC= 33> < P= 40 D= 8 A=0 ECC=107>e=12
BS0.2: < P=512 D= 7 A=2 ECC= 21> < P=512 D= 8 A=0 ECC=225> < P=879 D= 8 A=2 ECC=108> < P=517 D= 8 A=0 ECC= 77>e=15
C S1.1: < P=550 D= 8 A=2 ECC=147> < P=786 D= 8 A=1 ECC=144> < P= 40 D= 8 A=2 ECC= 33> < P= 40 D= 8 A=0 ECC=107>e=12
DS1.2: < P=512 D= 7 A=2 ECC= 21> < P=512 D= 8 A=0 ECC=225> < P=879 D= 8 A=2 ECC=108> < P=517 D= 8 A=0 ECC= 77>e=15
E S0.1: < P=540 D= 8 A=2 ECC= 40> < P=786 D= 8 A=1 ECC=144> < P= 40 D= 8 A=2 ECC= 33> < P= 40 D= 8 A=0 ECC=107>e=12
F S0.2: < P=512 D= 7 A=2 ECC= 21> < P=512 D= 8 A=0 ECC=225> < P=879 D= 8 A=2 ECC=108> < P=517 D= 8 A=0 ECC= 77>e=15

G S1.1: < P=512 D= 8 A=0 ECC=225> < P=786 D= 8 A=1 ECC=144> < P=512 D= 8 A=0 ECC=225> < P= 40 D= 8 A=0 ECC=107>e=12
H S1.2: < P=512 D= 5 A=0 ECC= 44> < P=512 D= 8 A=0 ECC=225> < P=512 D= 8 A=0 ECC=225> < P=517 D= 8 A=0 ECC= 77>e=15
J S0.1: < P=519 D= 8 A=1 ECC=190> < P=512 D= 8 A=1 ECC=196> < P= 40 D= 8 A=1 ECC= 78> < P=512 D= 8 A=0 ECC=225>e=12
K S0.2: < P=512 D= 7 A=1 ECC=122> < P=512 D= 8 A=0 ECC=225> < P=879 D= 8 A=1 ECC= 3> < P=512 D= 8 A=0 ECC=225>e=15

L S1.1: < P=509 D= 8 A=2 ECC=249> < P=786 D= 8 A=1 ECC=144> < P= 40 D= 8 A=2 ECC= 33> < P= 40 D= 8 A=0 ECC=107>e=12
M S1.2: < P=512 D= 7 A=2 ECC= 21> < P=512 D= 8 A=0 ECC=225> < P=879 D= 8 A=2 ECC=108> < P=517 D= 8 A=0 ECC= 77>e=15
N S0.1: < P=499 D= 8 A=2 ECC= 13> < P=786 D= 8 A=1 ECC=144> < P= 40 D= 8 A=2 ECC= 33> < P= 40 D= 8 A=0 ECC=107>e=12
P S0.2: < P=512 D= 7 A=2 ECC= 21> < P=512 D= 8 A=0 ECC=225> < P=879 D= 8 A=2 ECC=108> < P=517 D= 8 A=0 ECC= 77>e=15
Q S1.1: < P=489 D= 8 A=2 ECC=159> < P=786 D= 8 A=1 ECC=144> < P= 40 D= 8 A=2 ECC= 33> < P= 40 D= 8 A=0 ECC=107>e=12
R S1.2: < P=512 D= 7 A=2 ECC= 21> < P=512 D= 8 A=0 ECC=225> < P=879 D= 8 A=2 ECC=108> < P=517 D= 8 A=0 ECC= 77>e=15
T S0.1: < P=478 D= 8 A=2 ECC=109> < P=786 D= 8 A=1 ECC=144> < P= 40 D= 8 A=2 ECC= 33> < P= 40 D= 8 A=0 ECC=107>e=12
U S0.2: < P=512 D= 7 A=2 ECC= 21> < P=512 D= 8 A=0 ECC=225> < P=879 D= 8 A=2 ECC=108> < P=517 D= 8 A=0 ECC= 77>e=15
V S1.1: < P=478 D= 8 A=2 ECC=109> < P=394 D= 8 A=1 ECC= 54> < P= 40 D= 8 A=2 ECC= 33> < P= 40 D= 8 A=0 ECC=107>e=12



I set up delay 81%. Frames are letter-coded (first letter in every row) for reference. I skipped some letters (O, I) to avoid confusion.

Delta is going on during failsafe frames!
As you can see from the jumps in the first pcm_packet.position in the odd frames (S0.1 and S1.1) we have step of 5 every frame, and 1 step 6 in the first or second in the failsafe frame.

So we would get for the reconstructed aileron position in frames E..K
E: ail=540
F: ail=540-4=536 (7 stands for -4 at least)
G: ail=536 (no input for ail, as FS value overrides it)
H: ail=536-16=520 (5 stands for -16 at least?)
J: ail=519
K: ail=519-4=415 (7 stands for -4 at least)

Number H is weird. D=5 !! D=5 corresponds to a jump of -16 to -27 and that is much larger than we expect. We expect -12, maybe -13, which should be 6 and not 5. Do I miss something??

PM  EMAIL  HOMEPAGE  GALLERY  Attn:RR  Quote
11-25-2003 08:35 PM  13 years agoPost 37
w.pasman

rrElite Veteran

Netherlands

My Posts: All  Forum  Topic

Phil
E.g. if the flapperon mix was on, then ch6 popped up in the frame I was synced to, in place of the normal aileron channel.
I notice that if I turn on flaperon mix (aero mode), I get in even frames in the third pcm_packet (channel 6) also changing data if I give aileron. But I still get the aileron data in odd frames in the first pcm_packet (the expected aileron channel 1) so I think this channel 6 correlation is related to the flaperon mix.According to the FF8S manual channel 6 is the flaperon trim so the other way round, yes it's to be expected that channel 6 influences channel 1 too in this case. BTW my channel 6 rotate-knob has no effect but I assume I have something inhibited...

PM  EMAIL  HOMEPAGE  GALLERY  Attn:RR  Quote
11-25-2003 08:39 PM  13 years agoPost 38
w.pasman

rrElite Veteran

Netherlands

My Posts: All  Forum  Topic

Hi Angelos

Good to see that you're still around. I was a bit afraid this was going to be a two-man story

If you put the two bits from the four pcm_packets in a row from left to right as they come in, you have a row of eight bits. Number them from left to right as 1..8 and you have my bit numbering. I agree it is confusing, some start counting at 0, others at 1. Then some start counting at the left, others at the right.....

So bit 8 is the rightmost bit in pcm_packet[3].aux to put it another way (yeah I start counting pcm_packets with 0 because this is the C array index...)

PM  EMAIL  HOMEPAGE  GALLERY  Attn:RR  Quote
11-25-2003 08:46 PM  13 years agoPost 39
w.pasman

rrElite Veteran

Netherlands

My Posts: All  Forum  Topic

Frederic
IMHO, the receiver routes the channel positions it receives from the TX to the servo's without any manipulation. Features like mixing are implemented by the transmitter. (The emitted FS positions are also the positions after mixing) So, I would be surprised that the state of mixers influences anything other than the channel positions.
Am I mistaken?
Maybe you're mistaken, that's the question The transmitter might decide that some channel has priority in some cases and decide to put it somewhere else in the array. But upto now and believing Angelos is right with his latency quotes, there is little or no advantage of one place in the frame over another. If that is true I cant see really why you would swap channel positions.
Strange thing is still that Angelos gave us another channel order, and again other channel orders were suggested in the propo code [no sorry the autopilot project]. We could never detect those orders however, so either it is in again another transmitter (Angelos, what transmitter did you use?) or we are missing something very tricky.

PM  EMAIL  HOMEPAGE  GALLERY  Attn:RR  Quote
11-25-2003 09:12 PM  13 years agoPost 40
Angelos

rrKey Veteran

nr Oxford, OX11, UK

My Posts: All  Forum  Topic

I haven’t been following this thread, but it seems that you have my now figured out that the failsafe data are transferred in 4 consecutive frames each having two packets with failsafe data. The remaining two packets contain absolute and delta for normal operation. However, I can’t recall if I ever checked whether the failsafe packets carry delta values other than b’1000’. I am talking about the specific packet that has an absolute failsave value. Not the entire frame.

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

 9  Topic Subscribe

Thursday, October 19 - 4:35 am - Copyright © 2000-2017 RunRyder   EMAILEnable Cookies

Login Here
 New Subscriptions 
 Buddies Online