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
> > >
> > >
>
>