I am using TinyOS 1.x, but the question arose when I looked through the code, not from a practical problem of dropped frames.
Thanks for the answer.
I also read about a problem in high contention where the data in the frame will be scrambled.
I think I remember this to be a problem with a erroreous length byte, but I am not completely sure.
Was this revoled or is the source for this error known?
Martin
On 9/20/06, Philip Levis <[EMAIL PROTECTED]> wrote:
On Sep 20, 2006, at 7:17 AM, Martin Gercke wrote:
> Hi,
>
> I would really like to see somebody clear things up for me:
>
> In the CC2420 datasheet it says, that you can switch from "All RX
> states" to TX_CALIBRATE issuing a STXON of STXONCCA.
> What happens if the CC2420 is in state RX_FRAME e.g. and I call STXON?
> Is the frame I am reciving at the moment lost?
> Or is the CC2420 always first receiving the frame and then
> switching to TX-mode?
>
I believe, from my reading of the document (but am not 100% sure)
that you will transition to TX mode if you issue TXON while in the
midst of a frame. Note that CCA has two mechanisms: a RF threshold
*and* whether you are receiving valid 15.4 PHY data. So if you are
receiving a weak packet (below RF threshold) and TXONCCA, then you
will not enter the TX mode.
> There is also this strange thing in the state machine with the SACK
> command strobe.
> It looks like the state is switched directly after SFD is detected
> to TX_ACK_CALIBRATE.
> But the ACK has to know the Sequence number of the frame.
> And it should not stop the reception of the current frame.
The sequence number of the frame is the sequence number of the last
successfully received frame. Note that this can create a timing
issue: this can happen:
receive packet A, signal to software, who decides to SACK it (some
latency occurs)
receive packet B, still in RXFIFO buffer
SACK issued, but radio SACKs B rather than A
You will acknowledge B rather than A, even if you are not the
destination node for B. In TinyOS, at least, this can happen if in
arbitrating for the bus. E.g., if you are doing a lengthy flash
operation. This is why the 2.0 stack does not use SACK; false ACK
positives are really nasty for higher level protocols. The downside
is that, due to how the CC2420 works, if you use hardware (not SACK)
acks, then you can't snoop on packets to other nodes. Boomerang takes
the opposite approach. It uses SACKs so it can snoop, and so it can
incorrectly ACK packets (I've verified that this occurs, at least
with Boomerang versions <= 2.0.3).
> If somebody could clear this up for me, this would be great.
> At the moment I am thinking about if TinyOS might be dropping
> frames because of this.
> But I think this can't be the case, so that's why I am asking this
> here.
>
Are you using 1.x or 2.x?
The 1.x stack can drop frames when it receives them too quickly.
Essentially, it does not let the RXFIFO memory hold more than one
packet. If more than one arrives, it flushes the RXFIFO. I believe
Boomerang does this as well, but as its processing is a little bit
faster it happens a little less often. The TinyOS 2.0 stack does not
drop frames in this way; it spools out packets one by one from the
RFIFO.
Phil
_______________________________________________ Tinyos-help mailing list [email protected] https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
