discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] TETRA demodulator advices


From: Timothée COCAULT
Subject: Re: [Discuss-gnuradio] TETRA demodulator advices
Date: Sun, 06 Dec 2015 20:47:43 +0100

Hi Tom.

First, thank you for your answer.

Le mar. 1 déc. 2015 à 16:33, Tom Rondeau <address@hidden> a écrit :

This is a very open-ended question. It'd take a lot of work for someone to go through your receiver and make any suggestions. Your best bet is to ask very pointed questions about a behavior or block.

I know that it's a lot of work, I just wanted to know if, at a first glance, something looked out of place.
I'm sometimes lost in GNU radio when I have to choose a block among several that seem to do the same thing.

 
Bonus questions :

* using the FLL band edge after the low-pass seems odd because, even if it can recover frequency offset, some of the bandwidth will be lost.
Should I use the error ouput of the FLL to change the freq used by the Freq XLating FIR FIlter ? If yes, is there an example of this somewhere ?


That's more like it! This is a question we can actually answer.

Yes, you have the issue that you described. You could think to make a block that could pass a message the frequency translating filter that would adjust its center frequency, but you won't be able to do that very quickly. It would be a slow, very coarse frequency correction.

Instead, I would try to figure out the expected maximum frequency offset and make the LPF of the frequency translating filter block large enough to accommodate that. This LPF is a channel filter meant to reduce noise power from adjacent channels, so there is always a tradeoff between that and being able to lock on to your signal. The clock sync block performs the actual matched filtering, though, so you're not using this LPF to just isolate the signal exactly.

The main purpose of the FLL is to compensate the thermal offset of a crappy RTL-SDR device so it doesn't need to be really fast. 
I'll try to increase the cutoff frequency first, and see how it reacts with the adjacent channels.

 
* at first I wanted to use the Constellation receiver, but from what I understand the constellations in gnuradio work by first discretizing the signal, then doing the diff.
This does not work with PI/4 DQPSK because you need to first diff the complex samples, then discretize.
Is there any way I could cheat to create a PI/4 DQPSK constellation in gnuradio ?

I could see overloading the constellation object to have a child class with memory to handle this case.
 

I've looked into that but I'm afraid some blocks won't play well with the constellation class (for example, they expect a constellation to have 2**(bits) points, but PI/4 DQPSK uses 2 bits and has 8 points). 
I think I will stay with the flowgraph approach for now.

Best,
Timothée.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]