Protocol Stacks

More
26 Apr 2012 17:00 - 26 Apr 2012 17:37 #64 by rcH4x0r
Protocol Stacks was created by rcH4x0r
I'm putting the skeleton of the protocol 'stack' together and I thought I would write some notes about the design

The 'stack' consists of 3 modules:

Radio Resource Manager: This module is responsible for establishing radio links (Tx-Rx, Tx-Tx etc) and scanning/selecting the RF channels that are used (Walkera use a hopping sequence 12 packets long, 4 packets are transmitted on 3 channels). This is also where I propose to put the 'heartbeat' timer that triggers then regular transmission of packets

Radio Link Controller: This module is responsible for building the packets that are sent

Physical Layer: This module intialises the SoC's hardware (GPIO, SPI etc) and controls the radio chip

There are 3 protocols I would like to support:
Old Walkera 4/6/8 channels
New (Devo) Walkera 6/7/8/12 channels
DSM2

This is going to take a while to achieve :)

I have a cheap DSM2 Tx that came with my Champ aircraft which I want to hack into the Devo8. The reason is that we can very quickly actually test / use the Deviation FW even if the Walkera protocol isn't complete. Obviously the ultimate goal is to provide all the protocols using the native CYRF6936

I think this code should live in a directory at /src (i.e. /src/radio) since it will be applicable to all targets
Last edit: 26 Apr 2012 17:37 by rcH4x0r.

Please Log in or Create an account to join the conversation.

More
26 Apr 2012 18:32 #65 by FDR
Replied by FDR on topic Re: Protocol Stacks

rcH4x0r wrote: There are 3 protocols I would like to support:
Old Walkera 4/6/8 channels
New (Devo) Walkera 6/7/8/10/12 channels
DSM2


:) :) :) :) :)

Please Log in or Create an account to join the conversation.

More
26 Apr 2012 19:23 #67 by PhracturedBlue
Replied by PhracturedBlue on topic Re: Protocol Stacks
I've got one of those DSM modules too (I got it when I thought I'd use my turnigy as a universal Tx, as opposed to working on the Devo. However, I don't currently have any models that can use it.

I do have a J6Pro for my nine-eagles Helis that I'd like to support on the Devo (it is also based on the CYRF6936). I haven't done any protocol work yet though.

As for your layer definitions, at what level do I choose the protocol? Is it effectively a different Radio Link Controller for each protocol with a shared Radio Resource Manager for all protocols, or do you have a different Radio Resource Manager for each protocol as well?

You said that the RRM is responsible for initializing the links and selecting channels, but each protocol may do this in very different ways (I'd like to add support for the A7105 (turnigy module) for the same reason you want to add the DSM2. I assume the steps will be similar (it is SPI, and I basically know the protocol to talk to it). I guess it'll be easier for me to understand once I see how your code is partitioned.

Please Log in or Create an account to join the conversation.

More
26 Apr 2012 19:43 #68 by FDR
Replied by FDR on topic Re: Protocol Stacks
The more protocol the better... :woohoo:

Please Log in or Create an account to join the conversation.

More
26 Apr 2012 20:12 - 26 Apr 2012 20:19 #69 by rcH4x0r
Replied by rcH4x0r on topic Re: Protocol Stacks
The "Protocol" consists of three parts, the RRM & RLC layer plus the PHY layer. These layers can "mix & matched" - I imagine that the RRM is common to Devo 6/7/8/10/12 Tx but the RLC is slightly different depending on the number of channels.

My idea is that a Walkera Devo-XX (WDXX) protocol is composed of a generic Walkera Devo RRM + the appropriate RLC (6/7/8/10/12 channel). The WDXX RRM/RLC normally sits on top of a CYR6936 PHY but a flexible stack would allow other PHYs

DSM2/A7105 module stacks will be mostly 'transparent' and very limited in functionality - no telemetry, no Tx -> Tx.

In all cases the RRM will provide the timing info required to send packets at the correct interval.

>>each protocol may do this in very different ways

Exactly, so we allow for separate WDXX RRM, old Walkera 4/6/8 RRM, DSM2 module RRM, DSM2 native RRM, A7051 RRM etc etc all doing their own thing. Each type of RRM will work with >= 1 RLC. DSM2 & A7051 modules will likely use the same, thin, RRM (different timer intervals ?) & RLC (different channel ordering ?) but the PHY is different (SPI vs DSM2???)

The DSM2 module stack should make a very good model for a A7105 module stack.
Last edit: 26 Apr 2012 20:19 by rcH4x0r.

Please Log in or Create an account to join the conversation.

More
13 May 2012 03:47 #278 by PhracturedBlue
Replied by PhracturedBlue on topic Re: Protocol Stacks
Do you have any idea how often data is sent to the Devo Rx? In my V911, frames are sent every 1.46msec. I'm guessing we'll want to use an interrupt handler to trigger the send, but I'm concerned about having an ISR that does all the computation, so I was planning to just set a bit and have the main loop act on it.

Please Log in or Create an account to join the conversation.

More
13 May 2012 13:48 #281 by rcH4x0r
Replied by rcH4x0r on topic Re: Protocol Stacks
I have some concerns that the main loop will have a bit of 'timing jitter'. What I plan to do is use the main loop to collect & process the user input, then, when the timer ISR fires use that to actually do the transmission. If the main loop is busy drawing the GUI (or whatever) then we will transmit stale values but at least we will transmit regularly.

I don't know what the transmit rate is, I will measure it when I find my LA

Please Log in or Create an account to join the conversation.

More
13 May 2012 14:08 #282 by FDR
Replied by FDR on topic Re: Protocol Stacks
Newer DEVO receivers have a switch to select 11ms or 22ms rate...
Olders probably are on 22ms.

Please Log in or Create an account to join the conversation.

More
13 May 2012 14:34 #283 by rcH4x0r
Replied by rcH4x0r on topic Re: Protocol Stacks
That sounds more like the frame rate for the servos

Please Log in or Create an account to join the conversation.

More
13 May 2012 15:30 #284 by FDR
Replied by FDR on topic Re: Protocol Stacks
May be, but it woldn't have too much sense sending commands more often, if the servos got new values only every 11ms anyway...

Please Log in or Create an account to join the conversation.

More
13 May 2012 15:50 #285 by rcH4x0r

Please Log in or Create an account to join the conversation.

More
13 May 2012 17:03 #286 by FDR
Replied by FDR on topic Re: Protocol Stacks
Well, it doesn't say anything about the transmit rate and how it is related to the servo's 11/22ms rate, so at the and you have to measure it, I guess... ;)

