Without warning on an early August evening a significant proportion of the electricity grid in the UK went dark. It was still daylight so the disruption caused was not as large as it might have been, but it does highlight how we take a stable power grid for granted.
The story is a fascinating one of a 76-second chain of unexpected shutdown events in which individual systems reacted according to their programming, resulted in a partial grid load shedding — what we might refer to as a shutdown. [Mitch O’Neill] has provided an analysis of the official report which translates the timeline into easily accessible text.
It started with a lightning strike on a segment of the high-voltage National Grid, which triggered a transient surge and a consequent disconnect of about 500MW of small-scale generation such as solar farms. This in turn led to a large offshore wind farm deloading itself, and then a steam turbine at Little Barford power station. The grid responded by bringing emergency capacity online, presumably including the Dinorwig pumped-storage plant we visited back in 2017.
Perhaps the most interesting part followed is that the steam turbine was part of a combined cycle plant, processing the heat from a pair of gas turbine generators. As it came offline it caused the two gas turbines feeding it to experience high steam pressure, meaning that they too had to come offline. The grid had no further spare capacity at this point, and as its frequency dropped below a trigger point of 48.8 Hz an automatic deloading began, in effect a controlled shutdown of part of the grid to reduce load.
This is a hidden world that few outside the high-power generation and transmission industries will ever see, so it’s very much worth a read. It’s something we’ve touched on before with the South American grid shutdown back in June, and for entirely different reasons in 2018 when an international disagreement caused the entire European grid to slow down.
Header image: Little Barford combined-cycle power station against the sunset. Tony Foster, (CC BY-SA 2.0).
Sensors are critical in robotics. A robot relies on its sensor package to perform its programmed duties. If sensors are damaged or non-functional, the robot can perform unpredictably, or even fail entirely. [Dheera Venkatraman] has been working to make debugging sensor issues easier with the rosshow package for Robot Operating System.
Normally, if you want to be certain a camera feed is working on a robot, normally you’d have to connect a monitor and other peripherals, check manually, then put everything away again when you’re finished. [Dheera] considered this was altogether too much of a pain for basic sensor checks.
Instead, rosshow uses the power of SSH to speed things along. Log in to the robot, fire off a few command line instructions, and rosshow will start displaying sensor data in the terminal on your remote machine. It’s achieved through the use of Unicode Braille art in the terminal. Sure, you won’t get a full-resolution feed from your high-definition camera, and the display from the laser scanner isn’t exactly perfect. But it’s enough to provide an instant verification that sensors are connected and working, and will speed up those routine is-it-connected checks by an order of magnitude.
Robot Operating System is a particularly useful platform if you’re thinking about the software platform for your next build. If you do put something together, be sure to let us know.
Both our electrical meter and our gas meter are located in the basement of our house (we recently had the gas meter moved outside though). When people see this they always ask if the meter readers have to come inside once a month. The answer is no, these meters broadcast usage data which is picked up once a month when a utility company vehicle drives down the street. If you have wireless meters in your house, here’s a way to harvest and graph the wireless data so that you can analyze your usage patterns.
The hardware used here is a special USB dongle. This has a 900 MHz radio which picks out the packets from a reasonably large list of meter types, and pushes them through the USB interface. In the image above you can see that an Arduino with a USB host shield is used, but there are also drivers if you want to connect this directly to your computer.
We looked around and didn’t find any specifics on the hardware used on that board. But it can’t be all that hard to make one of these at home… the populated board seems to have just two ICs and a few passive components. Anyone up to the challenge of hacking together their own packet sniffer? We wonder if the Next HOPE badge could pull down the data?