Hi,

Happy that i found this forum, it seems like a good gathering of knowledgeable people.

I also fall into the category of persons who recently discovered SDR. I have been a radio amateur since i was a kid, but havent been much active. but it always interested me what was going on on the digital world, but gathering data and actually analyzing it seemed too far out of reach...until the SDR came along. It have revived my interrest in radios and signalling, and i want to get into the stuff again. I have been reading and reading, and have come so far, but im missing something, that i hope someone will be able to help me with, so I can understand and write a program in C# for decoding of the signal.

 So how far have i come?

I have sampled a nice DQPSK signal with a sample rate of 1.92Mhz.

I have made a set of raides cosine impulse responce coefficients, and used them in a FIR filter. the result is signal that seems free from noise, and plotting each sample in a constellation chart, i can see the it move around the plane, to different position, however there are no nice pattern so the movements. I was king of hoping i would be able to make out the decition "point" as the line should idea move through these points. the signal is kind of distorted, and i have a hard time figuring out where in the process i go wrong, it could be filter parameters, sample rates, or another factor I have not thought of.

Im not using any tools for this, as i can not afford MathLab or the like. Im writing and visualizing the signal in C# without helper libraries... I want to learn.

Later I will be able to post some pictures of the visual parts of the program, so the signals can be assessed.

The Raised Cosine function.

The After and before result of the signal.

The constellation plot... there are no real pattern, its all over the place, any help much appriciated.Best Regards

Kim Mortensen

You're on the right track, and being able to see the constellation points by following the signal trace is possible but tedious.   The phase of the constellation points will have a random offset from the coordinate axes since you have not done any synchronization yet.

You're also correct that in general the constellations for QPSK and DQPSK are the same, so until you are able to get some form of synchronization or detection going there isn't a notable difference between them.

As mentioned, the pulse-shaping filter that you're using in the demodulator needs to match whatever was used in the modulator or the constellation points will be distorted, i.e., they won't be points, they'll be blobs or squares or all sorts of odd distortions depending on the mismatch.  Even "raised-cosine" isn't a sufficient match, as there are an infinite number of those, usually expressed in percent of excess bandwidth, and if the percent of EBW doesn't match, the constellation points will be distorted. If you don't know what pulse-shaping filter was used in the modulator, you may have a guessing game going on for a while or will just have to deal with a distorted signal.

You haven't said what the symbol rate of your signal is, but getting the best symbol sample for symbol clock synchronization may involved interpolating between sample points.  In any case, a symbol clock recovery phase-locked loop is the usual way to recover timing on a continuous signal, and usually a polyphase filter or a Farrow filter or something similar is used to recover the symbol instants from the sample train.   If the signal isn't continuous, and is bursty instead, it will likely have a preamble that can be used to estimate symbol phase, and also carrier phase and frequency offset.

People spend careers doing this stuff and there are tons of nuances and oddball tricks and differences depending on a wide variety of things.  There are a few good texts that deal with signal synchronization and PSK is usually the primary example case that is used.   So getting a decent text might help you with next steps.

Once you get symbol sample timing sorted out, then you get to sort out frequency offset and carrier phase.   Then you can figure out how to detect the DQPSK data.  ;)

Is there some more analysis i can do on the raw sample to get more information that can be used.

I am very sure that im sampled TETRA. Which is DQPSK. According to spec. It used a raised cosine filter with roll off at 0.35. Thats in the ETSI spec. The symbol rate is 18k, so the bit rate is 36k.

When i make the raised cosine parameters, i can choose roll off which is 0.35, and amplitude probably doesnt matter here, but what about tabs. If i choose 255 tabs the raised cosine is wider than the spectrum and the full roll off is not visible. 

Not 100% sure what i should write for symbol rate. 36k og 18k. 

I think i should put some efgort in analyzing my upstream data before i waste a lot of time sorting out downstream problems caused by upstream contamination.

It sounds like the symbol rate is 18kHz, and the raw (undecoded) bit rate is 36kHz. 

The raised cosine filter needs to be matched to the symbol rate.  The idea is that the zero crossings of the sidelobes in the output of the receiver matched filter happen exactly at the symbol centers of the adjacent symbols, so that energy from adjacent symbols do not interfere with the symbol being demodulated.

Ok. And can i map tabs to samples.

So if i place the raised cosine over the signal. Centre of cosin at center of a peak in the signal. The side lobes zero crossing should kill the side signals by be directly on top of them.

Then it should be possible to se how it matches directly in audacity... hmmm.

I have work to do... 

I spend a lot of hours last night working with the filters, and came to reduce the tabs, and the tab count i used distorted the signal. 255 is too much, i used 5-15, then the signal was still recogniseable.

