Comment by drb999
2 years ago
Reminds me of an extremely similar case with a long distance microwave link at a mobile telecom provider in Australia that I worked for. They relied quite heavily on microwave link chains and this particular one was in northern Queensland where fixed lines were hard to find and no local engineers were locally present/aware of the changing environment.
Every week day + Saturday, from 7-3 the link would keep cutting out intermittently. Then work fine and the rest of the day and on Sunday… a crane, building a new residential building would operate during those hours right in the middle of the microwave path. Many weeks of theories and time wasted until someone had a chance to visit. :)
Amazing. Reminds me of the fact that militaries really don't want wind turbines in areas where good radar coverage is important (case in point: the Finnish Defense Forces anywhere near the Russian border); even though the blades aren't metal, they're still a source of noise and radar shadow.
I'm not at all knowledgable about this, but: is it feasible (and if so, hard?) or impossible to have some sort of live reporting from the turbines about the speed/position of their blades that connects to the radar system allowing it to ignore what it knows to be turbine noise/shadow and therefore be able to have turbines there and still get good radar?
Well, you can't just ignore a radar shadow or noise. Just like GP's point-to-point microwave link couldn't just "ignore" the crane. You can't make a bad Wi-fi connection faster by just telling your computer to ignore the wall between you and the hot spot. A wind turbine is a solid obstacle that conceals stuff behind it, and even if a single turbine might not be a big deal, most commonly someone interested in harnessing wind power would want to build an entire farm, which would be much worse.
8 replies →
Even if you ignored the turbines themselves, there would still be a "shadow" behind the turbines though I think? Which means you'd have a blind spot every now and then (when the wind is blowing and the turbines are active) which could be exploited by an enemy
3 replies →
Love that story.
For me it reminds me most debugging I see at work. People coming up with theories and doing some magic incantations on the interface.
Instead of reading the log files or reading error description which makes usually error and fix obvious in 10 seconds.
I've done a ton of low-budget analog hardware debugging, and the major problem with hardware debugging is each attempt to fix the problem takes a long time. If I had wanted to test every idea I had I could easily waste a week. Not to mention that I can't just run some automated test suite after the fact. For hardware, approaching debugging methodically is a necessity, not just best practice.
We don't typically have log files for hardware, but I'm always surprised when otherwise extremely intelligent people first try to debug by applying "fixes" that shouldn't have any causal effect on any weird observations we've gotten. I have no problem with people coming up with theories because each modification takes time, but each theory should ideally explain the data...
Reading log files with really obscure error messages might as well be reading a magical grimoire. Especially when the solution turned out to have nothing to do with the error message.
Hey but that is not a discussion, that's just throwing anecdote to bring other person down or make yourself feel better.
1 reply →
At that point, I'd have called a bush pilot to fly along the lines!