Sometimes, it's the small things in life...

Status
Not open for further replies.

Constantin

Well-known member
... took a while but it looks like I have worked through some of the bugs to allow my data loggers to operate at the same time, i.e. synchronized. Just used the SCK LEDs to see how well the bus master and the clients coordinated. Calculations suggested that the delta between the bus master and the clients would be on the order of 1500us or less - and could be better if one accounted for transmission time and all that. I'm not there yet, may tweak that going forward. But then again... do I really need to be better than +/- 5ms when I log data between various units? Unlikely as long as the data is summarizes on a second-by-second basis.

Anyhow, running the LED experiment allowed me to verify it visually with the help of a smartphone camera - put the thing in slo-mo video mode, run your test, and see what happens. At 240FPS, the changeover from one LED lighting to the other one being dead is happens in less than a frame. Running it in reverse, (i.e. both on/off), the results are similar. Happiness. That hopefully implies that all my data loggers can stay synchronized in their recordings, with hourly updates from the bus master that re-sets the local clocks. Put a nice RTC oscillator on the bus master (i.e. TXCO) and the system should function pretty synchronously and without the need for wires (Hello XBee S1!).

Why all this babbling? Well, let's just say that it took a while to get the bus master and the clients to communicate reliably, even with the help of EasyTransfer. That is, to implement a hopefully-rigorous protocol to re-transmit as needed, time out, and so on. While the use of a slo-mo camera to visually verify synchronicity may be obvious to the of you, I thought it was a cute idea to visually verify the thing.
 
Last edited:
Status
Not open for further replies.
Back
Top