I know with the CC2420 radio, the payload size you select does not affect how many bytes are actually transmitted over RF. I'm not sure about the CC1000 though.
I use a payload size of 90, but if I send 4 bytes of payload, only MSG_HEADER_SIZE + MSG_FOOTER_SIZE (FCF) + payload len bytes are transmitted. Cheers, Matt Vinai Sundaram wrote: > Hi David, > > Thank you for your response and the graphs attached. Can you explain > the experimental setup used to obtain the results? Specifically, is > this the throughput seen at the application layer ( packets that > passed CRC Check)? How many motes were used in the experiment and were > they competing for the radio? > > Regards, > Vinai. > > David Moss wrote: > >> Hi Vinai, >> I'm interested in this topic as well, and I have no answer as to why 29 >> bytes was chosen, but I've found that the optimal payload size >> depends on >> what type of environment your network exists within. With any radio, >> if you >> increase the available data length you're effectively decreasing the >> packet >> header:data ratio. By increasing the data length as much as possible, >> you're going to increase your data throughput to its maximum - in ideal >> cases. This is because it takes less header information per data >> information to transmit, and because on some radios (CC1000) the >> radio kicks >> back and forth between Tx->Rx->Tx between every packet which takes an >> extra >> 512 uS per back-to-back packet. So by decreasing the number of >> transmitted >> packets while still getting the same amount of data through, you're >> obviously going to increase throughput. >> >> However, if your network is in a noisy environment, then there's more >> chance >> for the packet to get corrupted during transmission. In this case, >> it will >> take longer to recover that packet because of its length - instead of >> losing >> only a little bit of data, you're losing a lot of data. And this is >> what I >> think your question is about - what's the nominal packet length that >> minimizes the effects of noise while maximizing throughput? It's a >> design >> problem. >> >> I'm sure this can be simulated with some kind of packet success rate >> probability for various environments, but it may be difficult to port >> that >> over to the real world because the packet success rate in your network >> environment may change over time, even by the minute. The best >> answer I can >> give you is, increase your TOS_Msg payload length as much as you're >> comfortable with while leaving enough free RAM on the mote to execute >> the >> app, and run it in the environment you plan to deploy in. If it's >> indoors >> with tight spacing, max out the payload. If it's outdoors on the ground >> with wider spacing, might as well keep the payload size pretty modest. >> >> The ultimate solution would involve some kind of back-end >> architecture that >> provides the ability to recommend how much data the payload of the >> current >> packet should be loaded with to maximize throughput based on an RSSI >> or LQI >> or something, and also provide the ability to increase/decrease the >> transmit >> power automatically to save battery on motes that are sitting near each >> other in a noiseless environment. >> >> I've attached several spreadsheets showing the packet throughput for >> mica- >> mote types with varying payload sizes. Noise was not a factor in any of >> these tests. >> >> -david >> >> >> >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of Vinai >> Sundaram >> Sent: Friday, April 21, 2006 1:39 AM >> To: [email protected] >> Subject: [Tinyos-help] Rationale for 29 bytes payload >> >> >> Hi , >> >> I need to send more than 29 bytes for the application I am working >> on. However, I do not want to increase the payload size so much that >> it will reduce the throughput of the network. Is "29 bytes" found to >> give close to optimal throughput? Are there any empirical/analytical >> studies that suggest a payload size range that would give >> near-optimal throughput? I didn't come across the reason for 29 bytes >> in any of the documents. >> >> Thank you for your help, >> Vinai. >> >> >> > > _______________________________________________ > 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
