What happened first

Is there a way to have multiple Photons monitoring for an event, and when it occurs, another device will be notified, such that if multiple Photons are triggered more than 10ms apart, I can know in what order they were triggered?

My understanding is I can’t use the RTC to generate timestamps with that level of precision and I don’t have any other ideas.


For the first part it’s definitive YES, but for the order of events being forwarded it’s probably NO.
The thing here is local and global latency and unpredictable routes.

AFAIK, the order of delivery of TCP packets is non-deterministic as each packet may take a completely different route from any other - especially when issued by different devices.

You might be able to have some local (only local latency) sync logic which allows you to instruct all devices to take a snapshot of their current millis() count simultaniously and use that in your subsequent events as correction constant for millis() based timestamp of event “send time”.

Thanks for your reply.

The devices will be on the same wifi network so at least it is only local latency. Am I right in thinking that if I try and take a snapshot of all current millis() That snapshot will have the same problem where I don’t know how much time elapses between the request for a snapshot and the value being stored and I don’t know that it;s the same lag on each device.

So all that will change is I lock in the potential error when I take the snapshot and if any device gets an advantage because of network issues, that advantage becomes permanent rather than random every time the issue occurs?

That depends on how you do the inter-device communication. If you are going with publish/subscribe you’ll have a round trip to the cloud and back.

That depends on your local setup and how you trigger the snapshot. e.g. with all devices in view of each other, a photo diode and a flash light you could trigger an interrupt for all devices pretty much simultaneously . The lag for this process would be in the range of µs (mainly due to interrupt latency). Some non-network RF approach could do the same in a multi room setup.

The limiting factor should not be the devices. With phantasy and creativity once the limiting factors are clear ways around them should be possible to find - and maybe challenging the original task definition may reveal that the demand for 10ms precission may not be that cruicial anyway (but I don’t know your exact use-case).

I hadn’t thought as far as inter-device communication but I would have done publish/subscribe so excellent point.

That is a really interesting idea with the flash as a sync. I’m thinking it would make user setup too cumbersome for my application, but it does show how much you can do with some creativity. The real precision demand for my system is human perception, if a human will see one event occur first my system has to be in agreement. So 50ms is probably acceptable 100ms is probably not. 10ms gives me enough room to be sure no human can genuinely disagree.