Retrotechtacular: How Solidarity Hacked Polish TV

July 5, 2016 by Jenny List 52 Comments

In the 1980s, Poland was under the grip of martial law as the Communist government of General Wojciech Jaruzelski attempted to repress the independent Solidarity trade union. In Western Europe our TV screens featured as much coverage of the events as could be gleaned through the Iron Curtain, but Polish state TV remained oblivious and restricted itself to wholesome Communist fare.

In September 1985, TV viewers in the city of Toruń sat down to watch an action adventure film and were treated to an unexpected bonus: the screen had a brief overlay with the messages “Solidarity Toruń: Boycotting the election is our duty,” and “Solidarity Toruń: Enough price hikes, lies, repression”. Sadly for the perpetrators, they were caught by the authorities after their second transmission a few days later when they repeated the performance over the evening news bulletin, and they were jailed for four months.

The transmission had been made by a group of dissident radio astronomers and scientists who had successfully developed a video transmitter that could synchronise itself with the official broadcast to produce an overlay that would be visible on every set within its limited transmission radius. This was a significant achievement using 1980s technology in a state in which electronic components were hard to come by. Our description comes via [Maciej Cegłowski], who was able to track down one of the people involved in building the transmitter and received an in-depth description of it.

Transmission equipment seized by the Polish police.

The synchronisation came courtesy of the international effort at the time on Very Long Baseline Interferometry, in which multiple radio telescopes across the world are combined to achieve the effect of a single much larger instrument. Before GPS made available a constant timing signal the different groups participating in the experiment had used the sync pulses of TV transmitters to stay in time, establishing a network that spanned the political divide of the Iron Curtain. This expertise allowed them to create their transmitter capable of overlaying the official broadcasts. The police file on the event shows some of their equipment, including a Sinclair ZX Spectrum home computer from the West that was presumably used to generate the graphics.

There is no surviving recording of the overlay transmission, however a reconstruction has been put on YouTube that you can see below the break, complete with very period Communist TV footage.

Continue reading “Retrotechtacular: How Solidarity Hacked Polish TV” →

Retrotechtacular: DC To DC Conversion By Vibrator

July 4, 2016 by Al Williams 42 Comments

Electricity comes in two basic forms: Alternating Current (AC) and Direct Current (DC). DC is handy to use and is easy to analyze. However, AC has some useful properties too. In particular, AC current can operate a transformer which can step it up or down easily. Power is conserved, of course (well, actually, you get less power because of losses in the transformer).

You can’t do that trick with pure DC. You can reduce a voltage, although that typically wastes power in heat (for example, a voltage divider or linear regulator). You can’t readily increase a DC voltage unless you convert it into some sort of AC first.

This was a particularly bad problem in the era of tubes–especially tubes in car radios. The car’s voltage was probably 12V but the tube’s plates might take hundreds of volts. What do you do? Some old car radios used what is called a dynamotor. This is just a motor and a generator in one box. You could spin the motor with 12V and have the generator produce a different voltage (even a DC voltage).

Continue reading “Retrotechtacular: DC To DC Conversion By Vibrator” →

Hackaday Links: July 3, 2016

July 3, 2016 by Brian Benchoff 10 Comments

