The microphone bioamplifier

As the in-ear microphone in the previous post couldn't detect a signal that would suggest objective tinnitus, the next step would be to examine EMG signals from facial muscles. This is usually done using a special-purpose device called a bioamplifier, special-purpose electrodes, and contact gel, none of which I have at hand. A perfect opportunity for home-baking, that is!

There's an Instructable called How to make ECG pads & conductive gel. Great! Aloe vera gel and table salt for the conductive gel are no problem, neither are the snap buttons for the electrodes. I don't have bottle caps, though, so instead I cut circular pieces out of some random plastic packaging.

As for the bioamplifier, why can't we just use the microphone preamplifier that was used for amplifying audio in the previous post? Both are weak low-frequency signals. There's no apparent reason for why it couldn't amplify EMG, if only a digital filter was used to suppress the mains hum.

It's a signal, but it's noise

First, a little disclaimer. It's unwise to just plug yourself into a random electric circuit, even if Oona survived. Mic preamps, for example, are not mere passive listeners; instead they will in some cases try to apply phantom power to the load. This can be up to 48 volts DC at 10 mA. There's anecdotal evidence of people getting palpitations from experiments like this. Or maybe not. But you wouldn't want to take the risk.

So I attached myself into some leads, soldered into a stereo miniplug, using the home-made pads that I taped on opposite sides of my face. I plugged the whole assembly into the USB sound card's mic preamp and recorded the signal at a pretty low sampling rate.

The signal, shown here from 0 to 700 Hz, is dominated by a mains hum (colored red-brown), as I suspected. There is indeed a strong signal present during contraction of jaw muscles (large green area). Moving the jaw left and right produces a very low-frequency signal instead (bright green splatter at the bottom).

It's fun to watch but still a bit of a disappointment; I was really hoping for a clear narrow-band signal near the 65 Hz frequency of interest.

Einthoven's triangle

At this point I was almost ready to ditch the EMG thing as uninteresting, but decided to move the electrodes around and see what kind of signals I could get. When one of them was moved far enough, a pulsating low-frequency signal would appear:

Could this be what I think it is? To be sure about it I changed the positions of the electrodes to match Lead II in Einthoven's triangle, as used in electrocardiography. The signal from Lead II represents potential difference between my left leg and right arm, caused by the heart.

After I plugged the leads in the amp already did this:

Looks promising! The mains hum was really irritating at this point, but I could get completely rid of it by rejecting all frequencies above 45 Hz, since the signal of interest was below that.

The result is a beautiful view of the iconic QRS complex, caused by ventricular depolarization in the heart:

Quite a side product!

My chip collection

Old IC (integrated circuit) packages are fun and I collect them. This involves going to flea markets to look for cheap vintage electronics like telephones, answering machines, radios or toys, and then desoldering and salvaging all the ICs and other interesting parts. Selected packages from my disorganized pile of chips follow. Most are POTS-related.

Sony CXA1619BS

A "one-chip-wonder", this is an FM/AM radio in a small package. It takes an RF signal (from the antenna) and an IF oscillator frequency as inputs and outputs demodulated monaural audio.

Sanyo LA2805

This chip does general answering machine related tasks. It has a tape preamp for recording and playback; voice detector logic; beep detection using zero-crossing comparation; power amplifier; line amplifier; and pins for interfacing with a microcontroller.

Unicorn Microelectronics UM91215C

The UM91215C is a tone/pulse dialer. A telephone keyboard matrix is connected to the input pins, and the chip outputs DTMF-encoded audio or pulsed digits, depending on the selected dialing mode. An external oscillator needs to be connected as well. It can do a one-key redial of the last dialed number, and it can also flash the phone line.

Holtek HT9170

A DTMF receiver, reversing the operation of UM91215C above. The chip, employing filters and zero-crossing detectors, is fed an external oscillator frequency and telephone line audio, and it outputs a four-bit code corresponding to the DTMF digit present in the signal. The use of external components is minimal, but a crystal oscillator is needed in this case as well.

SGS-Thomson TDA1154

A speed regulator for DC motors, this chip can keep a motor running at a very stable speed under varying load conditions. In an answering machine, it is needed to keep distortions in tape audio in the minimum.

Toshiba TC8835AN

This chip can store and play back a total of 16 audio recordings of 512 kilobits in size. It also contains a lot of command logic, explained in a 40-page datasheet. Type of audio encoding is not specified, but the bitrate can be chosen between 22kbps and 16kbps. The analog output must be filtered prior to playback.

Intel 8049

This monster of a chip is a 6 MHz, 8-bit microcontroller with 17 registers, 2 kilobytes ROM, 128 bytes RAM, and an instruction set of 90 codes. It's used in many older devices, from telephones to digital multimeters.

Portable TV, Raspberry-Pified

Recently I entered the era of video-capable portable music players. About time, too. My device of choice is this Action-branded Taiwanese gem from 1988 with a 5-inch CRT display (B/W), AM/FM radio, television receiver, and cassette player (mono, no rewind). It takes 9 D-sized batteries.

