Jan Floras blog

Here is my powerpoint from my presentation yesterday. The slides are not very great, but accompanied by my comments the presentation was ok. It was meant as an introduction to 802.15.4..

802.15.4 intro

Lately I haven’t been writing any posts. That is partly due to the fact, that I’ve been doing some bug fixes and trying to finish up some testing. Since this is pretty straight forward with nothing interesting to report, I haven’t had any news to post.

Also I’ve been participating in my schools anual revue playing drums in the revue band. So things have been a little slow compared to usual.

I found out that I might have some problems handling async state changes in the radio properly.. This is due to the fact, that the receiver is reenabled automatically when the MAC layer is done processing an incoming frame. This is by far the best way to do things, when using the buffer swapping paradigm between the PHY and MAC.

The problem arises, when the MAC layer request radio state changes before returning from the frame receive call. In that case, the PHY layer will just cancel the previous requested state change to try to enable the receiver again. I have fixed this problem, but have to check everything thouroughly to make sure that things work in every case. Also I enable interrupts before signalling the frame to the MAC, to make sure that any intermediate state change can receive interrupts from the radio.

I’ve been complaining about lack of information about the functionality of the RxEnable primitive on coordinators in cluster-tree networks. I’ve searched the internet, checked the bluetooth standard to see if they had similar considerations but it seems no one has addressed this problem. I see that Chipcon recommends that RxEnable is not used in beacon enabled mode at all! I’ve decided to do the following on coordinators in cluster-tree networks:

• RxOnWhenIdle is used to control the receiver in the coordinator superframe.
• RxEnable is used to control the receiver in the device superframe.

This way the functionality of both the RxOnWhenIdle PIB attribute and the RxEnable primitive are well defined. Also I don’t see this design decision imposing any limitations on what can be done by the upper layer.