This week, Popular Mechanics published cutaway diagrams of ships that will be seen in Star Trek: Beyond, released later this month. This is your cue for spoilers for the remainder of this paragraph. The USS Franklin looks suspiciously like – and was likely built after – the NX-01, the titular ship of Star Trek: Enterprise. The Abrams-verse Franklin was the first Warp 4 ship, yet the prime universe NX-01 was the first Warp 5 ship, with previous ships having trouble reaching Warp 2. We must now consider the Abrams-verse Trek is not a parallel universe to prime-universe Trek and should therefore be considered a completely separate canon (yes, even the destruction of Vulcan. If you see the new Star Trek movie, the NX-01 launched in 2151, and your suggested viewing beforehand is ST:ENT, S02E24, First Flight.

The Mechaduino is a Hackaday Prize entry that turns steppers into closed-loop servos. It’s a phenomenal idea, and now it’s a Kickstarter.

Walk into a dollar store, and you’ll find stupid solar powered electronic flower pots. They’re bits of plastic that shake a plastic flower back and forth when placed in the sun. They’re selling millions, and I have no idea why. [Scott] put a jolly wrencher on one of these flower pots. Really, this is just an exercise in 3D printing, but [Scott] printed the jolly wrencher. We don’t see a lot of that, due to how difficult it is to render the wrencher in OpenSCAD.

In just a few hours, Juno will perform an insertion burn around Jupiter. Does this mean pretty pictures? Not quite yet. This is the closest a spacecraft has ever gotten to Jupiter, and over thirty or forty orbits, Juno will fly between Jupiter’s massive radiation belts. Here’s the NASA trailer.

This video recently caught the Internet’s attention. It’s squares and circles that when put next to a mirror look like circles and squares. Yes, it’s weird. People have 3D printers, so of course these ambiguous objects were quickly reverse engineered and printed. Here’s how they work

It looks like Brexit has caught up to Mouser. Here’s their country select dialog for eu.mouser.com. Thanks [Tom] for the screencap.

Hacklet 114 – Python Powered Projects

July 2, 2016 by Adam Fabio 5 Comments

Python is one of today’s most popular programming languages. It quite literally put the “Pi” in Raspberry Pi. Python’s history stretches back to the late 1980’s, when it was first written by Guido van Rossum. [Rossum] created Python as a hobby project over the 1989 Christmas holiday. He wanted a language that would appeal to Unix/C hackers. I’d say he was pretty successful in that endeavor. Hackers embraced Python, making it a top choice in their projects. This week’s Hacklet focuses on some of the best Python-powered projects on Hackaday.io.

We start with [Jithin] and Python Powered Scientific Instrumentation tool, his entry in the 2015 Hackaday Prize. [Jithin] has created an “electronics lab in a box” style tool that can compete with commercial products with price tags in the thousands. Python Powered Scientific Instrumentation tool uses simple microcontroller powered hardware to create programmable gain amplifiers, waveform generators, LCR meters, CC sources and more. The microcontroller handles all the real-time operations. Data processing happens on a connected PC running Python scripts. Popular Python libraries like Scipy make signal processing and waveform displays easy.

Next up is [Bill Peterson] with jamPi. [Bill] loves his music keyboard, but hates having to lug around a laptop, audio interface, and all the associated cables. He needed a device which would be as flexible as a PC-based synthesizer, but as simple and compact as a MIDI sound module. JamPi does all this and more. [Bill] is using fluidsynth to generate sound. The control and interface software is handled in Python with the help of the fluidsynth.py module. All this functionality is wrapped up in a simple box with a 2 line character LCD. Now [Bill] is ready to jam anytime, anywhere.

Next is [i.abdalkader] with OpenMV, his entry in the 2014 Hackaday Prize. [i.abdalkader’s] goal was to create “the Arduino of machine vision”. He’s well on his way to accomplishing that. In 2015, OpenMV had a successful Kickstarter campaign. After a few manufacturing glitches, customers are now receiving their devices. OpenMV is a low-cost Python-powered machine vision device. An ARM microcontroller coupled to a simple image sensor makes up the core of the device. The camera is programmed in MicroPython, with the help of many image processing libraries created by the OpenMV team. [i.abdalkader] even created his own IDE using Glade and PyGTK.

Finally we have [osannolik] with Calibration and Measurement Tool. Have you ever want to display a few debug parameters from your embedded project, but didn’t have the display real estate (or any display at all)? What about changing a parameter without pulling out your JTAG setup and firing up your debugger? [Osannolik] has created a simple Python powered PC-based front end which can be used as a Swiss army knife for developing embedded systems. Variables can be displayed in real-time, parameters changed. Even graphs are available thanks to pyqtgraph.

If you want more Python-powered goodness, check out our new Python-powered project list! Did I miss your project? Don’t be shy, just drop me a message on Hackaday.io. That’s it for this week’s Hacklet. As always, see you next week. Same hack time, same hack channel, bringing you the best of Hackaday.io!

What Could Go Wrong: SPI

July 1, 2016 by Elliot Williams 58 Comments

Serial Peripheral Interface (SPI) is not really a protocol, but more of a general idea. It’s the bare-minimum way to transfer a lot of data between two chips as quickly as possible, and for that reason alone, it’s one of my favorites. But that doesn’t mean that everything is hugs and daffodils. Even despite SPI’s simplicity, there are still a few ways that things can go wrong.

In the previous article in this series, inspired by actual reader questions, I looked into troubleshooting asynchronous serial connections. Now that you’ve got that working, it’s time to step up to debugging your SPI bus! After a brief overview of the system, we’ll get into how to diagnose SPI, and how to fix it.

Continue reading “What Could Go Wrong: SPI” →

Fail Of The Week (in 1996): The 7 Billion Dollar Overflow

June 30, 2016 by Gerrit Coetzee 50 Comments

The year was 1996, the European Space agency was poised for commercial supremacy in space. Their new Ariane 5 Rocket could launch two three-ton satellites into space. It had more power than anything that had come before.

The rocket rose up towards the heavens on a pillar of flame, carrying four very expensive and very uninsured satellites. Thirty-seven seconds later it self destructed. Seven billion dollars of RUD rained down on the local beaches near the Guiana Space Centre in ~~Southern~~ South America. A video of the failed launch is after the break.

The cause of all this was a single improper type cast in a bit of code that wasn’t even supposed to run during the actual launch. Talk about a fail.

There were two bits of code. One that measured the sideways velocity, and one that used it in the guidance system. The measurement side used a 64 bit variable, but the guidance side used a 16 bit variable. The code was borrowed from an earlier, slower rocket whose velocity would never grow large enough to exceed that 16 bits. The Ariane 5, however, could be described with a Daft Punk song, and quickly overflowed this value.

The code that caused the overflow was actually a bit of pre-launch software that aligned the rocket. It was supposed to be turned off before the rocket firing, but since the rocket launch got delayed so often, the engineers made it timeout 40 seconds into the launch so they didn’t have to keep restarting it.

The ESA never placed blame on a single contractor. The programmers had made assumptions. The engineers had made reasonable shortcuts to make their job easier. It had all made it through inspections, approvals, and finally the launch event.

They certainly learned from the event; the Ariane 5 rocket has flown 82 out of 86 missions successfully since then. It has at least five more launches contracted before it is retired in 2023 for the Ariane 6 rocket being developed now. This event also changed the way critical software and redundant systems were tested, bringing the dangers of code failure to the attention of the public for the first time.

If you want to read more, there is a great discussion on Reddit which tipped us off to this fail, a quite thorough Wikipedia article, and the original article that ran in the New York Times is mirrored here.

Continue reading “Fail Of The Week (in 1996): The 7 Billion Dollar Overflow” →

Tools Of The Trade – Inspection

June 29, 2016 by Bob Baddeley 15 Comments

In the last episode, we put our circuit boards through the reflow process. Unfortunately, it’s not 100% accurate, and there are often problems that can occur that need to be detected and fixed. That’s what the inspection step is for. One could insert an inspection step after paste, after placement, and after reflow, but the first two are icing on the cake — the phase where most mistakes can be caught is after reflow.

There are a number of problems typical with a surface mount reflow process: Continue reading “Tools Of The Trade – Inspection” →