The batteries inside were leaking quite a bit so I removed them in favor of a DC adapter. They actually occupied roughly half of the casing. After removing them the device looked very empty and was unbalanced because of the heavy CRT. So I had to come up with something to fill the space with.

Then it struck me: it's a perfect video terminal and tape drive for the Raspberry Pi!

The screen

The Action has a 5" black-and-white CRT display and a television tuner. The receiver is on an AN5151N integrated circuit. Now, the Raspberry Pi outputs composite video. Someone else has tried injecting composite video onto the AN5151N before, with results that didn't look very successful to me at first sight, so I just ended up buying a cheap RF modulator. It modulates a TV-frequency carrier with the composite signal, and that can be fed into the aerial input of the TV to be demodulated again.

Aerial input to the TV is via a miniplug, so I had to improvise an adapter for coax. It works almost perfectly, except that the CRT crops out the extremes of the display.

The battery compartment before and after refurbishing:

The tape

The cassette player of this device is pretty simple. It does not have stereo, rewind, auto-stop, or any of the other hi-tech functions that many modern-day Walkmen have. It doesn't even stop automatically when Eject is pressed. But it works.

I've written a little Perl program that can write data onto cassettes and read it back using a sound card. For this project I removed the sound card step. The way I've written the data onto the tape is such that when amplified with the tape player's U821B chip, the voltage can directly be used as a binary 3v3 GPIO logic level. I wouldn't recommend this though, unless you know what you're doing, because the GPIO port is essentially a direct connection to the CPU and there's no overvoltage protecti... blast, I've just fried my RasPi!

A moment of silence. And a screenshot honouring the memory of its last words over ssh. Here, a logic "1" is low voltage, and "0" is high. A wee bit too high.

111111111111111111111111111111111111111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111111111111111111111111111111111111111
111111111111111111110110011Write failed: Broken pipe
$ █

Anyway, I also modified the TV's power circuitry to supply power to both the CRT and tape player at the same time, and installed a switch to silence the speaker when reading data. If it weren't for the aforementioned overvolt accident, this would now be complete. Cassettes could be used to store e.g. Vectrex games; also reading C64 cassettes will be supported.

Moral of the story: The GPIO port is not 5V tolerant! Assuming there will a second attempt some day, I'll just use a transistor to pull the GPIO pin high when there's a high on the tape. Or use a sound card.

RDS display on a Raspberry Pi

Earlier I modified my radio to output raw bits from its RDS decoder chip. The radio already displays a Programme Service name, but for FM DX purposes, it's fun to see more data. Also, the Programme Identification code can be decoded from very weak signals, identifying distant stations. And I can receive interesting traffic information messages by decrypting RDS-TMC with the encryption keys I've recovered. Now that I have a Raspberry Pi, it's time to make a dedicated little display.

First, I changed the radio connector from my previous modification. This one, salvaged from a mystery phone device I found at a flea market, doesn't come loose as easily as the Mini-DIN:

I bought a discount 2x16-character HD44780-compliant LCD at the local parts store and made a 4-pin connection to the Raspberry Pi GPIO header. I used another two GPIO pins to interface the Pi with my radio (one for data, one for clock). I then wrote a C program to read the 1187 bps RDS data, process it for error correction and synchronization, and output it to a Perl script for interpretation. The script then returns a text string to be displayed on the LCD. The bcm2835 library is used for GPIO interaction.

Turns out GPIO is not very good for data rates this high. The C program takes about 5 samples per RDS clock cycle, and uses 97 % of the CPU time. With the Perl script and LCD update running, the poor Pi can't keep up with realtime data, and lots of bits are lost. But after waiting patiently, I finally get a Programme Service name, Programme Identification code, and RadioText.

On the left, my radio. On the right, the RasPi in its doghouse:

Experimenting with lower sampling rates will hopefully alleviate the problems. But it kind of works already.

Update 2013-04-01: According to this benchmark, this very library should be able to handle GPIO speeds of several megahertz. So I tried running the program in strace to see what it's doing to burn so much CPU. Turns out it's sitting in a single nanosleep() call and never returning!

I experimented a bit and ended up replacing all calls to bcm2835_delayMicroseconds() (which uses nanosleep()) with calls to usleep(). And it works! CPU utilization is at 10% maximum, and a PS name appears lightning fast when changing stations. So, something was probably wrong with nanosleep() or bcm2835's implementation thereof.

Voice over laser

So now that I have the laser, I might as well try fun stuff out with it. Like modulating the beam. I know hams have experimented with long-range laser communication, so maybe it could even work.

So I built a poor girl's beam modulator. It is, in essence, a sophisticated optical apparatus which I call a "Laser". It consists of a piezo buzzer stolen from a defunct fire alarm, a piece of a makeup mirror I broke, and lots of Blu-Tack, among other things. The piezo buzzer is directly connected to my laptop's audio Line Out, so I can make it buzz arbitrary signals. The piezo makes the mirror vibrate, which causes deviations in the beam's direction. Kind of like a DMD, except not digital nor micro.

