AFSK signal demodulation with EZRadioPro

by <a href=""><font color="#000000"><font size="2">Hero Employee</font></font> </a> zopapp on ‎09-08-2016 06:26 AM


Although there is no explicit AFSK demodulation support on our Si446x product portfolio, with a carefully chosen receive configuration and a piece of decoding SW running on the host MCU it may be pulled off.


AFSK modulation is typically two audio tones 2FSK modulated onto a carrier. One tone represents marking the other spacing.


Form the EZRadioPro receiver’s perspective an AFSK signal is an FSK signal whose DR changes with the two audio tones’ frequency.  As an example take the Bell 202 modulation format where one audio frequency is 1200 Hz while the other is 2200 Hz. From the receiver’s perspective these signals translate to 2400 bps and 4400 bps DR streams, respectively. The reason the DR is twice as much as the audio tone frequency is that a full cycle on the audio tone translates to two bits: a 1 and 0 (or vice versa).


There are a couple of limitations on EZRadiPro that make the demodulation of such a signal troublesome. (1) EZRadioPro’s receive architecture is designed to operate on a single data rate throughout the whole radio packet and (2) there are no analog signals available from anywhere within the demodulation process, only digital signals come out.


The solution to overcome above issues is:


  • Configure the receive DR to the least common multiple (LCM) of the two different DRs corresponding to the two different tones. Staying at the Bell 202 modulation format this will be the LCM of 2400bps and 4400 bps which is 26400 bps.


  • Observe the received digital signal by placing RX_DATA to one of the GPIOs where the audio tones will appear as square waves as opposed to sine waves. Run an algorithm on your host MCU that decodes the data stream.

The limitations (and their mitigation) of above solution are:


  • If the LCM of the two DRs are relatively high compared to the higher frequency tone the Rx BW may become too wide for achieving good sensitivity. If this is the case you may want to try RX_RAW_DATA instead of RX_DATA on the GPIO as it has a roughly 10x higher sample rate than RX_DATA. The downside of this method is a slight sensitivity degradation, but the BW reduction it allows for will most likely make up for this. More on RX_RAW_DATA reception you can read in this article:


  • As the digital output will be oversampled compared to the modulating tones (both with RX_DATA and RX_RAW_DATA) it may as well happen that you see glitches on the output stream especially and low SNR scenarios. You may want to implement deglitching in your receive algorithm to prevent sensitivity degradation. Some hint on this you can read here:


The ultimate question after such a receive algorithm implementation is sensitivity. You will have to verify this for yourself on your own implementation.


From WDS start off from a direct Rx mode project with above considerations and you can start measuring straight away. As a 1st check hook up your GPIOs with both RX_DATA and RX_RAW_DATA on a scope (that is triggered off of the beginning of the AFSK packet in air) and observe (eyeball) the signal quality. Change the input power level and check where the signals fall apart, this quick experiment will give you a 1st feeling on sensitivity performance.