[Tinyos-help] SuRF Developer's Kit / OSHAN Announcements
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 (http://focus.ti.com/docs/prod/folders/print/cc430f5137.html). These chips are not even in production yet, but we got our hands on a bunch, and we're making them available to other wireless sensor network developers. And... they're running TinyOS. Check out the specs sheet on this SuRF developer platform: http://www.peoplepowerco.com/developers/SuRFQuickSpec.pdf. Since the core of the platform is so small, we made the developer board nice and large so you can get your hands in there to prototype new wireless devices. The CC430F5137 SoC featured on the SuRF platform contains all kinds of goodies: * MSPGCC4 support (available now on https://sourceforge.net/projects/mspgcc4/http://sourceforge.net/projects/oshan/ ) * RF1A Radio (300 - 900 MHz with SuRF's matching network configured for 900 MHz, up to +10 dBm, 2-FSK / GFSK / MSK / OOK / ASK modulation, data rates up to 500 kbps, and 255+ byte packets). * The radio gives you at least 2-3x the range of older 2.4 GHz platforms. This kind of range is critical for making consumer home wireless electronics work reliably. * AES-128 and CRC coprocessor * USCI (UART, SPI, IrDA- and I2C-capable) * FLL so you can operate it without an external crystal * Real-time-clock * 12-bit ADC's * 96-segment LCD support is available on the CC430F6137 version of the chip, which is not included on SuRF. We've produced a Linux Live DVD with Ubuntu 9.10 and the next release of TinyOS for the community, and links to the ISO will be posted later this month. The Live DVD will also contain an early version of OSHAN, which stands for Open Source Home Area Network. OSHAN, which is also covered by a BSD license, sits side-by-side with the TinyOS baseline to extend it and provide functionality developers need to commercialize home consumer wireless devices. The SuRF developer kit is a tool to get started with OSHAN. The development process for OSHAN is based on the practices used by Linus Torvalds to guide Linux, with Dr. Peter Bigot as the gatekeeper for OSHAN and its git repository. SuRF and OSHAN received a lot of press during its announcement yesterday. Here are a few articles: http://venturebeat.com/2010/03/15/people-power-releases-sdk-for-wireless-home-energy-sensors/ http://www.techthefuture.com/technology/surf-sdk-diy-smart-grid/ http://www.networkworld.com/news/2010/031510-people-power-pushes-green-wireless.html http://www.infoworld.com/d/developer-world/people-power-pushes-green-wireless-apps-664 http://www.earthtechling.com/2010/03/surf-smart-grid-kit-lets-you-develop-own-smart-grid-device/ http://earth2tech.com/2010/03/15/get-your-open-source-home-energy-developer-kit-courtesy-of-people-power/ http://blogs.zdnet.com/green/?p=10659 http://green.tmcnet.com/topics/green/articles/78637-people-power-intros-wireless-apps-potential-green-apps.htm Of course, leave it to the press to muddle a few facts: TinyOS has thousands of developers, OSHAN is getting ramped up. If you're interested in getting involved with the development of OSHAN, which will remain freely available and strong enough to use in real commercial devices, please contact me. Finally, People Power will be hosting SuRF Competition ( http://www.peoplepowerco.com/contest/). We're giving developers and researchers several months to produce something cool with SuRF, and the winner(s) will be selected by our technical advisory board. The winner will receive 5,000 shares of People Power stock options (someday worth millions), $5,000 USD, and a free SuRF Developer's Kit. You can pre-order your SuRF developer kit here: http://www.peoplepowerco.com/store/surf-developer-s-kit.html. We'll keep you updated as more open source developments are available. Enjoy, -David ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] CC2420 energy consumptions
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 telling you the LPL layer has been compiled in. You should only have to call setLocalSleepInterval once at the start of your application. After that, the layer in the radio stack responsible for managing radio power will automatically put the radio back to sleep when no more activity is found on the channel. The amount of time the radio is awake after activity is programmable by editing the DELAY_AFTER_RECEIVE preprocessor variable found in DefaultLpl.h (in the latest stack version). -David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rediviva Goth Sent: Thursday, September 25, 2008 12:18 PM To: tinyos-help@millennium.berkeley.edu Subject: [Tinyos-help] CC2420 energy consumptions Hi to all I am an engineering student and I'm studying consumptions for the CC2420 radio. I have noticed that energy consumptions are very high and I tried to use LPL interface to reduce consumptions. In my test program I switched the radio, I set the timer and when it is called the event fired I send data to another mote. Every time I send data invoke the command setLocalSleepInterval to avoid unnecessary energy consumptions of radio, but consumption remains unchanged. How should I use interface LPL? someone can show me an example code if it is possible? Thank you Sarah Rediviva ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] 802.15.4 TinyOS Qs
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 also
filtering out duplicate packets.
Type = TinyOS AM type. When you create a new AMSenderC(AM_WHATEVER), the
AM_WHATEVER definition is the type of packet.
TOSH_DATA_LENGTH defaults to 28, it represents the maximum size of the
payload portion of the packet, and is specified in the tos/types/message.h
file.
All of these fields will be filled in automatically by the radio stack when
you attempt to send a message.
-David
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jim Fell
Sent: Friday, September 05, 2008 8:45 AM
To: tinyos-help@millennium.berkeley.edu
Cc: Jim Fell
Subject: [Tinyos-help] 802.15.4 TinyOS Qs
Hello. On lines 45 through 59 of ./tinyos-2.x/tos/chips/cc2420/CC2420.h the
CC2420 header is specified:
typedef nx_struct cc2420_header_t {
nxle_uint8_t length;
nxle_uint16_t fcf; // Frame Control (Field)
nxle_uint8_t dsn;
nxle_uint16_t destpan; // Destination PAN ID
nxle_uint16_t dest; // Destination address
nxle_uint16_t src; // Source address
/** I-Frame 6LowPAN interoperability byte */
#ifdef CC2420_IFRAME_TYPE
nxle_uint8_t network; // I-frame (interoperability frame) byte
#endif
nxle_uint8_t type; // Packet type
} cc2420_header_t;
Can someone please clarify for me what the length and dsn fields are? Is
dsn Device Sequence Number? How is length used?
Can the type field be anything? For example, if I wanted to add additional
RF commands to the stack, could I make my own definitions using this type
field to specify each, or is it a static field?
Where is the maximum payload size specified? Is it TOSH_DATA_LENGTH (line
96 of CC2420.h)?
Thanks,
-Jim
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] PacketLink
Sorry, not sure why Blaze.h was being included. Please replace all occurrences of #include Blaze.h with #include CC2420.h. You won't need the blaze.h file. FYI, blaze is the project name of another radio stack that uses the CC1100/CC2500 radios. -David -Original Message- From: David Valencia [mailto:[EMAIL PROTECTED] Sent: Monday, July 21, 2008 11:40 AM To: [EMAIL PROTECTED] Cc: tinyos-help@millennium.berkeley.edu Subject: Re: PacketLink Thanks David for the abrupt reply. I grabbed those attachments, did what you told me but I got the following compiler errors: /opt/tinyos-2.x/tos/chips/cc2420/unique/DummyReceiveP.nc:2:19: Blaze.h: No such file or directory In file included from /opt/tinyos-2.x/tos/chips/cc2420/CC2420ActiveMessageC.nc:6 3, from /opt/tinyos-2.x/tos/platforms/telosa/ActiveMessageC.nc:64, from BaseStationC.nc:71: In component `UniqueReceiveC': /opt/tinyos-2.x/tos/chips/cc2420/unique/UniqueReceiveC.nc:69: failed to preprocess /opt/tinyos-2.x/tos/chips/cc2420/unique/DummyReceiveP.nc /opt/tinyos-2.x/tos/chips/cc2420/unique/UniqueReceiveC.nc:70: no match /opt/tinyos-2.x/tos/chips/cc2420/lpl/DummyLplC.nc:39:2: warning: #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: Re: [Tinyos-help] PacketLink To: 'David Valencia' [EMAIL PROTECTED], tinyos-help@millennium.berkeley.edu Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii By default, the base station will filter out duplicate packets just like any other node. It will not display the retransmission attempts. I've attached a few files you can drop into your tos/chips/cc2420/unique directory that will bypass the UniqueReceive layer if RECEIVE_HISTORY_SIZE = 0. This will stop the filtering of duplicate packets. Just do a CFLAGS+=-DRECEIVE_HISTORY_SIZE=0 in your BaseStation Makefile. -David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Valencia Sent: Monday, July 21, 2008 10:37 AM To: tinyos-help@millennium.berkeley.edu Subject: [Tinyos-help] PacketLink When using the PacketLink interface, and a node requires retransmission of a packet, if a BaseStation is being used to monitor network activity will the BaseStation see all of the retransmission attempts? As a simple test, I setup one node to transmit a packet using: call PacketLink.setRetries(Msg, 30); call PacketLink.setRetryDelay(Msg, 10); before I send, and it transmits to a destination address of a mote that is not on so I can force the retransmission. I have a mote programmed with the BaseStation application and all the BaseStation picks up is the initial packet sent by the mote but not the re-transmissions. -- Development environment: CYGWIN Platform: TelosB (tinyos-2.x: cvs disribution) ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- next part -- A non-text attachment was scrubbed... Name: DummyReceiveP.nc Type: application/octet-stream Size: 209 bytes Desc: not available Url : https://www.millennium.berkeley.edu/pipermail/tinyos-help/attachments/200807 21/64b9318b/attachment.obj -- next part -- A non-text attachment was scrubbed... Name: UniqueReceive.h Type: application/octet-stream Size: 1887 bytes Desc: not available Url : https://www.millennium.berkeley.edu/pipermail/tinyos-help/attachments/200807 21/64b9318b/attachment-0001.obj -- next part -- A non-text attachment was scrubbed... Name: UniqueReceiveC.nc Type: application/octet-stream Size: 2583 bytes Desc: not available Url : https://www.millennium.berkeley.edu/pipermail/tinyos-help/attachments/200807 21/64b9318b/attachment-0002.obj -- next part -- A non-text attachment was scrubbed... Name: UniqueReceiveP.nc Type: application/octet-stream Size: 5517 bytes Desc: not available Url : https://www.millennium.berkeley.edu/pipermail/tinyos-help/attachments/200807 21/64b9318b/attachment-0003.obj -- ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help End of Tinyos-help Digest, Vol 63, Issue 95 *** -- Development environment: CYGWIN Platform: TelosB (tinyos-2.x: cvs disribution) ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman
Re: [Tinyos-help] wavelength
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) = 0.1208 meters = 12.08 cm. The low end of the 2.4 GHz is 2.400 GHz. so the wavelength there is: Wavelength(low end) = (3*10^8 m/s) / (2.0*10^9 Hz) = 15 centimeters So the wavelength is between 12 to 15 centimeters, depending on which channel you're sitting on. 13 centimeters is a good answer. -David _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nahr ... Sent: Friday, July 18, 2008 5:37 AM To: Ittipong Khemapech Cc: tinyos-help Subject: Re: [Tinyos-help] wavelength I am using cc2420 chipcon with micaz mote I think I should review CC2420 datasheet Thanks for all 2008/7/18 Ittipong Khemapech [EMAIL PROTECTED]: It depends upon at which frequency they are working, I guess. Ittipong 2008/7/18 Nahr ... [EMAIL PROTECTED]: Hi all, Which is the wavelength of the signals generated by the motes in the TinyOS implementation? Thanks a lot. Nahr Elk ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] CCA Check in application layer.
If you want to check the channel *before* sending a packet, you can sample
the CCA pin directly. This GeneralIO is provided by HplCC2420PinsC.
The code you're looking at here actually sends a packet, if the channel is
immediately found to be clear. If you're not doing so already, you must
also 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 tinyos-2.x application, I would like to check the channel before
sending a packet. By copying the following code from CC2420TransmitP.nc,
I found the congest is always set as TRUE even I have only one mote turn
on. Could anyone help to solve this problem or any other smarter way to
check CCA? Thanks.
uint8_t status;
bool congestion = TRUE;
atomic{
call CSN.clr();
status = call STXONCCA.strobe();
if ( !( status CC2420_STATUS_TX_ACTIVE ) ) {
status = call SNOP.strobe();
if ( status CC2420_STATUS_TX_ACTIVE ) {
congestion = FALSE;
}
}
call CSN.set();
}
- Hui
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] CCA Check in application layer.
Clear channel assessments are performed automatically by the CC2420 radio
stack before any and every transmission, unless you explicitly disable it.
In the CC2420 radio, a CSMA strategy is implemented where initial and
congestion backoffs are set for random lengths of time to prevent
transmissions from taking place at the same time. These backoffs use an
alarm that fires asynchronously, interrupting any code you have executing,
unless you have your code in an atomic block.
When the backoff timer fires, the radio chip itself is responsible for
sampling the channel to make sure the channel is clear before proceeding
with a transmission.
There is a case where two radios attempt to transmit at exactly the same
time, sample the channel and see it's clear, and proceed to collide. This
doesn't happen too often, but it does exist.
If the channel is found to be in use at the time it is sampled, a congestion
backoff will allow the radio to wait for a random period of time before
trying again.
If you are attempting to add in your own channel sharing CSMA functionality
in the application layer to make sure the channel is clear before sending,
you'll find it to be of no use: the initial backoff set in the radio stack
will automatically cause a significant delay before sending the packet. By
the time the packet begins transmitting out of the radio, it could be
several milliseconds after you gave the initial command to send.
-David
-Original Message-
From: Hui 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.
But there is still a problem. When two nodes start the loop at the same
time, they will not receive any message. Then when exiting the loop,
they start sending message together, which causes some collision. Is
this correct?
- Hui
-David
-Original Message-
From: Hui Kang [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 17, 2008 1:04 PM
To: David Moss
Subject: Re: CCA Check in application layer.
Hi, David,
I find the interface ReceiveIndicator may be more suitable; it is used
by PowerCycleP.
- Hui
David Moss wrote:
Is this in a while() loop? In other words, how fast are you sampling?
Message transmissions can be on the order of ~1 ms.
If you have a node sitting there checking the CCA pin, and another node
transmitting nearby, do you see the LED's toggle from the CCA pin
toggling?
Take a look at the PowerCycleP module in the low power listening
implementation. It monitors the channel for activity using the CCA pin to
determine if there is a transmitter on the channel, and it may be a good
example of how to set something like this up.
-David
-Original Message-
From: Hui Kang [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 17, 2008 11:52 AM
To: David Moss
Subject: Re: CCA Check in application layer.
David Moss wrote:
If you want to check the channel *before* sending a packet, you can
sample
the CCA pin directly. This GeneralIO is provided by HplCC2420PinsC.
The code you're looking at here actually sends a packet, if the channel
is
immediately found to be clear. If you're not doing so already, you must
also acquire the SPI bus resource before sending commands over SPI.
-David
David,
thanks for your reply.
I use the interface GeneralIO as CCA and wire it to HplCC2420PinsC. My
code is
if ( call CCA.get() ) {
// toggle Blue led and send message
}
else {
// toggle Red led
}
Now I use three motes and find even when the three motes transmit
message at the same time (they blink blue led together), CCA.get( )
still returns true - it does not detect other motes is transmitting. Is
there any problem? Thanks.
- Hui Kang
-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 tinyos-2.x application, I would like to check the channel before
sending a packet. By copying the following code from CC2420TransmitP.nc,
I found the congest is always set as TRUE even I have only one mote turn
on. Could anyone help to solve this problem or any other smarter way to
check CCA? Thanks.
uint8_t status;
bool congestion = TRUE;
atomic{
call CSN.clr();
status = call STXONCCA.strobe();
if ( !( status CC2420_STATUS_TX_ACTIVE ) ) {
status = call SNOP.strobe();
if ( status CC2420_STATUS_TX_ACTIVE ) {
congestion = FALSE;
}
}
call CSN.set();
}
- Hui
Re: [Tinyos-help] adding some info to the acknowledgement
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 Sent: Wednesday, July 16, 2008 8:53 AM To: tinyos-help@millennium.berkeley.edu Subject: [Tinyos-help] adding some info to the acknowledgement Hi everybody, I'm programming a radio CC2420 using TinyOs1.x. I'm working with automatic acknowledgement, so i don't have to care about this for every transmission/reception of packets. Is it possible, in this mode, to access the acknowledgment packet and write some bits info in? If not, how should i do it? Thanks in advance ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] data rate of cc2420 on tmote
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 also hamper the speed of transmissions. If you were to disable acknowledgments and CSMA and enable DMA on the SPI bus if it's available (in MSP430's), you'll be transmitting a lot faster. This works fine for point-to-point systems in an interference free environment, but typically won't work well for true wireless networks. -David _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kirak, Hong Sent: Monday, July 14, 2008 11:07 AM To: tinyos-help@millennium.berkeley.edu Subject: [Tinyos-help] data rate of cc2420 on tmote Hi, I found some articles about cc2420 data rate from mailing list. Is it true that maximum reliable data rate is about 50kbps? (without any interferences) Actually I only achieved 30kbps, but I think it's because that I serialized sending. (send - sendDone - send - .) And I didn't touched any registers on CC2420 yet. Thanks, Kirak ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] multicast messages
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 you want a packet to get delivered to more than one node. Please send questions to tinyos-help@millennium.berkeley.edu -David _ From: Andrea Maestrini [mailto:[EMAIL PROTECTED] Sent: Friday, July 11, 2008 12:34 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: multicast messages Hi to all! I 'm new in TinyOS world and I have read the TEP 126 CC2420 RAdio Stack and TinyOS 2.0 tutorial and I have a doubtI have a simple question for you: - How to send a packet to a group of nodes but not to all of them? I can do broadcast AM_BROADCAST_ADDR and unicast by specifying the node address but how to do multicast in AMSend.send( ) ? In TinyOS 2.0 Can I do multicast comunication? Thanks for your help! Andrea Andrea Maestrini CREATE-NET Via alla Cascata 56C - 38100 Povo, Trento - Italy e-mail: [EMAIL PROTECTED] Phone: (+39) 0461 408400 personal ext: 311 Mobile: (+39) 3473390671 Fax: (+39) 0461 421157 www.create-net.org The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited according to the Italian Law 196/2003 of the Legislature. If you received this in error, please contact the sender and delete the material from any computer. ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] MTS400
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, July 08, 2008 8:51 AM To: tinyos-help@millennium.berkeley.edu Subject: [Tinyos-help] MTS400 Hi TinyOS users!! Is there a driver to use the MTS400 sensorboard with the MICAz mote? In case not, how could I measure temperature, light and humidity from this board? I need some information about it, does the ADC in the sensorboard have an I2C interface or is it easier than that? And... Is there a driver for the MDA100 board? Should I access to the ADC in the MDA100 through an I2C interface? Thanks in advance. _ Este mensaje se dirige exclusivamente a su destinatario, y puede contener información confidencial sometida a secreto profesional, o cuya divulgación esté legalmente prohibida.Cualquier opinión en él contenida es exclusiva de su autor y no representa necesariamente la opinión de la empresa. Si ha recibido este mensaje por error, le rogamos nos lo comunique de forma inmediata por esta misma vía y proceda a su eliminación, así como a la de cualquier documento adjunto al mismo. El correo electrónico vía Internet no es seguro y no se puede garantizar que no haya errores ya que puede ser interceptado, modificado, perdido o destruido, o contener virus. Cualquier persona que se ponga en contacto con nosotros por correo electrónico se considerará que asume estos riesgos. This e-mail is addressed exclusively to the recipient and may contain privileged information under a professional confidential agreement or it may be against the law to disclose its contents. Any opinion contained in it belongs exclusively to his/her author and does not necessarily reflect the company's view. If you receive this e-mail in error, please let us know immediately (by return e-mail) and proceed to its destruction, as well as any document attached to it. The sending of e-mails through the Internet is not safe and, therefore, error-free communications cannot be guaranteed, as they can be intercepted, changed, misled or destroyed or they might contain a virus. Any user contacting us through e-mails shall be understood to be assuming these risks. _ ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] cc2420 transmission delay ( backoff times)
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 transmitters. The more transmitters, the more likely the ack reception will be delayed by some significant amount. -David _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jun Sent: Friday, June 13, 2008 1:41 PM To: renjie huang Cc: tinyos-help@millennium.berkeley.edu Subject: Re: [Tinyos-help] cc2420 transmission delay ( backoff times) I think it's mainly due to software-ACK and the congestion backoff mentioned by Phil. Jun On Fri, Jun 13, 2008 at 12:10 PM, renjie huang [EMAIL PROTECTED] wrote: i have a question. Why do CC2420 need to wait for hardware ACK for such a log time? It should be very fast. On 5/28/08, Jongkeun Na [EMAIL PROTECTED] wrote: On Wed, May 28, 2008 at 2:06 AM, salvatore galati [EMAIL PROTECTED] wrote: ack wait time of 256 jiffies = 3,84 msec isn't one jiffy 32us? if so, the ack wait time should be 8.192ms. -- Jongkeun ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- Renjie Huang Sensorweb Research Laboratory http://sensorweb.vancouver.wsu.edu/ Washington State University ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- -- Mailto: [EMAIL PROTECTED] ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] DELAY_AFTER_RECEIVE in CC2420 Low Power Listening
Hi Jongkeun - Good observation. Sending an RTS / CTS to stop transmissions from other nodes is a good idea. I have two initial concerns about this approach, but maybe it should be studied a little more to confirm or deny these: 1) I'm concerned about the dependency on the link-layer to prevent phy-layer collisions, especially when we're dealing with such low power and somewhat long transmission distances that cause packets to be easily corrupted. 2) I'm concerned about the excess transmissions taking place to get a single packet through, and the impact on reliability and energy savings. 802.11's virtual sensing approach, from what I understand, works well especially because the transmission rates are high and the transmitters have access to mains power. In this case, getting a single packet through with an RTS / CTS requires at least 3 packets to be exchanged: RTS / CTS / Data. Transmissions are typically the largest energy consumer of any operation on the node. If one of those packets gets dropped, it will have to be retransmitted. Other nodes will also have to back off somehow to prevent collision if they miss the CTS packet, which brings us back down to PHY-layer collision avoidance. If you don't want to rely on the radio hardware to prevent collisions (and save energy by leaving the radio off), I think you'd be talking more about a TDMA solution. This is totally possible, but requires accurate clock management and synchronization between nodes. The RF230 implementation is pioneering some really nice synchronization protocols that would make something like that more possible, at least across homogeneous platforms. -David _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jongkeun Na Sent: Monday, 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? do you think it is worth to introduce such a virutal carrier sensing mechansim for LPL based sensor networks? if so, is it possible to implement it without an aid of radio H/W? Thanks, Jongkeun On Fri, May 30, 2008 at 9:17 AM, David Moss [EMAIL PROTECTED] wrote: Yes, in fact, this is what I'm implementing on the CC1100 and CC2500 radio stacks. The trick is getting the transmit branch of the radio stack to hold off for awhile if a packet was recently received. This allows one node to completely dominate the channel while it sends back-to-back packets with acknowledgment gaps in between. Packet delivery and acknowledgment success rate goes up, collisions go down, and energy efficiency goes way up. So far, this seems to work very reliable on my desk. I have yet to test it outside or in a real network, where any number of issues may come 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 detailed explanation. I fully agree with you regarding safety and robustness for applications. One more question, looking at the initial backoff (0x4) and congestion backoff (0x3) applied in the packetized wake-up transmission, I'm wondering there is any theory in choosing those backoff constants. What's the backoff strategy? intentionally to allow multiple wake-up transmissions mixed at the same time. What if we allows only one wake-up transmission at a time in medium by treating separately the first packet and the following resended packets in the packet train, i.e. the standard backoff is applied for the first packet and almost 0 backoff is used for the resended packets. Do you have any history or experience? Thanks, Jongkeun On Thu, May 29, 2008 at 8:54 AM, David Moss [EMAIL PROTECTED] wrote: Hi Jongkeun, The DELAY_AFTER_RECEIVE is not the length of a CCA receive check. The receive check is currently implemented through polling the CCA pin a number of times in PowerCycleP. This polling method will be transformed into an alarm/interrupt receive check for greater accuracy and efficiency, as soon as someone has time to do it. The goal of the receive check is to be as short as possible, and is the length of the time between packets in a packetized wake up transmission strategy. I've had these receive check perform reliably at 5 ms or less, but the current implementation makes the receive check last ~11 ms for reliability across everyone's systems and platforms. Only after activity is detected - either by transmitting a packet or receiving a packet - does the radio remain on for the time defined by DELAY_AFTER_RECEIVE, which is currently 100 ms. You'll notice the DELAY_AFTER_RECEIVE is #ifdef'd
Re: [Tinyos-help] about the metadata of cc2420
The metadata contains information about the packet that is used by the radio
stack. Like you said, it is not transmitted as part of the packet, but
rather contains side-note information about the packet.
The metadata fields are all 0's at boot time, because they haven't been
initialized. When you receive a packet, the buffer receiving the packet
doesn't have any of its metadata configured except the RSSI and LQI fields.
When you copy the metadata fields from your received packet to the payload
portion of a serial packet, seeing 0's in most of the fields is correct.
The timestamp should be the local relative time the packet was received,
which is the time the SFD (start frame delimiter) interrupt fired on the
radio chip when it began to receive a packet.
The RSSI and LQI fields reflect those values while the packet was being
received. At that time, there is a transmitter nearby, so you'll see lots
of energy on the channel. The RssiToSerial application monitors the RSSI at
any time - and the values you read mostly occur when a transmitter is not on
the channel. In those cases, you'll be reading the energy of the noise
floor.
When the radio receives a packet, it will automatically fill in the RSSI and
LQI fields in the metadata for that packet. If you want to read the RSSI
values when the radio is not receiving a packet, you would use
CC2420ControlC's ReadRssi interface. LQI values are only available when
receiving a packet.
-David
_
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
?
i see some codes of cc2420 driver . are all fields of metadata given an
significative value ? such as rssi , lqi and so on ?
i put the metadata in the payload when i receive a packet and send the
packet to serial port in order to see what the values are . i find
rxInterval,maxRetries and retryDelay are equal to zero . are they right ?
and the time field is some strange value , for example , every second , i
send a packet , the value of time field i receive are 3e 43 , ac 4d , 1a 27
, 88 46 ... , i don't know how do they figure out in the implemention of
cc2420 driver .
the rssi value i get (i use the interface CC2420PacketBody) is E5 or E9
when there is only one sender and one receiver . it is different with the
value i get by the application of /apps/tests/cc2420RssiToSerial whose value
is about 4A ,4B or 4C, why ? how do these value get in the implemention of
cc2420 driver ? read from the specified register ? and what about lqi ? (the
value i get is about 6B or 6C , and also one sender , one receiver )
typedef nx_struct cc2420_metadata_t {
nx_uint8_t rssi;
nx_uint8_t lqi;
nx_uint8_t tx_power;
nx_bool crc;
nx_bool ack;
nx_uint16_t time;
nx_uint16_t rxInterval;
/** Packet Link Metadata */
#ifdef PACKET_LINK
nx_uint16_t maxRetries;
nx_uint16_t retryDelay;
#endif
} cc2420_metadata_t;
--
zhang jiwen
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] DELAY_AFTER_RECEIVE in CC2420 Low Power Listening
Yes, in fact, this is what I'm implementing on the CC1100 and CC2500 radio stacks. The trick is getting the transmit branch of the radio stack to hold off for awhile if a packet was recently received. This allows one node to completely dominate the channel while it sends back-to-back packets with acknowledgment gaps in between. Packet delivery and acknowledgment success rate goes up, collisions go down, and energy efficiency goes way up. So far, this seems to work very reliable on my desk. I have yet to test it outside or in a real network, where any number of issues may come 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 detailed explanation. I fully agree with you regarding safety and robustness for applications. One more question, looking at the initial backoff (0x4) and congestion backoff (0x3) applied in the packetized wake-up transmission, I'm wondering there is any theory in choosing those backoff constants. What's the backoff strategy? intentionally to allow multiple wake-up transmissions mixed at the same time. What if we allows only one wake-up transmission at a time in medium by treating separately the first packet and the following resended packets in the packet train, i.e. the standard backoff is applied for the first packet and almost 0 backoff is used for the resended packets. Do you have any history or experience? Thanks, Jongkeun On Thu, May 29, 2008 at 8:54 AM, David Moss [EMAIL PROTECTED] wrote: Hi Jongkeun, The DELAY_AFTER_RECEIVE is not the length of a CCA receive check. The receive check is currently implemented through polling the CCA pin a number of times in PowerCycleP. This polling method will be transformed into an alarm/interrupt receive check for greater accuracy and efficiency, as soon as someone has time to do it. The goal of the receive check is to be as short as possible, and is the length of the time between packets in a packetized wake up transmission strategy. I've had these receive check perform reliably at 5 ms or less, but the current implementation makes the receive check last ~11 ms for reliability across everyone's systems and platforms. Only after activity is detected - either by transmitting a packet or receiving a packet - does the radio remain on for the time defined by DELAY_AFTER_RECEIVE, which is currently 100 ms. You'll notice the DELAY_AFTER_RECEIVE is #ifdef'd, so you can override it. I agree, 50 ms - or even 20 ms - is a better value for leaving the radio on after activity. The 100 ms value was chosen because highly congested networks need further optimization with the packetized wake up transmission in the default low power communication implementation. In fact, we need to connect a bunch of nodes to a logic analyzer to 1) improve acknowledgment success rate, 2) decrease packet collisions, and 3) optimize these timing values before it will make sense to decrease that value for the entire community. Right now the emphasis is on safety and robustness on everyone's applications. Once the items above are solved, we should be able to safely improve energy consumption while maintaining this level of robustness. -David _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf 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 is used to stretch the radio's ON time after receiving or sending a packet, and also detecting some CCAs at check time. I think that the cca detection related delay time should be seperated with the first two cases (after sending/receiving). If CCA detection is a false positive meaning that no packet is being transmitted to node, keeping radio ON during 100ms is too wasteful when we use a short check interval such as 100ms. Even though we use a shorter delay time such as 50ms, according to my experiment, there is no problem because radio is supposed to receive a packet after detecting CCAs, otherwise the radio should be OFF right after waiting an expected time for packet reception. I do not feel 100ms should be sticked for this case, a shorter delay would be fine if it is enough to guarrantee the packet reception at valid CCA detection. Am I missing something? Thanks, -- Jongkeun -- Jongkeun ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] DELAY_AFTER_RECEIVE in CC2420 Low Power Listening
Hi Jongkeun, The DELAY_AFTER_RECEIVE is not the length of a CCA receive check. The receive check is currently implemented through polling the CCA pin a number of times in PowerCycleP. This polling method will be transformed into an alarm/interrupt receive check for greater accuracy and efficiency, as soon as someone has time to do it. The goal of the receive check is to be as short as possible, and is the length of the time between packets in a packetized wake up transmission strategy. I've had these receive check perform reliably at 5 ms or less, but the current implementation makes the receive check last ~11 ms for reliability across everyone's systems and platforms. Only after activity is detected - either by transmitting a packet or receiving a packet - does the radio remain on for the time defined by DELAY_AFTER_RECEIVE, which is currently 100 ms. You'll notice the DELAY_AFTER_RECEIVE is #ifdef'd, so you can override it. I agree, 50 ms - or even 20 ms - is a better value for leaving the radio on after activity. The 100 ms value was chosen because highly congested networks need further optimization with the packetized wake up transmission in the default low power communication implementation. In fact, we need to connect a bunch of nodes to a logic analyzer to 1) improve acknowledgment success rate, 2) decrease packet collisions, and 3) optimize these timing values before it will make sense to decrease that value for the entire community. Right now the emphasis is on safety and robustness on everyone's applications. Once the items above are solved, we should be able to safely improve energy consumption while maintaining this level of robustness. -David _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf 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 is used to stretch the radio's ON time after receiving or sending a packet, and also detecting some CCAs at check time. I think that the cca detection related delay time should be seperated with the first two cases (after sending/receiving). If CCA detection is a false positive meaning that no packet is being transmitted to node, keeping radio ON during 100ms is too wasteful when we use a short check interval such as 100ms. Even though we use a shorter delay time such as 50ms, according to my experiment, there is no problem because radio is supposed to receive a packet after detecting CCAs, otherwise the radio should be OFF right after waiting an expected time for packet reception. I do not feel 100ms should be sticked for this case, a shorter delay would be fine if it is enough to guarrantee the packet reception at valid CCA detection. Am I missing something? Thanks, -- Jongkeun ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] About LowPowerListening
Hi Jiwen - 1. The radio stack takes care of sending the wake up transmission whenever you call AMSend.send. So call LowPowerListening.setRxSleepInterval(250), and then call AMSend.send() - no delays needed. I prefer to use Boot.booted() to setup the Rx sleep interval on a packet, and that setting will stick with the packet throughout the lifetime of the application unless you explicitly change it. 2. The acknowledgment is an 802.15.4 acknowledgment frame, defined on page 42 of the CC2420 datasheet. Your BaseStation will technically receive an acknowledgment, but because it is not a data frame, it will not pass the ack onto the application layer to forward to your computer. If you do some special modifications to the receive branch of the radio stack, you will be able to capture and report acknowledgment frames. 3. Miklos: Yes 4. The CC1000 radio and mica2 hardware comes in different flavors. The 433 MHz version transmits farther, and is the default frequency setting for the stack. If you have 915 MHz versions of the mica2's, you did the right thing by overriding the 433 MHz frequency setting with the 915 MHz setting. -David _ 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 and receiver have the same duty cycle (sleep interval ?) , for example 250ms , how long should i send the wake-up packet before i send my data ? that is to say that what should i set the parameter of setRxSleepInterval before i use the command AMSend.send() to send my useful datas ? in my test , i set it equal to sleep interval , i find there is no lost packet . 2. If the receiver receives the packet , it will give the sender an acknowledgement , what is the format of the acknowledgement ? where is the format defined ? if i use the Basestation to snoop the acknowledgement , can i receive it ? 3. Does rf230 support LowPowerListeing ? another question : David , i download the cvs tree of tinyos-2.x six days ago , i install the RadioCountToLeds to the mica2 motes , i find they can't communicate with each other . i have chaged the frequency in CC1000Const.h , just chaged #ifndef CC1K_DEF_PRESET #define CC1K_DEF_PRESET (CC1K_433_002_MHZ) To #ifndef CC1K_DEF_PRESET #define CC1K_DEF_PRESET (CC1K_915_998_MHZ) (My mica2 motes use 900MHZ) in the primary tinyos tree (not the version of cvs) , i just chage this , the mica2 motes can communicate with each other , but in the cvs version , they can't . Do you know why , David ? have you tried ? thank you very much !! 2008/5/27 David Moss [EMAIL PROTECTED]: Hi Jiwen - I've been out for a few days, sorry for the delay in the response. You're correct about the operation of setLocalSleepInterval. The amount of time the radio wakes up is ideally as short as possible, and is dependent upon the type of low power communication strategy implemented. The default CC2420 low power communication implementation, in an attempt to work on everyone's setup, is set to 11 ms receive check intervals. I've had this working reliably in more of a point-to-point scheme (no surrounding network) at 5 ms. Essentially, because the wakeup transmission is a packet train, the amount of time a receiver radio must perform an energy-based receive check is the duration of the gap in modulation between packets. On different strategies, like a BMAC-based strategy where a long continuously modulated signal is emitted from the transmitter, the receive check can be near instantaneous. The setRxSleepInterval() command is used to setup the packet, before transmission, to tell the radio stack how long to transmit that packet for to wake up its intended destination. So if you are about to transmit a packet to a node that has a local duty cycle of 250 ms, you have to tell the packet that the receiver's sleep interval is 250 ms. The radio stack will wake up the duty cycling receiver for that duration of time while attempting to deliver the packet. The cc1000_lpl directory is no longer valid, and should never be used. The default cc1000 directory contains a fully functional low power communication implementation, BMAC. -David _ From: jiwen zhang [mailto:[EMAIL PROTECTED] Sent: Monday, May 26, 2008 6:33 AM To: David Moss; tinyos-help Subject: Fwd: About LowPowerListening -- Forwarded message -- From: jiwen zhang [EMAIL PROTECTED] Date: 2008/5/25 Subject: About LowPowerListening To: David Moss [EMAIL PROTECTED], tinyos-help tinyos-help@millennium.berkeley.edu Hello David : Maybe i have asked the question to you , but i still have some puzzles . 1. about the command setLocalSleepInterval(uint16_t sleepIntervalMs) . in my
Re: [Tinyos-help] About TXFIFO.writeDone
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: tinyos-help@millennium.berkeley.edu Subject: [Tinyos-help] About TXFIFO.writeDone Hello A question about TXFIFO.writedone provided by CC2420TransmitP. async event void TXFIFO.writeDone( uint8_t* tx_buf, uint8_t tx_len, error_t error ) What values can take the error_t variable ? Thanks ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] About TXFIFO.writeDone
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, May 16, 2008 9:15 AM Cc: tinyos-help@millennium.berkeley.edu Subject: Re: [Tinyos-help] About TXFIFO.writeDone Explaining better... the error_t == FAIL When can occur (What could have happened in FIFO) ? Paolo wrote: Hello A question about TXFIFO.writedone provided by CC2420TransmitP. async event void TXFIFO.writeDone( uint8_t* tx_buf, uint8_t tx_len, error_t error ) What values can take the error_t variable ? Thanks ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] About CC2420Receive
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 received packet length is an edge case that occurs all the time.
Removing the 0-byte packet handler may cause your node to lock up. At least
it used to.
-David
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Paolo
Sent: Thursday, May 15, 2008 7:39 AM
To: tinyos-help@millennium.berkeley.edu
Subject: Re: [Tinyos-help] About CC2420Receive
ERRATA CORRIGE:
When this case (else code) occurs (practically/physically)?
else
{
// Length == 0; start reading the next packet
atomic receivingPacket = FALSE;
call CSN.set();
call SpiResource.release();
waitForNextPacket();
}
Sorry
Paolo wrote:
Hello,
Some questions about CC2420ReceiveP
1. the m_missed_packets variable is a REAL number of packets we missed
because we were doing something else ?
2. When this case (else code) occurs (practically/physically)?
else
{
// Length is too large; we have to flush the entire Rx FIFO
flush();
m_overflow_packets++;//lost packets for length 40
Bytes
}
thanks Paolo.
_
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] how to determine SACK packet
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 probably have yourself a real acknowledgment frame. Refer to the CC2420 datasheet for more details. -David _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paolo Sent: Thursday, May 15, 2008 1:32 AM To: tinyos-help@millennium.berkeley.edu Subject: [Tinyos-help] how to determine SACK packet Hello, How i can determine if a packet in RX fifo is a SACK packet ? If the cc2420_header_t-length is 5 bytes (2B FCF + 1B DSN + 2B FCS) i can say that is a SACK packet ? Thanks. ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] how to determine SACK packet
The SACK_HEADER_LENGTH constant in the receive branch refers to the position
in the data frame (non-ack packet) at which we can safely issue an
acknowledgment. This position is in the header of a normal packet:
typedef nx_struct cc2420_header_t {
nxle_uint8_t length;
nxle_uint16_t fcf; - 2
nxle_uint8_t dsn; - 1
nxle_uint16_t destpan; -2
nxle_uint16_t dest; -2
...
2 + 1 + 2 + 2 = 7.
When we have this much information downloaded, we can safely issue a SACK.
-David
_
From: Paolo [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 15, 2008 10: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 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
probably have yourself a real acknowledgment frame. Refer to the CC2420
datasheet for more details.
-David
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Paolo
Sent: Thursday, May 15, 2008 1:32 AM
To: tinyos-help@millennium.berkeley.edu
Subject: [Tinyos-help] how to determine SACK packet
Hello,
How i can determine if a packet in RX fifo is a SACK packet ?
If the cc2420_header_t-length is 5 bytes (2B FCF + 1B DSN + 2B FCS) i can
say that is a SACK packet ?
Thanks.
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Low Power Listening
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 to assume that every node around your node is on the same sleep schedule. Therefore, your node must specify the destination's sleep interval before sending the packet, which may be different than your local sleep interval. That way the radio stack will know how to deliver the packet to its intended destination. -David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nitin Sharma Sent: Tuesday, May 13, 2008 11:08 AM To: tinyos-help@millennium.berkeley.edu Subject: [Tinyos-help] Low Power Listening For Low Power Listening in the default Tinyos 2.x cvs stack (Box-MAC-2?) , the two interfaces as below: command void setLocalSleepInterval(uint16_t sleepIntervalMs); command void setRxSleepInterval(message_t *msg, uint16_t sleepIntervalMs); The Node (Receiver and Transmitter) would set its local sleep interval from the first command. The Receiver of course, if is peer-to-peer synchronized following the same sleep interval would be awake at that interval for receive check ? Why do we need to set the interval on the packet we're sending? Please let me understand. Thanks -- Nitin Sharma ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Low Power Listening
I've updated this wiki doc: The transmitter stops sending once it receives a link-layer acknowledgment or a timeout. The timeout is a few milliseconds longer than the receiver's check period. We no longer transmit for twice the receive check period because receive check reliability has increased since 2.0.1. Worst case is your transmitter will transmit for a few milliseconds longer than the destination's receive check period. -David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nitin Sharma Sent: Tuesday, May 13, 2008 12:58 PM To: tinyos-help@millennium.berkeley.edu Subject: Re: [Tinyos-help] Low Power Listening Thanks Janos and David. I have got yet another query. So i assume, the transmitter could decide to send as soon as it has a packet to send and the radio is on .And keep on retransmitting (within the receive check period interval ) unless acked or timeout. http://docs.tinyos.net/index.php/Writing_Low-Power_Applications says The transmitter stops sending once it receives a link-layer acknowledgment or a timeout of twice the check period. My concern is for a recipient with a relatively longer schedule. Does it keep 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. 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 to assume that every node around your node is on the same sleep schedule. Therefore, your node must specify the destination's sleep interval before sending the packet, which may be different than your local sleep interval. That way the radio stack will know how to deliver the packet to its intended destination. -David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nitin Sharma Sent: Tuesday, May 13, 2008 11:08 AM To: tinyos-help@millennium.berkeley.edu Subject: [Tinyos-help] Low Power Listening For Low Power Listening in the default Tinyos 2.x cvs stack (Box-MAC-2?) , the two interfaces as below: command void setLocalSleepInterval(uint16_t sleepIntervalMs); command void setRxSleepInterval(message_t *msg, uint16_t sleepIntervalMs); The Node (Receiver and Transmitter) would set its local sleep interval from the first command. The Receiver of course, if is peer-to-peer synchronized following the same sleep interval would be awake at that interval for receive check ? Why do we need to set the interval on the packet we're sending? Please let me understand. Thanks -- Nitin Sharma ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- Nitin Sharma ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] TinyOS Search Engine
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 6:08 PM To: tinyos-help@millennium.berkeley.edu Subject: [Tinyos-help] TinyOS Search Engine Hello Everyone, I created a TinyOS search engine that I thought might be useful for people in finding help and info that has already been posted online. The nice thing about this search engine is that it only returns results that are found on sites that are manually specified. Here is a link so that you can try it out for yourself. http://www.google.com/coop/cse?cx=000490616372089452102%3Ajdf9nzpy7se So far, I have specified the following site for inclusion in the results: http://docs.tinyos.net/, http://webs.cs.berkeley.edu/tos/, http://mail.millennium.berkeley.edu/pipermail/tinyos-help/, http://mail.millennium.berkeley.edu/pipermail/tinyos/, www.moteiv.com/community/TinyOS_Information If I have left out any important sites that could be useful to include, please let me know. Thanks. -Joey ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Collection: Loosing Connection to a Node
In creating the new CCxx00 radio stack's LPL/Wake-on Radio layer and testing it for CTP, I found lots of issues with low power communications in general that require lots of experimentation with the radio stack and a logic analyzer. Someone needs to do the same analysis on the CC2420 stack, and I unfortunately don't have time to do it now. Acknowledgments are the biggest problems. Collisions are another problem, but collisions ultimately feed into the acknowledgment problem. If we can avoid collisions and prevent each node from transmitting during an acknowledgment period, network reliability will improve. With the CCxx00 stack, I found it necessary to remove hardware address recognition to improve the performance of acknowledgment success rate. I forced each node to take time to receive every packet, and respect the acknowledgment wait period if the packet was not destined for that particular node. I also added progressive backoffs to the CCxx00 stack, where the CSMA backoff duration gets longer and longer as the channel is found to be busy. This works well for long-preamble transmissions, but probably won't work as well for packetized wake-up transmissions as is implemented for the CC2420. The CCxx00 stack was tested for WoR reliability and efficiency by setting up a small network of 4 nodes, each with a unique address (3, 2, 1, and 0). Each node's LEDs were connected to a logic analyzer, allowing me to see when a node was transmitting, receiving, and sending an acknowledgment. Nodes performed unicast transmissions: #3 transmitted to #2, #2 to #1, #1 to 0, and 0 acted like a base station receiver that didn't transmit. This setup allowed me to experiment with different radio stack parameters and functionality. I could see, using the logic analyzer, that nodes transmitted when they weren't supposed to (like during an acknowledgment wait period) or two nodes would try to transmit simultaneously, causing a collision. In CTP, I found it necessary to modify CtpForwardingEngine.h to set the FORWARD_PACKET_TIME equal to some much larger value, like 512 or 1024, to avoid network congestion. Maybe we should find a way to tie this value to the low power listening interval somehow. CTP works great. But the radio stack underneath has to be reliable under that kind of network congestion. When the CC2420 LPL implementation was created, most of the tests were point-to-point tests, and very few were network congestion tests. Any modifications done to the CC2420 stack to improve this situation should be contributed back to the TinyOS baseline. -David -Original Message- From: Philip Levis [mailto:[EMAIL PROTECTED] Sent: Monday, April 28, 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 is to blame for the misbehavior of CTP in our case. As Omprakash suggested, I repeated the tests by turning off the LPL. Nodes quickly discovered routes and packet losses were reduced dramatically. We later on retried with LPL but reduced our LPL sleep interval from 1000 ms to 125 ms. Attached you can find the logs. Node 7 is again TelosB with debug logs. The performance is much better, however, is not as sharp as it would be with no LPL. I would suspect that the beacons or the acks are getting lost when the LPL is activated, hence the poor route discovery process and the large amount of data loss. When LPL is used, are the beacons timed for the LPL sleep interval? For instance, we use setRxSleepInterval to set the receiving node's sleep interval for data transmission. Is something similar done for CTP beacons? Also, when CTP is used, ETX values are quite large. Even for a single hop, it is about 265. You will notice ETX values as large as 700 with 3-hop routes. However, with no LPL it was usually less than 300 even for 6-hop routes. Can this be due to beacons/acks getting lost with LPL? In summary, attached logs (4BITLE LPL w/ 125ms interval) are much better than the ones I sent last week (LE | 4BITLE LPL w/ 1000ms interval). But still, for an acceptable power consumption level, we need to use 1000ms or larger sleep interval. So, in this case, is it possible to improve CTP to better work with LPL? How can we assist you in this process? It might be useful to move this discussion over to -devel. The first step for doing this was to reduce CTP's control traffic so that it can function well with LPL (early versions had high control load). We completed this work a few weeks ago, and Om has just checked the changes into CVS. Now that CTP has a low control load, the next step is starting testing with LPL and figuring out what's going wrong and why. From your traces, it looks like LPL has a low
Re: [Tinyos-help] CCA for channel detection
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. Traverse all channels and average up many samples of RSSI on each channel, then pick the channel with the quietest average RSSI. -David _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of renjie huang Sent: Sunday, April 20, 2008 4:17 PM To: tinyos-help Subject: [Tinyos-help] CCA for channel detection Hi I am trying to use CCA for a node to detect all radio channels around. If CCA is false, then there may be some nodes transmitting packets on corresponding channel. But in my test there has some problem. When a node uses a channel , eg 11, while no other nodes are around, it will report channel 11 deteced. That means when the channel is not busy(no nodes are transmitting, including itself), CCA also can be false. for(ccaCheck = 0; ccaCheck 400; ccaCheck++) if(!call CC2420RadioControl.getCcaStatus()) count++; if(count 200) debug(DBG_ERR, channel =%i is detected \n, call CC2420Control.GetPreset()); This seems that CCA is not relaible. I don't know what is wrong with my code. Any advice is appreciated. Thanks -- Renjie Huang Sensorweb Research Laboratory http://sensorweb.vancouver.wsu.edu/ Washington State University ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] false CCA detection in LPL
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, 2008 10:57 AM To: tinyos-help@millennium.berkeley.edu Cc: [EMAIL PROTECTED] Subject: false CCA detection in LPL Folks, I've got false CCA detections in most of time when MIN_SAMPLES_BEFORE_DETECTION=3 (defaultlpl.h). Anyone knows why this default number is set a 3, or has any experience on a proper number in different situations? based on my experience, false CCA detections still appear up to 12, finally I got okay when the number is 30. And I suspect also the number is sensitive to which channel is used in what wireless environments are. Thanks, -- Jongkeun ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] is it true?
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 like to know if I had truly undestand : basically CC2420radio stack uses CSMA to acces to the channel but if we active Low Power Listening then it uses TDMA . Is it true? Best regards, Fun _ Envoyé avec Yahoo! http://us.rd.yahoo.com/mailuk/taglines/isp/control/*http:/us.rd.yahoo.com/e vt=52423/*http:/fr.docs.yahoo.com/mail/overview/index.html Mail. Une boite mail plus intelligente. ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Pumping up bandwidth - Mica2Dot/Mica2
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 receiving valid data. CSMA causes your transmitter to share the channel with other transmitters, and the channel checks may be spaced relatively far apart which dramatically decreases throughput. The CC1000 radio could be a really kick-ass radio if it were implemented properly. The ability to easily enable/disable Manchester, CSMA, etc. (among other things) would really improve its situation. The CC1000 radio is much more energy efficient than the CC2420 radio, and can transmit a lot farther than the CC2420 radio (but that broken matching network on mica2's and especially mica2dot's really cause everyone problems). It's unfortunate so many people dismiss the CC1000 radio as obsolete, when it could really outperform their radios in terms of efficiency and range (not throughput). 29 bytes is only a software (and RAM) limitation. Increase it by doing a CFLAGS+=-DTOSH_DATA_LENGTH=50 or something in your Makefile. Removing unnecessary fields from the CC1000 header will decrease the header:payload ratio and increase payload throughput. If you're thinking about rolling your own hardware, you should really be using CC1100 or CC2500 radios for any wireless application that doesn't require 802.15.4 compatibility: http://docs.tinyos.net/index.php/CC1100/CC2500 -David _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Edgar Charry Sent: Monday, April 14, 2008 3:57 PM To: [EMAIL PROTECTED]; Eric Keller Cc: tinyos-help@millennium.berkeley.edu Subject: Re: [Tinyos-help] Pumping up bandwidth - Mica2Dot/Mica2 Hi all, Thanks for your prompt replies. Unfortunately I that link didn't let me through. In fact I am still trying to undestand them, as I wasn't aware of that limitation of 33-50ms of the Mica2's! You are saying that the maximum bandwidth my app should require is 0-25Hz so that I have a nice reconstruction of my wave, due to HW limitations? I knew that the CC1000 has a maximum bandwidth of 76.8kbps and of course due to EEPROM readings/writings, CPU instructions, ADC's measurements etc. this number should decrease. But I wasn't expecting a final bandwidth of 30pckts/s!!! In fact, I thought there were problems related to the TOSBase. My app requirement need at least 100Hz (Mica2's transmission needed thus 200 pckts/s), which is necessary to track a complete gait cycle using acc and gyros with good definition. What is the most critical factor in the Mica2's that blow the transmission rate so bad? Does this happen with the Mica2Dot too? Data compression (sample with a higher freq, store in the RAM and then send the whole bunch of bytes) has a limitation of 29 bytes due to TinyOS, correct? Thanks guys for the good info. Cheers, Edgar Charry Date: Mon, 14 Apr 2008 12:20:38 -0600 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: tinyos-help@millennium.berkeley.edu Subject: Re: [Tinyos-help] Pumping up bandwidth - Mica2Dot/Mica2 Well, since people are quoting my second source messages, have a look at: http://www.etantdonnes.com/Motes/report_mica2/ (which seems to be down right now but will hopefully be back soon...). However my message speed/reliability measurements use only the standard GenericComm and TOS1 code. I think the OP was trying to fiddle timeouts and backoffs to speed things up further. Data mining of the help list should turn up some more useful advice in this respect. MS Eric Keller wrote: There is a limit to how many packets you can send with a mica2 which you are at or above. You probably want to lower your bandwidth requirements somehow. See this message: https://www.millennium.berkeley.edu/pipermail/tinyos-help/2008-April/032464. html Eric On Mon, Apr 14, 2008 at 4:59 AM, Edgar Charry [EMAIL PROTECTED] wrote: Hi all, I am trying to pump my packet transmission up between a Mica2Dot and a Mica2 to at least 200Hz [pckts/s]. I've decreased the timer constant to a bottleneck of 33ms (30 pckts/s) that pratically executes a round of ADC measurements and send the packet. Decreasing from this point doesn't give me more bandwidth. However, my packet is 14bytes long (the TinyOS header + just a couple of adc measurements + CRC). I suspect that this 33ms (parsed time stamps from XSniffer) are limited to the TOSBase.nc on the Mica2. I suspect that the PLL of the Mica2 is listening through channels and is not locked to the transmitter's one. Every loop thus should take 33ms. Actually, I haven't been through the CC1000 conf/mod components though, but I reckon with your experience this can be solved easily. Cheers, Edgar Charry Explore
Re: [Tinyos-help] Pumping up bandwidth - Mica2Dot/Mica2
The CC2420 has some range, and while 40 feet is good for a CC2420 on the ground, it isn't a whole lot when you compare it to other radios. With lower and lower frequencies, you can transmit much farther. 2.4 GHz gets eaten by the ground. A CC1000 radio has the potential to get about 400-600 feet on the ground, and possibly further. With a CC1100 radio, I'm able to reach 750 feet with nodes placed directly on grass, using wire antennas and 500 kbps. Lower that 500 kbps throughput and the range is extended even more. This kind of range is physically impossible for a CC2420 radio, while being more energy efficient. I like the CC2420 for improving ad-hoc networks and research, but it's time to move on to better radios. -David On Tue, 15 Apr 2008 00:09:02 -0400 Eric Keller [EMAIL PROTECTED] wrote: That was an interesting page, but I'll disagree about the range 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 be using CC1100 or CC2500 radios for any wireless application that doesn't require 802.15.4 compatibility: http://docs.tinyos.net/index.php/CC1100/CC2500 -David From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Edgar Charry Sent: Monday, April 14, 2008 3:57 PM To: [EMAIL PROTECTED]; Eric Keller Cc: tinyos-help@millennium.berkeley.edu Subject: Re: [Tinyos-help] Pumping up bandwidth - Mica2Dot/Mica2 Hi all, Thanks for your prompt replies. Unfortunately I that link didn't let me through. In fact I am still trying to undestand them, as I wasn't aware of that limitation of 33-50ms of the Mica2's! You are saying that the maximum bandwidth my app should require is 0-25Hz so that I have a nice reconstruction of my wave, due to HW limitations? I knew that the CC1000 has a maximum bandwidth of 76.8kbps and of course due to EEPROM readings/writings, CPU instructions, ADC's measurements etc. this number should decrease. But I wasn't expecting a final bandwidth of 30pckts/s!!! In fact, I thought there were problems related to the TOSBase. My app requirement need at least 100Hz (Mica2's transmission needed thus 200 pckts/s), which is necessary to track a complete gait cycle using acc and gyros with good definition. What is the most critical factor in the Mica2's that blow the transmission rate so bad? Does this happen with the Mica2Dot too? Data compression (sample with a higher freq, store in the RAM and then send the whole bunch of bytes) has a limitation of 29 bytes due to TinyOS, correct? Thanks guys for the good info. Cheers, Edgar Charry Date: Mon, 14 Apr 2008 12:20:38 -0600 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: tinyos-help@millennium.berkeley.edu Subject: Re: [Tinyos-help] Pumping up bandwidth - Mica2Dot/Mica2 Well, since people are quoting my second source messages, have a look at: http://www.etantdonnes.com/Motes/report_mica2/ (which seems to be down right now but will hopefully be back soon...). However my message speed/reliability measurements use only the standard GenericComm and TOS1 code. I think the OP was trying to fiddle timeouts and backoffs to speed things up further. Data mining of the help list should turn up some more useful advice in this respect. MS Eric Keller wrote: There is a limit to how many packets you can send with a mica2 which you are at or above. You probably want to lower your bandwidth requirements somehow. See this message: https://www.millennium.berkeley.edu/pipermail/tinyos-help/2008-April/032464.html Eric On Mon, Apr 14, 2008 at 4:59 AM, Edgar Charry [EMAIL PROTECTED] wrote: Hi all, I am trying to pump my packet transmission up between a Mica2Dot and a Mica2 to at least 200Hz [pckts/s]. I've decreased the timer constant to a bottleneck of 33ms (30 pckts/s) that pratically executes a round of ADC measurements and send the packet. Decreasing from this point doesn't give me more bandwidth. However, my packet is 14bytes long (the TinyOS header + just a couple of adc measurements + CRC). I suspect that this 33ms (parsed time stamps from XSniffer) are limited to the TOSBase.nc on the Mica2. I suspect that the PLL of the Mica2 is listening through channels and is not locked to the transmitter's one. Every loop thus should take 33ms. Actually, I haven't been through the CC1000 conf/mod components though, but I reckon with your experience this can be solved easily. Cheers, Edgar Charry Explore the seven wonders of the world Learn
Re: [Tinyos-help] Pumping up bandwidth - Mica2Dot/Mica2
I'm not sure if this applies to all mica2's, or just some older versions. I'm also not sure about OEM's. You'll have to screen yours nodes yourself to see if this applies. Our experience (and we're not alone) has been that there was not a good 50-ohm impedance match on the passive network connecting the radio chip with the antenna. Where there should be 50-ohm traces on the PCB, there is not. This steals a few dB of output power, and significantly decreases range (you double the range for every 3 dB, so even 3 dB less is half the range). Mica2Dot's are even worse: in an attempt to meet size specifications, the matching network is split across two sides of a PCB. This is never a good idea, because you may not be able to guarantee the reliability of the radio's matching network. With the matching network separated, small manufacturing differences of the PCB can cause significant differences in RF response from module to module. And, mica2dot's don't have a sufficient ground plane. Finally, the curly-q loop thing added to the end of the wire antennas that come with the mica2dot's are a bad idea. This adds some unnecessary horizontal polarization to the wave. A vertically 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: 'Edgar Charry'; 'Eric Keller'; tinyos-help@millennium.berkeley.edu Subject: Re: [Tinyos-help] Pumping up bandwidth - Mica2Dot/Mica2 YOW!!! Another information packed post (IPP). Maybe we could start a radio theory page on our new improved doc site? But what's that broken matching network mean? MS David Moss wrote: 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 receiving valid data. CSMA causes your transmitter to share the channel with other transmitters, and the channel checks may be spaced relatively far apart which dramatically decreases throughput. The CC1000 radio could be a really kick-ass radio if it were implemented properly. The ability to easily enable/disable Manchester, CSMA, etc. (among other things) would really improve its situation. The CC1000 radio is much more energy efficient than the CC2420 radio, and can transmit a lot farther than the CC2420 radio (but that broken matching network on mica2's and especially mica2dot's really cause everyone problems). It's unfortunate so many people dismiss the CC1000 radio as obsolete, when it could really outperform their radios in terms of efficiency and range (not throughput). 29 bytes is only a software (and RAM) limitation. Increase it by doing a CFLAGS+=-DTOSH_DATA_LENGTH=50 or something in your Makefile. Removing unnecessary fields from the CC1000 header will decrease the header:payload ratio and increase payload throughput. If you're thinking about rolling your own hardware, you should really be using CC1100 or CC2500 radios for any wireless application that doesn't require 802.15.4 compatibility: http://docs.tinyos.net/index.php/CC1100/CC2500 -David *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On Behalf Of *Edgar Charry *Sent:* Monday, April 14, 2008 3:57 PM *To:* [EMAIL PROTECTED]; Eric Keller *Cc:* tinyos-help@millennium.berkeley.edu *Subject:* Re: [Tinyos-help] Pumping up bandwidth - Mica2Dot/Mica2 Hi all, Thanks for your prompt replies. Unfortunately I that link didn't let me through. In fact I am still trying to undestand them, as I wasn't aware of that limitation of 33-50ms of the Mica2's! You are saying that the maximum bandwidth my app should require is 0-25Hz so that I have a nice reconstruction of my wave, due to HW limitations? I knew that the CC1000 has a maximum bandwidth of 76.8kbps and of course due to EEPROM readings/writings, CPU instructions, ADC's measurements etc. this number should decrease. But I wasn't expecting a final bandwidth of 30pckts/s!!! In fact, I thought there were problems related to the TOSBase. My app requirement need at least 100Hz (Mica2's transmission needed thus 200 pckts/s), which is necessary to track a complete gait cycle using acc and gyros with good definition. What is the most critical factor in the Mica2's that blow the transmission rate so bad? Does this happen with the Mica2Dot too? Data compression (sample with a higher freq, store in the RAM and then send the whole bunch of bytes) has a limitation of 29 bytes due to TinyOS, correct
RE: [Tinyos-help] Problems with ACKs in TinyOS 2.0.2
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 acknowledgment, setup a reliable packet transmission through
the PacketLink interface:
call PacketLink.setRetries(myMsg, 5);
call PacketLink.setRetryDelay(myMsg, 0);
This will automatically retry sending the packet 5 times, with no delays
between retransmissions. When you get a sendDone() event back, you can
check to see if the packet was delivered either by calling
PacketAcknowledgments.wasAcked(myMsg); OR by calling
PacketLink.wasDelivered(myMsg);.
You are receiving multiple packets at the base station because
acknowledgments are just as unreliable as sending any packet. If an
acknowledgement is dropped and you have to retransmit, then the base station
will receive duplicates. The PacketLink layer, combined with UniqueSend
and UniqueReceive layers in the CC2420 stack, prevent duplicate packet
receptions due to dropped acknowledgments. There is more documentation
here:
http://tinyos.cvs.sourceforge.net/*checkout*/tinyos/tinyos-2.x/doc/html/tep1
27.html
Finally, there is already a delay built into the send for the acknowledgment
wait period, and you will not get a sendDone() event back until an ack was
received or the ack wait period timed out.
-David
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Juan
Antonio López Riquelme
Sent: Monday, April 07, 2008 9:33 AM
To: tinyos-help@millennium.berkeley.edu
Subject: [Tinyos-help] Problems with ACKs in TinyOS 2.0.2
Hello,
I am working with TinyOS 2.0.2 and payload of 29 bytes. Two remotes nodes
send messages to node with BaseStation application.
I changed BaseStation program to work with 29 bytes of payload and
acknowledgements. I compiled with address 0. In BaseStationP:
#include AM.h
#include Serial.h
#define TOSH_DATA_LENGTH 29//Added line
The Makefile:
COMPONENT=BaseStationC
#CFLAGS += -DCC2420_NO_ACKNOWLEDGEMENTS
CFLAGS += -DCC2420_NO_ADDRESS_RECOGNITION
include $(MAKERULES)
The remote node requests an ack before to send the message:
call ACK.requestAck(PaqueteDatos);
if (call EnviarDatos.send(0, PaqueteDatos, sizeof(MensajeDatos)) ==
SUCCESS)
And finally the code at sendDone event:
event void EnviarDatos.sendDone(message_t* msg, error_t error)
{
if (PaqueteDatos == msg)
{
enviarDatosBusy = FALSE;
enviados = enviados + 1;
if (!call ACK.wasAcked(msg) intentos REINTENTOS)
{
intentos = intentos + 1;
FuncionEnviarDatos();
}
else
{
//New iteration with the sensors
intentos = 0;
...
}
...
}
}
If the ack failed the program tries to send the message 5 times. At the
computer sometimes I get the same message twice. Can the program requiere a
delay between sendDone is signaled and check the acknowledgement?
Thanks, Juan Antonio.
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] Problems with ACKs in TinyOS 2.0.2
Hi Juan
According to your BaseStation makefile, you are disabling acknowledgments at
the base station. This would cause PacketLink to fail because PacketLink
requires the destination node to send back an acknowledgment. Remove the
CC2420_NO_ACKNOWLEDGMENTS line from the BaseStation Makefile and recompile.
-David
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Juan
Antonio López Riquelme
Sent: Monday, April 07, 2008 1:45 PM
To: tinyos-help@millennium.berkeley.edu
Subject: Re: [Tinyos-help] Problems with ACKs in TinyOS 2.0.2
Hello,
Thank David for your answer.
I have implemented the new version with PacketLink. The messages arrive to
BaseStation, but wasDelivered failed. I know it because before a new
iterarion to read the sensors the program sends a message with three
variables: calls, inputs and dataSendDone. The program adds one to calls
when it call the fuction to send the data, inputs the same when the
execution is inside the function to send data and dataSendDone if
wasDelivery returns true.
For BaseStation I use this Makefile:
COMPONENT=BaseStationC
CFLAGS += -DCC2420_NO_ACKNOWLEDGEMENTS
CFLAGS += -DCC2420_NO_ADDRESS_RECOGNITION
CFLAGS+=-DPACKET_LINK
include $(MAKERULES)
In the Makefile for remote sensor also I added the flag DPACKET_LINK. The
configuration for remote mote:
#include Timer.h
#include HP2.h
configuration HP2AppC{}
implementation
{
...
components CC2420ActiveMessageC;
components new AMSenderC(AM_MENSAJEDATOS) as EnviarDatos;//Only I use
PacketLink with thsese messages
components new AMSenderC(AM_MENSAJEDATO) as EnviarDato;
components new AMSenderC(AM_MENSAJEBATERIA) as EnviarAlarma;
components new AMReceiverC(AM_MENSAJEPERIODO);
..
App.Packet - EnviarDatos;
App.AMPacket - EnviarDatos;
App.EnviarDatos - EnviarDatos.AMSend;
App.EnviarDato - EnviarDato.AMSend;
App.EnviarAlarma - EnviarAlarma.AMSend;
App.AMControl - CC2420ActiveMessageC;
App.PacketLink - CC2420ActiveMessageC;
App.Receive - AMReceiverC;
...
}
The module:
//In function to send data
...
call PacketLink.setRetries(PaqueteDatos, 10);
call PacketLink.setRetryDelay(PaqueteDatos, 100);
if (call EnviarDatos.send(0, PaqueteDatos, sizeof(MensajeDatos)) ==
SUCCESS)
...
//sendDone event
event void EnviarDatos.sendDone(message_t* msg, error_t error)
{
if (PaqueteDatos == msg)
{
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:[EMAIL PROTECTED]
To: 'Juan mailto:[EMAIL PROTECTED] Antonio López Riquelme' ;
tinyos-help@millennium.berkeley.edu
Sent: Monday, April 07, 2008 8:05 PM
Subject: RE: [Tinyos-help] Problems with ACKs in TinyOS 2.0.2
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 acknowledgment, setup a reliable packet transmission through
the PacketLink interface:
call PacketLink.setRetries(myMsg, 5);
call PacketLink.setRetryDelay(myMsg, 0);
This will automatically retry sending the packet 5 times, with no delays
between retransmissions. When you get a sendDone() event back, you can
check to see if the packet was delivered either by calling
PacketAcknowledgments.wasAcked(myMsg); OR by calling
PacketLink.wasDelivered(myMsg);.
You are receiving multiple packets at the base station because
acknowledgments are just as unreliable as sending any packet. If an
acknowledgement is dropped and you have to retransmit, then the base station
will receive duplicates. The PacketLink layer, combined with UniqueSend
and UniqueReceive layers in the CC2420 stack, prevent duplicate packet
receptions due to dropped acknowledgments. There is more documentation
here:
http://tinyos.cvs.sourceforge.net/*checkout*/tinyos/tinyos-2.x/doc/html/tep1
27.html
Finally, there is already a delay built into the send for the acknowledgment
wait period, and you will not get a sendDone() event back until an ack was
received or the ack wait period timed out.
-David
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Juan
Antonio López Riquelme
Sent: Monday, April 07, 2008 9:33 AM
To: tinyos-help@millennium.berkeley.edu
Subject: [Tinyos-help] Problems with ACKs in TinyOS 2.0.2
Hello,
I am working with TinyOS 2.0.2 and payload of 29 bytes. Two remotes nodes
send messages to node with BaseStation application.
I changed BaseStation program to work with 29 bytes of payload and
acknowledgements. I compiled with address 0. In BaseStationP:
#include AM.h
#include Serial.h
#define TOSH_DATA_LENGTH
RE: [Tinyos-help] Disable backoff CC2420 tmote sky
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 backoff should still be in play, and you will probably need to edit
the radio stack code to properly and completely remove it.
-David
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bhavish
Aggarwal
Sent: Thursday, April 03, 2008 5:05 PM
To: tinyos-help
Subject: [Tinyos-help] Disable backoff CC2420 tmote sky
Hi,
I too tried the same solution for disabling backoffs i.e. setting the
value of the events initialBackoff and congestionbackoff to 0 and 1 in
CC2420RadioM. But it did not make any perceivable difference in the
time taken for a packet to be transmitted (the time difference between
the send call and sendDone signal). This time was 6 ms before and
after turning off backoff.
Is there something I missed in this procedure?
Thanks,
Bhavish
On Thu, Jan 24, 2008 at 7:31 PM, shamo [EMAIL PROTECTED] wrote:
Dear Sir,
I just read David's answer about how to disable backoff.I use tmote sky.As
he said, I connect CC2420RadioM to MacBackoff, and write
initialBackoff(...)
and congestionBackoff(...) event to return 0 or 1. However, it does not
work. It seems that I can not disable the backoff in this way.I do not
know
why.Please give me a help. Can you give me an example?
Your answer:---
TinyOS 1.x:
configuration CC2420RadioC
{
provides {
...
interface MacControl;
interface MacBackoff;
...
}
}
interface MacBackoff
{
async event int16_t initialBackoff(TOS_MsgPtr m);
async event int16_t congestionBackoff(TOS_MsgPtr m);
}
Connect to MacBackoff, and when you get an initialBackoff(...) or
congestionBackoff(...) event, return 0 or 1. This method wasn't very
friendly for systems that wanted to specify different backoff periods for
different outbound AM types. With extra programming, you can get the
event
to set the backoff as you want it for any outbound message.
-David
-
SHA Mo
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] Receive Indicator
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 receiving. There is another physical indicator, EnergyIndicator, and a link level indicator, PacketIndicator available in the CC2420 stack. I think the EnergyIndicator is the only one being used right now. No documentation exists, this is purely for development and experimentation. -David _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nitin Sharma Sent: Wednesday, April 02, 2008 5:57 PM To: tinyos-help@millennium.berkeley.edu Subject: [Tinyos-help] Receive Indicator I was reading through when i got stuck in this. /** Byte reception/transmission indicator */ bool sfdHigh; ByteIndicator returns sfdHigh ? CC2420TransmitC ByteIndicator.isReceiving( ) , what does it return on reception and what on transmission? (Sorry , couldn't find the documentation) CC2420ReceiveC PacketIndicator.isReceiving( ) Whats the difference on Receive Detection using above i.e Reception from TransmitC or Reception from ReceiveC ( More generally, byte / packet ) Thanks. Nitin Sharma ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] SACK
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 frame is transmitted. -David _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of renjie huang Sent: Sunday, March 16, 2008 2:12 PM To: tinyos-help@millennium.berkeley.edu Subject: [Tinyos-help] SACK It seems that in TinyOS-2.x for CC2420 SACK strobe is issued when SACK_HEADER_LENGTH bytes of data is received and address check is passed. In this way it does not check crc before issuing SACK. Is it reliable enough? Why don't we wait until the whole packet is received from RXFIFO? If I want to issue SACK strobe only after receiving the whole packet from RXFIFO, is there something I should be careful? Thanks. -- Renjie ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] Can anyone help me clarify the MicaZ (CC2420) radiostack?
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 longer supported; however, you will be able to disable the CCA backoffs by searching and replacing any instance of STXONCCA with STXON in any CC2420 source code. -David _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ruoshui Liu Sent: Sunday, March 16, 2008 4:56 PM To: tinyos-help@millennium.berkeley.edu Subject: [Tinyos-help] Can anyone help me clarify the MicaZ (CC2420) radiostack? Dear all, Currently I am working on the MicaZ using CC2420 radio stack, and I am trying to completely disable the CCA function implemented by CC2420 radio stack. However, I did not find the right function to do so. Therefore, I went through the Mica High Speed Radio Stack and the Mica2 (CC1000) Radio Stack stated on the web: http://www.tinyos.net/tinyos-1.x/doc/. The question is what is the difference between the Mica2 (CC1000) Radio Stack and the Mica High Speed Radio Stack. Is the Mica2 (CC1000) Radio Stack totally different deign from the Mica High Speed Radio Stack, or interleaved design with it? They really confuse me! The other question is that where I can find the detail of MicaZ (CC2420) Radio Stack implemented with TinyOS 1.1.15. I know there is an article describing the MicaZ (CC2420) Radio Stack, but all the functions stated in that are implemented in TinyOS 2.0 which is not my case. I really need to find the right function to disable the CCA in CC2420 regardless whether the channel is busy or not by using TinyOS 1.1.15. Many thanks! Ruoshui ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] TXFIFO underflow not taken care of in TinyOS 2.0.2?
Hi Sha - You're right, we are missing a check for RXFIFO overflow. Right now the maximum default CC2420 packet size in TinyOS is 41 bytes (including CRC). The RXFIFO is 128 bytes, which means you'd be able to fit 3 full packets in the RXFIFO before an overflow occurs. Although I think it may be unlikely that you'd spontaneously receive 3+ full packets in the RXFIFO due to CSMA backoffs and transmit delays, it can still happen. But imagine this scenario: you receive 3 maxed-out packets that are valid, and get a fourth packet that causes an RXFIFO overflow, and is therefore corrupted. Do you flush the RXFIFO at that point and lose the 3 valid packets that are already in there? Or do you wait until you're reading out the fourth packet that is corrupted before flushing it? In the current scenario, you read out the amount of data as specified by the fourth packet and see that the CRC doesn't check out. Upon reading the next packet, the length is found to be invalid and the RXFIFO is flushed. Putting in an explicit check for RXFIFO overflow may be more desirable, but the question is, when is the best time to flush the RXFIFO? Right when the error occurs? Or after you get 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 have some questions concerning RXFIFO overflow. In CC2420ReceiveP.nc, RXFIFO is flushed only when the length byte is invalid. So where is RXFIFO overflow taken care of? Can reading bytes from RXFIFO automatically clear the overflow status? Also, in CC2420TransmitP, RXFIFO overflow status is not checked before issuing the STXONCCA or STXON strobe. So if RXFIFO has already overflowed, there will be no more space for ack frame. TinyOS 1.1.15 does do this check before sending and flush RXFIFO accordingly even though I'm not sure if it is for this purpose. Thanks, -Sha -- From: David Moss [EMAIL PROTECTED] Sent: Friday, March 14, 2008 5:26 PM To: 'Liusand' [EMAIL PROTECTED]; tinyos-help@millennium.berkeley.edu Subject: RE: [Tinyos-help] TXFIFO underflow not taken care of in TinyOS 2.0.2? 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. Due to the rules of the CSMA and Transmit modules, a new packet cannot be uploaded to the TX FIFO until the previous packet in the TX FIFO was transmitted. This should guarantee that the TX FIFO be empty when the next transmit occurs. If a cancel occurs, a quick SFLUSHTX empties the contents of the TX FIFO. -David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Liusand Sent: Friday, March 14, 2008 12:45 PM To: tinyos-help@millennium.berkeley.edu Subject: [Tinyos-help] TXFIFO underflow not taken care of in TinyOS 2.0.2? Hi, When I was studying CC2420TransmitP.nc, I noticed that TXFIFO is never flushed and underflow status is never checked. In CC2420RadioM.nc from TinyOS 1.1.15, TXFIFO is flushed in startSend() every time before it is written data to. It might be too conservative in TinyOS 1.1.15, but why overflow is never taken care of in TinyOS 2.0.2? Another related question is, in which situations TXFIFO underflow may happen? Thanks, Sha ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] TXFIFO underflow not taken care of in TinyOS 2.0.2?
The ACK delay was increased from ~128 (or lower) from earlier versions of the CC2420 to 256 simply to handle these types of cases. Functional tests show this delay works well for 'normal' networks of multiple nodes and unaltered CSMA backoffs; however, modifying the CSMA behavior may necessitate changes to the ACK delay. The ACK delay, like many parameters in the stack, was chosen based on the results of functional testing (with no SPI0 DMA). I'm not sure off the top of my head what the SPI throughput is, but it can also vary based on DMA settings. Adding SPI0 DMA support greatly 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 for the explanation. The treatment of packets already in the RXFIFO queue is definitely reasonable to the receiver. But if we use SACK to issue acknowledgements like in CC2420ReceiveP.nc, the 3rd packet may wait quite some time before the ack for it is sent, and hence the deadline at sender side may have been missed. The delay before ack timer fires is CC2420_ACK_WAIT_DELAY = 256, so does it take the delay in reading RXFIFO into consideration? What is the SPI speed in TelosB or TmoteSky? Thanks, Sha -- From: David Moss [EMAIL PROTECTED] Sent: Monday, March 17, 2008 10:21 AM To: 'Liusand' [EMAIL PROTECTED]; tinyos-help@millennium.berkeley.edu Subject: RE: [Tinyos-help] TXFIFO underflow not taken care of in TinyOS 2.0.2? Hi Sha - You're right, we are missing a check for RXFIFO overflow. Right now the maximum default CC2420 packet size in TinyOS is 41 bytes (including CRC). The RXFIFO is 128 bytes, which means you'd be able to fit 3 full packets in the RXFIFO before an overflow occurs. Although I think it may be unlikely that you'd spontaneously receive 3+ full packets in the RXFIFO due to CSMA backoffs and transmit delays, it can still happen. But imagine this scenario: you receive 3 maxed-out packets that are valid, and get a fourth packet that causes an RXFIFO overflow, and is therefore corrupted. Do you flush the RXFIFO at that point and lose the 3 valid packets that are already in there? Or do you wait until you're reading out the fourth packet that is corrupted before flushing it? In the current scenario, you read out the amount of data as specified by the fourth packet and see that the CRC doesn't check out. Upon reading the next packet, the length is found to be invalid and the RXFIFO is flushed. Putting in an explicit check for RXFIFO overflow may be more desirable, but the question is, when is the best time to flush the RXFIFO? Right when the error occurs? Or after you get 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 have some questions concerning RXFIFO overflow. In CC2420ReceiveP.nc, RXFIFO is flushed only when the length byte is invalid. So where is RXFIFO overflow taken care of? Can reading bytes from RXFIFO automatically clear the overflow status? Also, in CC2420TransmitP, RXFIFO overflow status is not checked before issuing the STXONCCA or STXON strobe. So if RXFIFO has already overflowed, there will be no more space for ack frame. TinyOS 1.1.15 does do this check before sending and flush RXFIFO accordingly even though I'm not sure if it is for this purpose. Thanks, -Sha -- From: David Moss [EMAIL PROTECTED] Sent: Friday, March 14, 2008 5:26 PM To: 'Liusand' [EMAIL PROTECTED]; tinyos-help@millennium.berkeley.edu Subject: RE: [Tinyos-help] TXFIFO underflow not taken care of in TinyOS 2.0.2? 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. Due to the rules of the CSMA and Transmit modules, a new packet cannot be uploaded to the TX FIFO until the previous packet in the TX FIFO was transmitted. This should guarantee that the TX FIFO be empty when the next transmit occurs. If a cancel occurs, a quick SFLUSHTX empties the contents of the TX FIFO. -David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Liusand Sent: Friday, March 14, 2008 12:45 PM To: tinyos-help@millennium.berkeley.edu Subject: [Tinyos-help] TXFIFO underflow not taken care of in TinyOS 2.0.2? Hi, When I was studying
RE: [Tinyos-help] TXFIFO underflow not taken care of in TinyOS 2.0.2?
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. Due to the rules of the CSMA and Transmit modules, a new packet cannot be uploaded to the TX FIFO until the previous packet in the TX FIFO was transmitted. This should guarantee that the TX FIFO be empty when the next transmit occurs. If a cancel occurs, a quick SFLUSHTX empties the contents of the TX FIFO. -David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Liusand Sent: Friday, March 14, 2008 12:45 PM To: tinyos-help@millennium.berkeley.edu Subject: [Tinyos-help] TXFIFO underflow not taken care of in TinyOS 2.0.2? Hi, When I was studying CC2420TransmitP.nc, I noticed that TXFIFO is never flushed and underflow status is never checked. In CC2420RadioM.nc from TinyOS 1.1.15, TXFIFO is flushed in startSend() every time before it is written data to. It might be too conservative in TinyOS 1.1.15, but why overflow is never taken care of in TinyOS 2.0.2? Another related question is, in which situations TXFIFO underflow may happen? Thanks, Sha ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] Which packet in RXFIFO is SACK acking?
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: Thursday, March 13, 2008 8:58 AM To: tinyos-help@millennium.berkeley.edu Subject: [Tinyos-help] Which packet in RXFIFO is SACK acking? Hi, I have a question on the SACK command strobe for CC2420. As we know, the RXFIFO can hold several packets as long as the total length is no more than 128. Hence, when the first packet is read out and then a SACK command is issued, which packet in the RXFIFO queue is the ack for? I checked CC2420ReceiveP.nc in T2, and it seems the ack is for the packet just read out. But some discussions on devel mailing-list said opposite. Can anyone help me undertand this? Thanks, Sha ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] Question on CC2420ReceiveP.nc in TinyOS 2.0.2
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 driver is attempting to change the state of the radio, and needs to verify the radio's status. -David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Liusand Sent: Thursday, March 13, 2008 6:35 PM To: tinyos-help@millennium.berkeley.edu Subject: [Tinyos-help] Question on CC2420ReceiveP.nc in TinyOS 2.0.2 Hi, I noticed that, in CC2420ReceiveP.nc from TinyOS 2.0.2, the receive() function calls RXFIFO.beginRead() without checking its return value. But as stated in CC2420Fifo.nc, beginRead() is supposed to return status byte returned when sending the last address byte of the SPI transaction. So does this mean the return value is not important and beginRead() will always succeed? Thanks, Sha ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] How to use interface RadioBackoff
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 of CSMA if it is simply listening for a specific case to arise. The RadioBackoff.requestInitialBackoff() event is signaled right before the message is attempting to send the first time. If the channel is found to be busy, CSMA will hold off on transmitting in a congestion backoff. Each subsequent congestion backoff that occurs while the channel is busy will result in the RadioBackoff.requestCongestionBackoff() event signaling. If you are interested in affecting the backoff times of CSMA, you MUST call back to the RadioBackoff interface INSIDE the event that fired. In other words, if you get a requestInitialBackoff() event and you're interested in changing the initial backoff delay, you call back only inside that event RadioBackoff.setInitialBackoff(...). Same thing with the requestCongestionBackoff() event - you must call back to RadioBackoff.setCongestionBackoff() inside the event if you want to affect operation. If you call the commands outside of an event, they will be ignored. Similarly, if you call back with the wrong command inside an event (like calling setCongestionBackoff() inside the requestInitialBackoff() event) it will be ignored. -David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of sergio mena doce Sent: Monday, March 10, 2008 7:16 AM To: tinyos-help@millennium.berkeley.edu Subject: [Tinyos-help] How to use interface RadioBackoff Hello, I'm working in tinyos application and I'd like to modify the backoff interval to do several communication test between motes. I don't understand fine how to use the interface RadioBackoff provided by the component CC2420CsmaC. When do requestInitialBackoff and requestCongestionBackoff events fires? When can I implement the setInitialBackoff and setCongestionBackoff? Can these commands go inside or outisde of the events? I hope your reply. Thanks. _ MSN Video. http://video.msn.com/?mkt=es-es ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] Looking for someone to port TinyOS to 16/32-bitPIC Microcontrollers
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 Timers, McuSleepC, UART, SPI, etc. The CCS compiler provides a lot of these functions built-in, which should make the implementations a lot easier. Anyone interested in this? -David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, March 05, 2008 2:20 PM To: [EMAIL PROTECTED] Cc: tinyos-help@millennium.berkeley.edu Subject: RE: [Tinyos-help] Looking for someone to port TinyOS to 16/32-bitPIC Microcontrollers Hi MS, These days there are over a one hundred (growing to 150) 16 32-bit PIC24, dsPIC, PIC32 products with a software stack and several supported RTOS-es, supported by a derivative of GCC compiler among others. These are price-competitive with Atmel and MSP430 and have parts up from 6KB to 512KB in Flash...i hope you can look at these again, RV -Original Message- From: Michael Schippling [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 05, 2008 10:47 AM To: Rishi Vasuki - C11300 Cc: tinyos-help@millennium.berkeley.edu Subject: Re: [Tinyos-help] Looking for someone to port TinyOS to 16/32-bit PIC Microcontrollers I believe there have been marginally successful attempts in the past, search back on this list for PIC to see if there's more info. But I think there are some hardware issues, e.g., the PICs I'm familiar with don't have a stack mechanism which makes implementing a real 'C' language difficult. If there are more modern PICs that are price competitive with Atmega and MSP, I'd be interested in looking at it again. MS [EMAIL PROTECTED] wrote: Hello, We were interested in investigating a port of TinyOS using our 8, 16 32-bit PIC Microcontrollers as hardware platforms. If anyone is interested in pursuing this, please contact me directly at [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Regards, Rishi ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- Platform: WinXP/Cygwin TinyOS version: 1.x, Boomerang Programmer: MIB510 Device(s): Mica2, MicaZ, Tmote Sensor board: homebrew ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] False acknowledgments and CRC
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 PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of renjie huang Sent: Tuesday, March 04, 2008 10:55 AM To: tinyos-help@millennium.berkeley.edu Subject: [Tinyos-help] False acknowledgments and CRC When I read following link, I have some question: http://docs.tinyos.net/index.php/CC2420_Known_Issues False acknowledgments can get sent back for corrupted packets that are not actually received. The issue is that acknowledgements are sent before the CRC check is performed. Does it mean hardware acknowledgments are send before CRC check is performed? But from CC2420 datasheet, it seems that AUTOCRC should be also enabled when hardware acknowledgment is enabled. Following is from CC2420 data sheet: CC2420 includes hardware support for transmitting acknowledge frames, as specified in [1]. Figure 22 shows the format of the acknowledge frame. If MDMCTRL0.AUTOACK is enabled, an acknowledge frame is transmitted for all incoming frames accepted by the address recognition with the acknowledge request flag set and a valid CRC. AUTOACK therefore does not make sense unless also ADR_DECODE and AUTOCRC are enabled. -- Renjie ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] UniqueSend question
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 implementation of UniqueSendP in tinyos-2.x/tos/chips/cc2420/unique/UniqueSendP.nc -David _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sikar Chan Sent: Sunday, February 24, 2008 10:42 AM To: tinyos-help@millennium.berkeley.edu Subject: [Tinyos-help] UniqueSend question Hi All Is there any different in coding for UniqueSend and just Send? I got confused with the coding for them as shown in http://www.tinyos.net/tinyos-2.x/doc/html/tep126.html Would any one give me some example or suggestion? Thanks Sikar Chan ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] serial send acknowledgement
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 stacks. -David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Philip Levis Sent: Wednesday, February 20, 2008 9:40 AM To: Kaan Tuna Cc: tinyos-help@millennium.berkeley.edu Subject: Re: [Tinyos-help] serial send acknowledgement On Feb 20, 2008, at 7:37 AM, Kaan Tuna wrote: Hello all, When we send data over the serial port, how can we verify that the receiver (PC, terminal...) succesfully received the packet? Do we need a modification in the application layer (ie in the code, SerialSend.SendDone ?)? Is there any implementation of this kind? Yes. You need a modification in the application layer. This has been a point of discussion on TEP 113. Currently, TinyOS acknowledges packets from the PC, but the PC does not acknowledge packets from TinyOS. The protocol would allow such a thing -- just send PROTO_PACKET_ACK to the PC -- but the serial stack implementation doesn't support it. On one hand, it would be nice if you could request ACKs; on the other, I'm worried about code bloat. Right now the serial stack is about 3.5-4K of code all together, and adding acks would probably add another 1K or so. Given that it's an infrequent request, yet many applications run into the code size limits on telos-family motes, I'm leery of adding support. Writing an alternative stack that supports acks isn't appealing, either, as that means maintaining parallel implementations (and I already maintain too much). Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] CC2420 Hardware ACKs
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]
[mailto:[EMAIL PROTECTED] On Behalf Of Rodolfo de
Paz Alberola
Sent: Thursday, February 14, 2008 4:28 AM
To: tinyos-help
Subject: [Tinyos-help] CC2420 Hardware ACKs
Hi all,
I was trying to set Hardware ACKs for CC2420 radio chip. I did a simple
ping pong application in which I posted a task call ack() inside the
event SplitControl.startDone(error_t error).
The task call ack activates HW acknowledgements in the following way:
bool activated = TRUE;
task void ack() {
atomic{
call CC2420Config.setAutoAck(activated,activated);
if (call CC2420Config.sync() != SUCCESS) {
post ack();
}
}
However, the mote that is sending messages is not receiving any ack.
Should I do anything else to activate CC2420 HW acks?. Any help?
Regards,
-
Rodo
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] CC2420 Hardware ACKs
Also, are you calling CC2420Config.sync() to commit your hardware
acknowledgment changes to the CC2420 hardware?
call CC2420Config.setAutoAck(TRUE, TRUE);
call CC2420Config.sync();
// wait awhile
event void CC2420Config.syncDone() {
...
}
-David
-Original Message-
From: 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 PacketAcknowledgements.requestAck(myMsg);
call AMSend.send(0x0, myMsg, sizeof(my_payload_t));
No, I thought that only calling the command setAutoAck
it should enable MDMCTRL0.AUTOACK leaving to the CC2420 radio chip
all the process.
This command that you mention for requesting acks I think that only
works for SW acks.
Does it the software work as expected using software acknowledgments?
Yes, I did another application using software acknowledgments and it
works fine,
but in this case I would like to use hw acks since i am trying to model
the
cc2420 radiochip which has hw acks as well.
Thanks for your help. Any idea?
Rodo
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(my_payload_t));
Does it the software work as expected using software acknowledgments?
-David
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rodolfo
de
Paz Alberola
Sent: Thursday, February 14, 2008 4:28 AM
To: tinyos-help
Subject: [Tinyos-help] CC2420 Hardware ACKs
Hi all,
I was trying to set Hardware ACKs for CC2420 radio chip. I did a simple
ping pong application in which I posted a task call ack() inside the
event SplitControl.startDone(error_t error).
The task call ack activates HW acknowledgements in the following way:
bool activated = TRUE;
task void ack() {
atomic{
call CC2420Config.setAutoAck(activated,activated);
if (call CC2420Config.sync() != SUCCESS) {
post ack();
}
}
However, the mote that is sending messages is not receiving any ack.
Should I do anything else to activate CC2420 HW acks?. Any help?
Regards,
-
Rodo
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] CC2420 Hardware ACKs
The CC2420 radio requires the acknowledgment request flag be set in the FCF
byte before it will automatically generate a hardware acknowledgment for any
received packet.
-David
-Original Message-
From: 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 PacketAcknowledgements.requestAck(myMsg);
call AMSend.send(0x0, myMsg, sizeof(my_payload_t));
No, I thought that only calling the command setAutoAck
it should enable MDMCTRL0.AUTOACK leaving to the CC2420 radio chip
all the process.
This command that you mention for requesting acks I think that only
works for SW acks.
Does it the software work as expected using software acknowledgments?
Yes, I did another application using software acknowledgments and it
works fine,
but in this case I would like to use hw acks since i am trying to model
the
cc2420 radiochip which has hw acks as well.
Thanks for your help. Any idea?
Rodo
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(my_payload_t));
Does it the software work as expected using software acknowledgments?
-David
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rodolfo
de
Paz Alberola
Sent: Thursday, February 14, 2008 4:28 AM
To: tinyos-help
Subject: [Tinyos-help] CC2420 Hardware ACKs
Hi all,
I was trying to set Hardware ACKs for CC2420 radio chip. I did a simple
ping pong application in which I posted a task call ack() inside the
event SplitControl.startDone(error_t error).
The task call ack activates HW acknowledgements in the following way:
bool activated = TRUE;
task void ack() {
atomic{
call CC2420Config.setAutoAck(activated,activated);
if (call CC2420Config.sync() != SUCCESS) {
post ack();
}
}
However, the mote that is sending messages is not receiving any ack.
Should I do anything else to activate CC2420 HW acks?. Any help?
Regards,
-
Rodo
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] CC2420 Hardware ACKs
Hi Rodo -
By default, software acknowledgments are enabled. This means
MDMCTRL0.AUTOACK is *disabled* by default. With the hardware auto-ack's
disabled, it is left up to CC2420ReceiveP to decide whether or not to issue
a software ack (via the SACK strobe).
There are two methods to enable automatic hardware acknowledgments:
1. On boot, turn on the radio, call CC2420Config.setAutoAck(TRUE, TRUE); and
then call CC2420Config.sync() to synchronize your settings with the radio
hardware. The (TRUE, TRUE) settings of setAutoAck are saying YES, issue
acknowledgments, and YES, use hardware acknowledgements instead of software
acknowledgments.
You will receive a syncDone() event when it's done configuring the hardware.
The radio will then automatically issue acknowledgments for valid packets
that have the acknowledgment flag set in the FCF byte of the header (set by
calling PacketAcknowledgements.requestAck(myMsg);
2. Enable hardware acknowledgments at compile time. This lets you avoid the
extra coding hassle required to enable hardware acks during runtime. Do this
by editing your Makefile to include the line:
CFLAGS+=-DCC2420_HW_ACKNOWLEDGEMENTS
When you compile, hardware 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] CC2420 Hardware ACKs
Thanks David for your reply, but now I don't know then the difference
between call or not call setAutoAck.
If I send a packet requesting the ack using the requestAck(myMsg)
comand, which means set the request flag in the FCF, I don't have to do
anything in the receiver to obtain an ack in the sender. The receiver
sends an ack automatically to the sender. So, what am i doing with this
command...sw or hw acks? Is then MDMCTRL0.AUTOACK enabled as default?
My understanding after reading the data sheet was:
- If MDMCTRL0.AUTOACK is not enabled: you have to check the request flag
and crc, if the flag is set and the crc valid, then you have to send the
ack. This meant for me SW acks.
- However, if autoack is enabled in the receiver, this mote sends the
ack automatically to the sender when the requested flag is set and crc
is valid.
Sorry for bother you again but I'm more confused now.
On Thu, 2008-02-14 at 09:34 -0700, David Moss wrote:
Also, are you calling CC2420Config.sync() to commit your hardware
acknowledgment changes to the CC2420 hardware?
call CC2420Config.setAutoAck(TRUE, TRUE);
call CC2420Config.sync();
// wait awhile
event void CC2420Config.syncDone() {
...
}
-David
-Original Message-
From: 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 PacketAcknowledgements.requestAck(myMsg);
call AMSend.send(0x0, myMsg, sizeof(my_payload_t));
No, I thought that only calling the command setAutoAck
it should enable MDMCTRL0.AUTOACK leaving to the CC2420 radio chip
all the process.
This command that you mention for requesting acks I think that only
works for SW acks.
Does it the software work as expected using software acknowledgments?
Yes, I did another application using software acknowledgments and it
works fine,
but in this case I would like to use hw acks since i am trying to model
the
cc2420 radiochip which has hw acks as well.
Thanks for your help. Any idea?
Rodo
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(my_payload_t));
Does it the software work as expected using software acknowledgments?
-David
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Rodolfo
de
Paz Alberola
Sent: Thursday, February 14, 2008 4:28 AM
To: tinyos-help
Subject: [Tinyos-help] CC2420 Hardware ACKs
Hi all,
I was trying to set Hardware ACKs for CC2420 radio chip. I did a simple
ping pong application in which I posted a task call ack() inside the
event SplitControl.startDone(error_t error).
The task call ack activates HW acknowledgements in the following way:
bool activated = TRUE;
task void ack() {
atomic{
call CC2420Config.setAutoAck(activated,activated);
if (call CC2420Config.sync() != SUCCESS) {
post ack();
}
}
However, the mote that is sending messages is not receiving any ack.
Should I do anything else to activate CC2420 HW acks?. Any help?
Regards,
-
Rodo
[Tinyos-help] RE: [Tinyos-devel] CTP + LPL
Matt and Phil -
This is meant to serve only as a private interface within the CC2420 stack
right now, not an interface provided by the ActiveMessage façade. After
all, once the interface is provided by ActiveMessage, it is no longer a
private CC2420-specific interface.
This is absolutely not a CTP or MultiHop protocol changing interface, since
that would make those libraries platform dependent, which is bad. This is
also not an LPL interface. Rather, the point of this interface is to simply
signal an event at the top of the stack that says the radio is sending a
message. Your application can do what it wants with that event.
For developers who want CTP + LPL on a CC2420 platform, this single
notification event gives them the ability to make it happen *right now*
without modifying any libraries. No modifications to CTP, no modifications
to LPL, no modifications to the radio stack, and nearly 0 cost.
You're correct: we should document this interface in the CC2420 TEP, or add
this to some other TEP to standardize it across radio stacks. A second
direction would be to continue adding onto the LowPowerListening interface
to make each outbound message use your local LPL 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@Millennium.Berkeley.EDU list'
Subject: Re: [Tinyos-devel] CTP + LPL
While I like this idea, are we going through a TEP vetting process
before adding new calls in the radio stack interface? I could think of
a lot of things that one might want to add to the CC2420 radio stack
but I thought the idea of the TEP process was to air these ideas
through feature extension proposals before just adding things when
they seem like a good idea. Then again maybe we need to draw a
distinction between public interfaces and private ones; I suppose
one could consider the internals of the CC2420 stack to be private
-- that is until any upper level code starts relying on the existence
of this interface and makes it impossible to port to other radio stacks.
On Feb 5, 2008, at 8:26 AM, David Moss wrote:
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.
You can access this interface to configure packets sent by any
module in your application, modifying the outbound packet based on
AM type, destination, etc. The main intention is CTP + LPL
integration (with examples attached modify as necessary), but you
can use it to add all sorts of system-wide functionality to your
application. Heres a small example:
event void SendNotifier.aboutToSend[AM_CTP_DATA](am_addr_t addr,
message_t *msg) {
call LowPowerListening.setRxSleepInterval(msg, 512);
}
Simply create a module that defines an LPL policy for your system,
and use the SendNotifier interface to enforce it.
If this hook works out, we can extend this to other radio stacks as
necessary.
-David
CtpLplC.ncCtpLplP.nc
___
Tinyos-devel mailing list
[EMAIL PROTECTED]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] Group ID on-the-fly change
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 ActiveMessageAddress.amGroup(). Accessing TOS_AM_GROUP or TOS_AM_ADDRESS directly is bad practice. Changing the address/group information will cause ActiveMessageAddressC to signal out an ActiveMessageAddress.changed() event. This notifies the radio stack that it needs to sync the radio hardware with the node's new address/group. -David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shaun Lawrence Sent: Monday, February 04, 2008 10:30 AM To: tinyos-help@millennium.berkeley.edu Subject: [Tinyos-help] Group ID on-the-fly change Anyone have an idea? Shaun -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shaun Lawrence Sent: Friday, February 01, 2008 11:34 AM To: tinyos-help@millennium.berkeley.edu Subject: RE: [Tinyos-help] Group ID Help That worked, now does anyone know how to change the GroupId on the fly? If I send a packet via the UART with a group id in the payload, is there a command I can call that will change TOS_AM_GROUP? Hopefully there is an easier way than editing/using the Deluge NetProg. Thanks all, Shaun -Original Message- From: Andreas Reinhardt [mailto:[EMAIL PROTECTED] Sent: Friday, February 01, 2008 2:49 AM To: [EMAIL PROTECTED] Cc: tinyos-help@millennium.berkeley.edu Subject: [Tinyos-help] Group ID Help Shaun, you wrote you were using BaseStation to monitor your packets. For some reason it always blanks the group ID field. Maybe my latest post regarding this issue is of some help: http://www.mail-archive.com/tinyos-help@millennium.berkeley.edu/msg17703.htm l Regards, Andreas ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] CTP + LPL
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.
You can access this interface to configure packets sent by any module in
your application, modifying the outbound packet based on AM type,
destination, etc. The main intention is CTP + LPL integration (with
examples attached - modify as necessary), but you can use it to add all
sorts of system-wide functionality to your application. Here's a small
example:
event void SendNotifier.aboutToSend[AM_CTP_DATA](am_addr_t addr, message_t
*msg) {
call LowPowerListening.setRxSleepInterval(msg, 512);
}
Simply create a module that defines an LPL policy for your system, and use
the SendNotifier interface to enforce it.
If this hook works out, we can extend this to other radio stacks as
necessary.
-David
CtpLplC.nc
Description: Binary data
CtpLplP.nc
Description: Binary data
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] CC2420 LQI/RSSI bug fix
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 into the wrong area of the metadata portion of the message_t. These bytes were then re-arranged in the part of the code that intentionally fills out metadata information, and in doing so, the LQI byte was overwritten by the RSSI byte. The fix has been checked into CVS. -David ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] about two radioes on one mote
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 radio for about 700-800 feet, on the ground, with basic wire antennas. There's a few FCC restrictions on 315 MHz, but 433 MHz is the next nicest thing. The CC1100 radio operates at 500 kbps, twice as fast as the CC2420 radio and thirteen times faster than the CC1000 in raw throughput. If you decrease the rate of throughput, you can even get farther range. The CC1100 radio is 4x4 mm, significantly smaller than the CC2420 radio. This is good for laying out a board, but the lower the frequency, the larger antenna you need as well. The CC1100 radio also has other nice features: hardware wake-on-radio (low power listening), forward error correction, FSK, MSK, GFSK, OOK, etc. to name a few. The CC2420 radio has quite a few problems: 2.4 GHz doesn't transmit very far under reasonable power output levels, 2.4 GHz is saturated with DSSS signals, etc. So if you're at all concerned about throughput, range, and chip size - then the CC1100 radio is the way to go. However, if you're interested in interfacing with other 2.4 GHz 802.15.4 devices, then the CC2420 radio is the way to go. If a small antenna size is the main concern but 802.15.4 isn't, then the CC2500 radio is the right choice. As far as interfacing both radios, this is done on a per-platform basis inside of the ActiveMessageC.nc file. Typically, you use the ActiveMessageC to forward interfaces onto the default radio. Then, you access your secondary radio directly. On my platform, I select the radio to send to on a per-message basis and have some logic at the ActiveMessageC level that directs the message to the proper device. -David _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of roberto pagliari Sent: Saturday, December 29, 2007 5:48 AM To: jiwen zhang Cc: tinyos-help Subject: Re: [Tinyos-help] about two radioes on one mote why did you use cc1100 instead of another cc2420? the modulation scheme is more robust. to answer your question, the communication between the microcontroller and the radio is based on spi (the uController is the master). If you need some code to implement the mac layer, and the packet formatting library, you might take a look at the tinyos stack. tinyos 1.x is csma, while tinyos 2.x is a mix of b-mac and x-mac. On Dec 27, 2007 6:32 PM, jiwen zhang [EMAIL PROTECTED] wrote: Hello all : we design a mote which has two radioes(cc2420 and cc1100) , now each one of them can send and receive data nomally , that is to say they are ok on hardware. now i want to use both of them in one application , sometimes i use one to communicate , sometimes i use the other (not synchronously , because they use the same SPI) . How to realize it ? Maybe it is a difficult question , but i think there must be a way to solve it . Is there someone having done this work ? can you give me some suggestions ? thank you very much!!! Jiwen ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] current MAC protocol in TinyOS
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 like B-MAC. Think of it like X-MAC on steroids. We're calling it BoX-MAC. The CC1000 radio stack primarily uses B-MAC at the moment. -David _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tie Luo Sent: Thursday, December 27, 2007 3:42 AM To: [EMAIL PROTECTED] Cc: tinyos-help@Millennium.Berkeley.EDU list Subject: Re: [Tinyos-help] current MAC protocol in TinyOS Hi, I was asking about TelosB with TinyOS 2.0. Thanks. On Dec 20, 2007 12:30 AM, Avinash Sridharan [EMAIL PROTECTED] wrote: Could be you be more specific about the platform and the version of TinyOS you are using ? -Avinash On Dec 18, 2007 8:23 PM, Tie Luo [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Dear All, Is the current MAC protocol in TinyOS B-MAC or X-MAC? I searched on tinyos.net and it seems to be B-MAC. I just want to confirm. Thanks. -- Regards, Tie ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- Phd Dept. of Electrical Engineering University of Southern California http://www-scf.usc.edu/~asridhar http://www-scf.usc.edu/%7Easridhar -- Regards, Tie ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] tinyos 2.x radio
We hired some help to come in and build us a complete system. The whole thing took about a month to put together, scripts and all, and there may be easier ways to go. The system is composed of a pixie box (computer) hosting dual 24-bit 50kSps DAQ's which record voltage measurements to a hard drive. The two voltage probes from the DAQ's are placed across a 1-ohm precision resistor, which is in series with the battery and the hardware being tested. Custom Matlab scripts are then used to process the raw data, converting the voltage samples into units of mA and plotting it. From the plots, we can select an area to integrate under the curve and find out information such as average mA's consumed, mAh/day (as if the highlighted section were to run all day long), microjoules, minimum mA's consumed, maximum mA's, etc. We'd like to open it up to the public (Matlab code at least), 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 measure the energy consumed by a node(or its microcontroller or radio)? What's the tool(apparatus or instrument) you used? Thank you very much! 2007/12/19, David Moss [EMAIL PROTECTED]: 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 all the CC2420 radios transmit all the time, the radios are never going to get to sleep. But by allowing your nodes to duty cycle and quieting down that network, you can get your power consumption down as low as 3-6 mAh/day pretty easily, somewhere around 1-5 second receive check intervals. At those limits, the microcontroller becomes the largest consumer of energy on the node and not the radio. In one of my deployments, I managed to get the CC2420 radios to ~4 mAh/day - that's about 425 days of lifetime for a 1700 mAh cell phone battery (not taking into account internal losses of the battery, etc.). Take a look at the BMAC and XMAC papers for more information on the trade-offs of power. http://www.polastre.com/papers/sensys04-bmac.pdf http://www.cs.colorado.edu/department/publications/reports/docs/CU-CS-1008-0 6.pdf The CC2420 low power listening implementation is a combination of the BMAC and XMAC strategies. -David _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] On Behalf Of roberto pagliari Sent: Tuesday, December 18, 2007 11:10 AM To: tinyos-help@millennium.berkeley.edu Subject: [Tinyos-help] tinyos 2.x radio Hi All, I have a question concerning the radio stack of cc2420 in tinyos 2.x. A low power listening is used, which means that the radio is turned off and on periodically in order to detect a preamble sequence. Hence, the transmitter broadcasts many times the packet to ensure reception to its neighbors. The radio stack of tinyos 1.x, at least the version I've been using, keeps the radio on all the time, and download the message from the cc2420 as soon as a preamble is detected. Is it possible to know, in terms of energy consumption and packet losses, which is the best strategy? thanks Roberto ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] Hardware Address Recognition
Hi Tiago - The TestPacketLink directory is for TUnit unit testing, and will not compile or run under normal circumstances. The interface itself should be easy to use: simply use the PacketLink interface in your BaseStation app, and wire it to CC2420ActiveMessageC. You'll also need to define the preprocessor variable PACKET_LINK somewhere, and I do it in my makefile (CFLAGS+=-DPACKET_LINK). That will compile in the PacketLink layer into the CC2420 radio stack. In your application, before your send a message over the radio, call PacketLink to configure the message correctly: // retry sending this message up to 50 times: call PacketLink.setRetries(myMsg, 50); // Add a X millisecond delay between each message retry (0 is the default) call PacketLink.setRetryDelay(myMsg, 0); // Then send your message. It will be delivered more reliably than before. call AMSend.send(addr, myMsg, sizeof(my_payload_t)); When you get your sendDone() event back, the message should have gotten ack'd if the receiver was nearby. You'll have to experiment with the PacketLink interface to get the behavior you desire for your application. The TEP should cover the rest of the details. -David -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 to search for the PacketLink component, but it seems not many people is using it, moreover it does not have any kind of reference in nesdoc, only the TEP. I found the example of PacketLink, more specific TestPacketLink, in the tinyos-2.x-contrib folder and even after i update it, it still don't compile, since as far as i know is missing the file: TestCase.h. Can you give us a clear example on how to use this component? or maybe send us the .h file, since i really need to write a reliable BaseStation application. Thanks in adavance, Tiago Uniiversity of Coimbra -- www.sounatural.com David Moss wrote: Sure - you can modify the basestation application to retransmit if you don't get an ack. Take a look at the PacketLink component and interface, it will help you do so automatically. For my deployment applications where good connectivity is required, I've modified base station to use the PacketLink interface to automatically retry failed transmissions. The acks will not automatically retransmit your packet, but will let you know if a single send got through or not. -David -Original Message- From: André Miguel de Almeida Marrão Rodrigues [mailto:[EMAIL PROTECTED] Sent: 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? Includind adding buffer to allow retransmission of packets? interference - it's possible from wifi collisions - in this configuration I think they should be very few range - that's not an issue in this case mismatched duty cycling parameters, etc. Did you modify your base station application to configure the outbound packet for delivery to a duty cycling receiver - yes we did So if the major problem is interference the acks shoudn't have resolved it? Thanks, André Rodrigues -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 configuration like BS --- Node I have packet loss when the acks are enabled and the code in the node retransmits the packed if it get lost. We are using 2% low power listening mode in T2 / TMote. Any ideias would be very apreciated. Regards, André Rodrigues PS: If a packet get lost in the BS - node direction, the 2.02 basestation code does the retransmission? - Original Message - From: David Moss [EMAIL PROTECTED] To: 'André Cunha' [EMAIL PROTECTED]; 'TinyOS ML' tinyos-help@millennium.berkeley.edu Sent: Thursday, December 13, 2007 5:16 PM Subject: RE: [Tinyos-help] Hardware Address Recognition 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 there's a redundant check. Hardware address recognition is enabled by default, and the redundant software address check performed for acknowledgements doesn't change that. Note at the top of CC2420ControlP
RE: [Tinyos-help] CC2420ReceiveP RXFIFO.readDone
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 SPI bus in any other way, you should be able to safely call continueRead(). CC2420ReceiveP (latest 2.x version), line 213, 218, and 266 do this. If you've toggle the CSN line or done anything else to the SPI bus, you must call beginRead() as demonstrated on line 259. 3. You do need to read out the rest of the bad packet to reach the beginning of the next packet in the RX FIFO. Another option is to flush out the RX FIFO, but then you risk losing any other packet that's in there. Lines 199-233 of CC2420ReceiveP demonstrate beginning to receive a packet, and cases where we don't want or care to receive the full packet because it's bad. Lots of edge cases here, and some I know are broken. -David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of André Cunha Sent: Wednesday, December 19, 2007 9:58 AM To: TinyOS ML Subject: [Tinyos-help] CC2420ReceiveP RXFIFO.readDone Hello all, I am trying to change the default code in RXFIFO.readDone in TOS2.0. I have some doubts on some parts of the code. I have some basic questions: 1. What is the meaning of the return of the following functions call FIFO.get() and call FIFOP.get()? 2. If I have more than one packet in the FIFO buffer do I use the RXFIFO.continueRead to read the next packet or can I use the RXFIFO.beginRead (without doing the flush)? 3. If I want to discard an bad packet or just one packet that does not fit some requirements (like the address) I need to call the RXFIFO.continueRead with the remaining length of the packet before reading a new one? Right? Thanks for the help. Best Regards André ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] tinyos 2.x radio
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 all the CC2420 radios transmit all the time, the radios are never going to get to sleep. But by allowing your nodes to duty cycle and quieting down that network, you can get your power consumption down as low as 3-6 mAh/day pretty easily, somewhere around 1-5 second receive check intervals. At those limits, the microcontroller becomes the largest consumer of energy on the node and not the radio. In one of my deployments, I managed to get the CC2420 radios to ~4 mAh/day - that's about 425 days of lifetime for a 1700 mAh cell phone battery (not taking into account internal losses of the battery, etc.). Take a look at the BMAC and XMAC papers for more information on the trade-offs of power. http://www.polastre.com/papers/sensys04-bmac.pdf http://www.cs.colorado.edu/department/publications/reports/docs/CU-CS-1008-0 6.pdf The CC2420 low power listening implementation is a combination of the BMAC and XMAC strategies. -David _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of roberto pagliari Sent: Tuesday, December 18, 2007 11:10 AM To: tinyos-help@millennium.berkeley.edu Subject: [Tinyos-help] tinyos 2.x radio Hi All, I have a question concerning the radio stack of cc2420 in tinyos 2.x. A low power listening is used, which means that the radio is turned off and on periodically in order to detect a preamble sequence. Hence, the transmitter broadcasts many times the packet to ensure reception to its neighbors. The radio stack of tinyos 1.x, at least the version I've been using, keeps the radio on all the time, and download the message from the cc2420 as soon as a preamble is detected. Is it possible to know, in terms of energy consumption and packet losses, which is the best strategy? thanks Roberto ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] Hardware Address Recognition
Sure - you can modify the basestation application to retransmit if you don't get an ack. Take a look at the PacketLink component and interface, it will help you do so automatically. For my deployment applications where good connectivity is required, I've modified base station to use the PacketLink interface to automatically retry failed transmissions. The acks will not automatically retransmit your packet, but will let you know if a single send got through or not. -David -Original Message- From: André Miguel de Almeida Marrão Rodrigues [mailto:[EMAIL PROTECTED] Sent: 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? Includind adding buffer to allow retransmission of packets? interference - it's possible from wifi collisions - in this configuration I think they should be very few range - that's not an issue in this case mismatched duty cycling parameters, etc. Did you modify your base station application to configure the outbound packet for delivery to a duty cycling receiver - yes we did So if the major problem is interference the acks shoudn't have resolved it? Thanks, André Rodrigues -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 configuration like BS --- Node I have packet loss when the acks are enabled and the code in the node retransmits the packed if it get lost. We are using 2% low power listening mode in T2 / TMote. Any ideias would be very apreciated. Regards, André Rodrigues PS: If a packet get lost in the BS - node direction, the 2.02 basestation code does the retransmission? - Original Message - From: David Moss [EMAIL PROTECTED] To: 'André Cunha' [EMAIL PROTECTED]; 'TinyOS ML' tinyos-help@millennium.berkeley.edu Sent: Thursday, December 13, 2007 5:16 PM Subject: RE: [Tinyos-help] Hardware Address Recognition 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 there's a redundant check. Hardware address recognition is enabled by default, and the redundant software address check performed for acknowledgements doesn't change that. Note at the top of CC2420ControlP the compile time options you have available (you should be able to configure these at runtime as well) #if defined(CC2420_NO_ACKNOWLEDGEMENTS) autoAckEnabled = FALSE; #else autoAckEnabled = TRUE; #endif #if defined(CC2420_HW_ACKNOWLEDGEMENTS) hwAutoAckDefault = TRUE; #else hwAutoAckDefault = FALSE; #endif // This changes the hardware address recognition. #if defined(CC2420_NO_ADDRESS_RECOGNITION) addressRecognition = FALSE; #else addressRecognition = TRUE; #endif -David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of André Cunha Sent: Thursday, December 13, 2007 9:21 AM To: TinyOS ML Subject: [Tinyos-help] Hardware Address Recognition Hello all, I was looking at the hardware recognition in the CC2420 in the file CC2420ControlP and, if fact, the CC2420 register (MDMCTRL0-ADDR_DECODE) is enabled. Looking at the CC2420ReceiveP in the RXFIFO.readDone I realized that the address verification is by software. Can anyone clarify this? I have changed the code of RXFIFO.readDone to only signal data reception but I would like to activate the hardware address recognition. Best Regards, André ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] Hardware Address Recognition
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 there's a redundant check. Hardware address recognition is enabled by default, and the redundant software address check performed for acknowledgements doesn't change that. Note at the top of CC2420ControlP the compile time options you have available (you should be able to configure these at runtime as well) #if defined(CC2420_NO_ACKNOWLEDGEMENTS) autoAckEnabled = FALSE; #else autoAckEnabled = TRUE; #endif #if defined(CC2420_HW_ACKNOWLEDGEMENTS) hwAutoAckDefault = TRUE; #else hwAutoAckDefault = FALSE; #endif // This changes the hardware address recognition. #if defined(CC2420_NO_ADDRESS_RECOGNITION) addressRecognition = FALSE; #else addressRecognition = TRUE; #endif -David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of André Cunha Sent: Thursday, December 13, 2007 9:21 AM To: TinyOS ML Subject: [Tinyos-help] Hardware Address Recognition Hello all, I was looking at the hardware recognition in the CC2420 in the file CC2420ControlP and, if fact, the CC2420 register (MDMCTRL0-ADDR_DECODE) is enabled. Looking at the CC2420ReceiveP in the RXFIFO.readDone I realized that the address verification is by software. Can anyone clarify this? I have changed the code of RXFIFO.readDone to only signal data reception but I would like to activate the hardware address recognition. Best Regards, André ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] Hardware Address Recognition
The base station does not automatically retransmit failed packets. There could be a lot of issues here: interference, collisions, range, mismatched duty cycling parameters, etc. Did you modify your base station application to configure the outbound packet for delivery to a duty cycling 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 configuration like BS --- Node I have packet loss when the acks are enabled and the code in the node retransmits the packed if it get lost. We are using 2% low power listening mode in T2 / TMote. Any ideias would be very apreciated. Regards, André Rodrigues PS: If a packet get lost in the BS - node direction, the 2.02 basestation code does the retransmission? - Original Message - From: David Moss [EMAIL PROTECTED] To: 'André Cunha' [EMAIL PROTECTED]; 'TinyOS ML' tinyos-help@millennium.berkeley.edu Sent: Thursday, December 13, 2007 5:16 PM Subject: RE: [Tinyos-help] Hardware Address Recognition 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 there's a redundant check. Hardware address recognition is enabled by default, and the redundant software address check performed for acknowledgements doesn't change that. Note at the top of CC2420ControlP the compile time options you have available (you should be able to configure these at runtime as well) #if defined(CC2420_NO_ACKNOWLEDGEMENTS) autoAckEnabled = FALSE; #else autoAckEnabled = TRUE; #endif #if defined(CC2420_HW_ACKNOWLEDGEMENTS) hwAutoAckDefault = TRUE; #else hwAutoAckDefault = FALSE; #endif // This changes the hardware address recognition. #if defined(CC2420_NO_ADDRESS_RECOGNITION) addressRecognition = FALSE; #else addressRecognition = TRUE; #endif -David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of André Cunha Sent: Thursday, December 13, 2007 9:21 AM To: TinyOS ML Subject: [Tinyos-help] Hardware Address Recognition Hello all, I was looking at the hardware recognition in the CC2420 in the file CC2420ControlP and, if fact, the CC2420 register (MDMCTRL0-ADDR_DECODE) is enabled. Looking at the CC2420ReceiveP in the RXFIFO.readDone I realized that the address verification is by software. Can anyone clarify this? I have changed the code of RXFIFO.readDone to only signal data reception but I would like to activate the hardware address recognition. Best Regards, André ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] Tunit setup on osx: serial port in tos-bsl problem
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 ?-r -e -I -p build/telosb/main.ihex.out-0 Note the ? in that line is supposed to be the BSL com port identifier, 133. Correct this by modifying your tunit.xml to remove the space: mote target=telosb motecom=serial@/dev/tty.usbserial-M4AJRG09:telosb installextras=bsl,133/ -David _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthias Woehrle Sent: Monday, December 10, 2007 9:19 AM To: tinyos-help@Millennium.Berkeley.EDU Subject: [Tinyos-help] Tunit setup on osx: serial port in tos-bsl problem Hi, I got a problem concerning setting up Tunit on my macbook (osx-tiger). I run Kevin Klues' setup ( http://docs.google.com/View?docid=ajjph9mvqk3z_bchp66xkmgk6npli=1 http://docs.google.com/View?docid=ajjph9mvqk3z_bchp66xkmgk6npli=1). The specific problem is that when the bootstraploader is executed, the serial port is not set (in my case:/dev/tty.usbserial-M4AJRG09, a tmote). [java] installing telosb binary using bsl [java] tos-bsl --telosb -c -r -e -I -p build/telosb/main.ihex.out-0 ... [java] MSP430 Bootstrap Loader Version: 1.39-telos-8 [java] An error occoured: [java] could not open port: [Errno 2] No such file or directory: '-r' [java] make: *** [program] Error 1 However, serial forwarder initialization works before that: [java] 160 [main] DEBUG com.rincon.tunit.run.TestRunManager - Creating serial forwarder serial@/dev/tty.usbserial-M4AJRG09:telosb [java] 205 [Thread-1] DEBUG com.rincon.tunit.sf.Sf - serial@/dev/tty.usbserial-M4AJRG09:telosb.9100: serial@/dev/tty.usbserial-M4AJRG09:115200: resynchronising [java] 205 [Thread-1] DEBUG com.rincon.tunit.run.TestRunManager - serial@/dev/tty.usbserial-M4AJRG09:115200: resynchronising [java] 208 [main] DEBUG com.rincon.tunit.run.TestRunManager - Disconnecting all serial forwarders [java] 2220 [Thread-0] DEBUG com.rincon.tunit.sf.Sf - serial@/dev/tty.usbserial-M4AJRG09:telosb.9100: server stopped [java] 3221 [main] DEBUG com.rincon.tunit.run.TestRunManager - Serial forwarders initialized successfully Some output from the ant execution is attached for debug as well as my build.xml and the tunit.xml. Note that the build.xml is patched with a fork in order toaccommodatefor a problem with osx'sAquaLookAndFeel. ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] How to send tones over CC2420?
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, 2007 5:47 PM To: Yashesh Mankad Cc: tinyos-help@Millennium.Berkeley.EDU Subject: Re: [Tinyos-help] How to send tones over CC2420? I have never done it, but I think, to do that you will have to put the CC2420 chip in debug mode. This is not support by tinyOS AFAIK, but I might be wrong. Because this is not useful for tinyOS, we just want to transmit packets. You should start reading the datasheet of the radio chip, and see if sending tone is possible. I think you will have to write your own driver for that.. Best regards, Alban 2007/11/3, Yashesh Mankad [EMAIL PROTECTED]: Hi guys, I have joined the forum just recently am new to the world of NesC. I am working on efficient jamming of 802.11 networks usinf sensor nodes. I am using the motiev Telosb mote with the CC2420 radio. I wanted to try sending continous tones through the radio. Can anyone tell me how to do this? Or can you tell me which interface do I look out for this purpose in the apps directory Thanks Yashesh. _ Now you can chat without downloading messenger. Click here http://in.rd.yahoo.com/tagline_webmessenger_5/*http:/in.messenger.yahoo.com /webmessengerpromo.php to know how. ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Basestation - tinyos 2.0.1 vs 2.0.2
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] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, November 08, 2007 12:22 PM To: tinyos-help@Millennium.Berkeley.EDU Subject: [Copfilter] Copy of quarantined email - *** SPAM *** [11.6/5.0][Tinyos-help] Basestation - tinyos 2.0.1 vs 2.0.2 Just checking, did BasestationCC2240 get removed from 2.0.1 when updating to 2.0.2? I just installed 2.0.2 and that directory seemed to go away... Kurt ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Scanned with Copfilter Version 0.84beta2 (ProxSMTP 1.6) AntiVirus: ClamAV 0.91.2-exp/4711 - Thu Nov 8 19:19:47 2007 AntiVirus: F-PROT 4.6.7 Engine version: 3.16.15 SIGN.DEF 7 Nov07 - SIGN2.DEF 7 Nov07 - MACRO.DEF 7 Nov07 by Markus Madlener @ http://www.copfilter.org ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] RE: about Blaze CC1100 radio stack
There are some docs available in tinyos-2.x-contrib\blaze\docs, showing the architecture of the Blaze radio stack. It's not dependent upon microcontroller, but your platform does need to have some wiring and stuff setup. This must be done manually. To start, take a look at the tinyos-2.x-contrib\blaze\tos\platforms\tmote1100 directory. This is an example platform I hacked together by attaching a CC1100 to a tmote's SPI bus - you can create your own platform as well (be sure to make a corresponding .target file in tinyos-2.x/support/make before trying to compile - there are tutorials on how to do this somewhere). To tell the code how the radio is actually connected to the microcontroller, you need to edit the equivalent of tinyos-2.x-contrib\blaze\tos\platforms\XYZ\chips\ccxx00. Each module or configuration here tells the source code how the radio is physically connected - including interrupts, SPI bus, and GPIO's. You'll have to make a version of that for the atmega microcontroller, and to do that I recommend you look at the tinyos-2.x/tos/platforms/micaz/chips/cc2420. The CCxx00 radio's platform-dependent code follows the CC2420 stuff closely. Because this is a dual-radio stack, your platform will need to include at compile time the radio type you want to use. I did this in tinyos-2.x-contrib\blaze\tos\platforms\XYZ\ActiveMessageC.nc by referencing the component CC1100ControlC. If you wanted to use the CC2500, or both, you'd reference CC2500ControlC. Finally, you'll also need to make sure your tinyos-2.x-contrib\blaze\tos\platforms\XYZ\.platform file includes all the correct directories at compile time. It's a task to port this to a new platform, but examples already exist all over the place so hopefully it won't be so bad. Really look 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: about Blaze CC1100 radio stack Hello David : Thank you very much ,now I have downloaded the source code. can you give some descriptions about project Blaze? what is the structure of blaze? I learn it was designed for microprocessor MSP430? If I want to transplant it to Atmega128L, what should I do?can you give me some suggestions? thank you very much!! 2007/11/5, David Moss [EMAIL PROTECTED]: Hi Jiwen - Yes, we have been finishing up the development of the CC1100/CC2500 radio stack, blaze. You can download it directly from CVS from the tinyos-2.x project, under its tinyos-2.x-contrib module. The directions for downloading CVS are at http://sourceforge.net/cvs/?group_id=28656 And you could use a command like: cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/tinyos co -P tinyos-2.x-contrib -David _ From: jiwen zhang [mailto: [EMAIL PROTECTED] Sent: Monday, November 05, 2007 12:43 AM To: [EMAIL PROTECTED] Subject: about Blaze CC1100 radio stack Hello : I am doing research about wireless sensor network ,recently we designed a kind of mote with Atmega128+cc1100, but there is no supporting in tinyos which made me very dispointed. Accidentally I find a project named Blaze CC1100 radio stack in www.tinyos.net http://www.tinyos.net/ , it provides supporting for cc1100 in tinyos, I really get the source code ,but i can't get a way to download it .I want to know whether it is free. can you give me a straightforward address to download it . Thank you very much. ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] CTP with and without LPL enabled on MicaZ
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 to manually edit the CTP library, accessing the LowPowerListening interface and setting up parameters like LowPowerListening.setLocalSleepInterval(ms) and LowPowerListening.setRxSleepInterval(msg, ms). We're somewhat in the process of developing a layer that will automatically configure CTP packets (and others) for some default low power listening usage model, but it's looking to be awhile before it's complete. -David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Xiaofan Jiang Sent: Friday, November 02, 2007 3:41 PM To: Tinyos Help Subject: [Tinyos-help] CTP with and without LPL enabled on MicaZ Hi, I'm trying to run some power measurements of motes running CTP collection with and without LPL enabled (on the MicaZ). However, I don't seem to see any difference. In this picture - http://buzzing.cs.berkeley.edu/~xjiang/webfiles/NOLPLvsLPL.png , the left is without LPL and the right is with. The lines with positive slopes are energies and the flat ones are powers, of four different motes. Does anyone know if I need to do anything other than including LOW_POWER_LISTENING in the CFLAGS in the Makefile to enable LPL? Also has anyone had any experiences with LPL on MicaZs? Thanks! -Fred ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] successive messages in LPL - do they use the preamble or do they not need to?
In TinyOS 2.0.1 the Ack LPL version should not stop sending its wake-up transmission to the broadcast address, ensuring all nodes in the vicinity receive the broadcast packet. The LPL layer, when sending to the broadcast address, disables acknowledgement requests and shouldn't even check acknowledgements on its internal sendDone() events. Preambles, or more aptly named wake-up transmissions are packetized (there's nothing preamble about it). In the TinyOS 2.0.1 Ack version, on the other hand, will simply transmit the packet it is trying to actually deliver. If acknowledged right away, it stops. In this sense it's just transmitting at 100% throughput. The NoAck LPL version will initiate another full wake-up transmission lasting the duration of a receive check. You're correct in assuming that a more efficient method for the NoAck version is for it to realize that because it just 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 help Forum (E-mail)' Subject: RE: [Tinyos-help] successive messages in LPL - do they use the preamble or do they not need to? Will/Should the second send initiate a second preamble within LPL or will/should LPL decide to send the message straight away (can't really use the ACK'd LPL as a number of the messages are basically broadcast so if I ACK then I run the risk of only the node that ACK'd receiving properly if the rest wake at different times). Ideally it would realise it had recently (or recently-enough) performed a long preamble so could just start transmitting straight away? thanks for the replies! -Ben -Original Message- From: David Moss [mailto:[EMAIL PROTECTED] Sent: 30 October 2007 19:25 To: 'Murray, Ben'; 'Tinyos help Forum (E-mail)' Subject: RE: [Tinyos-help] successive messages in LPL - do they use the preamble or do they not need to? 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 packets will be received during the same wake-up period. -David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Murray, Ben Sent: Tuesday, October 30, 2007 10:48 AM To: Tinyos help Forum (E-mail) Subject: [Tinyos-help] successive messages in LPL - do they use the preamble or do they not need to? [tos2, micaz] When using low power listening if I wish to send two packets over the radio, it is there a special way in which I can make sure they will both be sent after the same preamble such that all receiving motes that caught preamble in front of the first message also received the subsequent second message before they go to sleep again on will LPL/TOS take care of this internally? i.e. if my code look something like this: setRxSleepInterval(500) send(pkt1) -- senddone (confirming send accepted for pkt1) send(pkt2) (does this have to wait for the senddone from pkt1 or will it be put in a queue? Will a LPL node that wakes during the preamble receive both pkt1 and pkt2 during the same transmission in quick succession for (or at least during te same wake period) Many Thanks Ben ** ** *** Please consider the environment before printing this email. ** ** *** This email and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and may not be divulged to any third party without the express permission of the originator. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thales Research Technology (UK) Limited. ** ** *** ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/t inyos-help ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] Bug in CC2420 timestamp
2 edge cases:
1) A packet is received, generating a timestamp. The packet is dropped
internally to CC2420 hardware, while a second packet is received which
generates a second timestamp. The older timestamp is applied to the newer
packet.
2) A corrupted packet is received, forcing the CC2420 driver to flush
out the RX FIFO. The timestamp queue is possibly not flushed. The next
packet received gets a corrupted timestamp.
Both of these edge cases can be reproduced on a single node through the use
of unit tests. After reproducing the errors with unit testing, we can
engineer a solution and use those tests to know when the problem has been
solved.
One possible solution, which is what you may have been leading to: We can
generate a second timestamp for the end of frame SFD interrupt. Comparing
the SFD with EFD timestamps, we know if the duration of the packet was too
short and discard the timestamp. There are probably more reliable solutions
though.
How does comparing msg-time to the CC2420Receive.sfd( uint16_t time )
'time' value tell you that the timestamp should be discarded? That 'time'
value from the SFD interrupt gets stored in the timestamp queue before being
propagated to msg-time. Is there a 3rd issue here where msg-time is not
being set correctly to the latest value from the timestamp queue?
-David
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jeongyeup
Paek
Sent: Wednesday, October 31, 2007 9:37 AM
To: Min Guo
Cc: Federico Fiorentin; tinyos-help@Millennium.Berkeley.EDU
Subject: Re: [Tinyos-help] Bug in CC2420 timestamp
I am also having the same problem: incorrect timestamps.
This happens more often when there are more nodes sending more packets.
(which means more more sfd interrupts)
As Miklos said, the problem is not overflow but mismatch between
the timestamp(at sfd interrup) and the received packet.
As Federico said, the incorrect time is always in the past.
From these experience, we can guess that something is going wrong
in the management of timestamp_queue[] in CC2420ReceiveP.nc.
One way to check whether I have a wrong time or not is,
- when I get receive sfd signal, write down the 'uint16_t time16'.
- later, when I get a packet, compare 'time16' with 'msg-time'.
If they do not match, something went wrong... should discard.
One thing I am going to try today is to increase the size of
timestamp_queue[] in CC2420ReceiveP.nc: 8 -- 32;
since it might just be because of queue wrapping around.
Right now, there is no protection for 'head' and 'tail'
pointers for timestamp_queue[].
Thanks
- jpaek
Min Guo wrote:
Hi Federico,
I met the same problem. I've written a time synchronization component
for TinyOS 2.x. Currently some (very few) synchronization messages are
discarded because of the error of metadata-time (earlier than
expected).
Hope some one can point out the reason.
Regards,
Min
On 10/31/07, Federico Fiorentin [EMAIL PROTECTED] wrote:
Hi all.
The issues is the 16-bit timestamp in the received packet somethimes
results incorrect, in that case the time result always less than what
I aspect.
Probably the the timestamp refers to the previous SFD signal.
I tried to compare that timestmap against the time argument of the
RadioTimeStamp.receivedSFD(uint16_t time){ }. When the timestamp is
correct generally they are equal, in the other cases the
RadioTimeStamp result more precise.
Using:
RadioTimeStamp.receivedSFD(uint16_t time){ }
Now the problem is how can I determine to which kind of packet the SFD
event is referred.
Federico
2007/10/30, Miklos Maroti [EMAIL PROTECTED]:
Hi David,
The problem is not that it overflows, but it contains an inccorect
value. In certain situations there are more packets in the RXFIFO and
we do not know how to pair up the timestamps made for the SFD and the
data packets. This is especially problematic if for some reason some
of those packets get lost or not even get into the RXFIFO.
We should start a discussion on the Timestamping interface. I think it
should be allowed for the radio stack to say that it could not
properly timestamp the packet (just a flag) 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. Is the issue here that the
16-bit
timestamp rolls over to 0 periodically? Would a 32-bit timestamp be
better?
-David
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Federico
Fiorentin
Sent: Tuesday, October 30, 2007 6:39 AM
To: tinyos-help@Millennium.Berkeley.EDU
Subject: [Tinyos-help] Bug in CC2420 timestamp
I'm working on time synchronization with tmote sky motes and TinyOS2.
I'm using a poller that sends a PollPacket every X milliseconds
RE: [Tinyos-help] checking the radio status when using low powerlistening?
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 PowerCycleP module, looks like this:
enum {
S_OFF, // off by default
S_TURNING_ON,
S_ON,
S_TURNING_OFF,
};
The RadioPowerState interface can only be S_ON or S_OFF according to the
PowerCycleP code. And the SplitControlState can be any of the 4 states.
So, tap into PowerCycleC's State interfaces and you can query the state of
the radio:
call RadioPowerState.isState(S_ON);
call SplitControlState.getState();
etc...
TRANSMISSIONS:
The DefaultLplC configuration provides a similar interface for the Send side
of things:
interface State as SendState;
Its State enum is in the DefaultLpl.h file:
typedef enum {
S_LPL_NOT_SENDING,// DEFAULT
S_LPL_FIRST_MESSAGE, // 1. Sending the first message
S_LPL_SENDING,// 2. Sending all other messages
S_LPL_CLEAN_UP, // 3. Clean up the transmission
} lpl_sendstate_t;
-David
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Murray,
Ben
Sent: Tuesday, October 30, 2007 3:10 AM
To: Tinyos help Forum (E-mail)
Subject: [Tinyos-help] checking the radio status when using low
powerlistening?
Hi
is there a quick and concise way to check whether the radio is on/active
when using low power listening? For example, if I wanted to shut the radio
off fully (AMControl.stop()) but only if I was certain LPL was not in the
middle of detecting energy or receiving a packet and had initiated or
completed its own radio turn off action. Something along the lines of
Timer.IsRunning() perhaps?
Regards
Ben
***
Please consider the environment before printing this email.
***
This email and any files transmitted with it are intended solely for the use
of
the individual or entity to whom they are addressed and may not be divulged
to
any third party without the express permission of the originator. Any views
expressed in this message are those of the individual sender, except where
the
sender specifically states them to be the views of Thales Research
Technology
(UK) Limited.
***
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] shorter (cc2420/telosb) radio range in t2 compared tot1?
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 shorter. This causes less throughput but an increase in fairness. This brings up a good point though: more energy is consumed in T2 to deliver the same amount of information because throughput is diminished. We should explore turning the radio to IDLE during CSMA backoff wait periods to see how that impacts energy consumption and throughput. -David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeongyeup Paek Sent: Tuesday, October 30, 2007 12:33 AM To: tinyos-help Subject: [Tinyos-help] shorter (cc2420/telosb) radio range in t2 compared tot1? Dear all. I am running a very simple test applications where 40 nodes are broadcasting packets every 10 sec, and a BaseStation node is listening to those packets. And I am receiving far less packets in t2, compared to t1, for (what I believe to be) the same application. So I was wondering whether anyone had experienced shorter radio range in t2 compared to t1. The exact scenario is, 40 telosb nodes, with without 'CFLAGS += -DCC2420_DEF_RFPOWER=31', on an indoor testbed (http://enl.usc.edu/projects/tutornet/) where node 1~40 are sending broadcasts and node 10 is the BaseStation. I ran experiments several times, for several tens of minutes each time, and tried channel 23 and 26. Also, although I am new to T2, I have some experiences with T1. In T1, I receive packets from 15~20 nodes on average. In T2, I receive packets from 8~12 nodes on average. And the only guess that I can think of (assuming that I've done t1-t2 poring correctly) is shorter radio range in t2 compared to t1 for some weird reason. is this possible? -- Jeongyeup Paek Ph.D. student Embedded Networks Laboratory Department of Computer Science University of Southern California http://enl.usc.edu/~jpaek ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] Bug in CC2420 timestamp
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? -David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Federico Fiorentin Sent: Tuesday, October 30, 2007 6:39 AM To: tinyos-help@Millennium.Berkeley.EDU Subject: [Tinyos-help] Bug in CC2420 timestamp I'm working on time synchronization with tmote sky motes and TinyOS2. I'm using a poller that sends a PollPacket every X milliseconds and a set of clients that timestamp the arrival time of the PollPacket. I found that the 16 timestamp in the time field of the Metadata are somethimes incorrect ( CC2420Packet.getMetaData(msg)-time ). This affects the 1% of the TimeStamps per mote. I compared the value timestamp(n) - timestamp(n-1) of two different motes. Is there any patch or a way to fix it? I appreciate any advice ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] Question abouttinyos-2.x/apps/tests/cc2420/RssiToSerial
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 what it means: The RSSI register value RSSI.RSSI_VAL can be referred to the power P at the RF pins by using the following equations: P = RSSI_VAL + RSSI_OFFSET [dBm] where the RSSI_OFFSET is found empirically during system development from the front end gain. RSSI_OFFSET is approximately -45. E.g. if reading a value of -20 from the RSSI register, the RF input power is approximately -65 dBm. On the embedded side of this application, we're simply streaming raw RSSI values from the radio and sending them in a packet through the serial port. The Java side accepts those packets, does some GUI-friendly mangling to the RSSI value, and displays the bar graph. If you're going to start anywhere, I'd recommend editing the Java application to print out the raw RSSI values to the screen perhaps, or using the equation from the datasheet to convert them to [dBm]. It's a pretty easy hack. -David _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of sergio mena doce Sent: Tuesday, October 30, 2007 3:24 AM To: tinyos-help@millennium.berkeley.edu Subject: [Tinyos-help] Question abouttinyos-2.x/apps/tests/cc2420/RssiToSerial Hello. I'm a telecommunications engineering degree student from Barcelona (Spain). I'm working with tinyos-2.x under Linux. I have a question executing the RssiToSerial application. As you would can know, RssiToSerial shows by console strings like the following: [+++ ] When there isn't transmitter activity it shows: [+++ ] In the file README.txt of the RssiToSerial tells that since the Java side has to convert the readings into a CLI bar graph, it's scaled by some (possibly non-linear) factor. Is there any way to read the Rssi in dBm's, dBW,s or some units to measure the power of the Rssi? What does mean each '+' additive char of the string? Thanks by your help. _ Express yourself instantly with MSN Messenger! MSN http://clk.atdmt.com/AVE/go/onm00200471ave/direct/01/ Messenger ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] successive messages in LPL - do they use the preamble or do they not need to?
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 packets will be received during the same wake-up period. -David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Murray, Ben Sent: Tuesday, October 30, 2007 10:48 AM To: Tinyos help Forum (E-mail) Subject: [Tinyos-help] successive messages in LPL - do they use the preamble or do they not need to? [tos2, micaz] When using low power listening if I wish to send two packets over the radio, it is there a special way in which I can make sure they will both be sent after the same preamble such that all receiving motes that caught preamble in front of the first message also received the subsequent second message before they go to sleep again on will LPL/TOS take care of this internally? i.e. if my code look something like this: setRxSleepInterval(500) send(pkt1) -- senddone (confirming send accepted for pkt1) send(pkt2) (does this have to wait for the senddone from pkt1 or will it be put in a queue? Will a LPL node that wakes during the preamble receive both pkt1 and pkt2 during the same transmission in quick succession for (or at least during te same wake period) Many Thanks Ben *** Please consider the environment before printing this email. *** This email and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and may not be divulged to any third party without the express permission of the originator. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thales Research Technology (UK) Limited. *** ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] RE: Using blaze
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. interfaces are different, and the Blaze radio stack is compatible with the newest interfaces. You'll probably have to check out the TinyOS baseline to get it fixed. The CC1100Control errors are valid. I've been developing on a CC2500, and haven't had the chance to compile the CC1100 stuff on my machine. I'll send the CC1100 error messages you've found to Jared Hill (cc'd) who's also working on the stack to see if he can solve it and check it back in. So try getting the latest TinyOS baseline and we'll work on fixing those CC1100 compile time errors. Thanks, -David -Original Message- From: Gustavo [mailto:[EMAIL PROTECTED] Sent: Monday, October 08, 2007 8:54 AM To: [EMAIL PROTECTED] Subject: Using blaze Mr. Moss, We have been attempting to use your blaze radio in our mote since it provides all the code for the CC1100 radio. However, installing the files in the tinyos-2.x-contrib/blaze/ to the tos folder in opt/tinyos-2.x/tos results in the following error when we attempt to run make: (even with make tmote1100): mkdir -p build/utmost compiling ContinuousTransmitC to a utmost binary ncc -o build/utmost/main.exe -Os -O -mdisable-hwmul -Wall -Wshadow -DDEF_TOS_AM_GROUP=0x7d -Wnesc-all -mdisable-hwmul -target=utmost -fnesc-cfile=build/utmost/app.c -board= -DIDENT_PROGRAM_NAME= \ContinuousTrans\ -DIDENT_USER_ID=\gustavo\ -DIDENT_HOSTNAME= \Gustavo\ -DIDENT_USER_HASH=0xba450eabL -DIDENT_UNIX_TIME=0x470a4d36L -DIDENT_UID_HASH=0xd5cf4b3fL ContinuousTransmitC.nc -lm In file included from /opt/tinyos-2.x/tos/chips/blazeradio/am/BlazeActiveMessageC.nc:27, from /opt/tinyos-2.x/tos/chips/blazeradio/BlazeC.nc:55, from /opt/tinyos-2.x/tos/platforms/utmost/ActiveMessageC.nc:35, from ContinuousTransmitC.nc:11: In component `BlazeActiveMessageP': /opt/tinyos-2.x/tos/chips/blazeradio/am/BlazeActiveMessageP.nc:59: conflicting types for `AMSend.getPayload' /opt/tinyos-2.x/tos/interfaces/AMSend.nc:125: previous declaration of `AMSend.getPayload' /opt/tinyos-2.x/tos/chips/blazeradio/am/BlazeActiveMessageP.nc: In function `AMSend.getPayload': /opt/tinyos-2.x/tos/chips/blazeradio/am/BlazeActiveMessageP.nc:60: too many arguments to function `SubSend.getPayload' /opt/tinyos-2.x/tos/chips/blazeradio/am/BlazeActiveMessageP.nc: At top level: /opt/tinyos-2.x/tos/chips/blazeradio/am/BlazeActiveMessageP.nc:133: conflicting types for `Packet.getPayload' /opt/tinyos-2.x/tos/interfaces/Packet.nc:108: previous declaration of `Packet.getPayload' /opt/tinyos-2.x/tos/chips/blazeradio/am/BlazeActiveMessageP.nc:32: `Snoop.payloadLength' not implemented /opt/tinyos-2.x/tos/chips/blazeradio/am/BlazeActiveMessageP.nc:32: `Snoop.getPayload' not implemented /opt/tinyos-2.x/tos/chips/blazeradio/am/BlazeActiveMessageP.nc:32: `Receive.payloadLength' not implemented /opt/tinyos-2.x/tos/chips/blazeradio/am/BlazeActiveMessageP.nc:32: `Receive.getPayload' not implemented In file included from /opt/tinyos-2.x/tos/chips/blazeradio/select/RadioSelectC.nc:36, from /opt/tinyos-2.x/tos/chips/blazeradio/am/BlazeActiveMessageC.nc:41, from /opt/tinyos-2.x/tos/chips/blazeradio/BlazeC.nc:55, from /opt/tinyos-2.x/tos/platforms/utmost/ActiveMessageC.nc:35, from ContinuousTransmitC.nc:11: In component `RadioSelectP': /opt/tinyos-2.x/tos/chips/blazeradio/select/RadioSelectP.nc:116: conflicting types for `Send.getPayload' /opt/tinyos-2.x/tos/interfaces/Send.nc:114: previous declaration of `Send.getPayload' /opt/tinyos-2.x/tos/chips/blazeradio/select/RadioSelectP.nc: In function `Send.getPayload': /opt/tinyos-2.x/tos/chips/blazeradio/select/RadioSelectP.nc:117: too many arguments to function /opt/tinyos-2.x/tos/chips/blazeradio/select/RadioSelectP.nc: At top level: /opt/tinyos-2.x/tos/chips/blazeradio/select/RadioSelectP.nc:26: `Receive.payloadLength' not implemented /opt/tinyos-2.x/tos/chips/blazeradio/select/RadioSelectP.nc:26: `Receive.getPayload' not implemented In file included from /opt/tinyos-2.x/tos/chips/blazeradio/link/PacketLinkC.nc:51, from /opt/tinyos-2.x/tos/chips/blazeradio/BlazeC.nc:68, from /opt/tinyos-2.x/tos/platforms/utmost/ActiveMessageC.nc:35, from ContinuousTransmitC.nc:11: In component `PacketLinkP': /opt/tinyos-2.x/tos/chips/blazeradio/link/PacketLinkP.nc:166: conflicting types for `Send.getPayload' /opt/tinyos-2.x/tos/interfaces/Send.nc:114: previous declaration of `Send.getPayload' /opt/tinyos-2.x/tos/chips/blazeradio/link/PacketLinkP.nc: In function `Send.getPayload': /opt/tinyos-2.x/tos/chips/blazeradio/link/PacketLinkP.nc:167: too many arguments to function `SubSend.getPayload' In file included from
RE: [Tinyos-help] CC2420 Radio
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 which state does stay? Idle, Rx or Tx? regards, Ricardo ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] RSSI Measurement Information
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, September 27, 2007 11:15 PM To: tinyos-help@Millennium.Berkeley.EDU Subject: [Tinyos-help] RSSI Measurement Information Hi, I need some information about how the RSSI is sampled in the CC2420 radio. In particular, does anyone have a diagram and/or description of the filter used? Thanks, Tal ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] Does LowPowerListening implement McuSleepC?
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 radio low power listening functionality, the microcontroller must wake up and interact with the radio. This wakeup is caused by the periodic timer built into the low power listening functionality, defined by your local sleep interval. If there is nothing interesting on the channel for the radio to stay awake for, the radio goes back to sleep. The microcontroller, with nothing else to do, goes back to sleep on its own until the next interrupt. -David _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gary Pan Sent: Friday, September 28, 2007 11:23 AM To: TinyOS Subject: [Tinyos-help] Does LowPowerListening implement McuSleepC? Hi all, I am trying to test LowPowerListening to test the power consumption in Micaz. As I known, LowPowerListening control the radio on and off periodically. I wonder that if Lpl also controls MCU's sleeping mode as what McuSleepC does. If I want to add McuSleepC module in order to make the processor sleep, does it affect the function of Lpl? If the Rx receive radio pkt, does the Rx trick the processor and wake it up? _ Yahoo! oneSearch: Finally, mobile http://us.rd.yahoo.com/evt=48252/*http:/mobile.yahoo.com/mobileweb/onesearc h?refer=1ONXIC search that gives answers, not web links. ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] low power listening -- anomalous/random 100-200 ms delay/skew?
Ben - You're exactly right. When energy is detected - as long as the radio thinks it's an 802.15.4 carrier signal, the DefaultLplP module gets a signal to wake up and listen for a few moments. I have it set to 100 ms 'listen period' right now just for reliability reasons - i.e. maybe we have lots of transmitters in the area and the message we're hearing right now is to someone else, but there might be another message on the channel destined for the local node in a moment. Because the one shot timer is restarted, the timer fires get shifted. This may not work so well in the future if we want to implement a synchronous layer on top of the asynchronous layer. Instead, we'd want the asynchronous layer to use a periodic timer to keep the synchronous layer above happy. -David -Original Message- From: Murray, Ben [mailto:[EMAIL PROTECTED] Sent: Thursday, September 27, 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 ... when LPL is doing its CCACheck routine and the energyindicator signals its .detected() event an off timer is started as a one shot with a lifetime of 100 ms (set in defaultLPL.h with a definition of DELAY_AFTER_RECEIVE 100. Assuming energy remained present in the Channel during this time the off timer would be restarted. Energy is detected but no packet was received this would simply cause a delay in the LPL routine. Regards Ben -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Murray, Ben Sent: 27 September 2007 11:18 To: 'tinyos-help@Millennium.Berkeley.EDU'; 'David Moss' Subject: [Tinyos-help] low power listening -- anomalous/random 100-200 ms delay/skew? (TinyOS 2.0.2; Micaz; mib510; Cygwin) I have left a number of motes running in low power listening mode and have observed that occasionally one or more of the motes' LPL-receive-check experiences a sudden delay/shift of approximately 100 ms and shortly thereafter a second sudden delay/shift of approximately 100-120 ms. I am not running any transmitters although 2.4 GHz is quite a popular frequency... the first time I observed it two motes experienced the delay at the same time after three minutes of running, the second time I observed it a single Mote experienced the delay after approximately half an hour, and this morning one of the three motes I had left running had experienced this delay at some point overnight. One of the three motes experienced this delay in all three tests, one of the motes did not experience the delay at all, and the third Mote experienced the delay once in the first test but not again. When two motes experienced the delay, they experienced it at what appeared to be the same time and the delay was consistent between them. Is there a built-in function within low power listening that initiates a timeout/delay-of-start with regards to the sleep interval timer that lasts approximately 100 ms, perhaps to cope with noisy channels or received packets/suspected received packets? Signal detection as opposed to a random software/hardware error is because I have observed (using an oscilloscope) two motes undergoing the exact same delay at the exact same time. The receive event is not triggered and therefore I assume that this is some function to deal with a suspected packet when energy is detected. Would it be a trivial matter for me to find this function such that I could add an event trigger so that I know every time that LPL detects Channel energy but subsequently does not receive a packet (assuming this is what is causing the delay). Perhaps something like FalseReceive - this might allow me to correct the timing within my programme whenever this delay occurs. Also, if I could be directed to the exact function that would be very useful would as it might save me a lot of time trawling through code/editing something incorrectly ;-) Many thanks Ben ** * Please consider the environment before printing this email. ** * This email and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and may not be divulged to any third party without the express permission of the originator. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thales Research Technology (UK) Limited
RE: [Tinyos-help] low power listening -- anomalous/random 100-200 ms delay/skew?
Hi Mischa - Theoretically and to a degree, yes. But there could still be some reliability issues that you'll only be able to know about and make adjustments to by actually testing the implementation in your actual network. The best thing to do is to try lowering the value and see what you get - 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-200 ms delay/skew? Hi David, A follow-up question on this. If I assume that there are only broadcasts in my network I could lower this savely to 10ms without interfering with the receive event? cheers, Mischa David Moss wrote: Ben - You're exactly right. When energy is detected - as long as the radio thinks it's an 802.15.4 carrier signal, the DefaultLplP module gets a signal to wake up and listen for a few moments. I have it set to 100 ms 'listen period' right now just for reliability reasons - i.e. maybe we have lots of transmitters in the area and the message we're hearing right now is to someone else, but there might be another message on the channel destined for the local node in a moment. Because the one shot timer is restarted, the timer fires get shifted. This may not work so well in the future if we want to implement a synchronous layer on top of the asynchronous layer. Instead, we'd want the asynchronous layer to use a periodic timer to keep the synchronous layer above happy. -David -Original Message- From: Murray, Ben [mailto:[EMAIL PROTECTED] Sent: Thursday, September 27, 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 ... when LPL is doing its CCACheck routine and the energyindicator signals its .detected() event an off timer is started as a one shot with a lifetime of 100 ms (set in defaultLPL.h with a definition of DELAY_AFTER_RECEIVE 100. Assuming energy remained present in the Channel during this time the off timer would be restarted. Energy is detected but no packet was received this would simply cause a delay in the LPL routine. Regards Ben -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Murray, Ben Sent: 27 September 2007 11:18 To: 'tinyos-help@Millennium.Berkeley.EDU'; 'David Moss' Subject: [Tinyos-help] low power listening -- anomalous/random 100-200 ms delay/skew? (TinyOS 2.0.2; Micaz; mib510; Cygwin) I have left a number of motes running in low power listening mode and have observed that occasionally one or more of the motes' LPL-receive-check experiences a sudden delay/shift of approximately 100 ms and shortly thereafter a second sudden delay/shift of approximately 100-120 ms. I am not running any transmitters although 2.4 GHz is quite a popular frequency... the first time I observed it two motes experienced the delay at the same time after three minutes of running, the second time I observed it a single Mote experienced the delay after approximately half an hour, and this morning one of the three motes I had left running had experienced this delay at some point overnight. One of the three motes experienced this delay in all three tests, one of the motes did not experience the delay at all, and the third Mote experienced the delay once in the first test but not again. When two motes experienced the delay, they experienced it at what appeared to be the same time and the delay was consistent between them. Is there a built-in function within low power listening that initiates a timeout/delay-of-start with regards to the sleep interval timer that lasts approximately 100 ms, perhaps to cope with noisy channels or received packets/suspected received packets? Signal detection as opposed to a random software/hardware error is because I have observed (using an oscilloscope) two motes undergoing the exact same delay at the exact same time. The receive event is not triggered and therefore I assume that this is some function to deal with a suspected packet when energy is detected. Would it be a trivial matter for me to find this function such that I could add an event trigger so that I know every time that LPL detects Channel energy but subsequently does not receive a packet (assuming this is what is causing the delay). Perhaps something like FalseReceive - this might allow me to correct the timing within my programme whenever this delay occurs. Also, if I could be directed to the exact function that would be very useful would as it might save me a lot
RE: [Tinyos-help] low power listening -- anomalous/random 100-200 ms delay/skew?
In order to detect packets, you first have to detect energy. The energy detect only happens once, so even if there is lots of energy to be detected the 100 ms timer will only get triggered one time unless packets are detected afterward. If packets are detected, those packets must be destined for your local node in order to keep the radio turned on. The detection of energy can take between 0.1-10 ms depending on the LPL implementation, while I have the detection of packets set to 100 ms. 100 ms is probably a little overkill for some applications, but works rather reliably. Right now the CC2420 stack is not utilizing the byte detection. The idea there was first you would detect energy by performing the smallest radio on-time check possible (I've gotten the actual check down to 0.9 microseconds using a continuous modulation technique which is not available right now in the baseline). If energy is detected, you could remain on long enough to see if you're receiving bytes (i.e. the SFD line is high). If you're not receiving bytes then you could potentially go back to sleep - but that idea didn't prove to work well in a crowded network with multiple transmitters nearby. Another example there is if you start receiving a packet that is not destined for you, then the CC2420 will stop receiving bytes (the SFD line goes low) and you could shut off the radio. Again, that doesn't take into account the case where there are two transmitters nearby and only one of those transmitters is sending a packet to you while the other is sending packets to someone else. The packets are co-mingled on the channel in such a way that it's best to leave the radio on to receive a few packets to determine if there's something interesting on the channel. The highest level of detection is a packet detection which is what we're using now, where you actually receive a packet destined for your local node. At that point, you could leave the radio on for however long you want to potentially communicate at 100% throughput with whomever you're talking to. Yes, it's possible to set up different on-time delays based on the different types of detection levels, and I have yet to implement anything like that. But there's nothing stopping you from experimenting with it! Let me know if you have more questions, -David -Original Message- From: Murray, Ben [mailto:[EMAIL 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 energy rather than the current setup which signals the same event and incurs the same 100 ms delay. Whether or not this would be a wise idea I don't know though! :-) PowerCycleP uses: interface ReceiveIndicator as EnergyIndicator; interface ReceiveIndicator as ByteIndicator; interface ReceiveIndicator as PacketIndicator; And signals: signal PowerCycle.detected(); If either call EnergyIndicator.isReceiving() or call PacketIndicator.isReceiving() returns TRUE Potentially the two different types of energy detections could signal different length delays? I have had some vague success in signalling the detection event inside my programme but will come back to that later once I am sure what I'm doing is okay :-) -Ben -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Mischa Weise Sent: 27 September 2007 17:49 To: David Moss Cc: tinyos-help@Millennium.Berkeley.EDU Subject: Re: [Tinyos-help] low power listening -- anomalous/random 100-200 ms delay/skew? Hi David, A follow-up question on this. If I assume that there are only broadcasts in my network I could lower this savely to 10ms without interfering with the receive event? cheers, Mischa David Moss wrote: Ben - You're exactly right. When energy is detected - as long as the radio thinks it's an 802.15.4 carrier signal, the DefaultLplP module gets a signal to wake up and listen for a few moments. I have it set to 100 ms 'listen period' right now just for reliability reasons - i.e. maybe we have lots of transmitters in the area and the message we're hearing right now is to someone else, but there might be another message on the channel destined for the local node in a moment. Because the one shot timer is restarted, the timer fires get shifted. This may not work so well in the future if we want to implement a synchronous layer on top of the asynchronous layer. Instead, we'd want the asynchronous layer to use a periodic timer to keep the synchronous layer above happy. -David -Original Message- From: Murray, Ben [mailto:[EMAIL PROTECTED] Sent: Thursday, September 27, 2007 7:05 AM To: Murray, Ben; 'tinyos
RE: [Tinyos-help] CC2420 packet delivery
Since the RX FIFO queue is something like 128 bytes, it would take a few packets to make it overflow. Page 33 of the CC2420 datasheet explains: The RXFIFO can only contain a maximum of 128 bytes at a given time. This may be divided between multiple frames, as long as the total number of bytes is 128 or less. If an overflow occurs in the RXFIFO, this is signalled to the microcontroller by setting the FIFO pin low while the FIFOP pin is high. Data already in the RXFIFO will not be affected by the overflow, i.e. frames already received may be read out. A SFLUSHRX command strobe is required after a RXFIFO overflow to enable reception of new data. Note that the SFLUSHRX command strobe should be issued twice to ensure that the SFD pin goes back to its idle state. And that's what the driver does. -David _ From: roberto pagliari [mailto:[EMAIL 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 stay into the RXFIFO queue (is it true?) and sometime later the radio receives another packet, that would overflow, since the expected number of bytes was the previous one. What happens in that case? Does the radio flushes the RXFIFO queue? thanks On 9/18/07, David Moss [EMAIL PROTECTED] wrote: 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 transmitters next to each other without using clear channel assessments leaves them both transmitting and rarely receiving clean packets. If the length byte is within bounds, then the radio stack can safely download the packet and check the CRC byte regardless of what happened. If the length byte in the RX FIFO is not within bounds (smaller than expected, or larger than the RX FIFO size) then the RX FIFO certainly needs to be flushed. -David _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of roberto pagliari Sent: Tuesday, September 18, 2007 4:43 PM To: tinyos-help@Millennium.Berkeley.EDU Subject: [Tinyos-help] CC2420 packet delivery Hi All, does anyone know what happen if, during the receiption of a packet, a STXON (not STXONCCA) strobe command from the microcontroller is issued? Does the radiochip turn the circuit to the transmitter? If so, should I flush the RXFIFO queue? many thanks, Roberto ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-devel] Re: [Tinyos-help] Question about printf
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 mysterious infinite loop (try to debug older version of the CC2420
stack for example). I don't think it's a matter of using printf
incorrectly, it's a matter of having an incompatible printf/serial stack
implementation underneath for what you're trying to do.
For some types of single-phase debugging that would support Phil's for()
loop, I've experimented with a basic single-phase serial stack located at
tinyos-2.x-contrib/rincon/tos/lib/directserial. Unfortunately, if it's
compiled in alongside the baseline serial stack, they conflict and cause
some problems, but it would be nice to get them to coexist. With a
single-phase serial stack, Printf could then support nearly all of its use
cases (except for timing critical issues I suppose) and possibly require
less memory since its buffer is flushed out completely by the time the call
to printf() returns.
-David
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Philip
Levis
Sent: Saturday, September 22, 2007 1:02 PM
To: Kevin Klues
Cc: [EMAIL PROTECTED]; TinyOS-Devel list; tos
Subject: [Tinyos-devel] Re: [Tinyos-help] Question about printf
On Sep 21, 2007, at 8:25 PM, Kevin Klues wrote:
I don't seen anything in 'man 3 printf' that implies that it has to be
a blocking operation. In fact the manual shouldn't imply this.
printf is part of the standard C library, not affiliated with any
particular operating system.
Right -- the printf semantics have more to do with the associated
file stream (printf is really just a call to fprintf) than with
printf itself. In the case of printf, the file stream is stdout.
To implement printf() functionality for any mcu that has a libc (such
as msp430-libc or avr-libc) you just have to fill in the body of the
'putchar' function declared in stdio.h. This is exactly what the
PrintfP component in tos/lib/printf does. No magic. it just
collects the bytes coming in via calls to putchar, packs them into
TInyOS serial messages, and sends them out over the USART.
Right -- so look at how putchar is typically implemented. The example
from avr-gcc's stdio.h goes like this:
static int
uart_putchar(char c, FILE *stream)
{
if (c == '\n')
uart_putchar('\r', stream);
loop_until_bit_is_set(UCSRA, UDRE);
UDR = c;
return 0;
}
int
main(void)
{
init_uart();
stdout = mystdout;
printf(Hello, world!\n);
return 0;
}
It should be left up to whatever operating system that implements it
to define the semantics.
Great: I'd like to define a printf semantics that crashes the computer.
Look -- to reiterate my last mail, I agree that this function is
useful, and it should be available. I'm just saying that, because it
does differ significantly from what one might expect from printf,
maybe it should be named differently. E.g.:
void test() {
uint16_t i;
for (i = 0; i 20480; i++) {
printf(\n);
}
}
If you can find a reasonable implementation of printf besides yours
that does not print out 20480 newlines, then my concern is totally
unfounded and wrong.
Phil
___
Tinyos-devel mailing list
[EMAIL PROTECTED]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-devel] Re: [Tinyos-help] Question about printf
CVS copy/pasting problems in my local drive. I've committed it now, but it
may take awhile for sourceforge to post it.
In the meantime, there should be another copy of it inside of
tinyos-2.x-contrib/tunit/tos/lib/directserial
-David
-Original Message-
From: Kevin Klues [mailto:[EMAIL 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 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 mysterious infinite loop (try to debug older version of the CC2420
stack for example). I don't think it's a matter of using printf
incorrectly, it's a matter of having an incompatible printf/serial stack
implementation underneath for what you're trying to do.
For some types of single-phase debugging that would support Phil's for()
loop, I've experimented with a basic single-phase serial stack located at
tinyos-2.x-contrib/rincon/tos/lib/directserial. Unfortunately, if it's
compiled in alongside the baseline serial stack, they conflict and cause
some problems, but it would be nice to get them to coexist. With a
single-phase serial stack, Printf could then support nearly all of its use
cases (except for timing critical issues I suppose) and possibly require
less memory since its buffer is flushed out completely by the time the
call
to printf() returns.
-David
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Philip
Levis
Sent: Saturday, September 22, 2007 1:02 PM
To: Kevin Klues
Cc: [EMAIL PROTECTED]; TinyOS-Devel list; tos
Subject: [Tinyos-devel] Re: [Tinyos-help] Question about printf
On Sep 21, 2007, at 8:25 PM, Kevin Klues wrote:
I don't seen anything in 'man 3 printf' that implies that it has to be
a blocking operation. In fact the manual shouldn't imply this.
printf is part of the standard C library, not affiliated with any
particular operating system.
Right -- the printf semantics have more to do with the associated
file stream (printf is really just a call to fprintf) than with
printf itself. In the case of printf, the file stream is stdout.
To implement printf() functionality for any mcu that has a libc (such
as msp430-libc or avr-libc) you just have to fill in the body of the
'putchar' function declared in stdio.h. This is exactly what the
PrintfP component in tos/lib/printf does. No magic. it just
collects the bytes coming in via calls to putchar, packs them into
TInyOS serial messages, and sends them out over the USART.
Right -- so look at how putchar is typically implemented. The example
from avr-gcc's stdio.h goes like this:
static int
uart_putchar(char c, FILE *stream)
{
if (c == '\n')
uart_putchar('\r', stream);
loop_until_bit_is_set(UCSRA, UDRE);
UDR = c;
return 0;
}
int
main(void)
{
init_uart();
stdout = mystdout;
printf(Hello, world!\n);
return 0;
}
It should be left up to whatever operating system that implements it
to define the semantics.
Great: I'd like to define a printf semantics that crashes the computer.
Look -- to reiterate my last mail, I agree that this function is
useful, and it should be available. I'm just saying that, because it
does differ significantly from what one might expect from printf,
maybe it should be named differently. E.g.:
void test() {
uint16_t i;
for (i = 0; i 20480; i++) {
printf(\n);
}
}
If you can find a reasonable implementation of printf besides yours
that does not print out 20480 newlines, then my concern is totally
unfounded and wrong.
Phil
___
Tinyos-devel mailing list
[EMAIL PROTECTED]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
--
~Kevin
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] Question MSP430x1xx and MSP430x2xx
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 your compiled application tells you it uses. Although there are stack space profilers out there that can help in this area, I generally leave at least 1kB RAM available above what the compile time RAM size says, just to be safe. -David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Griessen Sent: Wednesday, September 19, 2007 12:32 PM To: tinyos-help Subject: Re: [Tinyos-help] Question MSP430x1xx and MSP430x2xx Sivan Toledo wrote: TI just announced $50 boards that have an MSP430F2274 and a 2.4GHztransceiver. The MSP430F2274 has 32K flash where the MSP430F1611 of Tmote Sky has 48K. How will 32K flash affect the ability to port tinyOS to the MSP430F2274? How about the CC2510 and CC2511 with a radio and 8051 micro with 32K flash? Is there any tinyos porting effort going for that recently? How much extra flash is needed beyond the reported compiled size of a tinyOS program? As in: compiled ReadMoistureSensorsC to build/ecosens1/main.exe 14150 bytes in ROM 360 bytes in RAM John Griessen -- Ecosensory tinyOS devel on: ubuntu Linux; tinyOS v2.0.2; telosb ecosens1 ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] CC2420 packet delivery
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 transmitters next to each other without using clear channel assessments leaves them both transmitting and rarely receiving clean packets. If the length byte is within bounds, then the radio stack can safely download the packet and check the CRC byte regardless of what happened. If the length byte in the RX FIFO is not within bounds (smaller than expected, or larger than the RX FIFO size) then the RX FIFO certainly needs to be flushed. -David _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of roberto pagliari Sent: Tuesday, September 18, 2007 4:43 PM To: tinyos-help@Millennium.Berkeley.EDU Subject: [Tinyos-help] CC2420 packet delivery Hi All, does anyone know what happen if, during the receiption of a packet, a STXON (not STXONCCA) strobe command from the microcontroller is issued? Does the radiochip turn the circuit to the transmitter? If so, should I flush the RXFIFO queue? many thanks, Roberto ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] external antenna
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: tinyos-help@Millennium.Berkeley.EDU Subject: Re: [Tinyos-help] external antenna Are we sure that the antennas are for the right wavelength? By linksys I guess you mean a dongle from an 802.11b,g router? Do they have the same connector as your Tmote? And are the connectors seated well? Also, you're sure you disabled the internal antenna? I think there's a capacitor that needs to be removed on the standard Tmotes. ...I guess I should try this sometime... MS André Miguel de Almeida Marrão Rodrigues wrote: Hello I have tried these kind of antennas and it also did not work in an indoor scenario with 2 walls. For 200mts in your scenario perhaps you should use TMoteMiniPro or other nodes with a power amplifier. André - Original Message - From: subhash nemani [EMAIL PROTECTED] To: tinyos-help@Millennium.Berkeley.EDU Sent: Thursday, September 13, 2007 11:41 AM Subject: [Tinyos-help] external antenna we have tmotes without internal antenna and provision for external i.e SMA connector .i have connected linksys 7dBi antennas but it is not covering even a distance of 20 mts what might be the problem??? please help me in this regard i have tired the power settings using commands at the cygwin prompt also but no result atleast i need to transmit the signal for 200mts plzzz help me thank u in advance ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- Platform: WinXP/Cygwin TinyOS version: 1.x, Boomerang Programmer: MIB510 Device(s): Mica2, MicaZ, Tmote Sensor board: homebrew ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] forcing a node in LPL mode to stop listening if a transmission is continuous
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 LPL layer. There are two cases (that I can think of) where a transmitter will keep transmitting a message to a low power listener after the receiver already got the message: 1) the message is sent to the broadcast address, or 2) the Rx mote didn't properly send back an acknowledgement for a unicast message. If the transmitter is sending unique messages over and over again (unique meaning each message has the same source and DSN byte), then the receiver will definitely stay awake to receive all of them. If you have a transmitter that is calling AMSend.send() in a loop, then each of those messages is not unique. The receiver, upon detecting one of the transmissions, will stay awake to receive all further messages at a high rate of throughput. -David _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Murray, Ben Sent: Thursday, September 06, 2007 7:04 AM To: tinyos-help@Millennium.Berkeley.EDU Subject: [Tinyos-help] forcing a node in LPL mode to stop listening if a transmission is continuous Again, perhaps a slightly strange scenario, but I was wondering if there was a standard way to stop a node using the low power listening technique from receiving successive messages in the presence of a continuous transmitter? If, for example, a transmitter is set up to continuously transmit message after message the Mote using low power listening reception appears to remain on once it has detected the presence of a transmission the first time it performs an LPL receive? Is there any way to make it go back to sleep after the first (or nth) message received such that it is not trapped into remaining on and limits itself to receiving only one (or possibly only n) message(s) per LPL wake period? Is this sort of functionality existent in tinyOS at all? Many thanks Ben *** Please consider the environment before printing this email. *** This email and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and may not be divulged to any third party without the express permission of the originator. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thales Research Technology (UK) Limited. *** ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] low power listening -- controlling when it wakes and confirming s leep period?
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 listening implementation on top of an asynchronous implementation. And, rather than adjust when the receiver wakes up to expect a transmission, a possibly better method is to adjust when the transmitter begins transmitting its message to align with a specific receiver. By keeping the receive checks asynchronous, receivers will wake up at different times within the local geographical network and will be able to receive messages from transmitters targeting those individual receivers. This effectively shares the channel through more of a time division (TDMA). Your transmitters can also form a table of when its neighbors are awake based on when they receive acknowledgements from those receivers. Although a layer like this is not built into the radio stack now, it's just waiting for an implementation. Look up WiseMAC. -David _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Murray, Ben Sent: Thursday, September 06, 2007 3:43 AM To: tinyos-help@Millennium.Berkeley.EDU Subject: [Tinyos-help] low power listening -- controlling when it wakes and confirming s leep period? I am using LowPowerListening with a MicaZ mote and am curious about a few more specifics. I am using the setLocalSleepInterval(X ms) command. My first question concerns the actual sleep period. Given the above command, will the mote: a) perform its low power listening period (taking approximately 5 ms) and having completed that go to sleep for X ms, for a total period of (X + 5) ms? /or/ b) would it wakeup every X ms, with the low power listening period basically taking up the first 5 ms of each X ms period? My second question concerns the timing of the wake period, and whether when this occurs is adjustable/controllable? For instance, if I have set my sleep interval to 5000 ms is there a way I can control when the wake period will occur. For the purpose of this example let us assume that my mote knows that a signal will be transmitted once every 5000 ms, and that it knows (magically) how many milliseconds its current waketime is shifted by with respect to this transmitted signal. E.g. (view with a mono-spaced font!) Tx:__|_|_|_|... Rx:__|___N_X___A_|_|... ... where N is the point where the receiver magically knows that it has missed the transmission and by how many milliseconds, so instead of activating its lpl receive period at X, it adjusts the low power listening period such that the new space lpl receive period is at A and subsequent receive period are now synchronised with the transmitter. Ignoring whether or not this is a good idea, is it possible to do something like this? Perhaps by altering the localsleepinterval value -- would this initiate a new listening period from the point at which it was called in the code? The other rough way to force this to happen I suppose might be to stop the radio altogether, and start it again with low power listening enabled -- is the wake period of low power listening active at the start immediately when setlocalsleepinterval is called / startDone is completed, or at the end, or somewhere in the middle? Apologies if this has been asked before! Thanks in advance Ben *** Please consider the environment before printing this email. *** This email and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and may not be divulged to any third party without the express permission of the originator. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thales Research Technology (UK) Limited. *** ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] forcing a node in LPL mode to stop listening if a transmission is continuous
If you're sending message after message at the application layer, then you receiver mote always has a job to do: get the latest message. As you've pointed out, it will remain on for a short period of time to see if there are more messages to receive. Low power listening normally implies low throughput, because your receiver is spending most of its time sleeping. To get the receiver to go to sleep automatically, you'll need to first setup the transmitter to transmit its message using low power listening through call LowPowerListening.setRxSleepInterval(myMsg, interval_in_ms); Then, when you get a sendDone, wait for awhile before sending the next message. If you try to send another message immediately, the receiver will indefinitely stay on. You could just tell the receiver to shut off manually if you want, that will turn it off but you won't be enjoying any benefits 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 if a transmission is continuous It should be TinyOS 2.0.2 assuming I did the upgrade from 2.0.1 correctly make command structure env CFLAGS=-DLOW_POWER_LISTENING make micaz install mib510,/dev/ttyS0 In the header file: #define NOACK_LOW_POWER_LISTENING The transmitter was set up so as to increment a counter and send that to counter value in successive messages (I am basically using a modified version of BlinkToRadio). I am partly through reading a paper linked to from tutorial number 16 which infers that in LPL mode if the receiver detect a packet it will receive at packet and then remain listening for long enough to catch another packet which I guess is what is happening here? I guess what I wanted to know was if I had a similar situation with a transmitter continuously sending message after message (even if this was only for a limited time) whether there was some way that I could tell my LPL receiver to go back to sleep rather than to continue listening to further successive packets. Would it be feasible perhaps to actually shut the radio off (AMControl.stop) or would that interfere with the LPL? Or perhaps there is a way to send a call directly into the LPL component to stop it attempting to receive a further following packet? Or would I need to customise the LPL component to do this? What I was trying to do was to have one Mote continuously transmitting, and a second Mote turning on occasionally in order to listen to the message the first Mote was transmitting at that point in time, but then to stop listening again. Cheers Ben -Original Message- From: David Moss [mailto:[EMAIL PROTECTED] Sent: 06 September 2007 17:55 To: 'Murray, Ben'; tinyos-help@Millennium.Berkeley.EDU Subject: RE: [Tinyos-help] forcing a node in LPL mode to stop listening if a transmission is continuous 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 LPL layer. There are two cases (that I can think of) where a transmitter will keep transmitting a message to a low power listener after the receiver already got the message: 1) the message is sent to the broadcast address, or 2) the Rx mote didn't properly send back an acknowledgement for a unicast message. If the transmitter is sending unique messages over and over again (unique meaning each message has the same source and DSN byte), then the receiver will definitely stay awake to receive all of them. If you have a transmitter that is calling AMSend.send() in a loop, then each of those messages is not unique. The receiver, upon detecting one of the transmissions, will stay awake to receive all further messages at a high rate of throughput. -David _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Murray, Ben Sent: Thursday, September 06, 2007 7:04 AM To: tinyos-help@Millennium.Berkeley.EDU Subject: [Tinyos-help] forcing a node in LPL mode to stop listening if a transmission is continuous Again, perhaps a slightly strange scenario, but I was wondering if there was a standard way to stop a node using the low power listening technique from receiving successive messages in the presence of a continuous transmitter? If, for example, a transmitter is set up to continuously transmit message after message the Mote using low power listening reception appears to remain on once it has detected the presence of a transmission the first time it performs an LPL receive? Is there any way to make it go back to sleep after the first (or nth) message received such that it is not trapped
[Tinyos-help] RE: regarding TestNetwork application
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: Tuesday, September 04, 2007 8:42 PM To: [EMAIL PROTECTED] Subject: regarding TestNetwork application Respected Sir, I have loaded mica2 motes with test network application. I am using listen tool to listen to serial port. I should be receving 32 bytes on the pc using the Listen tool. But i recieve only 23 bytes or 17 bytes at show below. (23 bytes) 00 FF FF 00 02 0F 22 EE 00 01 00 00 00 02 06 EE 00 02 00 21 00 37 00 (17 bytes) 00 FF FF 00 00 09 00 16 21 00 06 00 02 00 00 00 37 What is the problem, why am i not receiving 32 bytes on pc. I am testing this application with 1 basestation and 3 mica2 motes. I have not modified TestNetwork application at all. So i need your help regarding this. Why am i not receving 32 bytes on the pc Listen tool. Regards, Arpan. Solanki Graduate Student. Lamar University, Beaumont, Texas. ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] RE: CC2420 lpl
Hi Tony, There is a reason behind this, but you can adjust it to meet your application's needs. The radio shares the SPI bus with the flash, so applications that access flash alongside radio will contend for the SPI bus. In earlier versions, the Tx node would release the SPI bus between the transmission and listening for an ack, which would allow the flash to acquire the SPI bus in between. This meant the Tx node wouldn't have access to the SPI bus to hear the ack. Because either the transmitter *or* the receiver could have flash accessing the SPI bus causing the acknowledgement to be delayed, the solution came in two parts: 1) don't let the transmitter release the SPI bus when it's waiting for an acknowledgement, and 2) extend the ack wait period to handle the case where the receiver can't acquire the SPI bus in time. If your application does not use the SPI bus (or any other 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: CC2420 lpl Hi David, Sorry for annoying you with more questions. In the tinyos 2.02 version of the cc2420 libs you've changed CC2420_ACK_WAIT_DELAY from 128 jiffies to 256 jiffies, nearly halving the possible send rate when using acks. I was wondering what the reason behind this is. Thanks Tony ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] acknowledgements in Tinyos2.0.2 usingBaseStationCC2420, not supported?
Tiago - This flag shouldn't be application dependent. When you set the flag at compile time, or adjust the interface and call CC2420Config.sync() at runtime, the address recognition settings should change. With address recognition off, your mote should be receiving packets that are destined 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] acknowledgements in Tinyos2.0.2 usingBaseStationCC2420, not supported? David, Thanks for your time!! You were right I was using an old version of CC2420ControlP, since I was compiling using the BaseStationCC2420 that incorporates the CC2420ControlP old version. I just simply used the new BaseStation and the ack started to appear... so once again thanks! I notest the flag -DCC2420_NO_ADDRESS_RECOGNITION, on the BaseStation Makefile, does this flag only work on the BaseStation code or can I use on different application using the CC2420ActiveMessageC component? Because I tried with no success. I also tried using the CC2420Config.setAddressRecognition(bool on) through CC2420ControlC, as u suggested in a previous mail. Thanks in advance, Tiago David Moss wrote: 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, BaseStationCC2420 is deprecated. It looks to me like some files in your CC2420 stack are not up to date with version 2.0.2. Specifically, the CC2420ControlP you're using is old enough not to incorporate the newest interfaces defined by CC2420Config - that's where the errors are coming from. If you're 100% sure that your tos/chips/cc2420 stack is up to date, can you be sure that CC2420ControlP is not being pulled from some other location? First verify your tos/chips/cc2420/control/CC2420ControlP provides the interfaces that CC2420Config is complaining about, and if it does then try adding the following line to your tos/chips/cc2420/control/CC2420ControlP module: #warning Using the newest CC2420ControlP When you compile, if you see that line printed to the command line at compile time, you can be sure of which CC2420ControlP file nesC is trying to use. Attached is the CC2420ControlP you should be using. You can even try putting that directly in your apps/BaseStation directory to force nesC to use it instead of some other, older CC2420ControlP. -David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tiago Camilo Sent: Wednesday, August 22, 2007 7:55 AM To: tinyos-help@Millennium.Berkeley.EDU Cc: Philip Levis Subject: [Tinyos-help] acknowledgements in Tinyos2.0.2 usingBaseStationCC2420, not supported? Hi all, I am trying to implement acknowledgementsin my telosb motes, using the tinyos2.0.2. I am using the component CC2420ActiveMessageC with the interface PacketAcknowledgements as suggested in the TestAcks application of folder cc2420. However i can make this work using the BaseStationCC2420 application ( tinyos2.0.1). The source does not receive any acknowledgments from the BaseStation. I found out that in the makefile there is the declaration: CFLAGS += -DCC2420_NO_ACKNOWLEDGEMENTS, which explains the lack of ack. However when i try to compile BaseStationCC2420 without this option i have this error: compiling BaseStationC to a telosb binary ncc -o build/telosb/main.exe -Os -O -mdisable-hwmul -Wall -Wshadow -DDEF_TOS_AM_GROUP=0x7d -Wnesc-all -target=telosb -fnesc-cfile=build/telosb/app.c -board= -D'TOSH_DATA_LENGTH=102' -DIDENT_PROGRAM_NAME=\BaseStationC\ -DIDENT_USER_ID=\tandre\ -DIDENT_HOSTNAME=\homenux\ -DIDENT_USER_HASH=0xb4d39b1cL -DIDENT_UNIX_TIME=0x46cc4aafL -DIDENT_UID_HASH=0xeb773d58L BaseStationC.nc -lm In file included from /opt/tinyos-2.x/tos/chips/cc2420/control/CC2420ControlC.nc:53, from /opt/tinyos-2.x/tos/chips/cc2420/csma/CC2420CsmaC.nc:61, from /opt/tinyos- 2.x/tos/chips/cc2420/CC2420ActiveMessageC.nc:58, from /opt/tinyos-2.x/tos/platforms/telosa/ActiveMessageC.nc:61, from BaseStationC.nc:71: In component `CC2420ControlP': CC2420ControlP.nc :236: `CC2420Config.getShortAddr': async mismatch with declaration /opt/tinyos-2.x/tos/chips/cc2420/interfaces/CC2420Config.nc:64: previous declaration of `CC2420Config.getShortAddr' CC2420ControlP.nc:244: `CC2420Config.getPanAddr': async mismatch with declaration /opt/tinyos-2.x/tos/chips/cc2420/interfaces/CC2420Config.nc:70: previous declaration of `CC2420Config.getPanAddr' CC2420ControlP.nc:76
RE: [Tinyos-help] acknowledgements in Tinyos2.0.2 usingBaseStationCC2420, not supported?
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, BaseStationCC2420 is deprecated. It looks to me like some files in your CC2420 stack are not up to date with version 2.0.2. Specifically, the CC2420ControlP you're using is old enough not to incorporate the newest interfaces defined by CC2420Config - that's where the errors are coming from. If you're 100% sure that your tos/chips/cc2420 stack is up to date, can you be sure that CC2420ControlP is not being pulled from some other location? First verify your tos/chips/cc2420/control/CC2420ControlP provides the interfaces that CC2420Config is complaining about, and if it does then try adding the following line to your tos/chips/cc2420/control/CC2420ControlP module: #warning Using the newest CC2420ControlP When you compile, if you see that line printed to the command line at compile time, you can be sure of which CC2420ControlP file nesC is trying to use. Attached is the CC2420ControlP you should be using. You can even try putting that directly in your apps/BaseStation directory to force nesC to use it instead of some other, older CC2420ControlP. -David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tiago Camilo Sent: Wednesday, August 22, 2007 7:55 AM To: tinyos-help@Millennium.Berkeley.EDU Cc: Philip Levis Subject: [Tinyos-help] acknowledgements in Tinyos2.0.2 usingBaseStationCC2420, not supported? Hi all, I am trying to implement acknowledgementsin my telosb motes, using the tinyos2.0.2. I am using the component CC2420ActiveMessageC with the interface PacketAcknowledgements as suggested in the TestAcks application of folder cc2420. However i can make this work using the BaseStationCC2420 application ( tinyos2.0.1). The source does not receive any acknowledgments from the BaseStation. I found out that in the makefile there is the declaration: CFLAGS += -DCC2420_NO_ACKNOWLEDGEMENTS, which explains the lack of ack. However when i try to compile BaseStationCC2420 without this option i have this error: compiling BaseStationC to a telosb binary ncc -o build/telosb/main.exe -Os -O -mdisable-hwmul -Wall -Wshadow -DDEF_TOS_AM_GROUP=0x7d -Wnesc-all -target=telosb -fnesc-cfile=build/telosb/app.c -board= -D'TOSH_DATA_LENGTH=102' -DIDENT_PROGRAM_NAME=\BaseStationC\ -DIDENT_USER_ID=\tandre\ -DIDENT_HOSTNAME=\homenux\ -DIDENT_USER_HASH=0xb4d39b1cL -DIDENT_UNIX_TIME=0x46cc4aafL -DIDENT_UID_HASH=0xeb773d58L BaseStationC.nc -lm In file included from /opt/tinyos-2.x/tos/chips/cc2420/control/CC2420ControlC.nc:53, from /opt/tinyos-2.x/tos/chips/cc2420/csma/CC2420CsmaC.nc:61, from /opt/tinyos- 2.x/tos/chips/cc2420/CC2420ActiveMessageC.nc:58, from /opt/tinyos-2.x/tos/platforms/telosa/ActiveMessageC.nc:61, from BaseStationC.nc:71: In component `CC2420ControlP': CC2420ControlP.nc :236: `CC2420Config.getShortAddr': async mismatch with declaration /opt/tinyos-2.x/tos/chips/cc2420/interfaces/CC2420Config.nc:64: previous declaration of `CC2420Config.getShortAddr' CC2420ControlP.nc:244: `CC2420Config.getPanAddr': async mismatch with declaration /opt/tinyos-2.x/tos/chips/cc2420/interfaces/CC2420Config.nc:70: previous declaration of `CC2420Config.getPanAddr' CC2420ControlP.nc:76: `CC2420Config.setAutoAck' not implemented CC2420ControlP.nc:76: `CC2420Config.isAddressRecognitionEnabled' not implemented CC2420ControlP.nc:76: `CC2420Config.setAddressRecognition' not implemented CC2420ControlP.nc:76: `CC2420Config.isAutoAckEnabled' not implemented CC2420ControlP.nc:76: `CC2420Config.isHwAutoAckDefault' not implemented In component `CC2420ControlC': /opt/tinyos-2.x/tos/chips/cc2420/control/CC2420ControlC.nc:98: cannot find `ActiveMessageAddress' make: *** [exe0] Error 1 I know that the CC2420 stack was changed in this last version. Are we still waiting for a updated BaseStationCC2420 (since in 2.0.2 cvs it seems to be deleted), or am I missing something? Thanks in advance, Tiago Camilo ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help CC2420ControlP.nc Description: Binary data ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] Low Power Listening not working with Dissemination???
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 message to successfully traverse an entire network using dissemination. A collection network sends out beacons periodically that wake up other nodes. Those nodes' radios may already be awake when your own message is transmitted next. This could explain a decrease in latency for a collection network vs. dissemination. Formally combining LPL + Collection / Dissemination is one of the next phases currently being researched and developed for TinyOS. If you make any headway, I think the majority of the community would be interested in hearing about your experiences. -David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christian Hermann Sent: Thursday, August 23, 2007 10:47 AM Cc: TinyOS Subject: [Tinyos-help] Low Power Listening not working with Dissemination??? Hallo, I'm using dissemination to send commands to the nodes and LQI collection to collect the data. All works fine without LPL (beside the fact that dissemination is a lot slower than collection with increasing node depth). But if I set LPL duty cycle to 1000 for example, commands need very long (several seconds) to reach its destination or even get lost completely quite often. Collection becomes a little slower, but still delivers data reliably with around 100ms total delivery time at node depth 2 or 3. (PS: I also activated PACKET_LINK layer) Does anyone know about issues with dissemination vs. LPL? Thanks Christian Gary Pan schrieb: Hi all, Does anyone successfully use TinyOS plugin for Eclipse under linux machine? Every time I try to create an application, it could not get through. Is TinyOS plugin for Eclipse supported on Linux system? - Gary - Shape Yahoo! in your own image. Join our Network Research Panel today! ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- Christian Hermann Am Weinberg 9 08529 Plauen Fax +49 3741 470159 Tel +49 173 4020035 [EMAIL PROTECTED] http://www.christian-hermann.de ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] low power listening - actual listening time?
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 actually kicks on for a little longer than that because the crystal oscillator powers up - this is not included in the 5 ms measurement. 5 ms is much less than the amount of time it takes to receive a packet (especially with CSMA) because it's only detecting channel energy. Once it sees energy on the channel, it stays awake longer to receive the packet. The CC1000 radio (mica2) previously did a preamble byte check, which is much more complex than the newer implementations (BMAC) that sense channel energy. In the case of the CC1000 radio, the receive check is much less than 5 ms. -David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Murray, Ben Sent: Wednesday, August 22, 2007 2:28 AM To: tinyos-help@Millennium.Berkeley.EDU Subject: [Tinyos-help] low power listening - actual listening time? When using low power listening, as discussed in the duty cycle help thread, I understand that the ON time is approx 5 ms. does anyone know approximately how long the radio is actually receiving during this period? I assume that some of it is due to start up time and that the receiver must be enabled for a certain length of time in order to detect a signal. The main reason I ask is because I am trying to work out just how much of a problem clock drift might be. I have read in a paper that the clock drift of a mica2 is approx 40 µs per second which amounts to 2.4 ms per minute. Is there a commonly used rule of thumb perhaps for estimating what the extra amount of time a transmitter might have to be active prior to another Motes estimated low power listening wakeup time. For example, if receive Mote is known to be on a one minute sleep period and the transmit node knows when this receive Mote was last awake, is it normal to begin transmission about 2.4 ms before you think receive Mote might wake up? *** Please consider the environment before printing this email. *** This email and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and may not be divulged to any third party without the express permission of the originator. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thales Research Technology (UK) Limited. *** ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] acknowledgements in Tinyos2.0.2 usingBaseStationCC2420, not supported?
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, August 22, 2007 7:55 AM To: tinyos-help@Millennium.Berkeley.EDU Cc: Philip Levis Subject: [Tinyos-help] acknowledgements in Tinyos2.0.2 usingBaseStationCC2420, not supported? Hi all, I am trying to implement acknowledgementsin my telosb motes, using the tinyos2.0.2. I am using the component CC2420ActiveMessageC with the interface PacketAcknowledgements as suggested in the TestAcks application of folder cc2420. However i can make this work using the BaseStationCC2420 application ( tinyos2.0.1). The source does not receive any acknowledgments from the BaseStation. I found out that in the makefile there is the declaration: CFLAGS += -DCC2420_NO_ACKNOWLEDGEMENTS, which explains the lack of ack. However when i try to compile BaseStationCC2420 without this option i have this error: compiling BaseStationC to a telosb binary ncc -o build/telosb/main.exe -Os -O -mdisable-hwmul -Wall -Wshadow -DDEF_TOS_AM_GROUP=0x7d -Wnesc-all -target=telosb -fnesc-cfile=build/telosb/app.c -board= -D'TOSH_DATA_LENGTH=102' -DIDENT_PROGRAM_NAME=\BaseStationC\ -DIDENT_USER_ID=\tandre\ -DIDENT_HOSTNAME=\homenux\ -DIDENT_USER_HASH=0xb4d39b1cL -DIDENT_UNIX_TIME=0x46cc4aafL -DIDENT_UID_HASH=0xeb773d58L BaseStationC.nc -lm In file included from /opt/tinyos-2.x/tos/chips/cc2420/control/CC2420ControlC.nc:53, from /opt/tinyos-2.x/tos/chips/cc2420/csma/CC2420CsmaC.nc:61, from /opt/tinyos- 2.x/tos/chips/cc2420/CC2420ActiveMessageC.nc:58, from /opt/tinyos-2.x/tos/platforms/telosa/ActiveMessageC.nc:61, from BaseStationC.nc:71: In component `CC2420ControlP': CC2420ControlP.nc :236: `CC2420Config.getShortAddr': async mismatch with declaration /opt/tinyos-2.x/tos/chips/cc2420/interfaces/CC2420Config.nc:64: previous declaration of `CC2420Config.getShortAddr' CC2420ControlP.nc:244: `CC2420Config.getPanAddr': async mismatch with declaration /opt/tinyos-2.x/tos/chips/cc2420/interfaces/CC2420Config.nc:70: previous declaration of `CC2420Config.getPanAddr' CC2420ControlP.nc:76: `CC2420Config.setAutoAck' not implemented CC2420ControlP.nc:76: `CC2420Config.isAddressRecognitionEnabled' not implemented CC2420ControlP.nc:76: `CC2420Config.setAddressRecognition' not implemented CC2420ControlP.nc:76: `CC2420Config.isAutoAckEnabled' not implemented CC2420ControlP.nc:76: `CC2420Config.isHwAutoAckDefault' not implemented In component `CC2420ControlC': /opt/tinyos-2.x/tos/chips/cc2420/control/CC2420ControlC.nc:98: cannot find `ActiveMessageAddress' make: *** [exe0] Error 1 I know that the CC2420 stack was changed in this last version. Are we still waiting for a updated BaseStationCC2420 (since in 2.0.2 cvs it seems to be deleted), or am I missing something? Thanks in advance, Tiago Camilo ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
