Posted by warrenm 14 hours ago
A machine shop should connect 1/3 of their lights to each phase so it is immediately obvious if a phase gets dropped. Lots of equipment will suffer on two of three phases but with lower performance or even damage.
It's way less of a problem with modern machinery, and leds will blink in uncorrelated phases in a frequency that is different from the grid's anyway.
How does one connect a lamp to 3-phase power?
Are/were there 3-phase fluorescent tubes available?
Or are we relying on the spinny-thing that is to be observed to somehow be illuminated by all three phases, with three lamps or fixtures, simultaneously? Without such malarcky as shadows or inverse-square to muddy our vision?
Or maybe a multiplicity of single fixtures with 3 tubes -- one tube per each phase?
And even then: Doesn't it still strobe somewhat at (50*3*2)=300 or (60*3*2)=360Hz, instead of the 100- or 120-Hz that a shop lit by a single phase might provide?
(LEDs are out-of-scope of this question, of course: Line-voltage LED lamps can have integrated electronics and can therefore have diode elements that are driven by things that approach [or even achieve] DC, which changes the rules.
And, of course: Incandescent lamps have enough persistence that stroboscopic effects are generally not an issue with a human eye.)
No, it’s not. It’s a neat trick that visually reveals when the utility drops a phase, but there are better ways to handle avoiding equipment damage.
Best practice is to use phase monitoring relays that can de-energize a motor when a phase is dropped/reversed to prevent damage. The trip time is adjustable and it’s more reliable than manually hitting an e-stop. It also won’t let a motor with incorrect phasing start up either. You see phase loss relays on a lot of compressor motors and other large motors.
Here’s a flyer for an Eaton product: https://www.eaton.com/content/dam/eaton/products/industrialc...
It's a quick way to know if something is down, using context clues that are already there to begin with!
I couldn't help myself, downvote at will.
> Jeff: A full ghillie suit? Or I don't know what they're called.
If you see someone up in a tall tower wearing a ghillie suit [0]... that sounds like time to call emergency services while avoiding their line-of-sight. :p
(Perhaps they meant "Hazmat" [1])
> Tower painting has changed a lot over the years. The older towers have lead in them. So whenever there's a project on the tower, it's not unusual to see the guys in some kind of a, what do they call those?
My first thought would be “that might be the dumbest sniper I have ever seen”…while I was taking cover, because even if they are dumb, they might still be a capable marksman.
https://www.faa.gov/sites/faa.gov/files/airports/engineering...
tl;dr NVGs are sensitive to near IR so you want lights that are dim in those wavelengths (but not completely out since you still want to see them with NVGs) while still being bright in visible light. There's a neat picture of the flying controll tower on one of the UK's Queen Elizabeth-class aircraft carriers that shows two rooms with similar illumination levels in visible light, but under NVGs one room which isn't NVG compatible is massively brighter than the other. In the NVG-compatible room there were still a handful of panel indicator lights that were not compatible and lit up the whole space
Lights on towers mean stuff, especially to airplanes.
Lights are required for tall towers, and get this, towers next to airports.
You can guess how tall a tower is by looking at the lights.
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 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
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.
Probably more robust than line of sight, and able to pool with other NTP servers in your home-lab (and beyond).
There are FAA rules on this.
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.)
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.
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.)
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.
presumably this makes it more striking, and thus easier to notice and avoid
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...
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.
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.
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.
(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.)
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.
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 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))
xs=($c $xs[1,4]);y=$((((xs[4]-xs[0])<<30-0x3fffd60f*ys[2]+0x7d32617c*ys[1])>>30));ys=($y $ys[1])
The zsh dependency is super unfortunate, though :(
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
see https://www.ecfr.gov/current/title-14/chapter-I/subchapter-E...