Paul , Thanks for the reply.
Let me try to explain my scenario according to your questions: Data Rate : Not the raw physical layer data rate which is 250 kbps for CC2420. A number that accounts for the MAC layer including the headers and footers, and also the headers and footers of AMSenderC. PayLoad Size: This is size of TinyOS Active Message (TOS_Msg) data portion which in my case is 106. I understand that there may be too many variables in this data rate number so to say. But lets say we assume a very simple setup, a single tmote sending this 106 byte data payload TOS_Msg packet to another Tmote. What I am looking for is the experimental setup (that you were talking about), to come up with those numbers in a theoretically sound manner. Since there are so many variables how do we account and control all these variables. Some variables are intuitive such as radio interference, probably conducting the tests in a place where there are no interfering signals. ACKS - understandable, disable or enable by setting SP_FLAGC_RELIABLE. But what is confusing is how to observe the combined effect of all of these. Can you give some references to some papers that talk about such experiments ? It would be really helpful. Hope I have cleared some doubts about the scenario. Thanks, Somnath On Thu, Dec 3, 2009 at 9:13 AM, Paul Johnson <[email protected]> wrote: > Somnath, > > There aren't really straightforward answers to your questions because they > both are non-deterministic to a degree. > > For the first question: What data rate are you talking about? The raw > number of bits(including headers/footers?) that can be successfully > delivered over the air using the hardware or the number of payload bits that > you can deliver? The CC2420 can support variable length payload sizes. Are > you talking about the default payload size, or can modifications be made to > increase it? Are there more than 1 transmitter operating on the particular > channel? Is there interference from other wireless devices (baby monitors, > WiFi, Bluetooth, etc)? Are the transmissions broadcast (no ack) or unicast > (acks)? > > All of these effect the data rate. If you have the hardware, you can just > run a few simple tests to get some anecdotal results, but they won't be able > to fully describe every possibility mentioned. > > The second question also needs to be qualified. If you are using the > AMSenderC, it provides fair queuing between all concurrent instances of > AMSenderC. Are there any other instances of AMSenderC competing for access > to the radio? How often are interrupts occurring (timer interrupts, adc > done interrupts, etc)? These can significantly bog down an attempt to use > the radio. How many times does the sender have to back-off because it > detects that the medium is busy? > > As you can see there are many different variables that can impact the > answers to both of your questions. Aside from some anecdotal results, I > doubt anyone will be able to provide you better data than what you could > achieve by experimentally determining these answers yourself using your own > hardware/RF environment. > > Sorry I couldn't be more helpful, but the short answer is "it's hard to > calculate these for any generic situation, and you will get more accurate > results if you test these yourself using your own hardware/software and RF > environment" > > -Paul > > Somnath Mitra wrote: > > Hello , > > I need the exact data rate number that is achievable on a tmote > (I do not mean CC2420 data rate - which is 250 kbps). I mean the data rate > that is achievable taking into account the MAC layer. > > I would also like to know the time to transmit [probably a formula] a > packet of n bytes, from the point an application calls SendMsg.send() on the > sender mote to the point where the message is received by the application > layer on the receiver mote. > > The motes are Tmotes running TinyOS 1.15 and the Boomerang TinyOS stack > from MoteIV. > > Thanks, > > Somnath > > ------------------------------ > > _______________________________________________ > Tinyos-help mailing > [email protected]https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > >
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
