Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Slightly off topic: typically, lights of neighboring towers blink asynchronously. But sometimes they are synchronized. Very satisfying. Anyone knows how this works? My best guess is e.g. DCF77. Thoughts?


I believe it's usually GPS/GNS (they all receive the time via GPS independently, and flash at predetermined times). The FAA requires synchronization for many classes of obstruction because it makes it clear that you're looking at obstruction lights rather than e.g. brake lights or traffic lights on the ground.


Could they also use power grid sync? Not sure as I haven't talked to anyone in wind power, but grid sync would be pretty close to 1 Hz at least in the US.

Building a product that would sync at 1 Hz via GPS that works in the US and other countries with 50 Hz power would be a little easier than syncing to grid phase though.


You can have each tower derive a perfectly stable 1Hz signal from the mains, but you have no way to synchronize those signals. Each tower's 'tick' starts at a random point in the 60Hz cycle.

You need an external, dedicated channel for this. You either synchronize with signals sent between towers or with a global signal from somewhere else (space). GPS broadcasts atomic time references for free, so everyone just uses that


Just like a freeway, public good and public benefit are things government should be doing well. (We the people, for us the people)


Definitely GPS. Other methods have been used in the past--I remember reading operating reports from a wind farm nearly 20 years ago that slowly brought all its lights in line with each other over several months--but these days you can buy mainstream lighting with the GNSS receiver built in from a number of suppliers. They make it easy.

For wind farm use most also have an external input for ADLS triggers, though that usually also requires a separate controller and communications connection to manage the ADLS signals.

The flashing red lights are L-864 type. The requirements are 20 to 40 flashes per minute (FPM), and typically 30 FPM is used.


Hmm... maybe I could build a 1pps GPSDO based on light flashes from nearby towers, then. No need for my own GPS antenna!


You'd probably have better timekeeping from a reasonably connected Pi with a common NTP daemon (take your pick, some are easier to configure / query), and a realtime-ish thread to emit your PPS signal on a GPIO or similar.

Probably more robust than line of sight, and able to pool with other NTP servers in your home-lab (and beyond).


True, but I'm not thinking of a practical method, just fun. I already have GPS derived time here, but that's been reliable and boring!


My observation is not that they are sometimes synchronised, but some subset of the towers are synchronised (this was my observation in Melbourne AU). Upon asking reddit, it appears that it is the FAA-preferred option that all lights are synchronised: https://www.faa.gov/documentLibrary/media/Advisory_Circular/...


I’ve driven through wind farms where the blinking tower lights are synchronized. Highly distracting.


If you look close - almost impossible in the dark - you will see that most wind turbines don't have any lights at all. Too many lights is a distracion but all the synchronized lights are an easy to understand 'stay away from this whole area'.

There are FAA rules on this.


Driving through a massive wind farm at night is a trip since they all blink in unison. Having them all independently would look interesting but could rapidly descend into madness:

https://archive.org/details/bigclive_20230516


When it's on purpose it's typically done through GPS driven clocks. This is how wind farms manage it, where all towers are required to blink together.


Yeah, I've seen it with windfarms. Always wondered why do they need to blink at the same time. The scale of the blink is pretty jarring at night (but also awe-some, in the same way any big enough infrastructure project inspires a kind of awe).

