Clipper Windpower: Solutions In Search Of Problems

The first modern wind turbines designed for bulk electricity generation came online gradually throughout the 80s and early 90s. By today’s standards these turbines are barely recognizable. They were small, had low power ratings often in the range of tens to hundreds of kilowatts, and had tiny blades that had to rotate extremely quickly.

When comparing one of these tiny machines next to a modern turbine with a power rating of 10 or more megawatts with blades with lengths on the order of a hundred meters, one might wonder if there is anything in common at all. In fact, plenty of turbines across the decades share fundamental similarities including a three-blade design, a fairly simple gearbox, and a single electric generator. While more modern turbines are increasingly using direct-drive systems that eliminate the need for a gearbox and the maintenance associated with them, in the early 2000s an American wind turbine manufacturer named Clipper Windpower went in the opposite direction, manufacturing wind turbines with an elaborate, expensive, and heavy gearbox that supported four generators in each turbine. This ended up sealing the company’s fate only a few years after the turbines were delivered to wind farms.

Some history: the largest terrestrial wind turbines were approaching the neighborhood of 2 megawatts, but some manufacturers were getting to these milestones essentially by slapping on larger blades and generators to existing designs rather than re-designing their turbines from the ground up to host these larger components. This was leading to diminishing returns, as well as an increased amount of mechanical issues in the turbines themselves, and it was only a matter of time before the existing designs wouldn’t support this trend further. Besides increased weight and other mechanical stresses on the structure itself, another major concern was finding (and paying for) cranes with enough capacity to hoist these larger components to ever-increasing heights, especially in the remote locations that wind farms are typically located. And cranes aren’t needed just for construction; they are also used whenever a large component like a generator or blade needs to be repaired or replaced. Continue reading “Clipper Windpower: Solutions In Search Of Problems”

Solar Power Your Pi

Running a Raspberry Pi with solar power sounds easy. Of course, like most things, the details are what get you. About a year ago, [Bystroushaa] tried it without success. But the second time turned out to be the charm.

Of course, success is a relative term. It does work, but there is concern that it won’t be sufficient in the winter. In addition, if the battery dies, everything doesn’t restart automatically. Still, it is usable, and there should be ways to solve those problems.

The original attempt used a PiJuice hat and solar panel. This time, the design didn’t use these, opting instead for a LiFePO4 battery, a solar regulator, and a solar panel. The rest of it comes down to mechanical and physical mounting. The cheap regulator has some drawbacks. For example, it doesn’t allow for monitoring like more expensive units. It also cannot balance the cells periodically, although that could be done with an external controller.

We’ve seen solar-powered Pi boards before. Or, try a Game Boy.

Heartbeat packets of LKV373

Audio, Not Video Over The LKV373 HDMI Extender

[eta] found herself in a flat with several LKV373 HDMI extenders. Find the corresponding transmitter, plug it into your device, and you’ve got a connection to the TV/sound system, no fussing with wires behind the TV. However, [eta] wanted to get rid of the need to plug in a laptop and start sending packets directly to play music. As her flatmate [dan] had already reverse-engineered the receiver, she tested her prototype against their virtualized receiver, de-ip-hmdi.

The actual sending of images was surprisingly straightforward — just a JPEG sliced into 1024 bytes chunks and sent over. However, early testing showed nothing on the receiver. The end of a frame needed marking by setting the most-significant bit of the chunk number to one. Now de-ip-hdmi showed the image, but the actual hardware would not. With something missing, [eta] returned to Wireshark to scan packets. Noticing some strange packets on port 2067, she analyzed the pattern to reveal it sent another packet just before a new frame and included the frame number. With this tweak, it was still not enough. Ultimately, heartbeat packets sent every second synchronize things, but compared to the noise of the video packets, they were easy to miss. Now [eta] had some functioning video streaming rust code.

In theory, audio for the LKV373 followed the same thought process as video. Two channels of 32-bit big Endian integers at 44,100 hz chunked into 992-byte sections and sent as a packet formed the audio stream. With only 992 bytes, two streams, and 4 bytes per sample, each packet only held 2.812 milliseconds of sound. The first tests resulted in no audio output or distorted crunchy sound. Of course, this was every audio engineer’s worst nightmare: jitter. With a spin loop and an efficient ring buffer, the audio packets were soon slinging across the network reliably.

The code is available on a hosted version of GitLab. It’s a beautiful journey through reverse engineering some obscure but relatively cheap hardware. Along the way, there is nicely annotated Rust code, which makes it all the better.