People Power Company (http://www.peoplepowerco.com) announced its SuRF
Developer Kit (http://www.peoplepowerco.com/developers/) yesterday. This
really is the next generation of open source wireless sensor networks, using
an MSP430XV2 core combined with a radio in a single 7x7 mm system-on-a-chip
Are you compiling in the low power listening layer with the stack? By
default it is not there to save ROM for apps that don't need it. Add lpl
to your make command, like make telosb lpl or just add
CFLAGS+=-DLOW_POWER_LISTENING to your Makefile to add in the LPL layer.
You'll see a warning
Length = length of the header + payload of the packet, minus the size of the
length byte itself (1). This is what allows for variable length packets.
DSN = Data Sequence Number, a number incremented for each packet sent by a
particular node. This is used in acknowledging that packet, and
: #warning
*** LOW POWER COMMUNICATIONS DISABLED ***
make: *** [exe0] Error 1
I do not think you included Blaze.h as an attachment, unless of course I
should have that already.
Thanks in advance.
David
Message: 6
Date: Mon, 21 Jul 2008 10:46:58 -0700
From: David Moss [EMAIL PROTECTED]
Subject
Just calculate it.
Wavelength = c / f
where c = speed of light ~= 3*10^8 m/s, f = frequency
The default channel, 26, is somewhere in the high region of the 2.4 GHz ISM
band, which would be around 2.485 GHz = 2.485*10^9 Hz.
Wavelength(high end) = (3*10^8 m/s) / (2.485*10^9 1/s) =
acquire the SPI bus resource before sending commands over SPI.
-David
-Original Message-
From: Hui Kang [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 17, 2008 10:26 AM
To: David Moss
Cc: tinyos-help@millennium.berkeley.edu
Subject: CCA Check in application layer.
Dear All:
In my
Kang [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 17, 2008 1:27 PM
To: David Moss
Subject: Re: CCA Check in application layer.
David Moss wrote:
Yes, I think it essentially reads the CCA pin as well. Indeed that's what
PowerCycleP uses to see if something else is transmitting on the channel
You can't modify the acknowledgment frame generated by hardware. It is
possible to create your own acknowledgment in software, but that will take
quite a bit of work.
-David
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Maria
Luisa Ruiz de Arbulo
The raw data rate is 250 kbps. You'll never achieve this in any practical
application because of the CSMA channel sharing taking place. The biggest
impedance to throughput is clear channel assessments and the CSMA backoffs.
The acknowledgment wait period is another big delay. SPI bus speeds
Hi Andrea -
You cannot specify a subset of nodes to send a packet to without programming
in your own logic (i.e. deliver the packet to the broadcast address and
include the list of addresses that should accept the packet within the
payload). The AM_BROADCAST_ADDR is the address to use when
Take a look at
http://docs.tinyos.net/index.php/MTS400
We do not actively support this project, but lots of work has been done for
you to pick it up and keep going.
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Antonio
Prados Vilchez
Sent: Tuesday,
There are no backoffs when transmitting an acknowledgment. Even if the ack
is transmitted instantaneously to the receiver, it still takes time to
download and process the acknowledgment from the RXFIFO.
The ack wait period was chosen experimentally in an environment with
multiple
, June 02, 2008 9:29 PM
To: David Moss
Cc: tinyos-help@millennium.berkeley.edu
Subject: Re: DELAY_AFTER_RECEIVE in CC2420 Low Power Listening
It sounds like a sort of virtual carrier sensing. How about introducing a
thing like NAV of 802.11 for a packetized wake-up transmission as a general
approach
_
From: jiwen zhang [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2008 8:11 AM
To: David Moss
Subject: about the metadata of cc2420
Hello David :
as we know , the metadata is not sended when we use the command
AMSend.send to send a packet . Can you explain the function of the metadata
into play.
-David
_
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jongkeun
Na
Sent: Thursday, May 29, 2008 7:24 PM
To: David Moss
Cc: tinyos-help@millennium.berkeley.edu
Subject: Re: DELAY_AFTER_RECEIVE in CC2420 Low Power Listening
Thank you David for your
Of Jongkeun
Na
Sent: Wednesday, May 28, 2008 4:02 PM
To: David Moss; tinyos-help@millennium.berkeley.edu
Subject: DELAY_AFTER_RECEIVE in CC2420 Low Power Listening
Hi David,
I have a question about a parameter used in CC2420 LPL module.
* DELAY_AFTER_RECEIVE=100ms defined in DefaultLpl.h
This value
_
From: jiwen zhang [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 28, 2008 7:03 PM
To: David Moss
Cc: tinyos-help
Subject: Re: About LowPowerListening
Hello David :
about the command setRxSleepInterval() , i want to ask some questions
again .
1. In my test , the sender
I've never experienced an error in the writeDone() event. The error codes
are documented in tos/types/TinyError.h. An error_t is typedef'd to a
uint8_t.
-David
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Paolo
Sent: Friday, May 16, 2008 8:41 AM
To:
Not sure if the error is ever FAIL. It's generated from the underlying
platform's SPI driver, not the CC2420 chip. The error code is always
SUCCESS in writeDone() from my experience.
-David
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Paolo
Sent: Friday,
We miss a packet if the receive interrupt fires and we can't service it.
I'm not sure how often this really occurs because the code was left over
from earlier implementations. The m_missed_packets variable indicates how
many receive interrupts fired that we haven't handled.
The 0-byte
The FCF word contains a few bits that indicate the type of frame is an
acknowledgment frame. It is possible to receive a 5-byte packet that is not
an ack frame but simply noise, where the CRC passes. If the FCF word of a
packet is an acknowledgment type, and the length is 5 bytes, then you
:54 AM
To: David Moss
Cc: tinyos-help@millennium.berkeley.edu
Subject: Re: [Tinyos-help] how to determine SACK packet
Thanks David
another question: the SACK_HEADER_LENGTH variables is set to 7 byte, Why ?
FCF (2B) + DSN(1B) + FCS (2B) = 5B ???
David Moss wrote:
The FCF word contains
Your node has a local sleep interval defining how often the radio wakes up
to perform a receive check.
Other nodes in the vicinity may have different sleep intervals. For
example, maybe you have a node nearby that is not actually part of your
network and is awake all the time.
It would be bad
on retrying for twice the check period in the worst case? Any
insight into how many retransmissions?
Thanks again.
Nitin
On Tue, May 13, 2008 at 1:46 PM, David Moss [EMAIL PROTECTED] wrote:
Your node has a local sleep interval defining how often the radio wakes up
to perform a receive check
This is good stuff. I suggest creating a link to this on
http://docs.tinyos.net http://docs.tinyos.net/ if it hasn't been done
already.
-David
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Joey
Wilson
Sent: Wednesday, April 30,
, 2008 10:40 AM
To: Bulut ERSAVAS
Cc: Omprakash Gnawali; David Moss; Atakan Bodur; tinyos-help (E-mail);
TinyOS Development
Subject: Re: [Tinyos-help] Collection: Loosing Connection to a Node
On Apr 28, 2008, at 9:25 AM, Bulut ERSAVAS wrote:
Hi Phil Omprakash,
It appears that the LPL
You don't need other nodes around for the hardware CCA to show the channel
is in use. WiFi and other transmitters will cause energy and noise on the
channel.
An RSSI based approach is good for deciding the best channel to establish a
network, if you're trying to find a quiet channel.
3 was chosen experimentally, and yes, you may need to jack it up if there is
a lot of other communication interference going on in your band. Or, change
your channel.
-David
_
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jongkeun
Na
Sent: Tuesday, April 15,
No.
The default CC2420 stack always uses CSMA.
-David
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of funofnet
Funofnet
Sent: Sunday, April 13, 2008 9:06 AM
To: tinyos-help@millennium.berkeley.edu
Subject: [Tinyos-help] is it true?
Hi,
Please I whould
Manchester encoding. And CSMA.
Manchester halves the throughput. Instead of 76.8 kbps, Manchester will
force your radio to transmit at 38.4 kbps. Getting rid of Manchester may
not be a simple task: it's there to zero out the energy seen by a receiver,
so it can easily know that it's
of the CC2420,
I'm getting over 40 feet of range, and my motes are
actually buried in
the floor.
I'm pretty sure that doesn't help their range.
Eric
On Mon, Apr 14, 2008 at 9:28 PM, David Moss
[EMAIL PROTECTED] wrote:
If you're thinking about rolling your own hardware, you
should really
polarized wave is much
better. Horizontal polarization gets eaten quickly by the ground. Straighten
out those wire antennas, and add a ground plane.
-David
-Original Message-
From: Michael Schippling [mailto:[EMAIL PROTECTED]
Sent: Monday, April 14, 2008 8:05 PM
To: David Moss
Cc
The functionality youre interested in - reliably link layer transmissions -
is included in the CC2420 radio stack in the PacketLink interface. You can
add the PacketLink layer into the radio stack by adding
CFLAGS+=-DPACKET_LINK into your Makefile. In your software, instead of
requesting an
)
{
enviarDatosBusy = FALSE;
if (call PacketLink.wasDelivered(msg)) dataSendDone = dataSendDone +
1; //The value is always the init value (0).
//There is a code below and it runs.
}
}
Thanks in advance,
Juan Antonio.
- Original Message -
From: David Moss mailto
The proper way to disable CCA is to tell the radio to transmit without CCA.
I don't support Tinyos 1.x, but if you look for a strobe command like
STXONCCA and change it to STXON then the radio will not use clear
channel assessments and there should never be a congestion backoff. The
initial
The indicators in the CC2420 stack are used for low power listening
strategies. In this case, the byte indicator is high when the radio is
receiving bytes, and low when the radio is not receiving bytes: it follows
the SFD line exactly, and produces the same result whether you're
transmitting or
From the datasheet:
Two command strobes, SACK and
SACKPEND are defined to transmit
acknowledge frames with the frame
pending field cleared or set, respectively.
The acknowledge frame is only
transmitted if the CRC is valid.
The CRC is checked in hardware before the acknowledgment
The CC1000 and CC2420 radios are completely different, with no relation to
each other.
Disabling CCA is easy to do in TinyOS 2.x: you just capture requestCca()
event in the RadioBackoff interface, provided by CC2420CsmaC, and call back
within that event to setCca(FALSE).
TinyOS 1.x is no
any remaining valid packets out?
-David
-Original Message-
From: Liusand [mailto:[EMAIL PROTECTED]
Sent: Friday, March 14, 2008 10:33 PM
To: David Moss; tinyos-help@millennium.berkeley.edu
Subject: Re: [Tinyos-help] TXFIFO underflow not taken care of in TinyOS
2.0.2?
Thanks, David.
I
increases
the throughput.
-David
-Original Message-
From: Liusand [mailto:[EMAIL PROTECTED]
Sent: Monday, March 17, 2008 8:08 AM
To: David Moss; tinyos-help@millennium.berkeley.edu
Subject: Re: [Tinyos-help] TXFIFO underflow not taken care of in TinyOS
2.0.2?
Hi David,
Thanks
The TX FIFO is preloaded with data. The data is not being transmitted to
the CC2420 as the transmission is taking place, unlike other chips. Because
of the preload, it is impossible for the CC2420 to produce a TXFIFO
UNDERFLOW. All the data to send is available on the chip when transmit
occurs.
The ACK should be generated for the packet you're currently reading out of
the RXFIFO. The ACK will only be issued if the packet you're currently
reading out has a valid CRC.
-David
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Liusand
Sent:
The status byte returned by the command over SPI is not important in this
particular case, so we ignore it intentionally. In order to get a receive()
event fired, the radio must be in the proper state, and therefore
beginRead() will always succeeds.
The status byte is important when the radio
The RadioBackoff interface is designed to allow (possible several) modules
in your application layer to listen in on what the radio stack is doing, and
decide whether or not to affect the operation of CSMA. Unlike the former
CsmaBackoff interface, a module is not required to affect the operation
I've been successful in getting the most basic TinyOS 2.x application to
compile for a PIC18F85J11 using the CCS compiler. This required a custom
application to mangle the app.c output of nesC so CCS could compile it.
This is a preliminary start. Now, implementations are needed for things
like
The wiki is incorrect, and I'll update it. Your observations on the
datasheet are correct.
The actual CRC check in software is done after the SACK has been issued, but
the hardware is intelligent enough to know not to send an ACK if the CRC
failed.
-David
_
From: [EMAIL
UniqueSend is simply a layer inside of radio stacks, providing the Send
interface to layers above, and using the Send as SubSend interface to
connect to layers below. Its purpose is to set a unique DSN (data sequence
number) byte in the packet's header on the way out.
There's a reference
There's another aspect to consider here as well: uC-to-uC serial
communications. Although I haven't looked into it much deeper, I suspect
TinyOS's asymmetric serial acknowledgments could be playing a part in the
failures we've seen in preliminary attempts to get uC's to talk through
their serial
Are you requesting an acknowledgment before sending?
call PacketAcknowledgements.requestAck(myMsg);
call AMSend.send(0x0, myMsg, sizeof(my_payload_t));
Does it the software work as expected using software acknowledgments?
-David
-Original Message-
From: [EMAIL PROTECTED]
: Rodolfo de Paz Alberola [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 14, 2008 9:12 AM
To: David Moss
Cc: 'tinyos-help'
Subject: RE: [Tinyos-help] CC2420 Hardware ACKs
Hi David,
On Thu, 2008-02-14 at 08:56 -0700, David Moss wrote:
Are you requesting an acknowledgment before sending?
call
9:12 AM
To: David Moss
Cc: 'tinyos-help'
Subject: RE: [Tinyos-help] CC2420 Hardware ACKs
Hi David,
On Thu, 2008-02-14 at 08:56 -0700, David Moss wrote:
Are you requesting an acknowledgment before sending?
call PacketAcknowledgements.requestAck(myMsg);
call AMSend.send(0x0, myMsg, sizeof
acknowledgments will be the default
(MDMCTRL0.AUTOACK = 1) and software acknowledgments will be disabled.
-David
-Original Message-
From: Rodolfo de Paz Alberola [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 14, 2008 1:01 PM
To: David Moss
Cc: tinyos-help
Subject: RE: [Tinyos-help
settings, but I would be
hesitant to make those kinds of changes without a lot of backing.
-David
-Original Message-
From: Matt Welsh [mailto:[EMAIL PROTECTED] On Behalf Of Matt Welsh
Sent: Wednesday, February 06, 2008 3:10 PM
To: David Moss
Cc: 'TinyOS Development'; 'tinyos-help
This is what the ActiveMessageAddressC component is supposed to handle in
2.0.2, although it won't change the enum / defined TOS_AM_GROUP.
call ActiveMessageAddress.setAddress(am_group_t group, am_addr_t addr);
You should always access TOS_AM_GROUP through call
I just added a hook to the CC2420 radio stack in CVS to configure an
outbound message. The interface is called SendNotifier, and has a single
event:
event void aboutToSend(am_addr_t addr, message_t *msg);
This event is provided by CC2420ActiveMessageC, and is parameterized by
am_id_t.
Dane Murdock here at Rincon discovered an edge case bug with the CC2420
receive branch when applying TUnit unit testing to CC2420ReceiveP.
This edge case occurred only with receiving a full payload. Having a
complete payload to download, the RSSI and LQI bytes were automatically
downloaded
I can answer the part about why CC1100?
The CC1100 radio can operate around 315 MHz, 433 MHz, and 915 MHz. The
lower the frequency, the farther range you'll be able to transmit, and at a
lower power output level (less energy). At 315 MHz, for example, we're able
to transmit using a CC1100
Hi Tie,
Sorry, I've been on vacation for awhile and will continue to be on vacation
for the next week.
The CC2420 radio stack uses a combination of B-MAC and X-MAC. Its behavior
is a lot like X-MAC in that transmissions get cut short, but the actual
detection of a transmitter is done more
), but due to the
custom nature of the system it is somewhat difficult to do so.
-David
_
From: zhiyong yang [mailto:[EMAIL PROTECTED]
Sent: Friday, December 21, 2007 2:49 AM
To: David Moss
Subject: Re: [Tinyos-help] tinyos 2.x radio
Hi:
I have a question. How did you
-Original Message-
From: Tiago Camilo [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 19, 2007 10:20 AM
To: David Moss
Cc: 'André Miguel de Almeida Marrão Rodrigues';
tinyos-help@millennium.berkeley.edu
Subject: Re: [Tinyos-help] Hardware Address Recognition
Hi David,
I tried
1. FIFO and FIFOP are GPIO pins provided by the CC2420 radio. These are
status pins, and I believe they're used to indicate data exists in the RX
FIFO that can be read out by the microcontroller. The datasheet provides
more details.
2. If you haven't toggled the CSN line, and haven't used the
The answer mostly depends on how noisy your network is.
A CC2420 radio that is always left on (1.x) will consume ~462 mAh/day. To
put this amount of power in perspective, your node will last about 3.6 days
on a 1700 mAh (cell phone) battery.
Obviously if you have setup a network where
: Thursday, December 13, 2007 3:04 PM
To: David Moss; tinyos-help@Millennium.Berkeley.EDU
Subject: Re: [Tinyos-help] Hardware Address Recognition
Hi
The base station does not automatically retransmit failed packets.
It means that I should change the code of the standard basestation that
comes with T2.02
Address recognition is in both hardware and software. You can disable
address recognition in hardware to sniff packets, but with software
acknowledgements enabled you don't want to send an ack back unless you've
received a packet to your local address or to the broadcast address. That's
why
receiver?
-David
-Original Message-
From: André Miguel de Almeida Marrão Rodrigues
[mailto:[EMAIL PROTECTED]
Sent: Thursday, December 13, 2007 11:20 AM
To: David Moss; 'André Cunha'; 'TinyOS ML'
Subject: Re: [Tinyos-help] Hardware Address Recognition
Hi
I would like to know why in a simple
Looks like you have a space between bsl, and the com port identifier
mote target=telosb
motecom=serial@/dev/tty.usbserial-M4AJRG09:telosb installextras=bsl,
133/
You can see from the tos-bsl line TUnit is trying to execute that it doesn't
know what's going on:
tos-bsl --telosb -c
Modify the TX_MODE setting in the MDMCTRL1 register to enable the infinite
retransmissions test mode. This will continuously retransmit the contents
of the TXFIFO.
-David
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Alban
Hessler
Sent: Wednesday, November 14,
Yup. BaseStationCC2420 is deprecated because the CC2420 stack has the
ability to enable/disable auto-acks and address recognition at compile time.
There's no longer a need to maintain two separate portions of the CC2420
stack.
-David
-Original Message-
From: [EMAIL PROTECTED]
at that micaz
platform code for the CC2420 to see what it's doing, and then use the CC1100
platform code examples to port it over in the micaz mindset.
-David
_
From: jiwen zhang [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 06, 2007 4:44 AM
To: David Moss
Subject: Re
Although the LOW_POWER_LISTENING compiler flag will add in the low power
listening layer into the radio stack, some other functionality needs to
exist to tell it what to do.
Currently, CTP does not instruct the radio stack to use low power listening.
To make it happen, right now developers have
delivered a packet to a
node, it should send the next packet with no packetized wake-up
transmission. I'll ensure this gets documented.
-David
-Original Message-
From: Murray, Ben [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 31, 2007 1:44 AM
To: 'David Moss'; Murray, Ben; 'Tinyos
) and the time synch apps
should check for that flag.
Miklos
On 10/30/07, David Moss [EMAIL PROTECTED] wrote:
I haven't done much work with the timestamps in the CC2420 apart from
Jonathan's original implementation, nor have I used it enough to have
experienced any type of erratic behavior
RECEIVE CHECK / RADIO POWER:
In 2.0.2 (and possibly earlier versions) the PowerCycleC configuration
provides two State interfaces:
interface State as SplitControlState;
interface State as RadioPowerState;
The State enumerator, which should actually be located in a header file and
not the
Here's one possible explanation: the CSMA backoff changed between T1 and T2.
In T1, the CSMA backoff wasn't very fair, allowing one transmitter to
possibly hog the channel. The CSMA congestion and initial backoffs were
flipped in T2, making the initial backoff longer and the congestion backoff
I haven't done much work with the timestamps in the CC2420 apart from
Jonathan's original implementation, nor have I used it enough to have
experienced any type of erratic behavior. Is the issue here that the 16-bit
timestamp rolls over to 0 periodically? Would a 32-bit timestamp be better?
You may have to take this application as an example and convert it to
provide the information you're looking for. This app's original intention
was to give you a warm fuzzy feeling about RSSI coming out of the CC2420.
Page 49 of the CC2420 data sheet offers more information about RSSI and
If you get a sendDone() event and call your next send() event quickly
(within tens of milliseconds) then both radios will still be awake and you
will be communicating at 100% throughput. Both radios will remain active as
long as there is useful communication taking place. In this manner,
multiple
Hi Gustavo,
First off, glad to see someone trying out this radio stack even though
there's no commercial hardware available.
I think the main problem here is the TinyOS 2.x baseline interfaces recently
changed and are not compatible with TinyOS-2.0.2. The AMPacket, Packet,
AMSend, etc.
Rx is default for everything.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ricardo
Tiago
Sent: Sunday, September 30, 2007 6:45 PM
To: tinyos-help@Millennium.Berkeley.EDU
Subject: [Tinyos-help] CC2420 Radio
Hi,
When the cc2420 radio is turned on , in
It's all done in hardware, so all the information related to RSSI sampling
can be found in the CC2420 datasheet.
http://www.stanford.edu/class/cs244e/papers/cc2420.pdf
-David
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tal Rusak
Sent: Thursday,
The microcontroller sleep period and the radio duty cycling are completely
separate. The microcontroller sleep functionality is built into the TinyOS
operating system - when there are no tasks to execute in the scheduler, the
microcontroller goes to sleep automatically.
In order to use the
, 2007 7:05 AM
To: Murray, Ben; 'tinyos-help@Millennium.Berkeley.EDU'; 'David Moss'
Subject: RE: [Tinyos-help] low power listening -- anomalous/random 100-200
ms delay/skew?
I think I may have found the answer to my own question :-) but I have a new
question now, but I will put that in a new e-mail
- if performance doesn't suffer, then go with it
-David
-Original Message-
From: Mischa Weise [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 27, 2007 9:49 AM
To: David Moss
Cc: tinyos-help@Millennium.Berkeley.EDU
Subject: Re: [Tinyos-help] low power listening -- anomalous/random 100
PROTECTED]
Sent: Thursday, September 27, 2007 10:34 AM
To: 'Mischa Weise'; David Moss
Cc: tinyos-help@Millennium.Berkeley.EDU
Subject: RE: [Tinyos-help] low power listening -- anomalous/random 100-200
ms delay/skew?
It may also be possible to specify different Timer settings for packets and
spurious
PROTECTED]
Sent: Monday, September 24, 2007 10:50 PM
To: David Moss
Cc: tinyos-help@millennium.berkeley.edu
Subject: Re: [Tinyos-help] CC2420 packet delivery
Hi David,
if a STXON command strobe is issued, during the receiption of a packet I'm
sure the radio will transmit it. If the received bytes
Phil's case is important. I've seen a lot of support in TinyOS for
split-phase debugging output. But there's this whole other area where
single-phase debugging output is critical, i.e. tracing through code as it
executes or trying to get something to print out before the uC gets locked
up in a
PROTECTED]
Sent: Saturday, September 22, 2007 1:33 PM
To: David Moss
Subject: Re: [Tinyos-devel] Re: [Tinyos-help] Question about printf
The directserial directory isnt there.
Kevin
On 9/22/07, David Moss [EMAIL PROTECTED] wrote:
Phil's case is important. I've seen a lot of support in TinyOS
Typically you don't need more flash than what is specified by the ROM size
at compile time. But you should be concerned about RAM. The RAM size
specified at compile time is only the heap. The stack space is not taken
into account - so your platform should have sufficiently more RAM than what
Never explicitly tried it before with the intention of noting the results,
but your node should transmit, leaving the RXFIFO turned to garbage and
filtered out naturally by the receive methods (i.e. checking for a proper
length byte and CRC). I could be wrong, but note that having two
You guys are moving the C73 capacitor over to connect the external antenna,
right?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Michael
Schippling
Sent: Thursday, September 13, 2007 10:25 AM
To: André Miguel de Almeida Marrão Rodrigues
Cc:
What version of TinyOS are you using? If you're using the NoAck LPL layer
from 2.0.1, that would exhibit the behavior you describe, and I'd recommend
using something different.
For all other scenarios, the motes should go back to sleep if a transmitter
continuously sends the same message at
The correct answer to your first question is A, because a one-shot timer is
used in the LPL layer. The use of a one-shot resets the timer after every
wake-up, which allows you to change the period arbitrarily after the next
timer fire.
Your second question concerns a synchronous low power
of the low power
listening implementation
-David
_
From: Murray, Ben [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 06, 2007 10:35 AM
To: 'David Moss'; Murray, Ben; tinyos-help@Millennium.Berkeley.EDU
Subject: RE: [Tinyos-help] forcing a node in LPL mode to stop listening
Hi Arpan -
I'm not sure what the problem could be off hand, as I'm not familiar with
the test network application. I'm forwarding your request to the
tinyos-help mailing list to see if anyone else can help,
-David
_
From: Arpan Solanki [mailto:[EMAIL PROTECTED]
Sent:
peripheral on
SPI0) then you can safely lower the CC2420_ACK_WAIT_DELAY value and maintain
the same acknowledgement reception reliability.
-David
-Original Message-
From: Tony O'Donovan [mailto:[EMAIL PROTECTED]
Sent: Monday, September 03, 2007 4:07 AM
To: David Moss
Subject: Re
for
other motes. If this is not the case, let me know and we'll need test it
out further.
-David
-Original Message-
From: Tiago Camilo [mailto:[EMAIL PROTECTED]
Sent: Friday, August 24, 2007 4:01 AM
To: David Moss
Cc: tinyos-help@Millennium.Berkeley.EDU
Subject: Re: [Tinyos-help
Tiago -
BaseStationCC2420 was removed in 2.0.2 because it is no longer necessary.
It was originally there because the CC2420ControlP module needed some
special modifications. Now, because those modifications are now controlled
by software and/or preprocessor variables in the 2.0.2 CC2420 stack,
LPL has not been formally integrated into collection or dissemination. Your
nodes' radios are off most of the time - in your case, they're asleep for
about a full second before waking up momentarily to see if something else is
talking. This naturally causes significant delays in getting a
Although I don't have much advice on clock drift, the CC2420 low power
listening transmitter (micaz / tmote) should transmit a little longer than
the receive check period, ensuring overlap.
In the case of the CC2420, the 5 ms is approximately how long the radio is
in receive mode. The radio
I'd like to take a look at this, but will be unavailable to do so today.
Tomorrow I'll probably have time to investigate and get back with you.
Thanks for the report
-David
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tiago
Camilo
Sent: Wednesday,
1 - 100 of 296 matches
Mail list logo
