Here's my emails. You should be able to find them on the list
by searching for "radio reliability":
MS
Hi, I've been whinging about this for a while and finally got around
to running some experiments to characterize the radio message reliability
and speed with the mica2's. I'll be doing a little with micaz's soon but
I only have two right now so it won't be as interesting.
Basically I found that message ACKs are not too good and that under forced
worst case conditions the reliability of the CSMA backoffs and such (de)scales
linearly with the number of mica2's that are trying to transmit at the same
time.
I put my report up at:
http://www.etantdonnes.com/Motes/report_mica2/
and I will post the full data set and test code if someone asks for it.
Otherwise here's the conclusion section:
Conclusions
Using a message request/reply system where a basestation requests a message
from each re-Mote, by either indivudual point-to-point request and reply or
broadcast request with a p-t-p reply, I have arrived at the following
conclusions. These are under generally best-case conditions where five
re-Mote mica2s and one base station are within 2 meters of each other:
Point-to-point request messages should be throttled to less than about 10
per second or many replies will be dropped.
Broadcast request messages should be run without message ACKs enabled and
should be throttled such that there is about 20-30ms per re-Mote to allow
for replies. If the request timing is too short many replies will be dropped.
With message ACKs enabled in a point-to-point roundrobin mode where there
is little chance of transmit overlap and CSMA backoff, about 20 successful
individual messages per second can be sent with less than 3% failure rate.
However about 20% of the message ACKs are never received.
When ACKs are enabled in a semi-broadcast mode where there is a good chance
of CSMA backoff, message failures increase drastically, up to a 30% failure
rate in some cases. See Experiments for details.
Without ACKs, in a roundrobin mode where there is little chance of transmit
overlap and CSMA backoff, successful messages are around 26 per second with
less than 2% failure rate.
Without ACKs in a broadcast mode where there is maximum chance of transmit
overlap and CSMA backoff, successful messages are around 25 per second but
the failure rate varies linearly from 1% with one re-Mote to 6.5% with five
re-Motes. I don't know how far the failure rate linearity can be extrapolated.
enjoy
MS
_______________________________________________
I put a tgz archive of my sumtotal mote experience at:
http://www.etantdonnes.com/Motes/robocode.tar.gz
Here's the glossy intro:
This archive contains code to test radio communications on
the Mica Motes. It is actually a robot control application but
has been slightly extended to do message request/reply cycles
just about as fast as they can be done. Within the message code
radio ACKs are implemented, as well as sequential access to both
the radio and UART using the GenericComm component. In addition
to the message code, there is code for using PWM outputs, binary
inputs, and low-level ADC access. It's just about everything
I know about the mica2 and micaz, and some parts may be edible.
I make no representations as to suitability, paridigmatic TOS
usage, or clarity of vision...
enjoy or whatever
MS
_______________________________________________
As a follow up to my previous report on Mica2 message reliability
I got my grubby paws on a couple MicaZ's and tried a similar testing
regime. As part of this I had to fix a naughty threading bug in my
host-side Java driver, so if you downloaded my code from:
http://www.etantdonnes.com/Motes/robocode.tar.gz
you should patch it up with:
http://www.etantdonnes.com/Motes/javaupd.tar.gz
This only affects the host side when using the faster micaz...
Anyway, the original mica2 report is at:
http://www.etantdonnes.com/Motes/report_mica2/
and the addenda that deals with micaz is:
http://www.etantdonnes.com/Motes/report_micaz/
The conclusion section ('Z's work WAY better than '2's in most respects):
With Micaz's, using a message request/reply system where a basestation
requests a message from each re-Mote, by point-to-point request and reply I
have arrived at the following conclusions:
Point-to-point request messages should be throttled to about 25
(request/replies) per second or many replies will be dropped. This amounts
to something between 10 and 20ms delay between message request sends.
With message ACKs enabled in a point-to-point mode, under ideal conditions
where there is little chance of transmit overlap and CSMA backoff, about 50
successful individual messages per second can be sent with almost no
failures. ACKs are consistently received for successful messages.
Without ACKs, in a point-to-point mode, under ideal conditions where there
is little chance of transmit overlap and CSMA backoff, successful messages
are around 66 per second with almost no failures.
The ACK mechanism works very reliably in the MicaZ. When radio reception is
marginal, ACK failures generally align with message failures (in contrast
to the Mica2 where ACKS are dropped almost 10 times more often than
messages). However, I don't know how this scales in a multi-re-Mote
situation since I only have two micaz's.
An observation during testing of bad reception: The Micaz's seem to be
quite sensitive to antenna positioning and object interference. The two
communicating devices were in different rooms separated by some major
plumbing, and slight re-postioning of the re-Mote had a large effect on
successful message completion. Also just waving my hands around either the
base-station or re-Mote caused many message failures. The Mica2's were much
less sensitive on both counts in the same environment. YMMV of course...
whee
MS
[EMAIL PROTECTED] wrote:
I am wondering if anybody have done any actual testing on the capacity
(number of messages, say 39 bytes/msg) TOSBase can handle per sec on
Crossbow mib510/micaz. My setup is 3 micaz motes communicating with a
forth mote running TOSBase. All four motes reports to the basestation
with 39 byte messages every 40 ms. Thats 75 messages/s and the
Oscilloscope application shows a lot of package loss.
Any suggestions are much appreciated.
Stig Støa
Norwegian University of Technology and Science
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
