The following details the results of changing the payload size in TinyOS’s AMStandard module to 128 bytes, rather than the stock 28 bytes
It should be noted that speeds here are the useful data speeds, ie. excluding headers and trailing data for the packets.
The setup for this test was the same as for the 28 byte tests (See Initial Speed Tests), except that the payload size has been changed to 128 from 28.
Larger payload sizes are presumably possible, except that when I attempted to change above this, the ‘mote seems to crash. I’ve yet to determine the cause.
It occurred to me at this point that I was testing a round-trip time, and that in my implementation, that nearly never happens (only for slow-speed communication on the base band, anyway) and the tests were giving me invalid data.
The return packets from the Pong `mote were causing the CSMA aspect of the Ping mote to throttle back on its transmissions in addition to the in-built ACK messages.
To counter this, I rewrote the Ping and Pong apps thus.
The Ping module only sent again once it had a sendDone() acknowledgement from the AMStandard module, preventing the module from flooding the stack (The cause of the crashes in the previous tests).
The Pong module was set NOT to reply with the message it received, but to merely count the incoming messages and report a count once a second.
This produced a HUGE leap in speed, as can been seen from the graph below.This shows a peak speed of ~30kB/s, and an average of approximately 26kB/s! And this is with the stock system, save for the payload size changes.
While this may look like my work is done, we must remember that this method is pretty much taking over the entire message system, and owns the radio all the time.
Ideally, a kernel-level system should be implemented to take a pointer to an area of memory along with a size and an address to send to, and it should process the data transmission automaticly without using the call stack constantly.