Jan Floras blog

But instead I just solved all problems regarding beacon tracking I’m using the timers in the radio to be able to delay operations until a future commence time. The problem before was, that I had only one delay slot available and that this slot would potentially be used by operations preceding my beacon rx operation. But by expanding to two delay slots, I can just hand the operation over to the radio driver well before the actual commence time and let the radio driver take care of timing business

And now I really need to get some sleep, before I find myself sleeping on my laptop

Unfortunately, the old code isn’t as reusable as I’d wished. I’ve fixed some minor but fatal flaws in the alarm implementation.. Those were due to the difference between the hardware time and software symbol time.. That is in place now.

My problem is now to time the reception of beacons as tight as possible. The beacon reception can potentially commence just as the CAP or CFP ends, meaning there is only 12 symbol periods in which to do the shift. Maybe it will be necessary to implement some specific PHY code for this.. We’ll have to see about that. But that will be tomorrow, as it is getting kinda late!

Scan works with the new PHY layer now!! Wheeee..

After cleaning up some none trivial bugs and spending half a day writing configuration files, it finally seems like things are getting along.. With scan in place, the next hurdle will be beacon tracking. I’ll return to that tonight.. But first I’ll go and give my drums a good beating I’ve deserved it!!

I didn’t find time to report on my work from last week. This is partly because it was my girlfriends birthday friday, and that I’ve spend the entire weekend having relatives from both families visiting..

But I’ve got the send and receive functionality of the new PHY interface in place. Also it turned out, that when using packet mode to do CCA - CCA - TX, the packet can be written to packet RAM while the CCA operations take place, so that the operation must be startet only 12 symbol periods before the actual commence time. That improve things alot.

So only energy detection left,  and that should just work as always.. So hopefully I’ll have scan and beacon tracking running again at the end of the day.

It’s been awhile since I last posted something here. I took the sunday off (almost). Monday I fixed the ACK timing, so everything should be a-ok with regards to timing. I spend half the monday finding and fixing an annoying bug causing ccaSend to malfunction. But that is history now.

Today was spend working at RealMail and band rehearsals. So only time to do a little wrapping up of the code at this late hour + writing this post.

Hmm, as I was optimizing a little bit on my radio driver code, it struck me, that I’ve completely forgotten to take ACK timing into account. An ACK TX should commence 12 symbol periods after reception in a non-beacon enabled PAN, and between 12 and 12 + 20 symbol periods after reception on a backoff boundary in a beacon enabled PAN.

This also means that we need to be superframe “aware” in some form in the PHY, in order to “hit” the backoff boundary.. But since the reception must start on a backoff boundary, it should be simple math to figure out the timing.

I have some social activities to tend to this evening (who would have imagined? ), so I’ll probably not get around to fixing the ACK timing before sometime tomorrow.

Converting between MCU time and radio time can actually be done quite simple. I the two timers are just reset at approximately the same time and they are “ticking” at the same rate, the timestamps they produce are compatible. It doesn’t matter if they differ a little bit. The reason for that is, that the reference time is decided by the radio (tx and rx times) due to the nature of beacon synchronization. As long as time differences are the same (which they eventually will be), it all cancels out.

I’ve chosen to require the MCU to provide a symbol time granularity timer and alarms. This of course means, that the timer interface needs to support reprogramming of the timer, since the symbol time is dependent on the radio channel used. But that shouldn’t be a big problem, compared to the problems it solves!

With regards to timer wrapping, it will only be an issue that has to be handled by the alarms provided for the two timers. The radio alarms are in hardware, so all is good. The MCU alarms that I already have should be able to handle the wrapping as well.

One last “issue” is the difference in timer precision. The radio only has a 24 bit timer, while I’ll require the MCU to provide 32 bit time stamps. The reason for that is, that a 24 bit timer will wrap in approx. 4-5 minutes using the smallest symbol period, which is 16 micro seconds. So we need to be aware of wrapping issues when converting radio timestamps to MCU timestamps.

As far as I can see, the only thing left now is to finish writing the new PHY interface using the new knowledge gained over the last couple of days. Hopefully no more unexpected issues will arise!

Okay, the problem described in the last post is obviously a bug, but you have to do the “right” thing in order to trigger it, and unfortunately I did!

It turns out that if you initialize your timer compare registers by writing the high register followed by the low register, you will experience the bug I described. If you on the other hand initialize only the high registers, which is enough to disable the comparator functionality, and leave the low register at its out-of-reset value, everything works like a charm!!?

So now I don’t have to worry about that anymore. That means that the radio event timer is free for me to use. Now I only have to figure out a clever way of converting between radio time and MCU time, in order to produce time stamps that can be used to trigger radio operations. I should probably do that first thing tomorrow.. It’s getting kinda late, and it has been a long and productive day

Wheee.. The new dedicated radio driver is done. I’ve done some heavy rewriting of the code, doing optimizations to gain speed. Now, due to executing things in kind of an out of order fasion, the turn around time is down to almost the 9 symbol periods, which is the hardware latency. So it doesn’t get much faster than this, folks

Just barely having solved the previous problems, new ones arise, of course! I discovered a bug in the Freescale radio a while back. It turns out that when the radio is in receive mode, waiting for a frame to arrive, if the event timer wraps, the radio changes back to idle mode. I’ve previously worked around this issue by resetting the event timer on every frame reception. But as my code grows more and more dependent on the radio timers, this is no longer an acceptable solution…

I think I’ll conduct a small test to check up on this problem. Just to convince myself that the problem really does exist, and that it is caused by the wrapping of the event timer. It could be a match on some of the timer registers, like a hidden feature to easily time transition to idle mode. Who knows.

Grrr.. It turns out from my analysis, that the timing when switching between GTS’s or between CAP and CFP is so tight, I really need a dedicated driver to do things as fast as required! Hardware latency for changing mode of operation in the Freescale radio is 9 symbol periods, and the time given, worst case, for this change is 12 symbol periods. This leads to the need of REALLY fast code!

So right now I’m restructuring my code, so that I’ll have one dedicated driver for 802.15.4, and one generic TinyOS driver.