The GSM buzz

You probably recognize the loud buzz a ringing mobile phone often causes in nearby speakers. But where does it come from? Let's dissect the sound and see if it reveals something about the call!

First we need to know a little about how GSM works. A certain cell site (tower) is responsible for handling all the calls made in its coverage area. But the allocated frequency band is very limited. Several phones can talk to the same tower on the same frequency by taking turns. Thus, one GSM phone will only transmit a short burst of digitally encoded speech at a time, and will then wait silently for its next turn. This is called time-division multiple access (TDMA).

Up to 8 phones can fit on a single frequency. They take turns during what's called a TDMA frame. One phone may only transmit once every frame, in its own allocated time slot. One frame lasts 0.004615 seconds, a time slot thus being one eighth of this.

Now, let's zoom into the buzzing sound. Plotted below is its waveform. Not surprisingly, it is also a plot of the voltage variation in the speaker cable.

It looks like voltage is being switched on for a short moment and then cut off for a longer period. You may know from high-school physics that a radio transmitter produces an oscillation in the electromagnetic field, which in turn creates a current (and voltage) in a conductor. So the voltage spikes are probably the periods during which the phone is transmitting. And sure enough, when TDMA timeframes are superimposed onto the waveform, magic happens:

So, what does this reveal about the call going through? Nothing whatsoever, luckily.

Slow-scan visions on Linux

As a programmer writing obscure little FLOSS projects for fun, having someone actually read and fix my code is a compliment. Recently I got a pull request on slowrx, my somewhat stalled slow-scan television demodulator project, and was inspired to write more.

The project started in 2007 when I was trying to find a SSTV receiver for Linux that could run in "webcam mode" and just save everything it receives. It would use modern stuff like ALSA instead of OSS and Gtk+2/3 instead of 1. Preferably it would work even if the receiver wasn't exactly tuned at the zero-beat frequency. Turned out existing software couldn't do this, so I accepted the challenge.

So here's how slowrx looks today:

FM demodulation is done by a 1024-point Fast Fourier Transform and Gaussian spectrum interpolation. The windowing function adapts to SNR, so the resolution drops under noisy conditions but we get a clearer image (or the user may opt to use a narrow window regardless of noise). Sound card clock mismatch is calculated using a linear Hough transform on the sync channel and fixed by re-running the demodulation at the adjusted rate. The program will detect VIS headers at any in-band frequency and shifts the reception window accordingly. It can decode the FSK callsign after the picture. The program stays up for hours without a segfault. Yeah – it's written in C99!

Pictures I've received using slowrx:

I've noticed the 8- and 12-second black-and-white Robot modes are still in use today. I believe they were the "original" SSTV modes that used to be viewed on a green phosphor screen in a much more analogue environment. So I've been thinking about an optional phosphor filter for B/W modes:

The infrared impulse

Imagine a movie party with friends. Just as the 237-minute Love Exposure is about to start, you feel the need to have a remote controller. You remember the spare TV remote lying around. You also happen to have an infrared phototransistor from a Hauppauge HVR-1100 PCI card. So you quickly try to come up with a way to receive the signals using stuff you readily have at home.

Far-fetched? Well, it did happen to me. The movie was some great stuff, so I decided to sit and watch it instead. But the next day, I finished this remotely useful contraption. (Of course proper USB IR receivers are cheap on eBay and well supported on Linux, but hey.)

Long story short, I connected the phototransistor directly into the sound card's line in by soldering the leads to a stereo jack. The sound card is becoming my favorite method of sampling the outside world into the computer.

And sure enough, pressing the button "1" on the remote produces this waveform:

By comparing the timing to some common IR protocols I found out the signal is Manchester-encoded RC-5. After running-average type lowpass filtering, thresholding and Manchester decoding in Perl, we get these 14 bits:

The first "11" is a start bit sequence, then follows a toggle bit that tells whether this is a repeat or a new keypress. The rest is an address field (11110b = 1Eh) and the command itself (000001b = "number 1").

Yay, no new hardware needed!