SignalProcessing: Difference between revisions

From GNU Radio
Jump to navigation Jump to search
(Imported from Redmine)
 
 
Line 63: Line 63:
==== How NOT to implement a Numerically Controlled Oscillator. ====
==== How NOT to implement a Numerically Controlled Oscillator. ====


While implementing an I/Q demodulator using the basic equations I=input*cos(f*t) and Q=input*sin(f*t), my first implementation was a very naive time increment by 1/fs (fs: sampling frequency) at each time step. This works for about 30 seconds, and then the output suddenly starts oscillating due to a reference signal erroneous frequency. This issue reminds me of the [http://sydney.edu.au/engineering/it/~alum/patriot_bug.html Patriot Missile time programming issue]. The right way is, by looking at the [[redmine/projects/gnuradio/repository/entry/gnuradio-core/src/lib/general/gr_nco.h|implementation of the NCO in Gnuradio]], to increment the phase until it reaches 2*pi, and keep the phase in the [0:2pi] interval by subtracting an integer number of 2*pi when the upper bound is met. As an illustration of this issue:
While implementing an I/Q demodulator using the basic equations I=input*cos(f*t) and Q=input*sin(f*t), my first implementation was a very naive time increment by 1/fs (fs: sampling frequency) at each time step. This works for about 30 seconds, and then the output suddenly starts oscillating due to a reference signal erroneous frequency. This issue reminds me of the [http://sydney.edu.au/engineering/it/~alum/patriot_bug.html Patriot Missile time programming issue]. The right way is to increment the phase until it reaches 2*pi, and keep the phase in the [0:2pi] interval by subtracting an integer number of 2*pi when the upper bound is met. As an illustration of this issue:


[[File:nco.png|]]
[[File:nco.png|nco.png]]


used with this counter processing block which provides the IQ function http://gnuradio.org/redmine/attachments/438/gr-counters.tar.gz, is instructive. First of all as it is provided with the "right" way of generating the reference signal using the d_nco.sincos function. If you run the example with the constant input, the sound card will generate a constant tone, and if you feed the IQ demodulator with a 440 Hz sine wave you get constant I/Q outputs. Now if one uncomments in lib/counters_iq.cc lines 83 and 84 in which time is incremented (_time+=dt) and the NCO is generated as cos(f*_time); recompile (make install) and run the example again, you will first hear the tone change within the first 5 seconds, then wait for another 35 seconds and the output frequency will jump to a completely different value. Obviously a rounding error and erroneous representation of _time as a floating point number occur, but I have not yet had the time to fully analyze the details (whether the error comes from the representation of _time or the calculation of trigonometric functions on large arguments).
used with this counter processing block which provides the IQ function http://gnuradio.org/redmine/attachments/438/gr-counters.tar.gz, is instructive. First of all as it is provided with the "right" way of generating the reference signal using the d_nco.sincos function. If you run the example with the constant input, the sound card will generate a constant tone, and if you feed the IQ demodulator with a 440 Hz sine wave you get constant I/Q outputs. Now if one uncomments in lib/counters_iq.cc lines 83 and 84 in which time is incremented (_time+=dt) and the NCO is generated as cos(f*_time); recompile (make install) and run the example again, you will first hear the tone change within the first 5 seconds, then wait for another 35 seconds and the output frequency will jump to a completely different value. Obviously a rounding error and erroneous representation of _time as a floating point number occur, but I have not yet had the time to fully analyze the details (whether the error comes from the representation of _time or the calculation of trigonometric functions on large arguments).

Latest revision as of 06:55, 15 March 2017

Signal Processing Discussion Forum

Please use this space to discuss and explain your signal processing ideas/questions/issues. Make appropriate subpages and links here.

Modulation

Specific types of modulations - analog, digital and diversity in space, time and frequency are all welcome!

Question: I was trying to understand the relation between samples per second,modulation schemes and bit rate when I found this article. I have a doubt as in sub problem 4 of problem 1 he calculates the bit rate of a 8 psk signal as baud rate* log2(8). Then in problem 2 of part4:digital he says when an analog voice signal is sampled at twice the bandwidth (Nyquist rate) the data rate is doubled. Does that mean when you sample a signal you increase the data rate by atleast 2 times. Have I got it right. Can you please explain?

FSK Modulation Parameters

Digital

(Derived from the email by Dan CaJacob [1])

The sensitivity and gain parameters for the FM Mod and Quad. Demod blocks are reciprocals of one another. To control deviation, in these parameters, you can just calculate Modulation Index. The Modulation Index can be thought of as having units of Radians.

The parameters become:

sensitivity = (pi * modulation_index) / samples_per_symbol

and on the receive side:

gain = samples_per_symbol / (pi * modulation_index)

Modulation index itself can be set explicitly or derived from a desired deviation and baud rate:

modulation_index = deviation / (baud_rate / 2)

So, for a Minimum Modulation Index of 0.5, as is used in GMSK, the sensitivity reduces to:

sensitivity = (pi / 2) / samples_per_symbol

As it is in the example nbfm_tx.py. This is slightly different because it is meant for audio and not data transmission.

Audio

For (de)modulating audio, the equations become:

sensitivity = (2 * pi * max_deviation) / samp_rate

for modulating audio (like voice).

gain = samp_rate / (2 * pi * max_deviation)

for receiving audio.

Filtering

IIR, FIR, adaptive, and even analog - all the techniques.

Synchronization

Carrier, symbol and timing recovery.

Forward Error Correction

Including data integrity! Quite an expansive topic.

Hardware and Physics

The impacts of the physical world on software defined radio. Cascade analysis, near-far problem, and channel models.

Local Oscillator Jitter Analysis

Analysis of the influence of the jitter of the local oscillator and ADC clocking circuit on phase measurement resolution. Resolution budget including sample & hold current leakage, ADC clocking circuit with respect to signal frequency (most significant in baseband measurements using fast ADC) and sampling resolution (bits).

How NOT to implement a Numerically Controlled Oscillator.

While implementing an I/Q demodulator using the basic equations I=input*cos(f*t) and Q=input*sin(f*t), my first implementation was a very naive time increment by 1/fs (fs: sampling frequency) at each time step. This works for about 30 seconds, and then the output suddenly starts oscillating due to a reference signal erroneous frequency. This issue reminds me of the Patriot Missile time programming issue. The right way is to increment the phase until it reaches 2*pi, and keep the phase in the [0:2pi] interval by subtracting an integer number of 2*pi when the upper bound is met. As an illustration of this issue:

nco.png

used with this counter processing block which provides the IQ function http://gnuradio.org/redmine/attachments/438/gr-counters.tar.gz, is instructive. First of all as it is provided with the "right" way of generating the reference signal using the d_nco.sincos function. If you run the example with the constant input, the sound card will generate a constant tone, and if you feed the IQ demodulator with a 440 Hz sine wave you get constant I/Q outputs. Now if one uncomments in lib/counters_iq.cc lines 83 and 84 in which time is incremented (_time+=dt) and the NCO is generated as cos(f*_time); recompile (make install) and run the example again, you will first hear the tone change within the first 5 seconds, then wait for another 35 seconds and the output frequency will jump to a completely different value. Obviously a rounding error and erroneous representation of _time as a floating point number occur, but I have not yet had the time to fully analyze the details (whether the error comes from the representation of _time or the calculation of trigonometric functions on large arguments).

Signal Identification and Classification

Figuring out what is out there, and what it means to you. One mans noise is another mans signal. So which is it?

Standards

Dissecting and understanding specific industry standards such as 802.11, GSM, 802.15.4, etc.