Electronics > Beginners

Can I demodulate Bell 202 FSK using a microcontroller?

(1/5) > >>

Ok, I just told you everything I know abount demodulation.  I would like to demodulate Caller ID packets directly using a microcontroller.  I know they make special chips that handle that (HT9032D), but I would have to get one, and they require a crystal.

Caller ID uses Bell 202 modulation, which is FSK, with mark/space frequencies of 1200Hz/2200Hz, and a bit rate of 1200 bps.  So I thought I could run the incoming signal through a bridge rectifier, and then for a single bit period a mark would have two highs and a space would have three or possibly four.

Of course I don't know if a bit always starts at a zero crossing point, nor do I know what the waveform looks like in the transition from a space to a mark.  At 2200 Hz, it wouldn't quite get back to zero when the bit period ends, and I don't know what happens then.

Well, this may be a crazy idea, but since the frequencies are so low, I just wondered if it might be possible to demodulate the signal directly instead of using whatever other method would normally be used if the frequencies were much higher - PLLs or whatever.

Knowing that someone will ask, it's because I live in a gated community, and visitors pull up to the gate call box, then enter a number.  The box then dials my phone number, I answer and hit "9" and the gate opens.  But if I'm not near a phone, it goes to voicemail, and the visitor can't get in.  So I want to set up  a device that wlll detect the calling number of the gate box from Caller ID, answer the phone, transmit a "9" in DTMF, then hang up.  I use an Ooma home phone system, which outputs Caller ID packets to all wired extension phones, so that part is already done.  I just need to listen on the line and demodulate the packets, which are sent after the first ring.

Yes, of course it is possible with a microcontroller.  Even a rather simple slow microcontroller.
I have had a few generations of desktop personal computers whose maximum processing power was less that a $10 microcontroller today.

On that note (pun intended), you could just record some samples (maybe ten or so) of  the signal into audio files you can use on your PC.  Convert them to raw linear PCM 16 bit per sample signals at a sampling rate of at least 8000 samples per second or faster (maybe up to 24,000 or 48,000 samples / second if you wish).

Then maybe just use your PC to write the code to detect the signal and decode the digits, use standard C or a bit of simple standard C++ if you want.   Write it without dependence on libraries and PC functions for the core decoding function -- only processing the numeric sample data and giving a boolean (true / false) signal detection indication
as an output.  But for analysis and debugging you can print other information to the screen or a file but such parts should be able to be isolated from the build by conditional compilation or such.

Feed blocks of data into the decoder routine somehow, say:
bool detect_expected_caller_id( const uint32_t * const p_sample_data_input, const uint32_t number_of_samples  );

Maybe make it decode the whole transmission as a block, though then you'd need other code to detect the phone ring, determine if / when the transmission starts, and then record & analyze the digital transmission at the appropriate timing.  Then other subsequent code to answer and play the digit string out (which can be synthesized by the MCU or prerecorded audio) if appropriate.

So when you have it working in PC based code reading data from the prerecorded sound files, you can switch to having the PC work by coupling a live signal to the PC sound card.  Then when that works you can copy the important bits of the code to the MCU and then on the MCU you will only need the skeleton of the other accessory routines you need such as timers, MCU initialization, ring detection, phone answering relay control, synthesis or replay of DTMF, etc. though some of that you could also duplicate mostly portably on the PC.

Of course the simplest solution might be to just record about 300ms of "9" on your voice mail greeting but the MCU way is more interesting.

Your questions about the phase offset and continuity of the waveform are exactly the sorts of things you should be thinking of relative to the the decoder's ability to make assumptions or not about the form of the signal it will see.
I don't know the answers -- they depend in part on the specifications for caller ID, and in part on the implementation of those specifications (where variation of choices is permissible) by the equipment in your area's phone system.
The original standards should probably be specifications you can find online if you try, but it is also simple enough that you can likely just decode it based on a sample since in your case the expected single number will always be the same so you just need a matching pattern detector as opposed to a full decoder if you want to take a shortcut at first.

There is a kind of digital filter resonator algorithm that can detect a single tone frequency called the Goertzel algorithm which used to be used for things like decoding DTMF and sometimes FSK modem signals.  Since it can efficiently decode single tones it is more efficient when you have only a couple / few / several of possible tones of interest to detect as opposed to analyzing for every possible one of hundreds or thousands of tone frequencies.

However MCUs these days are VERY powerful and they can actually use general algorithms like certain implementations of the FFT (fast Fourier transform) for real or complex signals to decode every possible tone among a grid of a few hundred or few thousand possibilities limited by the digital sample rate and bandwidth.
So you could even do that though it would be wastefully inefficient given only a few needed tones.

You'll need to have some level discrimination to enable the deteection only at a signal level above some reasonable minimum (it'll be in the specification documents... maybe -24 dBm or something on the low side and maybe -3 dBm on the high side just a guess).     

And ring detection and timing logic to look for the sequence among or between the ring events or whatever your use case is.

I am 100% sure if you look on say github you can find Bell 202 and Caller ID decoder software for MCUs like maybe one of the PICs or the STM32 since this will have been a popular topic since the 1990s through maybe 2010 when it became less relevant to have tonal signaling over landlines.   But given your ideas you can make your own version reasonably simply and it will be interesting.

Audacity is good free PC software to record and view and modify and convert audio waveforms.

There are FFT libraries like FFTW for the PC, and similar ones from CMSIS-DSP for ARM MCUs, and many others that are just generic C implementations of the N-point real input FFT for fixed point or floating point math.

I suggest using FP32 floating point math and a Cortex-M4F or better which will have a suitable built in FPU for the MCU side.  This matches the PC's floating point processing implementation fairly exactly so the code will be portable if you use a portable FFT or tone decoder subroutine.

If this is a landline you'll want an AC audio coupling transformer and/or capacitively coupled arrangement to get the AC signal and a zener diode / optocoupler / resistor circuit or similar to detect the high voltage ring signal.

CMSIS-DSP is one DSP library for ARM Cortex M based MCUs.

I suggest to use the MCU's built in ADC if it has a 12-bit per sample one since it will be good enough.  You could otherwise use a proper audio codec connected via I2S to the MCU but for this simple tone processing that fidelity is not at all useful.

You can use a simple RTOS like FreeRTOS or any of the other common ones if you want to facilitate interleaving the parts of the code like ring detection, answering, play back, recording, processing recorded data, etc. If is not needed but simplifies life particularly if you want to also have some debug logging / tracing output going etc. etc. and not interfere with the quasi real time parts so easily.


You can use Arduino or MBED I suppose though I suspect there are already many free projects in those ecosystems to do this very detection thing.

Google HAM TNC.
This is used for hamradio APRS and packet radio.

Thanks very much, evb149, for the extended response.  You gave me a lot to think about.  I guess at some point it becomes simpler to just buy the Caller ID chip and the crystal and be done with it.  I've looked for relevant Arduino projects, and that appears to be what they all do.  But I think the first step is to use Audacity to record a packet and see what the phase transitions actually look like.  I already have the interface circuit which I built back in the day to record phone calls.  Maybe that will reveal some really simple way to detect the specific calling number.

I did find this on Github:


It's written for the Atmega328P, so an Arduino Uno or Nano should work.  It looks awfully complicated, but I'll study it to see if I can figure out what's going on.

As mentioned, packet radio uses Bell 202 FSK.  And there are open projects online.  Look for "PIC TNC", "PIC16F628  TNC" or similar.  I've done it, it isn't difficult.  A website by Mike something (Berg?) has several examples.  I even remember helping him test one.


[0] Message Index

[#] Next page

There was an error while thanking
Go to full version