You're right, it's very concerning that TinyOS 1.x is as unstable as it is on mica- hardware. Your battery observation is exactly what is reflected on the datasheet though - 1.3V batteries in series = 2.6V, which is less than the 2.7V required to use the at45db flash.
Deluge samples the battery voltage to determine if it's safe to attempt use the flash for OTAP. If you want these things deployable, you might want to check that out. -David -----Original Message----- From: Munaretto, Daniel [mailto:[EMAIL PROTECTED] Sent: Friday, September 22, 2006 1:54 AM To: David Moss Cc: [email protected] Subject: RE: [Tinyos-help] conflict flash-radio,micaz Thanks very much for your explanation. So you confirm the version of Xbow, that CSMA-CA is in micaz by default. BTW, during my tests, it seems true that there is a conflict between flash and radio on micaz. In fact now they "survive" after the reading-from-flash phase and they last for several consecutive tests, until the batteries of one of them fall down at 1.3 V. But the number of received and decoded packets, when i use the readings from flash, is less than the one when i don't use readings. So really it seems that in some cases, while you're using the flash, you cannot use the radio properly... quite unpredictable.. cheers Daniele -----Original Message----- From: David Moss [mailto:[EMAIL PROTECTED] Sent: Thu 9/21/2006 6:03 PM To: 'Tie Luo'; [EMAIL PROTECTED]; Munaretto, Daniel Cc: [email protected] Subject: RE: [Tinyos-help] CSMA-CA on CC2420micaz Collision avoidance is implemented differently on the two different radios. To start with Daniel's questions - the CC2420 2.4 GHz radio has a CCA pin on the chip that can be sampled to determine if another node is transmitting. How it determines this is defined in a control register - you can sample the channel energy, valid 802.15.4 data, or both. When the CCA pin shows that no other mote is transmitting, and the proper backoffs have executed, the radio can send the message. From the definitions I understand, this is a CSMA-CA scheme. The CC2420 has more limitations on the MAC layer than the CC1000. This is because a lot of the processing can take place on the chip. The synchronization header, and packet header are defined in the CC2420 datasheet, and the TinyOS message header for the CC2420 reflects this. You can get access to modifying some of these things - like auto acknowledgements, CRC checking, preamble length, etc. by modifying registers on the CC2420. All of this is available in the software radio stack, so if you want to hack, go for it. For Mica2 motes on TinyOS 1.x, you can find the Mac interfaces in the CC1000RadioC.nc configuration: configuration CC1000RadioC { provides { interface StdControl; interface BareSendMsg as Send; interface ReceiveMsg as Receive; interface CC1000Control; interface RadioCoordinator as RadioReceiveCoordinator; interface RadioCoordinator as RadioSendCoordinator; interface MacControl; interface MacBackoff; } } The LowPowerListening interface in TinyOS 1.x is actually split up into explicit commands inside CC1000RadioIntM.nc. This is improved in TinyOS 2.x, as well as the TinyOS 1.x Rincon CC1000 stack - get it in the TinyOS 1.x CVS under /contrib/rincon/tos/lib/CC1000Radio. Whereas the CC2420 radio checks for a clear channel automatically using the CCA pin, the CC1000 must do it in software using an ADC reading from the RSSI pin on the CC1000 chip. Through a simple running average algorithm (that has the possibility of improvement in the default TinyOS 1.x implementation - see the rincon CC1000 radio stack) the microcontroller can determine the RSSI noise level, and therefore be able to know when someone is transmitting by comparing sampled values. Changing the backoff period is very useful because it allows one mote to secure the channel and transmit as fast as possible. Look for interfaces like MacBackoff or CsmaBackoff in the radio stack to do this. When a transmission starts, the radio stack sends out an initial or congestion backoff event to request a backoff interval. If your application responds to that event with a specified backoff period, fantastic. Otherwise, the default radio stack values are used. The backoff period is probably the number one thing that affects data throughput and accessing the channel fairly - those two are inversely proportional. Using the MacControl or CsmaControl interfaces, you can completely disable CCA (clear channel assessment). This will make your motes transmit as fast as possible, but requires one mote to secure the channel ahead of time to avoid interference and collisions. Sometimes this crashes the mote, depending on which software version you're using. When it comes to acknowledgements, the CC2420 takes care of them automatically if that register is set (which it should be in TinyOS). The CC1000 does it manually by flipping the receiver into a transmitter and the transmitter into a receiver very briefly, and the receiving mote sends out a few bytes of acknowledgement. If an ack was received, the ack byte will be set to 1 (or TRUE) in the transmitted packet's metadata. What else? -david _______________________________________________ Tinyos-help mailing list [email protected] https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