Please Log in or Create an account to join the conversation.

More
13 May 2012 17:17 #287 by rcH4x0r
Replied by rcH4x0r on topic Re: Protocol Stacks

FDR wrote: May be, but it woldn't have too much sense sending commands more often, if the servos got new values only every 11ms anyway...


One reason _might_ be to allow for 1 or more packets to be lost during transmission. It makes even less sense for a switch on the receiver to control the rate of transmission.

FDR wrote: Well, it doesn't say anything about the transmit rate and how it is related to the servo's 11/22ms rate, so at the and you have to measure it, I guess...


No, it doesn't, it tells us what the function of the Rx switch is.

I was looking at my notes on the old Walkera system & that sends every 2.6ms

Please Log in or Create an account to join the conversation.

More
13 May 2012 17:41 #288 by FDR
Replied by FDR on topic Re: Protocol Stacks
Yes, you are right about it is the servo rate, and it doesn't have any sense to switch is on the receiver either... :oops:

If it sends every 2.6ms, then the whole three frequency sequence will fit in the 11ms servo window, not to mention the 22ms one...

Please Log in or Create an account to join the conversation.

More
13 May 2012 18:10 #289 by rcH4x0r
Replied by rcH4x0r on topic Re: Protocol Stacks
The frequency hopping sequence is 4 packets on channel A, 4 packets on channel B, 4 packets on channel C then back to channel A. At 2.6ms per block ....

I have only looked at 4 channel Walkera gear & those 4 channels occupy a whole packet (stick position and trim values). It may well be that the protocol changes for 6 & 8 channel sets

What I don't understand is why Walkera transmit the stick position and the trim value. Makes no sense to me

Please Log in or Create an account to join the conversation.

More
13 May 2012 18:31 - 13 May 2012 18:32 #290 by FDR
Replied by FDR on topic Re: Protocol Stacks
Do they still do the same, or it was that way only in the 24xx protocol?

One thing I can think of is: the onboard flybarless systems should handle the stick input and the trim value in a different manner. But still: how often do you change the trim within a flight?
I hope the devo protocol is a more deliberated one...
Last edit: 13 May 2012 18:32 by FDR.

Please Log in or Create an account to join the conversation.

More
13 May 2012 18:51 #291 by FDR
Replied by FDR on topic Re: Protocol Stacks
I thought to a previous topic about the values, calculated by the main UI loop, and then sent by the interrupt: somehow it should be assured, that all the channel values sent out were calculated at once. Since the timer will interrupt the calculating process, it can happen, that for example two channels are freshly calculated, but the rest are from the previous task. I think it can be dangerous...
Not to mention if the interrupt can happen while writing a single multibyte value! Can it be, or they are one clock operations, as I think they are?

Please Log in or Create an account to join the conversation.

More
13 May 2012 19:18 #292 by PhracturedBlue
Replied by PhracturedBlue on topic Re: Protocol Stacks
we are sending commands every msec, I don't think we really need to worry about the values being inconsistent. the amount of change that can happen in a msec isnn't really very much. If you really want to guarantee they are consistent, you can disable interrupts when assigning the variables, but I really doubt that'll be necessary.
Assigning a 32bit value is an atomic operation (non-interuptible), so you shouldn't need to worry about a single channel being corrupt.

Please Log in or Create an account to join the conversation.

More
13 May 2012 19:28 #293 by rcH4x0r
Replied by rcH4x0r on topic Re: Protocol Stacks

FDR wrote: I thought to a previous topic about the values, calculated by the main UI loop, and then sent by the interrupt: somehow it should be assured, that all the channel values sent out were calculated at once. Since the timer will interrupt the calculating process, it can happen, that for example two channels are freshly calculated, but the rest are from the previous task. I think it can be dangerous...
Not to mention if the interrupt can happen while writing a single multibyte value! Can it be, or they are one clock operations, as I think they are?


Don't worry about it, proper design will ensure that only a complete, consistent set of values will be picked up and sent. For example, interrupts will be disabled during the final step of processing, when the 'control mixer' is transferring a new set of data to it's output buffer ready for the transmission in the 'transmit' ISR

Please Log in or Create an account to join the conversation.

More
13 May 2012 19:32 #294 by FDR
Replied by FDR on topic Re: Protocol Stacks
OK, I won't worry too much! ;)
I dont think it would be catastrophic, just for exapmle in case of a mixed only channel, if the master value is from an other calculation than the mixed one, the rx will see it as a jittering or a random noise as opposed to the expected value, because sometimes it is right, but sometimes it's not. But you are probably right, it won't make too much difference in a few ms...

Please Log in or Create an account to join the conversation.

Time to create page: 0.068 seconds
Powered by Kunena Forum