Radio Protocol stacks

Any particular requirements ?

- Single master or multi master ?

- Point-to-point, or any-to-any ?

- What do you want to run on top ? TCP/IP traffic, or a simple char stream, or ...?

- Encrypted or not ?

- Automatic discovery or manual setup ?

- One-way to two-way radio ?

Depending on your requirements, 802.11 may be appropriate. If you need something simpler, you could take a subset. The core functionality (data frames + ack) combined DCF backoff is fairly straightforward.

Check Contiki's Rime, "a lightweight communication stacks designed for low-power radios."

Roberto Waltman

[ Please reply to the group, return address is invalid ]

Hi Arlet,

Thanks ! Very articulate questions ! the answers -

1) Single master - Hub-Spoke appraoch. 2) Point to point 3) Preferably TCP/IP traffic for error correction etc. 4) No automatic discovery 5) Two way radio - I am thinking of TDMA allocation for each node and the time allocated to each node further subdivided for two way.

If I use 802.11 protocol or leverage on it , are there any commercial implications to it? or are we free to use it?

I am also looking at 802.15.3 /zigbee as it matches the data rate I am looking for. Has anyone used it?

BR Rate.

WooooW I this is great! I didnt event know software like this was available. I have been looking for a non-premptive event driven kernel for a long time now. Thanks roberto!

I'm not using Contiki, but I am using the underlying protothreads facility, and it's working very nicly so far. Protothreads is especially cool if you enable usage of gcc's "pointer to label" feature: no more restrictions on usage of the switch statement inside a protothread.

--
Grant Edwards                   grante             Yow! I'm having an
                                  at               EMOTIONAL OUTBURST!!  But,
                               visi.com            uh, WHY is there a WAFFLE
                                                   in my PAJAMA POCKET??

Not very clear on what protothreading is exactly , but I am going to read about it very soon! I am assuming it is a event/interrupt driven non-premptive protocol?

Sorry, I should have included a link:

It's the threading facility that Contiki uses.

The papers available in PDF format at

are good reads.

It's a cooperative multi-threading system that doesn't use or disable interrupts. It uses a single stack with only 2-4 bytes of RAM overhead required per thread.

It provides a way to write code that would normally be an FSM in a linear manner using normal control flow mechanisms like loops, if/then/else, etc.

I'm using it for the "foreground" processing on a small system where there's a highly time-critical critical interrupt driven subsystem that can't tolerate the latency that would be caused by any other subsystem either using or disabling interrupts. I was dreading doing the traditional superloop-and-a-bunch-of-FSMs approach, so I went searching for stackless non interrupt disabling therading systems, and protothreads was the best fit for what I needed.

--
Grant Edwards                   grante             Yow! I know things about
                                  at               TROY DONAHUE that can't
                               visi.com            even be PRINTED!!

There may be some free implementations, but it seems you only need a subset anyway. 802.11 works with a single channel shared by all nodes, and collision avoidance by random backoff.

The specification is available on line, see:

It's quite big, but the important stuff is chapter 7 (frame formats), and chapter 9.2 (DCF). If you have a fixed network, you don't really need the beacons and management frames. Basically all you need is the data frame format, and the random backoff mechanism (DCF).

If you want to avoid contention altogether, you could have the master poll all the clients, using the PCF poll frame.

It is a good match for TCP/IP, since it presents itself to the OS as an Ethernet-like interface.

The big headers could be a disadvantage for your relatively slow interface, but you could modify the headers to use shorter addresses.

I've also used the protothread mechanism *inside* an ISR, to replace a state machine.