When I push the start button on a master device, I need the master device and a slave device (or several slave devices) to all start a process within 1 second of the button push (for the prototypes this is just lighting an LED). Triggering both devices within the 1 second window is easy, but the hard part is that I need all devices to start their process within 100 uSec of each other. This 100 uSec of simultaneity can be anywhere inside that 1 second window so there should be plenty of time to do synchronizing if needed (I'm just not sure how).
The proof-of-concept devices consist of an Arduino UNO, an XT09-si, and a single LED. The master also has a pushbutton switch.
Right now, I have a master that broadcasts a single 3-byte message as the start command to the slave devices (I'm only testing with 1 slave right now, but eventually there will be 10 slaves). In theory after pushing the button on the master device I should be able to transmit a broadcast message from the master to the slave(s), then delay the master for time X to allow each slave to receive and process it's message, and then trigger the master's LED (hopefully at the same time as the slaves). On the slave side they only need to receive the message and trigger their LED.
I have all the code for this written and working (except for the synchronizing/simultaneity timing issue). By monitoring both the master and slave's LED pins with an oscilloscope I see that there is a lot of variability between tests. If I trigger channel 1 off the master's LED pin, I see channel 2's pulse anywhere between -150 uSec and +150 uSec relative to the master.
I understand from the product manual that there is 100-200 uSec of variability in the initialization and synchronization overhead associated with the FIRST packet of RF data that is sent, but not subsequent packets. So I assume that the RF modules are "synced up" after the first packet, right? Sending a 2nd packet (or more) should be more consistently timed and repeatable.
I tried sending enough bytes to the RF module to force it to use 2 packets - a first packet filled with junk data to allow the modules to sync, and then a 2nd packet containing the start command. The slaves should receive the first packet all at random times, and then discard them. But they should be synced up and ready to receive the 2nd RF packet (containing the start command) all at the same time. But I saw the same variability between the triggering during this test also. So I'm not sure if this actually did what I intended. There isn't a way to actually "see" the RF transmission as packets.
I have played around with lowering PK and RB down to 3 bytes (the same size as the start command) but it appeared to have no effect. I played with RO=0 too.
Am I going about this all wrong? Is there some other parameter that I need to adjust? What should PK, RB, etc. be set to? Is it a problem with the interface baud rate being different from the RF baud rate?
Current settings: BD=3, BR=1, PK=0x03, RO=0x03, RO=0, everything else is factory default.