[Tinyos-devel] 2.0.2 CC2420

Tue Feb 12 12:58:50 PST 2008

Hi David,

Thank you very much for your prompt response.
Could you explain more on "the current ACK frame is inherently broken"?
I think I have to sit down:), trying to do the pure software ACK. As you
mentioned, the extra latency is our biggest concern now. I'm also curious
about how large this extra latency could be for transmitting more bytes
to the radio.

Another concern I have is about the format of an ACK generated by software.
If I set the packet type to be ACK, would cc2420 accept and transmit it?

Thank you,

Jun
On Feb 12, 2008 8:07 AM, David Moss <dmm at rincon.com> wrote:

>  Hi Jun,
>
>
>
> You're correct – the strobe command only sends a single byte to the
> CC2420, and the CC2420 itself automatically generates the ACK frame for the
> packet you just received.
>
>
>
> I'd certainly love to make the hardware generate a different frame because
> the current ACK frame is inherently broken, but we can't change the
> hardware.  The only way around this would be to generate your own ACK frame
> in software and inject it into the radio's TXFIFO for transmission.  The
> only reason that hasn't been done yet is A) someone needs to sit down and do
> it, and B) the ack wait period will probably need to increase due to the
> added delay of generating an acknowledgment in software, which may not be a
> big deal.
>
>
>
> -David
>
>
>
>
>  ------------------------------
>
> *From:* Jun [mailto:yanjunrockets at gmail.com]
> *Sent:* Tuesday, February 12, 2008 3:24 AM
>
> *To:* David Moss
> *Cc:* tinyos-devel at millennium.berkeley.edu
> *Subject:* Re: [Tinyos-devel] 2.0.2 CC2420
>
>
>
> Hi, David,
>
>
>
> I have a question on the difference between SACK and HACK. I traced the
> code
>
> of SACK till CC2420SpiImpIP and found out that strobe() only sends one
> byte
>
> to spi in order to generate an ACK. So does the CC2420 ratio prepare the
> body
>
> of the ACK and sent it?  If that's true, is it possible to generate a
> customized
>
> ACK totally in HW?
>
>
>
> Thank you,
>
>
>
> Jun
>
>
>
>
>
> 2007/7/4 David Moss <dmm at rincon.com>:
>
> I would be very hesitant to allow the baseline CC2420ReceiveP to perform
> its
> former software address check to support this edge case because
> acknowledgement performance may suffer as a whole, which we've already
> seen
> and quantified to some degree.
>
> There are a few timing issues going on with acks in the background to take
> into consideration:  After the Tx mote sends its packet, the SPI bus must
> be
> acquired by the Rx mote.  This resource acquiring may add significant
> delay
> depending on what else is going on with the SPI bus (flash, other task
> handling).  By the time the Rx mote acquires its SPI resource and is able
> to
> download the packet, the Tx mote's ack wait period is winding down.  The
> Rx
> mote must SACK as fast as possible to ensure the ack is received by the Tx
> mote within the ack wait window.  The fastest way to SACK is to download
> the
> first byte (length) and the second byte (fcf) to see if A) we have a valid
> packet and B) if the packet requested an ack.  If we wanted to test for
> the
> address, we'd have to download several more bytes before being able to see
> the destination address.  True, it's only a few more bytes, but it's
> certainly not optimized.
>
> Another way around this case is to do what the BaseStationCC2420 does,
> which
> is override a module from the CC2420 stack with a version that does what
> you
> want.  I've made it fairly easy to do:  there's an FCF_LENGTH parameter in
> CC2420ReceiveP which is currently set to 2 (because the FCF is 2 bytes).
>  By
> setting it to 7, Receive will make sure the packet's length is at least 7
> bytes, read those 7 bytes and SACK, then continue reading the rest of the
> packet.  Because we're reading in 7 bytes from the header before SACK'ing
> instead of 2, the destination address will be available and we can check
> it.
> (attached, this file isn't tested).
>
> If other users agree that this really isn't an edge case and we should see
> this software address check version as the default, then by all means it
> should be in there.  However, SACK's do not perform as well as hardware
> ack's, and it's been my focus to get them optimized as much as possible.
>
>
> -David
>
>
>
>
>
> -----Original Message-----
> From: Chieh-Jan (Mike) Liang [mailto:cliang4 at cs.jhu.edu]
>
> Sent: Wednesday, July 04, 2007 11:20 AM
> To: David Moss
>
> Cc: tinyos-devel at millennium.berkeley.edu
> Subject: Re: [Tinyos-devel] 2.0.2 CC2420
>
> > ....  If you want the base
> > station to disable address recognition to sniff all packets, and also
> send
> > out SACK's when it receives a packet with its address, that's another
> issue.
> >
> > -David
> >
>
> I think this could be useful. In addition, adding address check should
> not affect the two applications you mentioned: base station and sniffer.
> Any thoughts?
>
> Thanks
>
> Mike
>
> > -----Original Message-----
> > From: J. Ryan Stinnett [mailto:jryans at rice.edu]
> > Sent: Tuesday, July 03, 2007 10:45 PM
> > To: David Moss
> > Cc: 'Chieh-Jan (Mike) Liang'; tinyos-devel at millennium.berkeley.edu
> > Subject: Re: RE: [Tinyos-devel] 2.0.2 CC2420
> >
> > Does this have any effect on snooping with CC2420?  Just to confirm, the
> > address recognition feature needs to be disabled as in BaseStationCC2420
> > before snooping will work, is that correct?
> >
> > Thanks,
> > Ryan
> >
> > David Moss wrote:
> >> Yup - there's a good reason for this.  The destination address is
> checked
> >> automatically by hardware while receiving the packet transmission.  So
> by
> >> the time the uC gets the signal that a new packet has arrived, the
> packet
> >> has already gone through the address/pan check.  Therefore, we don't
> need
> > a
> >> second address check in software before issuing a SACK.
> >>
> >> -David
> >>
> >>
> >> -----Original Message-----
> >> From: David Moss [mailto:dmm at rincon.com]
> >> Sent: Tuesday, July 03, 2007 9:45 PM
> >> To: 'Chieh-Jan (Mike) Liang'
> >> Cc: 'tinyos-devel at Millennium.Berkeley.EDU'
> >> Subject: RE: [Tinyos-devel] 2.0.2 CC2420
> >>
> >> Yup - there's a good reason for this.  The destination address is
> checked
> >> automatically by hardware while receiving the packet transmission.  So
> by
> >> the time the uC gets the signal that a new packet has arrived, the
> packet
> >> has already gone through the address/pan check.  Therefore, we don't
> need
> > a
> >> second address check in software before issuing a SACK.
> >>
> >> -David
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: Chieh-Jan (Mike) Liang [mailto:cliang4 at cs.jhu.edu]
> >> Sent: Tuesday, July 03, 2007 7:41 PM
> >> To: David Moss
> >> Cc: tinyos-devel at Millennium.Berkeley.EDU
> >> Subject: Re: [Tinyos-devel] 2.0.2 CC2420
> >>
> >> Something about SACK in the new CC2420 stack is not clear to me. In the
> >> old implementation, before SACK is strobed, the mote ID is compared
> with
> >> the packet destination address. However, this check is not performed
> any
> >> more. Is there any reason behind this?
> >>
> >> Thank you
> >>
> >> Mike
> >>
> >> David Moss wrote:
> >>> Just updated the CC2420 stack in preparation for 2.0.2.  The file
> >>> architecture has been re-arranged a little bit, making it easier to
> see
> >>> how the stack is put together.  As a result, the .platform files that
> >>> reference the cc2420 were updated.
> >>>
> >>>
> >>>
> >>> Test results are included. Let me know if you have any issues.
> >>>
> >>> -David
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Recent Updates (from the readme):
> >>>
> >>> * New chip SPI bus arbitration working with Receive and Transmit.
> >>>
> >>>
> >>>
> >>> * Applied TUnit automated unit testing to CC2420 development
> >>>
> >>>   > Caught lots of bugs, especially through regression testing
> >>>
> >>>   > Source code in tinyos-2.x-contribs/tunit/
> >>>
> >>>
> >>>
> >>> * Applied TEP115 behavior to CC2420 SplitControl in Csma and Lpl
> >>>
> >>>
> >>>
> >>> * Updated ActiveMessageAddressC to provide the ActiveMessageAddress
> >>> interface
> >>>
> >>>   > Updated CC2420ConfigP to handle
> >>> ActiveMessageAddress.addressChanged() and
> >>>
> >>>     sync automatically upon address change events.
> >>>
> >>>
> >>>
> >>> * Updated CC2420Config interface to enable/disable sw/hw
> acknowledgements
> >>>
> >>>
> >>>
> >>> * Updated CC2420ConfigP to share register editing through single
> > functions
> >>>
> >>>
> >>> * Acknowledge after packet length and FCF check out valid.
> >>>
> >>>   > The destination address is confirmed in hardware, so we don't need
> >>>
> >>>     to download the entire header before acking.
> >>>
> >>>
> >>>
> >>> * Moved the getHeader() and getMetadata() commands to an internal
> >> interface
> >>>   called CC2420PacketBody, provided by CC2420PacketC
> >>>
> >>>
> >>>
> >>> * Separated core functionality into different sub-packages/directories
> >>>
> >>>   > Updated micaz, telosb, intelmote2 .platform files
> >>>
> >>>   > Logically organizes code
> >>>
> >>>
> >>>
> >>> * Updated some LPL architecture
> >>>
> >>>   > Removed continuous modulation because it didn't work 100% and I
> >>> don't have
> >>>
> >>>     time to make it work.
> >>>
> >>>   > Decreased backoffs and decreased on-time for detects, saving
> energy.
> >>>
> >>>
> >>>
> >>> * Updated to the new AMPacket interface; made the radio set the
> outbound
> >>>
> >>>   packet's destpan after send().
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> ------------------------------------------------------------------------
> >>>
> >>> _______________________________________________
> >>> Tinyos-devel mailing list
> >>> Tinyos-devel at Millennium.Berkeley.EDU
> >>>
> >
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
> >>
> >>
> >
>
>
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at Millennium.Berkeley.EDU
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>
>
>
>
> --
> --
> Mailto: yanjunrockets at gmail.com
>

-- 
--
Mailto: yanjunrockets at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20080212/c8c9b2cb/attachment.html