Jan Floras blog

I think I’ve found a great solution for the orphan scanning problem. Instead of just letting the scan time for each channel be predefined as aResponseWaitTime, we need a dynamic wait time like for the other scan types. aResponseWaitTime corresponds (almost) to a scan duration of 5. So by performing a “normal” orphan scan when scan duration is not set, and otherwise just perform a scan similar to the other scan types, this approach will not violate the standard.

It is really strange. When doing an orphan scan, each channel is scanned for at most aResponseWaitTime symbol periods. When sending out an coordinator realignment as a response to the orphan notification frame send out by the scanning device, the realignment message must be send in the CAP when the coordinator is beacon enabled. aResponseWaitTime corresponds to a beacon order of 5.. So if we have a beacon enabled coordinator with at beacon order > 5, we cannot be sure to get a reply when doing orphan scan….

Indirect data transmission is now working. I fixed a bug in the radio driver, causing the ack’s to be discarded because of CRC error on the receiver side. I didn’t wait for the radio to finish up the transmission. Also, I cut away some code from the radio driver by always ack’ing in stream mode. I didn’t think that it was fast enough, but it is

Fixed a bug in the start module. When starting a coordinator in non-beacon mode, the beacon generator would be started anyway. That is not the case now. Also found some new things for my todo list *sigh*…

I’ve corrected the ack error and a couple of other minor bugs. The problem with the ack was, that I’d set the wait time too short. Since a frame reception is first signalled to the MCU after both preamble, start of frame delimiter and frame length indicator has been received, I had to add a total of 12 symbol periods to the wait time to make it correct. And that solved the problem.

So now I have a coordinator that can actually accept associations and disassociate devices. Next up is data transmission from the coordinator. That should be pretty easy, now that I have the indirect transmission queue and beacon generator in place.

It’s been awhile since I last wrote.. I’ve been busy writing coordinator functionality over the weekend. My beacon generator works now, I have an indirect transmission queue, and coordinator association functions are in place.. Now I just have to do some debugging in order to get everything working the way it should. It seems like my device does not receive any acknowledgements upon sending its association requests. So right now I get 3 association requests, the association procedure fails, and afterwards the device extracts the 3 association responses from my coordinator. So it seems that when this ack problem gets solved, my coordinator should actually be capable of having a device associating to it

I’ve been fighting with the receiver control for the last week or so.. On of the problems with RxEnable is to decide, what superframe to enable the receiver in. When running a multihop cluster network, the coordinator nodes have no way of knowing what superframe the RxEnable request is related to!.. Again it seems that I just have to make a decision on what to do.. As usual the standard does not address the problem of multiple superframes. I guess I’ll try to talk to the people in my study group today, to see if anyone has any great suggestions on what to do about this.
I’ve also decided, that the RxEnable request will force the CAP into idle mode (with the receiver on, of course) in the entire duration of the rx on period. If the rx on period extends beyond the CAP, the receiver will be enabled when no other activity (such as GTS’s) with higher priority takes control of the radio.

RxEnable, and a couple of minor things is virtually all that is left before the RFD code is done. Hopefully it won’t be much longer!!

After I found out that the RxEnable primitive works beyond the CAP, I thought it was time for a redesign of the way the receiver “resource” is controlled. Originally my thought was to let the CapControl module handle the CAP period, let the CFP module handle the CFP period and so forth. But with RxEnable “crossing” over these boundaries, it thought it might be better to control the receiver in a dedicated module. So I did a little analysis work to find out, when we can expect to encounter receiver state changes. It looks like this:

CAP:

• When macRxOnWhenIdle is changed
• When the rxOnCount in the CAP module is changed
• When idle in CAP

Other:

• When explicitly requesting to enable/disable receiver (RxEnable, BeaconTracker, CFP)
• When idle in CFP or inactive period

So the conditions for turning on/off the receiver when encountering the above changes looks like this:

Turn on receiver (AND following conditions):

1. NOT(Receiving) AND NOT(Transmitting)
2. (CapActive AND (rxOnCount OR macRxOnWhenIdle)) OR globalRxEnabled

Turn off receiver (AND following conditions):

• Receiving
• NOT((CapActive AND (rxOnCount OR macRxOnWhenIdle)) OR globalRxEnabled)

All this logic will be put into one RxControl module and will hopefully work as intended

I had a few memory leaks due to PIB attribute memory not being released. That is corrected now. I’ve started looking into writing RxEnable. In non-beacon mode this is straight forward. So I’ve already finished that one. In beacon mode there is a challenge, since the rx on period can actually extend into the CFP and idle period, as long as it does not break any CFP activity. That means that I have to move the rx on control from the CAP control module to a higher level (covering both CAP, CFP and idle period).

I’ve added some more stuff to the todo list. There is a few minor details that has to be added/corrected (even though they are not strictly needed at this point) before I can say that my RFD is done Come to think of it, I haven’t tested the orphan scan either. I should probably do that some time soon.

I’m done with rewriting the CAP control module. Seems to work at least as well as before, but now it is possible to adjust the size of the transmit buffers. I’m currently trying to find and fix memory leaks. That should probably take some time. Tomorrow I think I’ll try to write the missing functionality, so that I have a complete RFD.

Data tx and rx is now working. It was a bit of a challenge since the upper layer should be able to send more than one data frame at a time. So a little extra memory management was needed, compared to the association primitives.

I really need to rewrite some of my CAP control code. Right now I only have 4 queue slots, 2 for the coordinator CAP and 2 for the device CAP (I make a distiction between direct and indirect transmitted frames, so one for each type). I have a strong feeling that this will not be sufficient in some (most?) cases. So I want to make a variable size queue for each of the CAPs that can be controlled from a header file. So that is my next task