Protocol Stacks

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

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.

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

That sounds more like the frame rate for the servos

www.helifreak.com/showthread.php?p=3874920

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

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

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