Decoding News Helicopter Signals On YouTube

A serendipitous YouTube video recommendation led [Oona] to a raw copy of a news helicopter car chase video. While watching the video she noticed an odd sound playing from her left speaker. That was all it took to put [Oona] on the hunt. Decoding mystery signals is a bit of an obsession for her. We last saw [Oona] decoding radio signals for bus stop displays. She isolated the left audio channel and sent it through baudline software, which helped her determine it was a binary frequency shift keyed (BFSK) signal. A bit more work with SoX, and she had a 1200 baud bit stream.

Opening up the decoded file in a hex editor revealed the data. Packets were 47 bytes each. Most of the data packets was static. However, thee groups of bytes continuously changed. [Oona] decoded these numbers as latitude and longitude, and plotted the resulting data on Google Earth. Plotting her data against the position of the car in the video revealed a match. [Oona] had a complete track of the news helicopter as it followed the car. The telemetry data is in 7-bit Bell 202 ASCII, and is most likely part of an Interruptible Foldback (IFB) system used by the helicopter news crew and the studio producers. Click past the break for the YouTube video that started this all.

Continue reading “Decoding News Helicopter Signals On YouTube”

Sniffing Data From Radio-Controlled Bus Stop Displays

A few weeks ago in Finland [Oona] discovered a radio data stream centered around 76KHz in a FM broadcast and she recently managed to decode it. This 16,000bps stream uses level-controlled minimum-shift keying (L-MSK) which detection can be quite tricky to implement. She therefore decoded the stream by treating the received signal as non-coherent binary FSK, which as a side effect increased the bit error probability. [Oona] then understood that the stream she was getting was the data broadcast by Helsinky buses to the nearby bus stop timetable displays. She even got lucky when she observed a display stuck in the middle of its bootup sequence, displaying a version string. This revealed that the system is called IBus and made by the Swedish company Axentia. However their website didn’t provide the specs for their proprietary protocol. After many hours of sniffing and coding, [Oona] successfully implemented the five layer protocol stack in Perl and can now read the arrival times of the nearby buses from her apartment.

An Atmega328-based Radioteletype XY Scope Display

[Jack] tipped us about a Crossed Bananas Display (CBD) he just designed. A CBD is a tuning aid for frequency-shift keyed (FSK) modes and is basically an oscilloscope in X-Y mode. At one time, radioteletype operators used binary FSK to transmit text over radio waves. In this scheme, the “1” is called the mark frequency and the “0” is called the space frequency. If both frequencies were perfectly tuned (correct phase) the resulting display would look like the one shown above, explaining the origin of the “crossed banana” name.

The build is based on an ATmega328 and a 1.8″ ST7735R display which has a 128×160 resolution. The MC33204PG operational amplifier is used in conjunction with a potentiometer to scale the input in the microcontroller ADC’s range. Another potentiometer sets the refresh rate of the graph. The whole project is enclosed in a painted cast-aluminium bud box and all the sources for this project can be found here.

Rebuilding The Electronics In A Remote Control Car

Inspired by the many autonomous rovers such as Curiosity and the self-driving Google car, [Rohit] decided to build his own by taking an off-the-shelf remote control car and adding his own electronics. Unfortunately, he couldn’t find the datasheet for the chip used to receive radio signals and drive the motors, so he ended up building his own electronics and putting them in the car.

[Rohit]’s car – the Thunder Rumbler RC Car – is driven by applying power to two motors. This is an easy system to control, as only two channels are needed to make the car go forward, left, right, or backwards. To drive these two motors, [Rohit] found an SN754410 quadruple half-H bridge driver chip lying in his box of assorted electronic components. Thanks to a helpful instructable, this chip was easily controlled with an Arduino.

That left the problem of sending a wireless signal to the Arduino. [Rohit] accomplished this by relying on an Android phone to provide the remote control.

[Rohit] whipped up a small program running on his desktop that allows him to send ‘L’, ‘R’, ‘U’, or ‘D’ to the Android phone to dictate if the car should go left, right, forward, or reverse. The Android phone receives these commands via the Internet and sends an audio signal through the headphone port. This audio signal is connected to two analog pins of the Arduino. With a little bit of software and a bit of reading up on frequency shift keying, [Rohit] was able to make his car move in any direction.

Even though [Rohit] realized his goal of controlling a remote control car on his own terms, the build is far from done. He plans on adding some ultrasonic sensors and using the Android’s camera for object detection.