[Tinyos-help] Can Radio Receive become "Stuck" ?

[Philip Levis]

On Jun 21, 2006, at 4:23 PM, Ted Herman wrote:

> Dear Radio Stack Experts (using moteiv distro, GenericComm interface):
>
> I've got a program that enters a curious behavior.  Initially, for  
> a few
> minutes, it sends and receives messages.  Sending is driven by Timer
> events.  Then it stops receiving messages, though it continues to send
> messages (the sending is done out of a posted task).   I watch the
> messages via sf/TOSBase.
>
> Why do I think it stops receiving messages?  The first thing in the
> ReceiveMsg event is a call to Leds.greenToggle().  During the first
> few minutes, this blinks as one would expect, but then stops blinking
> (other behavior such as the sent message contents confirms the
> hypothesis that the mote is not receiving, though messages are in
> the air to be received).
>

What do you mean "the message contents?" It's always possible that  
down in the data-link layer below GenericComm it's being received,  
but is then being filtered out due to address, AM type, etc.

> Because messages continue to be sent, I reckon the task queue
> can't be such that Led blinking would be inhibited (I welcome being
> corrected on this point, since I'm a T2 newbie).  In fact, I added
> a Leds.redToggle() to the sending task, and I do see the red
> blink once a minute, as expected, even as the receiving is deaf.
>

Your analysis is correct. If you're able to send (specifically,  
timers fire and you get sendDone events), then the task queue is OK.

> What would be the efficient way to diagnose this kind of situation?
>

Joe's suggestion (look at your receive pointers) is a good place to  
start. One easy way to test if you're munging receive pointers is to  
just put a

return msg;

at the top of the function, right after you toggle the LED.

If you do that and the failures continue, then something is happening  
below. You can try instrumenting the AM implementation to see if it's  
receiving packets but then filtering them. If AM isn't receiving  
packets, then you can test to see if the receiving node is entering  
receive states. Basically, as you diagnose the problem as deeper and  
deeper in the stack, then you have to deal with trickier code. I  
haven't used moteiv's distribution for mica-family nodes, but it's my  
general experience that these kinds of problems tend to occur at the  
AM level for some reason or another.

Phil