Jan Floras blog

I’ve been working with beacon reception today, trying to implement the functions needed when macAutoRequest is enabled. That is, extracting pending data from the coordinator and passing on beacon payload. I’ve discovered that, when I’m associating, it seems the Freescale coordinator does not get the ACK for the associate response frame. The reason I discovered this is, that the device address remains in the beacon as having a pending transaction.

I’ve also found out that I need to handle the poll timeouts differently than I have done previously. This is due to the fact, that you do not always know what kind of data to expect following a poll.. That means that I have to assume that the next frame received from the coordinator is indeed the pending transaction..

The problem described ealier was not really a bug as much as a todo. I forgot, that radio timestamps are only 24 bits and needs to be extended to 32 bits to be compatible with the MCU timestamps. This led to miscalculations..

I also found another bug that might be a little bit harder to get around. The way the radio works now, an operation can’t be “submitted” to the PHY layer too close to its commence time. This means, that backoff periods < 3 backoff slots are problematic right now. I could just ignore this problem, adding 3 backoff slots to every CAP transmission. This will cause the stack to be a little more inefficient, but will break no compatibility. So this is not at the top of my priority list, but I might look at what can be done to make it better some time in the future...

It is now possible to associate in beacon enabled mode.. That is quite of a progress, since that means that CSMA-CA scheme + the timing of the CAP using beacons is working as it should. This also means that all of my work this past weekend finally pays of, as the weekend and week is coming to an end. I’m pretty exited right now to say the least

There are still some bugs though. After transmitting a few times the transmissions starts to be deferred due to insufficient space in the CAP. This is of course not the case.. Hope to fix that before I go to sleep.

Right now I test using a configuration where the superframe length = beacon interval length. I also have to test this with a shorter superframe, to see if the CAP boudaries are obeyed.

Now associate works That is, one of my devices is able to associate to a Freescale coordinator in non-beacon mode. Next step is to make beacon mode work. I’ve already implemented the sync part, but need to handle timing of CAP and CFP.

The problems with extracting responses from the coordinator in beacon mode has been solved. I decided to wait aResponseWaitTime for the response regardless of mode (beacon or non-beacon). If the response is extracted earlier (due to it being present in the beacon) everything is fine. This should cause no problems.

I’ve run into a problem because the standard isn’t very clear about the timeout when extracting a response from the coordinator using poll.

In a non-beacon enabled PAN all is clear. You send the request, wait aResponseWaitTime symbol periods and then try to extract the response using a data request command.

In a beacon enabled PAN, this are quite different though. The standards says to extract the response when it appears in the coordinator beacon, but also, that we should wait no longer than aResponseWaitTime. The problem is then, when the beacon interval is greater than aResponseWaitTime (which it can easily be!).

I currently see two possible solutions to this. Either we have to poll explicitly when beacon interval > aResponseWaitTime, or the aResponseWaitTime only applies to non-beacon enabled PANs, and we have to time out by some other criteria when the PAN is beacon enabled. I hope to dig up some kind of clue in the standard!

I’ve moved on to making the CAP and CSMA-CA to work, both in beacon and non-beacon networks. I’ve used most of the weekend to get to a point, where the CAP and CSMA functionality should actually work, but it remains untested. I’ve started rewriting the old associate module so that I can test that against the CAP module. Hopefully I’ll have something running tomorrow night, but you know how it is with my predictions.. I’m way too optimistic