I am trying to convert some raw unscaled I/Q sample data back to the original input data. I've been reading a lot of different posts and articles in I/Q demodulation and the focus is almost solely on the process of combining the two separate I and Q pieces on the transmitter side into one and then separating them again at the receiver side. I haven't found any helpful documentation on how to do the final piece of this.

A lot of programs exist that output data directly in an I/Q raw format. In my case, I have 16-bit signed integers in the format of $i[0], q[0], i[1], q[1], ...$ . Presumably, the signal originated from a binary output on the transmitter end. After the first demodulation part, the separation of the I and Q values on the receiver end, what final steps are needed to complete the cycle back to that input binary value?

I realize this is most likely extremely simple, especially after all of the math that had to be done to get the two waveforms back from the single RF one. Nevertheless, I have yet to find a decent explanation of this final process.

  • $\begingroup$ is the I/Q data at baseband or is it modulated up to some intermediate frequency, $\omega_0$? if it's at baseband, then $i[n]$ is your input $x[n]$ and $q[n]$ is the Hilbert transform $\hat{x}[n]$. $\endgroup$ Nov 20, 2016 at 4:40
  • $\begingroup$ so, i think this is the case: $$ i[n] + j\,q[n] = e^{j \omega_0 n} (x[n] + j \, \hat{x}[n]) $$ so to get $x[n]$ you need to first multiply the complex I/Q data by $e^{-j \omega_0 n}$ and then the real part has your original data and the imaginary part is the Hilbert transform of the original data. but you need to know what the IF frequency, $\omega_0$ is. $\endgroup$ Nov 20, 2016 at 4:42
  • $\begingroup$ OK, that makes sense. Just a little more background, the signals are from some unknown IoT devices - so a thermostat. All of the data is recorded at the 2.4 GHz or 908MHz frequencies, and in their own respective files. I don't think anything is changed from that frequency. What would I have to use for $\omega _0$ then? $\endgroup$ Nov 20, 2016 at 4:59
  • $\begingroup$ how many I/Q samples per second are you getting? $\endgroup$ Nov 20, 2016 at 5:28
  • $\begingroup$ 16000000 is the sample rate $\endgroup$ Nov 20, 2016 at 13:57

2 Answers 2


In addition to hotpaw2's answer:

Presumably, the signal originated from a binary output on the transmitter end.

I'd say that is most probably wrong.

The typical digital transceiver based on complex baseband looks like this:

Binary data -(0/1)->
 Symbol mapper =(complex-valued symbols)=>
  pulse shaper =(complex-valued, "smooth" digital baseband signal)=>
   synchronous dual-DAC =(I & Q signals)=>
    filters =>
     I: mix with cos(2 pi f_RF) --\
                                   subtract--> filters -(RF signal)-> Antenna
     Q: mix with sin(2 pi f_RF) --/

On the transmitter end, you'll see some RF signal – and that is always analog, never binary.

I haven't found any helpful documentation on how to do the final piece of this.

You cannot have read very much, because every textbook I know introduces both, the direct conversion transmitter and the direct conversion receiver (note: these go by different names, also zero-if or quadrature receivers).

Since you're already getting complex samples, we may assume you're working with a receiver that works like this

Antenna -(RF signal)->
 band-pass filter ->
  multiply with cos(2 pi f_RF) -> low-pass filter -(I signal) ->
  multiply with sin(2 pi f_RF) -> low-pass filter -(Q signal) ->
   =(IQ signal pair)=> synchronous dual ADC =(digital complex baseband signal)=> 
    PC software

So, the analog part has been done for you.

Now, it's up to your PC software to do (not necessarily in this order, but all of these are typically necessary):

  • estimation/correction of the difference in f_RF (no two physical oscillators are perfectly identical)
  • estimation/correction of the difference in phase (i.e. the cos() of receiver and transmitter didn't "start" at the same time, and the signal was "in the air" for some non-zero amount of time due to limited speed of light)
  • reversing the pulse shaping of the transmitter
  • estimation/correction of the symbol rate (ie. how many digital samples is a single symbol long?)
  • guessing which symbols got sent by the transmitter
  • converting these symbols back to the bits they stood for

In reality, there's a few additional steps (channel coding, hardware imperfection corrections, equalizing, …).

Anyway, the order of these steps, and how exactly they're done depends completely on what kind of modulation scheme/waveform the transmitter produces; notice how you can't use a 3G mobile phone to get the bits your cordless landline phone sends, or use your WiFi card to receive digital TV, or use your CCTV receiver to receive satellite telephony.

Even for receivers for the same kind of signal, there's a lot of choices a SDR engineer makes – the type of timing recovery mechanism, for example, acceptable computational complexity when converting samples to symbols vs error rate when doing that, and a lot, lot more.


I realize this is most likely extremely simple,

Nope. It's the hardest problem, and pretty much the main problem, of digital communications technology, the science backing one of the biggest technical sectors of modern days. Building good receivers is hard, in general. There's a lot of tools to help you deal with that. But: even these tools require solid understanding of the theory behind digital communications before you can go out and write your own SDR receiver.

But don't despair:

There's a lot of "simple" systems that are relatively easy to receive, and a tutorial alone might get you pretty far. It's an exciting field of technology, and I wouldn't have spent a solid part of my life on that if it wasn't fun!

I've witnessed literally dozens of times how being able to actually get binary data out of something that is just a digital representation of an analog signal makes people a) happy and b) makes the understanding of the theory take giant leaps.

I'll encourage you to experiment with digital signals!

Based on your assumption, the transmitted signal was binary, I'll go ahead and take an audacious guess at what your profession is: Is it possible you are a Computer Science student?

I can see this signal world might be a bit daunting if you're coming from a background where you can safely assume that for


input==output, but that's simply not the case for digital communications.

In any case, no matter what you are, I'd recommend reading a bit on signal theory. The GNU Radio wiki has a page on recommended literature. Get one of the basic DSP books, and one of the basic Digital Comm books; some of them are freely available as PDF.

Parallely, take a 5-minute read of the introduction chapter of the GNU Radio guided Tutorials. These tutorials are meant to slowly, and carefully, and sequentially (don't skip a chapter) allow you to build a simple digital receiver. What they do is teach a tool, but they need to rely on some signal theoretic background, so they might be not that perfectly clear if you lack that.

  • $\begingroup$ Thanks Marcus for this great, detailed feedback. $\endgroup$ Jan 17, 2020 at 17:55

One common situation is where the IQ data to be transmitted is band-limited to below some small fraction of the RF carrier frequency. Some SDR receiver front ends (RTL-SDR USB dongles, etc.) might multiply the RF input by a complex phasor at or near the carrier frequency, and then low-pass filter and downsample this intermediate result to produce a received IQ data stream, from which the original bandlimited binary data might be recovered (with some probability of accuracy depending on things such as the channel S/N, frequency offset and phase synchronization errors, etc.) The exact method of binary data recovery depends on the exact modulation scheme (BPSK, GMSK/FSK, ODFM, etc.)

  • $\begingroup$ So, since this is dealing with a variety of IoT devices all potentially communicating via the same carrier frequency, each of the modulation schemes might be different. The overall I/Q values file is not limited to a specific device and, as such, each of the individual devices might go about doing the whole process differently - even though they all conform to 802.15.4? $\endgroup$ Nov 20, 2016 at 14:18
  • $\begingroup$ @DannyFlack yes. There's more than one way to do a certain thing. See my answer. $\endgroup$ Nov 20, 2016 at 14:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.