The receiver side is situated a short distance away. It is just a simple wide-spectrum photodiode. It connects to another sound card's Line In. When the beam deviates a little, it won't directly hit the diode any more, and this causes the diode voltage to fluctuate. This should allow us to send information over the channel.

I found a piece of audio with a folk tune in the beginning followed by a lady reading out numbers. I applied a suppressed-carrier single-sideband modulation at 6 kHz, so as to avoid the hum caused by lighting in the room. It's painfully trivial using SoX and Perl, by the way:

open(S,"sox salakalastaja.wav -t .raw -e signed -|");
open(U,"|sox -b 16 -c 1 -e signed -t .raw -r 44100 ".
       "- ssb.wav sinc 6000 -n 4096");
 
while(not eof(S)) {
  read(S,$a,2);
  print U pack("s",unpack("s",$a) *
          cos(($n++ * 2 * 3.141592653589793 * 6000) / 44100);
}
 
close(U);
close(S);

I still need to make some amplifiers. The piezo could take a lot more voltage, but line level only goes so far. Also, the unamplified output of the photodiode is very weak at -90 dB, so we're almost hitting the 16-bit quantization floor. Here's a sine wave being transmitted over the laser:

However, audio from initial crude testing is actually pretty intelligible. In the beginning, you can hear the 50 Hz buzz caused by flickering lamps, and then me tuning the heterodyne to 6.000 kHz. The noise mostly comes from 16-bit quantization/dithering.

Enchanting subcarriers on FM, part 2

As explained in the previous post, I modified my Sangean ATS 909 receiver by equipping it with a digital RDS output. May it now be told in pictures.

Of course everything had to start from reading some service manuals and data sheets. Energy drinks were also necessary. Yes, I colored the board schematic with color pencils for ease of use!

I figured I would need four separate outputs from the decoder (data, clock, quality bit, and ground) so I chose a 4-pin mini-DIN plug in one end of the cable. The other end is a familiar DB-25. Data is input via the parallel port's ACK, BUSY, and Paper Out pins; I picked a random GND pin for the ground.

The RDS circuit is hidden under the corner of an RF shielding plate. It would have been tedious and mistake-prone to remove the shielding, so I just used my precision soldering skillz and left all the wires outside the plate. Now the chip was wiretapped.

The front cover has a mini-DIN-sized placeholder-looking feature that I used for this purpose. Probably it was related to the speaker's airflow though. I hotglued the 4-pin connector in place. Holes in the control board came in handy when wires needed to be taken through.

The socket fits nicely in the front cover. I had to remove the Sangean logo from its place but hotglued it back next to the connector. (If something else looks dissimilar to the classic ATS 909, it's because I've also replaced the default backlight LEDs with super bright ones!)

I'm relieved the radio still works! Next it will be time to test the connection. It won't happen until my cheap parallel-to-USB converter arrives in the mail, since my laptop is new enough not to have a parallel port.

But even now already, when I wiggle the connector around, the speaker audio gets superimposed by data! Of course this isn't exactly what's supposed to happen since it means I've shorted a connection, but OMG! It's audible and even more evident in the oscillogram:

Update: The converter (idVendor=1a86, idProduct=7584) arrived, but apparently it just emulates a USB printer and low-level parallel bit-banging is not even possible. So I took the thing apart and built a simple twin-channel voltage divider in place of its internals that I then attached to a stereo phone jack (all parts salvaged from an old radio). Data goes to left channel, clock to the right; I'll just have to ignore the quality bit.

I connected this to the sound card's line in and behold! The clearest possible data and clock signals on separate channels!

There is slight crosstalk, probably via ground since I used quite small resistors for the voltage divider. But the data is good:

This means I can completely comment out my software clock recovery and PLL. I rolled the FM dial and logged some stations.

Now I'm going to bed.

Summer fun: tinkering with a broken GPS

My latest flea market find is a Magellan eXplorist XL GPS receiver. It was claimed to be broken and sold for €3. Inside it had an SD card containing detailed maps for the whole country. I took it home, changed the batteries and looked inside. Turned out one of its battery terminals had been installed backwards and was not touching the battery. Amazingly, this was the only fault it had, and after fixing it I now have a working GPS receiver!

I've tested the receiver on walks and bike trips. It works perfectly and is very accurate. The maps are detailed and quite up-to-date (from 2007). I can type in a street address and it will calculate a route for me. It even knows many shops, restaurants and public services.

The device has a peculiar connector on the backside. Markings on the PCB reveal that it's a custom USB connector. This was probably the only way they could make a USB connector water-proof. I don't need water-proofness but USB would be fun, so I cut a hole on the side and installed a standard USB-A connector instead.

This hack actually works and the eXplorist is recognized ­(as a modem for some reason). Turned out the device can even communicate with Linux using NMEA, so I can now install gpsd and do all sorts of fun location aware stuff on my laptop!

Later I've downloaded more maps to the device from OpenStreetMap. They're awesome! Some Python scripts need to be used for map conversion (pymagellan).

As an added bonus, Magellan has chosen the highly-acclaimed Comic Sans MS as the font for all menus.