But again i think i need to look at the signal for starters. Just purely inspecting the signal both prior and after the filtering, the signal is riding on a low frequency wave, and some times jumps to a offset from 0 - and thats already from the reciever. so i need to figure out if there is anything i can do to improve the quality of the recieved signal - A sine top of the signal should have the same value (approx) throughout the signal, otherwise i can undestand the constellation wil go haywire... /-:

The front end of demod requires care with symbol timing,carrier tracking and match filtering apart from having sampled proper signal with good snr. The number of matched filter taps is irrelevant. The sine wave(carrier) must be removed otherwise even the best recovered symbols will rotate in circles instead of fixed constellation points

Welcome Kim, sounds like you are jumping right in with both feet. It is fortunate these days that there are a lot of free tools from Octave (a MATLAB equivalent) to Gnuradio.

DQOSK is a bit harder than QPSK to decode (there is a good summary here: https://www.allaboutcircuits.com/textbook/radio-fr...) and your constellation should be sampled at the symbol rate for the data (that gives you the nice points in a cloud as opposed to the lines going everywhere). There is a whole sub-genre of interesting stuff around recovering the clock timing from the digital stream in a QPSK (or DQPSK) system.

If you know the symbol rate for your signal try plotting your constellation with samples taken at that rate, and then move the relative start time of the sampling ahead or back one sample time, in small increments, to see if you can sync up with the symbols in the signal.

Hi,

Thanks for responding. The syncronisation is a whole big topic i will be looking after i master this part. But after i Filter the signal properly, I assume I should be able to plot I and Q on a x/y chart, and move one sample at a time and see the dot move around in the chart, and hit the decition points in the plot. However i can see that the plot is fooling around all over the place, there are no sane direction to the move, so something must be off already at this stage.

I must admit that I have just done some attempts to work with the GNU Radio, and thought i could produce a wav file with a clean and crisp DQPSK information in it, then i could probably stand a better chance at rootcausing this. the wav file is an actual sample file from a SDR, so I dont know the signal quality.
But Im not familiar with this program enough to piece such a program together and make a file.

I completely feel your pain! When I started I was in the same spot where I didn't know if the signal was correct, the software decoding it was correct, or the circuit was correct! So many unknowns makes untangling what works and what doesn't really difficult. My solution was to buy a vector signal generator that had all of the modulations built in (an Aniritsu MG-3700) so that I could start with "known good" waveforms and pipe those into my SDR.

That isn't a practical solution if you don't have a source or access to a VSG however, you do have access to Mathworks MATLAB if only for 30 days. You can download a fully functional version of the software on a 30 day demo license, have it generate the waveform data using the DQPSK Baseband module, and then you can feed that into your software. I also took an intro to DSP class at the local community college for $45 and that gave me access to the student version of MATLAB for the year.

That said, and assuming you are looking at the baseband signal, take your symbol rate, and plot your constellation. Let's say your symbol rate is 1k sym/sec, and you have your 1.92Msps. That would put a symbol every 1,920 samples. So plot phase/amplitude for each I/Q pair every 1920 samples. Start at an offset of 0 samples, and then move the initial offset by 10 samples until you have moved one half symbol time (so about 95 steps). If your samples are landing in the "right" place in the constellation for any of these tests then I'd agree your software isn't computing the phase and amplitude correctly or there is an interfering signal.

Always best though to start with a signal you know is correct.

That is funny, because that was exactly what I was doing prior to the last reply. 

I have the I and Q in seperate arrays, so when plotting the constellation i could offset the whole array pointer. So for each offset value, I did the plot to se if anything would look somewhat like what i was aiming at. but no..

Question, I read also that the Q is phase shifted 90 degrees with respect to I (or is sampled 90Deg efter Q). so shouldent i phase shift 90 degrees before i can use Q together with I to form the plot?

To repeat my work flow:

I record 2Mhz worth of signal from my SDR.
Feed this into my Raised Cosine filter
Plot to screen.

I feel im missing something. Others do decimation etc, but i think its just to optimize the process, for me more samples must mean better result at the output, so i dont want to reduce anything as long as its not good enough as it is.

When I investigated the signal, i did a low pass filtering of the signal in audacity, and i remember that the plot looked more correct (there was a distinct hole in the middle, no paths were crossing 0,0), so was assuming the raised cosine would do a much better job. I applied the low pass filtering just so i could get a cleaner look at the signal.

Your assistance is much appriciated.
Best Regards

Kim Mortensen

Hi

the widely spread rumor that Q is I phase-shifted by 90° is a dangerous one. It is true if you look at a continous harmonic oscillation - this can be described as a rotating vector in the IQ plane and then the Q oscillation is the I oscillation phase shifted by 90 degrees. But in this case the Q part does not carry any information - it can completely be reconstructed by looking at the I part.

In modulation, however, I and Q are two orthogonal ways to store information. The relation of I and Q in the baseband signal tell you aboput the current phase-shift in the high frequency signal. I and Q TOGETHER form your DQPSK signal - so if you sample your signal as ChuckMcM said, you have to sample both I and Q and plot the result in the IQ plane - for good timing, the results should be on a circle.

DQPSK differs from QPSK like this: Information is NOT coded directly in the I and Q part of the symbol, but in the DIFFERENCE of the I and Q part of the current symbol to the last symbol. This way you can cope with small sampling frequency offsets without perfect synchronization at the cost of twice the noise (the noise of two symbols is in one symbvol decision).

Hi,

The differnece between DQPSK and QPSK should not be vissible to me at this point, as demodulation would be the same. the Differential part will be apparent later when im able to decipher the bits.

But, I take that you agree that my approach is correct, and that i should be able to map the I and Q directly on the constellation plane, once the signal have been filtered through a RRC/FIR Filter.

What about filtering, there are some complex filters out there, im using a standard FIR filter with RRC coefficients and send "I" array through the filter, then the "Q" array to produce something i would hope would be able to plot - Or is complec filters a different story?

Best Regards
Kim Mortensen

"The differnece between DQPSK and QPSK should not be vissible to me at this point" - That depends on the quality of your DQPSK signal and on the exactness of your timing recovery. With an imperfect timing recovery you will not see separate points in the IQ plane, but a circle or something more exotic.

Also: only the final symbol samples (not the 1.9MHz you have, but the downsampled version that has only one sample per symbol) should be on a circle in the IQ plane. Depending on the symbol shape ("basic waveform"), the IQ signal can have an amplitude unequal to one (leave the circle) in between those final symbol samples.

Also if you choose the wrong input filter, you can cause inter symbol interference (ISI) which can cause the signal to leave the circle. Your filtering METHOD seems fine to me, the coice of the filter KERNEL may (or may not) be wrong. Generally for SNR maximation you should choose a matched filter (the same filter that has been used to generate the transmission signal from an impulse train).

Nice info you are giving me...

Im using the raised consine, that should be perfect for eliminating ISI. 

When you say Filter Kernal, is that how i calculated the filter parameters? IF-- my sample is DQPSK, i was sampling a DQPSK that was filtered with a raised cosine and roll off of 0.35, that is in the specs for Tetra - So hope im correct on that part.

The Middle part worries me.. "final symbol sample".. There is so much new info in that section you have to explain to me. 

I have not downsampled anything, and im drawing everything. Now im slightly confused. So two symbols make two bits, as the state of the last symbol + first make up one bit set (two bits).

But as the constallation can only point at one place. which is made up of one I and one Q, this point must come from one cycle of the signal.

One cycle of the signal i about 400 samples.

How can i downsample to one sample pr symbol. Im my head the signal would become straight lines between sample spots?

When you are filtering the input signal with your raised cosine that was also used when generating this sequence, this is equal to a corellation of the signal with the raised cosine (since the raised cosine is symmetrical and real, corellation and convolution are equal). Corellation is another way of saying you are looking at how similar your input stream is with the raised cosine at every sampling instant. It is most similar with a raised cosine every 400 samples because that is the symbol interval as you pointed out.

Yet another way of putting it is this: By filtering the input signal with the matched filter, you have collected the energy of the entire symbol length into the center sampling point.

After corellation there is no point in keeping 400 samples per symbol, you just need one. This one sample is a pair of I and Q values. Together they form a complex number a*exp(j*phi). Since this is PSK, information is only stored in phi. QPSK means that there are four possible phis and DQPSK means that the information is not in phi directly, but in the difference of phi to the last measured phi.

To get your bits, you could decode:

phi(k) - phi(k-1) = 

0° : Bits 00
90° : Bits 01
180° : Bits 10
270° : Bits 11

That's if the bits are not grey-coded, but that is another story you can google later...

Ok. It makes very much sence.. if the signal fits the raised cosine form its energy wil be preserved and that is the waveform at that sample point that is the value. 

phi(k) - phi(k-1) =..

What i k. I assume i have to involve Q and I in that equation.

Very gratefull for your assistance...

Best regards

Kim mortensen

k is the discrete time index or symbol index. k is the current symbol, k-1 the last one and so on.

phi and I and Q are related by the formula:

I + j*Q = a * exp(j*phi)

so I and Q are some form of Kartesian coordinates and phi is the argument of the polar form

Ok, 

Just realized that there are multible threads in here, and i dont know if everyone is getting all the messages, or it only to whom i reply.

But thanks, ill have a look at it.

But.... I spend hours to midnight looking at this FIR filter, and found that i could severily distort the signal if i put too many tabs on the filter. to i tried with a minimum (5) and the resulting signal looked much like the raw signal, but without the noise.. however i notised something else. The DC part of the signal is bouncing up and down - so, as i take the signal raw valued and try to plot his into a constellationplane, surely this will not work.

I dont know if its before or after i filter, something has to be done to the signal to normalize it/stabalize it around 0, thats for starters, otherwise i can not trust the values at all.