And it details that the time it takes to send a packet is sum of the Time on Air and Time for CSMA-CA and Retries.
Basically, I want to use the XBees for precision timing.
Here’s all the delays involved
Internal microcontroller delays - Measurable. no problem
Fill XBee buffer (fully or partially) and then tell it to send - Measurable, no problem
Perform random delay - Hard to determine, problem
Perform CCA - Constant .128ms
Transmit if CCA is clear. If it is not clear repeat steps 3-5. - Hard to determine, problem
Done (broadcast packet)
Can I set the random delay parameter to ‘1’ so that the random delay function: (0 : 2^BE - 1) * 0.320 ms , will choose a number between 0 and 1 so that they random delay is always .320ms?
How can I find out how many times the packet was ‘delayed’ in the CSMA algorithm?
How can I find out how many times the CCA failed?
If these cannot be solved, then I cannot use the XBee for a precision timing application. In fact, if these cannot be solved I don’t think I can use a CSMA radio for a precision timing application.
I have found that if I need to explore a specific aspect of a problem on a forum it is better to start a new thread. Otherwise people will often go off on tangents that I do not need to explore. Plus makes for better material for searching later.
Maybe I should have combined the last thread…my bad.
Anyways, I know I can measure the delay under a given circumstance. But change the retry count as already noted and that number will change. I think CSMA is killing my XBees for precision timing use.
The only hole up my sleeve is if I can somehow use digimesh and rely on the fact that all xbees wake up and go to sleep at exactly the same interval. Then use that interval to resyncronize clocks across the field. A digi employee told me about that. I think you are supposed to monitor the sleep line.
You could use synchronized clocks on each remote unit, and then only sending them a “at this time go” command.
Sort of like:
9:18:00: “At 9:19:30, execute.”
9:19:30: Everyone executes
To do exactly what you are proposing I think you will need a dumber RF module than xbees, but then you run into all of the dumb rf module problems that and xbee solves.
You can disable CCA (CSMA/CA) if you dare; it’s a setting in XBees as I recall. Maybe setting the backoff coefficient to 0 or some such.
Find a rarely or never used 2MHz chunk of spectrum, or one where you assure that the received signal strength is much stronger than WiFi signals. Remember that WiFi is 20MHz wide and 802.15.4 is 2MHz. So only a percentage of the WiFi signal falls in the area of the 802.15.4 channel. The channel numbers in 802.15.4 are not in common with 802.11, so look at a frequency chart. Suggest you use one of the highest channels in 802.15.4 (outside the US, there are a a few more channels).
But generally, wireless is what it it is. So be sure your app can tolerate noise and interference now and then. Or you automatically or manually choose a new freq if the interference is too much or too often.
kd5crs:
You could use synchronized clocks on each remote unit, and then only sending them a “at this time go” command.
Sort of like:
9:18:00: “At 9:19:30, execute.”
9:19:30: Everyone executes
To do exactly what you are proposing I think you will need a dumber RF module than xbees, but then you run into all of the dumb rf module problems that and xbee solves.
Brian
For the timing aspect I think a dumber module is what I need. You guys have it.
For data transfer XBees still have the dumb stuff beat.
And even with the backoff set to 0, that just puts a 0 in for the delay equation which makes the delay a multiple of ??3.28ms?? and we don’t know how many times it will retry. And we don’t know how many times it’ll check for a clear channel.
So I think the answer is: use XBees for data transfer…they work great. Use dumb radios for stuff you don’t want CSMA, retries, and other logic that makes data play nice.
check the XBee docs… I recall a setting that disables CCA.
But the concept in the unlicensed spectrum, for sharing, is CCA (CSMA/CA) or Freq. Hopping.
That’s just the way it has to be with shared-use spectrum
Or to do the synchronized “At time x, do something”, you use the XBee as a comunication modem, and connect its serial port to your microprocessor which is accepts the commands to be done at a future time.
Even without such an application processor, and with CCA, most situations you’d see maybe 10mSec of jitter.