Wind farms have a certain amount of nimbyism because they "spoil the natural landscape." (So do regular farms -- nothing natural about grain silos or row crops, but that's a side topic...) Anyways, having that many towers blink in unison across that big a landscape is a weird effect when you first see it. I think there's an argument that if they blinked independently it would feel more natural in a way.

But since the blinking is all FAA requirements, I assume it's to help identify all the individual towers from the air. I suppose if they were all blinking independently, it would be a predator-trying-to-focus-on-a-single-zebra-in-the-herd problem, except in this case the predator is a pilot trying not to crash into a turbine.

Sure would emit more subtle 'part of the landscape' vibes though.

(Which I guess is exactly what you don't want when you're flying above them. Sigh.)


It's so pilots see the entire wind farm as a single entity and can interpret what they see and understand the extent of the wind farm easily. There is a pretty good study you can read on this:

https://www.airporttech.tc.faa.gov/DesktopModules/EasyDNNNew...

As to community impact, radar-activated lighting is an approach that is being used in places this is a concern. It allows the lights to remain off unless there is a plane within the envelope that requires the lights to activate. It's expensive though.


Does it have to be radar? Can it use ADS-B?


Little cropdusters and sport aircraft are who the anticollision lights are designed intended to protect, and many of them are not ADS-B equipped.

In the US, ADS-B is not required below 10,000 feet and when more than 30 miles away from the 30 largest commercial airports.


This is a safety measure. You can't rely on ALL aircraft having functional (or installed) transponders. You must actively sense incoming craft because they don't always politely announce themselves.


At small unattended airfields, you can sometimes turn on the field lights by transmitting on a particular frequency (as if you were calling the non-existent tower in quick succession).

https://www.aopa.org/news-and-media/all-news/2017/march/flig...

(Of course, in this case it works because the pilot already knows the airfield is there.)


The FAA document says "sensor-based" but every installation I have seen in the US uses radar.


> Always wondered why do they need to blink at the same time.

presumably this makes it more striking, and thus easier to notice and avoid


One option - Maybe the blinking time is set to a INDEPENDENT? accurate time piece - ie Blink on the change of a second


That's what DCF77 is. Or GPS.


It's probably just a side effect of them being powered on at the same time or not?


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.


There's got to be some rubidium frequency standard that's a drop-in replacement for a 555 timer ;)


A chip scale atomic clock (with a handy 1Hz output) can be yours for barely over five thousand euros and half that if you buy 250 of them. https://www.microchip.com/en-us/product/csac-sa65

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...


GNSS (GPS) is the typical standard used.


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.


Well yes, obviously, but I'm just being a internet pedantic about "a few minutes".


And you are technically correct, which is the best kind of correct anyway.


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.


Maybe you'll get a kick out of this, I did it in a bored afternoon a while back:

    echo -ne '\e[8;32;90;t';n=20;t=524292;l=$((t-1));m=$((2**n-1));c=0;xs=(1);ys=(1);for ((i=0;i<n*m;i++));do b=$((l&1));l=$(((l>>1)^(b*t)));c=$(((c<<1|b)&m));[ $((i%n)) -eq 0 ] &&{xs=($c $xs[1,4]);y=$((((xs[4]-xs[0])<<30-0x3fffd60f*ys[2]+0x7d32617c*ys[1])>>30));ys=($y $ys[1]);yd=$((120+(y >> 24)));printf '\e[48;5;%um ' $yd};done
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.

The LFSR is this part:

    b=$((l&1));l=$(((l>>1)^(b*t)));c=$(((c<<1|b)&m))
The hand-made filter is this part:

    xs=($c $xs[1,4]);y=$((((xs[4]-xs[0])<<30-0x3fffd60f*ys[2]+0x7d32617c*ys[1])>>30));ys=($y $ys[1])
I specifically tuned the filter peak just slightly away from being an integer divisor of 90 columns, to give the pattern a slight "rolling" effect.*


What... the... fuck. Mind blown.

The zsh dependency is super unfortunate, though :(


It is amazing! With some brutal hacks to some array indices, and probably some excessive quoting changes it can work in Bash too:

  echo -ne '\e[8;32;90;t'; n=20; t=524292; l=$((t-1)); m=$((2\*n-1)); c=0; xs=(1); ys=(1); for ((i=0; i<n*m; i++)); do b=$((l&1)); l=$(((l>>1)^(b*t))); c=$((((c<<1)|b)&m)); if ((i%n==0)); then xs=("$c" "${xs[@]:0:4}"); y=$(( ((xs[4]-xs[0])<<30) - 0x3fffd60f*ys[1] + 0x7d32617c*ys[0] )); y=$((y>>30)); ys=("$y" "${ys[@]:0:1}"); yd=$((120+(y>>24))); printf '\e[48;5;%um ' "$yd"; fi; done
This could probably be submitted to https://github.com/attogram/bash-screensavers/blob/main/gall...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: