Re: [Discuss-gnuradio] Delay determination between Tx and Rx signal for limesdr mini with help of gnu radio.

[CEL]

Dear Atiqur,

the sampling rate is the product of symbol rate and samples per symbol
(quite intuitive, isn't it?).

Nyquist should be no problem here: you're the one producing that
signal, so it will inherently "fit". 

4sps? Are you sure? That's way too little. Many (most) channels
wouldn't even be coherent for a single symbol duration.

I think it'd be best if you tried to write a full system specification,
in tabular form. Start with:

1 Purpose of system
2 data rate
3 FEC used
4 modulation used
5 symbol rate 
6 pulse shape
7 analog bandwidth
8 samples per symbol
9 sample rate
10 potentially necessary rational resample

You'll notice that 1, 2, 3, 4 are the things you choose based on your
requirements, 6 and 7 are inherently linked, 5 is a result of 2&3&4,
and you need to pick 8, 9 and 10 together so that your system
technically is possible. If in doubt, start with a sampling rate in the
1MS/s region, I'm pretty sure that the limeSDR supports that.

This table is your guide when it comes to designing your system, using
*whatever* tool. As you notice, none of this is specific to GNU Radio –
it's just the bare minimum set of parameters you'd need to come up with
a digital transmitter.

Since it's the raw foundation of whatever you're doing: You're at
Hochschule Bremen, which probably means you have a good
adviser/supervisor (I only know one EE prof from there, and he's really
nice). Make the above table, take it to him and talk about it. As
someone advising a couple of students, that's exactly the kind of
discussions I'd want to have as early as possible.

Best regards,
Marcus

On Mon, 2019-07-15 at 18:25 +0200, Md. Atiqur Rahman wrote:
> Dear Marcus,
> 
> Thank you so much for the nice explanation about CMA and polyphase block. I 
> rearranged it as it shows in the attached file.
> 
> Moreover, I thought my sample rate was ok as less than 64K it was not working 
> (maybe for the Nyquist rate is not satisfied). Maybe it is a silly question 
> but I must need to ask you as I am using 4sps but how I will find my data 
> rate? (I do not know because I never calculate my data rate from sps before: 
> as in here in gnu radio. Therefore, I put 64k sample rate from the tutorial 
> of PSK modulation scheme ) If I have data rate then I could easily find out 
> my sampling rate for this particular SDR. I know it is silly please don't 
> mind. I am just a beginner of DSP and SDR communication systems.
> 
> Sincerely,
> Atiqur
> 
> On Mon, Jul 15, 2019 at 5:48 PM Müller, Marcus (CEL) <address@hidden> wrote:
> > Dear Atiqur,
> > 
> > my concerns are less of the GRC variant, but of the DSP variant:
> > 
> > * If your GRC doesn't complain about you using Throttle together with
> > the hardware blocks, that's a bug in the hardware blocks. Anyway, NEVER
> > use Throttle with hardware blocks. You incur the two-clock problem, and
> > will run into overflows/underruns. You can't see that with a GNU Radio-
> > internal visualization. More info under [1].
> > 
> > * Your sampling rate is laughably low for SDR applications, which is
> > why I presume that the LimeSDR doesn't support sampling rates that are
> > so low.
> > 
> > * No matter what you say, an equalizer and a timing/phase recovery is
> > something to be done on the *receive* side, not on the transmit side. 
> > 
> > Best regards,
> > Marcus
> > 
> > [1] 
> > https://wiki.gnuradio.org/index.php/FAQ#When_do_I_use_a_throttle_block.3F
> > On Mon, 2019-07-15 at 17:40 +0200, Md. Atiqur Rahman wrote:
> > > Dear  Marcus, 
> > > Thank you for your quick reply.
> > > 
> > > Actually, I am very much new in GRC. The GRC is running without giving me 
> > > any error though. If I use 32KS/s, it stopped working by saying python 
> > > stop working. Therefore, I am giving 64KS/s.
> > > 
> > > I am following the grc-tutorial, hence that modulation scheme contains 
> > > equalizer and timing recovery on the transmit side. Shouldn't I use it? 
> > > please correct me if I am wrong. 
> > > 
> > > Sincerely,
> > > Atiqur
> > > 
> > > On Mon, Jul 15, 2019 at 5:05 PM Müller, Marcus (CEL) <address@hidden> 
> > > wrote:
> > > > Oh, and why are you doing an equalizer and a timing recovery on the
> > > > *transmit* side!?
> > > > 
> > > > On Mon, 2019-07-15 at 15:04 +0000, Müller, Marcus (CEL) wrote:
> > > > > Also, without knowing, I'm almost certain that 64kS/s is not a 
> > > > > possible
> > > > > sampling rate for the device. You really might want to read the 
> > > > > console
> > > > > output very closely!
> > > > > On Mon, 2019-07-15 at 14:56 +0000, Müller, Marcus (CEL) wrote:
> > > > > > So, first of all: 
> > > > > > 
> > > > > > never use "Throttle" in a flow graph with hardware. 
> > > > > > In fact, GRC will *scream* at you that you shouldn't be doing that! 
> > > > > > 
> > > > > > Then: I can't claim to have any knowledge of the limeSDR driver, but
> > > > > > unless that driver specifically allows you to start the TX and RX
> > > > > > streaming at the exact same instance: That delay is not a 
> > > > > > deterministic
> > > > > > value.
> > > > > > 
> > > > > > Best regards,
> > > > > > Marcus
> > > > > > 
> > > > > > On Mon, 2019-07-15 at 16:46 +0200, Md. Atiqur Rahman wrote:
> > > > > > > Hello Guys, I am having trouble to find the proper delay point 
> > > > > > > between Rx and Tx signal while running the qpsk modulation scheme 
> > > > > > > on gnu radio to my Limesdr mini board. While I am running the 
> > > > > > > program through limesdr, I realize that it has a greater delay 
> > > > > > > between (as expected). However, until now I am unable to find the 
> > > > > > > proper amount of delay. I am changing the range of the delay from 
> > > > > > > gui range(int type) to find the delay which will give me the 
> > > > > > > synchronized Rx and Tx so that I could ensure that there is no 
> > > > > > > missing data at the receiver side. 
> > > > > > > 
> > > > > > > I attach the file here in this email. Hope anybody would like to 
> > > > > > > help. Thanks in advance.
> > > > > > > 
> > > > > > > Sincerely,
> > > > > > >  Atiqur 
> > > > > > > 
> > > > > > > _______________________________________________
> > > > > > > Discuss-gnuradio mailing list
> > > > > > > address@hidden
> > > > > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > > > > > 
> > > > > > _______________________________________________
> > > > > > Discuss-gnuradio mailing list
> > > > > > address@hidden
> > > > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > > > > 
> > > > > _______________________________________________
> > > > > Discuss-gnuradio mailing list
> > > > > address@hidden
> > > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > > 
> > > 
> 
>

smime.p7s
Description: S/MIME cryptographic signature