At FastComments we have Mongo deployed across three continents and four regions on dedicated servers with full disk encryption, across two major providers just incase. It was setup by one person. Replication lag is usually under 300ms.
My manual Spark is pretty fun and beats Civic Sis and other fast cars in rallycross. I have done 100+ redline clutch dumps in that car. It still drives fine.
If they don't sync to a common clock source, they won't stay in sync for long. Probably not even for a few minutes or so.
You'd get the same phenomenon that you see when operating turn signals in traffic. They seem to weave "in and out" of sync. The frequency at which that happens is the beat frequency, i.e. the difference between the two blinking frequencies.
It's a bit larger than a 555, but it should keep you within a small handful of microseconds per day until the aging effects start to add up which make getting more than a millisecond a year dicey, even if the thing doesn't die on you: https://www.ipgp.fr/~crawford/2017_EuroOBS_workshop/Resource...
A cheapo 20ppm quartz watch crystal definitely doesn't drift by a second every few minutes, but it will over about about half a day at maximum error. A 5ppm one (still sub one Euro) will keep a second about every two days. A 0.5ppm TCXO can be had for about 15 Euros from Mouser and that gets you two weeks.
If you have shared line power you can just use that and everything will be locked in sync forever.
If you don't want to use that or radio, and you are outside, you could try to be really clever am sync your flash phases to a specific position of the sun. This is what the Long Now clock does. It'll be a different time each day, but it'll be the same for all units, within a small tolerance.
Well, yeah. I was sort of assuming that you won't use a TCXO or even just a cheapo quartz crystal, because it doesn't make a lot of sense: You've now thrown money at something that will relatively quickly desync anyway.
I mean, sure, the TCXO will mean that you only start seeing a phase difference between the two after weeks instead of minutes, but what's the point of that? I you want them to be at the same phase, you'll need to sync them at some point, and you do that by using a common clock source.
So either you shell out some effort for a real solution (power line is nice, and also qualifies as a common clock source as I've predicated), or you don't. And if you don't, there's no point in using a precise-ish clock at all, and you'll likely end up with very quick desyncing.
Wouldn't the mains frequency be a common clock source, if nothing else?
But presumably these lights at least have battery backup, given the obvious risks in case all of them were to fail at the same time due to a grid issue.
Yeah, the mains frequency qualifies, if you explicitly use that.
(Doesn't solve the problem if you want them to be in sync phase-wise, i.e. blink at the same time or similar, but at least they won't drift apart, which was what this is about.)
You could still sync with that signal because it's not perfect.
For example, say you have a scheme where a period longer than the last one is symbol A, about the same period is B and shorter is C. You will get a random-ish sequence of symbols.
If you have an algorithm that, say, resets the timer to zero whenever a certain symbol sequence is detected, you can eventually get back in sync. With some care you can make sure you only sync when the sequence happens and the light has only been off for a short period to avoid excessively long off periods or truncated on periods.
Then you just need to have a local oscillator good enough to do that timing analysis and that can maintain sync between these symbol occurrences.
You could do it on the tiniest micro. Once you've counted the zero crossing detector, these days you might save 3 to 5 whole dollars over a GPS receiver on your very expensive ICAO compliant lamp and also ruled out using DC into the bargain! And theoretically it desyncs when the grid is too stable for days on end (and you just get BBBBB or ABABAB for millions of cycles)!
In terms of what is actually used, they do often use GPS and many of them have MODBUS or similar data connections which presumably wire into the wind turbine's telemetry somehow for fault detection.
It is entirely self-contained (but needs zsh, not bash, for dumb reasons). Terminal at 90 columns works best.
It is just a very simple integer LFSR as a random number source, followed by a hand-made integer IIR filter (manually placing poles on the z-plane). All of this entirely with trivial integer operations only (effectively using 32 bit fixed point arithmetic)
So without any external input or tools at all, and not even using zsh's $RANDOM, it makes an "analog" weavy pattern.
reply