Hi,
Off-topic: not sure about the terminology in the GNURadio community, just be aware that for most electrical engineers “sps” means samples
per second and not samples per symbol. I’d rather not use the acronym at all in a block diagram to improve readability.
Cheers,
Jonas
From: Discuss-gnuradio [mailto:discuss-gnuradio-bounces+jonas.manthey=address@hidden]
On Behalf Of Kyeong Su Shin
Sent: Montag, 15. Juli 2019 19:45
To: address@hidden; address@hidden
Subject: Re: [Discuss-gnuradio] Delay determination between Tx and Rx signal for limesdr mini with help of gnu radio.
Marcus already gave you good answers, but here's a few additional notes that I would like to make:
-Some GNU Radio hardware blocks (especially SDR sources and sinks) do not complain even when they are misconfigured. You will have to check actual specifications of the hardware
that you are using before configuring those blocks (it probably won't set your boards on fire, but you may get unexpected behaviors from them). I do not know the specifications of LimeSDR, though.
-In real-world, you can NEVER synchronize a receiver and a transmitter by simply adding delay blocks. That 'delay block' trick only works for simulation purposes. Since I think
your LimeSDR is transmitting to itself, maybe you can find a trick to make things a bit simpler, but what you really should do is implementing a frame-level synchronization. I do not know which GNU Radio blocks are built for this purpose, since I use my own
custom blocks for this. It is not that difficult to implement, if you have some ideas about the real-world transmitters, though.
-As Marcus mentioned, your data rate is simply the sampling rate (in the source block) divided by SPS (smaples per symbol) multiplied by bits per a symbol (2 for QPSK). Clearly,
it does not tell you anything about the supported sampling rates of the board.
-Please make sure that you are not violating your local laws if you are actually transmitting radio signals using your SDRs (you apparently are, unless you are using a loopback
cable with attenuators). You may end up annoying your local RF regulation bodies.
As Marcus suggested, you may want to seat together with someone who has knowledge about the real-world digital RF transceivers and have some discussions about your design.
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
> > >
> > >
>
>
|