Re: [Discuss-gnuradio] CIC + halfband filter compensation

[Andy Walls]

> From: Geoffrey Mainland
> Date: Wed, 25 Apr 2018 16:39:11 -0400
> 
> I hope you will forgive a few naive signal processing questions :)
> 
> 1) What is the frequency response of the CIC and halfband filters in
> the
> USRP? This was addressed long ago on the mailing list
> (https://lists.gnu.org/archive/html/discuss-gnuradio/2007-05/msg00191
> .html),
> but the associated MATLAB script is no longer available now that the
> nabble archive is gone.

Attached are images generated from an Octave script, showing the
performance of the X310's CIC filter and 3 half-band filters,
filtering, decimating, and folding-in from the radio's 200 Msps down to
6.25 Msps.

The CIC filter is in blue.  It's droop hardly worth mentioning.

The Octave script is also attached.  It is far from generic.  It will
need significant modification if you have a different situation.


> 2) How do I design a filter to compensate appropriately?
>
> I know there are other methods for avoiding CIC droop, like
> oversampling, but I'd like to understand how to compensate with a
> filter
> as well.

As far as CIC compensation filters go:

http://lmgtfy.com/?q=cic+compensation+filter

:)

Seriously, there is plenty of reading material out there.

Regards,
Andy

> Thanks!
> Geoff
%
% (C) 2018 Andy Walls 
%

% The X310 DDC chain has 4 Integrator Stages  and 4 single delay Comb stages
% followed by a decimation stage.  We'll model that here, using the
% equations in https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/an/an455.pdf

M = 1; % differential delay
N = 4; % stages
R = 4; % decimation rate to go from 200 Msps down to 50 Msps
d = ones(1, R*M); % FIR filter coefficients before raising to N
  % Since it is like a cascade of N identical filters
[hd, wd] = freqz(d, [1], R*8*1024);
hd = hd .^ N;
hd = hd/hd(1);
wdturn = [wd(1:(R*8*1024/R))' wd((R*8*1024/R):-1:1)' ...
  wd(1:(R*8*1024/R))' wd((R*8*1024/R):-1:1)'] * 50/pi; % Fs = 200, fold into 0-50 multiple times

% The X310 DDC uses up to 3 x% Nyquist Half-band filters

% Coefficients from
% uhd/fpga-src/usrp3/top/x300/coregen_dsp/hb47.coe
% Generated with round((2^18-2)*halfgen_test(.21,12,1))
%  83% effective BW, 64dB to 85dB rolloff

a = [   -62, 0,194, 0,  -440, 0,   855, 0,  -1505, 0,  2478, 0, ...
  -3900, 0,   5990, 0, -9187, 0, 14632, 0, -26536, 0, 83009, ...
 131071, ...
  83009, 0, -26536, 0, 14632, 0, -9187, 0,   5990, 0, -3900, 0, ...
   2478, 0,  -1505, 0,   855, 0,  -440, 0,194, 0, -62];
b = a;

% Coefficients from
% uhd/fpga-src/usrp3/top/x300/coregen_dsp/hb63.coe
% Generated with round((2^18-2)*halfgen_test(.22,16,1))
%  88% effective BW, 64dB to 87dB rolloff
c = [ -35, 0, 95, 0, -195, 0, 352, 0, -582, 0, 907, 0, -1354, 0, 1953, 0, ...
  -2751, 0, 3813, 0, -5249, 0, 7264, 0, -10296, 0, 15494, 0, -27083, 0, ...
  83196, 131071, 83196, ...
  0, -27083, 0, 15494, 0, -10296, 0, 7264, 0, -5249, 0, 3813, 0, -2751, ...
  0, 1953, 0, -1354, 0, 907, 0, -582, 0, 352, 0, -195, 0, 95, 0, -35];

[ha,wa] = freqz(a, [1], 8*1024);
ha = ha/ha(1);
[hb,wb] = freqz(b, [1], 4*1024);
hb = hb/hb(1);
[hc,wc] = freqz(c, [1], 2*1024);
hc = hc/hc(1);

% Fold freq axis to show aliasing into final passband
% Scale to original 50 Msps Fs
waturn = [wa(1:(8*1024/2))' wa((8*1024/2):-1:1)'] * 25/pi; % Fs = 50, fold 25-50 onto 25-0
wbturn = [wb(1:(4*1024/2))' wb((4*1024/2):-1:1)'] * 12.5/pi; % Fs = 25, fold 12.5-25 onto 12.5-0
wcturn = [wc(1:(2*1024/2))' wc((2*1024/2):-1:1)'] * 6.25/pi; % Fs = 12.5, fold 6.25-12.5 onto 6.25-0

clf;
plot( ...
 wdturn, 20*log10(abs(hd)), ';CIC filter 200 Msps folded to 50 Msps;', ...
 waturn, 20*log10(abs(ha)), ';1st HB filter 50 Msps folded to 25 Msps;', ...
 wbturn, 20*log10(abs(hb)), ';2nd HB filter 25 Msps folded to 12.5 Msps;', ...
 wcturn, 20*log10(abs(hc)), ';3rd HB filter 12.5 Msps folded to 6.25 Msps;');
title('X310 DDC CIC & Default Halfband Filters Alias Folding Performance');
ylabel('Gain (dB)');
xlabel('Frequency (MHz)');
grid on;
hold off;

% Passband droop at the final fold
% At Fs/2 = 6.25 MHz
worst_pass = ...
   20*log10(abs(hd(R*8*1024/32))) ...
 + 20*log10(abs(ha(8*1024/8))) ...
 + 20*log10(abs(hb(4*1024/4))) ...
 + 20*log10(abs(hc(2*1024/2)))
ideal_pass = ...
   20*log10(abs(hd(1))) ...
 + 20*log10(abs(ha(1))) ...
 + 20*log10(abs(hb(1))) ...
 + 20*log10(abs(hc(1)))
worst_droop = ideal_pass - worst_pass

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] CIC + halfband filter compensation

[CEL]

Hi Geoff,

might be a good idea to ask this on usrp-us...@lists.ettus.com, because
these CICs are not part of GNU Radio :)

Anyway: There's nothing much to interpret about CIC responses; they are
well-known. The length (and potentially order, as in exponent) of the
CIC used depends on your specific USRP model. (and, potentially, UHD
version)

It's rare that one actually designs an equalizing filter for the CIC –
in all USRPs, the CIC comes before the halfband filter(s), and thus,
you'd typically only see "the flattest part" of the frequency response
of the CIC.

Designing a compensating filter is mathematically impossible, but you
can alleviate certain aspects of the CIC impulse response. But this
would really require you to state what the target metric is over which
bandwidth. Also, it's almost certain that this filter would be
computationally much worse than just oversampling at the USRP end and
then decimating in software with a filter that fits what you need
better.

Notice that I very much believe that "what you need" is the critical
aspect here: Occam's razor tells me that unless you can define why the
CIC is your problem very well, then it's likely you're trying to solve
something that doesn't need solving (or that equalizing parts of the
CIC response isn't the answer you're looking for ;) ).

So, if you asked me: Describe what your system need is, and how you
came to the conclusion that the CIC is a problem! This mailing list is
very prone to having interesting discussions about real-world problems
where every party learns a lot.

Best regards,
Marcus

On Wed, 2018-04-25 at 16:39 -0400, Geoffrey Mainland wrote:
> I hope you will forgive a few naive signal processing questions :)
> 
> 1) What is the frequency response of the CIC and halfband filters in the
> USRP? This was addressed long ago on the mailing list
> (https://lists.gnu.org/archive/html/discuss-gnuradio/2007-05/msg00191.html),
> but the associated MATLAB script is no longer available now that the
> nabble archive is gone.
> 
> 2) How do I design a filter to compensate appropriately?
> 
> I know there are other methods for avoiding CIC droop, like
> oversampling, but I'd like to understand how to compensate with a filter
> as well.
> 
> Thanks!
> Geoff
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Meaning of header_payload_demux0 - Parser returned #f

[Roberts, Alex S.]

Bump.

Alex Roberts | Research Engineer | Applied Power Division (11)
Southwest Research Institute | (210) 522-6014 | 
alex.robe...@swri.org
[SwRI Logo]

From: Roberts, Alex S.
Sent: Tuesday, April 10, 2018 1:13 PM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Meaning of header_payload_demux0 - Parser 
returned #f

Looks like I only replied to Michael and not the list...

The example is included with gnuradio is available on the gnuradio github.
https://github.com/gnuradio/gnuradio/tree/master/gr-digital/examples/packet

>From my understanding of this particular example, OFDM carrier allocation and 
>all the good stuff that comes along with OFDM is not part of the example. It 
>just performs constellation encoding, header/payload muxing, correlation 
>estimation, carrier frequency recovery w/ costas loop, and header / payload 
>demuxing.

Thanks,
Alex.




--

Alex Roberts
Research Engineer
Applied Power Division (11)
Southwest Research Institute
Office: (210) 522-6014 | Pager (210) 513-1672

From: Roberts, Alex S.
Sent: Wednesday, March 28, 2018 8:56 AM
To: Michael Dickens
Subject: RE: [Discuss-gnuradio] Meaning of header_payload_demux0 - Parser 
returned #f

The example is included with gnuradio is available on the gnuradio github.
https://github.com/gnuradio/gnuradio/tree/master/gr-digital/examples/packet

>From my understanding of this particular example, OFDM carrier allocation and 
>all the good stuff that comes along with OFDM is not part of the example. It 
>just performs constellation encoding, header/payload muxing, correlation 
>estimation, carrier frequency recovery w/ costas loop, and header / payload 
>demuxing.

Thanks,
Alex.

From: Michael Dickens [mailto:michael.dick...@ettus.com]
Sent: Wednesday, March 28, 2018 8:44 AM
To: Roberts, Alex S.; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Meaning of header_payload_demux0 - Parser 
returned #f

Hi Alex - If you want to share your GRC file with me (privately) and/or the 
list, we'll see what we can figure out. Guessing it's an OFDM sync issue, since 
GR's OFDM implementation is for async messages, and those are on a message by 
message basis. - MLD

On Tue, Mar 27, 2018, at 8:50 PM, Roberts, Alex S. wrote:
Michael that provides insight into the error, unfortunately it does not explain 
the behavior of the example. The example uses the tx_packet and rx_packet 
hierarchical blocks. The output of the tx is routed to the input of the rx. I 
bypassed the example channel model and I'm not using hardware at the moment, so 
I would expect the example would have little issue with poor SNR and would 
maintain sync.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Fundamental question on Sampling rate

[Derek Kozel]

The B2x0 family of USRPs can do 16, 12, and 8 bit complex samples over the
USB cable. 12 bit ends up incurring CPU load to convert back into 16 bit
values on the host computer, but saves on USB throughput, useful on some
computers. The maximum sample rate is 61.44 MS/s using one channel. UHD can
then convert the over the wire format to the host format you desire.

On Thu, Apr 26, 2018 at 3:20 PM, Martin K 
wrote:

> Unless I'm mistaken the B210 can do 8 bit sample depth, giving you 1 Gbps
> data rate at 62.5 MS/s. This might help.
>
>
> On Thu, Apr 26, 2018 at 6:11 AM, Derek Kozel 
> wrote:
>
>> Hello Mehtap,
>>
>> There will have some filter roll off as well, so the rule of thumb is to
>> have a margin in your sample rates. A safe margin is that your bandwidth of
>> interest be no more than 80% of the theoretical bandwidth of your sample
>> rate, so your recommended rate would be 62.5 MS/s. Helpfully 61.44 MS/s is
>> a common rate due to it being a telecom rate. That's only 1.7% off your
>> target, not a problem. One of the USB3 based SDRs would work in that case,
>> at least as far as sample rate goes.
>>
>> Regards,
>> Derek
>>
>>
>> On Thu, Apr 26, 2018 at 10:47 AM, Jeff Long  wrote:
>>
>>> Correct, you need at least 50 MS/s complex (I+Q) which is 100 MS/s or
>>> 400 MB/s from an I/O point of view. GNU Radio blocks can be used for real
>>> time decoding. Depending on what kind of "decoding" you want to do, the
>>> processor may not be able to keep up.
>>>
>>>
>>> On 04/26/2018 04:05 AM, mehtap özkan wrote:
>>>
 Dear All,
   Mine is more of a fundamental question.
 I have a 50 MHz (3 db bandwidth) wide QPSK signal.
 I am aware that Gnuradio blocks can not be used for real time decoding.
 In order to record the signal and demodulate it correctly, what should
 the minimum sampling rate be?
   If the minimum sampling rate is 100 MSPS, then I am pretty much stuck
 with USRP x310 as the only selection available.(or maybe LIMESDR-PCIe)
 I am also not sure  if the source block streams 100 MSPS sampled signal
 or I+Q (50 MHz-I, 50 MHz-Q).
 Thank you in advance.


 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
> --
> Martin K.
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Issue with Pybombs installation

[Derek Kozel]

Hello Erislandy,

The git tag of a release can be found online at Github.
https://github.com/gnuradio/gnuradio/tags

If you have the repository checked out then you can use git show

> git show v3.7.12.0
commit e4acf4f2f0623fa3ef25dae234b22293d94cd89a (tag: v3.7.12.0)
Author: Marcus Müller 
Date:   Fri Mar 30 16:46:58 2018 +0200
...

Regards,
Derek

On Thu, Apr 26, 2018 at 2:07 PM, Erislandy Mozo Bigñotte <
em...@mondragon.edu> wrote:

> Hello Ravi Sharan,
>
> Thank you for your comment,  Where can I  find the commit associated with
> a release ?
>
>
> Regards...
>
> 2018-04-25 20:05 GMT+02:00 Ravi Sharan 
> :
>
>> Hi Sumit,
>>
>> Q1 - You might have installed libuhd-dev as a system-wide package
>> using apt-get (if you're using ubuntu). Removing/uninstalling that
>> should work.
>>
>> Q2 - To install other tags/releases of a package in your desired
>> prefix (in your case uhd):
>>
>> 0) Check if the package is already installed and uninstall it using
>> pybombs
>>
>> 1) Find the commit associated with the release
>> - In your case it is f072067
>>
>> 2) Edit the following lines in the ~/.pybombs/recipes/gr-recipes/uhd.lwr
>> #gnuradio: master
>> gitrev: f072067
>>
>> 3) Install the package using:
>>  pybombs -p  install 
>>
>> Cheers,
>> R
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Fundamental question on Sampling rate

[Martin K]

Unless I'm mistaken the B210 can do 8 bit sample depth, giving you 1 Gbps
data rate at 62.5 MS/s. This might help.


On Thu, Apr 26, 2018 at 6:11 AM, Derek Kozel  wrote:

> Hello Mehtap,
>
> There will have some filter roll off as well, so the rule of thumb is to
> have a margin in your sample rates. A safe margin is that your bandwidth of
> interest be no more than 80% of the theoretical bandwidth of your sample
> rate, so your recommended rate would be 62.5 MS/s. Helpfully 61.44 MS/s is
> a common rate due to it being a telecom rate. That's only 1.7% off your
> target, not a problem. One of the USB3 based SDRs would work in that case,
> at least as far as sample rate goes.
>
> Regards,
> Derek
>
>
> On Thu, Apr 26, 2018 at 10:47 AM, Jeff Long  wrote:
>
>> Correct, you need at least 50 MS/s complex (I+Q) which is 100 MS/s or 400
>> MB/s from an I/O point of view. GNU Radio blocks can be used for real time
>> decoding. Depending on what kind of "decoding" you want to do, the
>> processor may not be able to keep up.
>>
>>
>> On 04/26/2018 04:05 AM, mehtap özkan wrote:
>>
>>> Dear All,
>>>   Mine is more of a fundamental question.
>>> I have a 50 MHz (3 db bandwidth) wide QPSK signal.
>>> I am aware that Gnuradio blocks can not be used for real time decoding.
>>> In order to record the signal and demodulate it correctly, what should
>>> the minimum sampling rate be?
>>>   If the minimum sampling rate is 100 MSPS, then I am pretty much stuck
>>> with USRP x310 as the only selection available.(or maybe LIMESDR-PCIe)
>>> I am also not sure  if the source block streams 100 MSPS sampled signal
>>> or I+Q (50 MHz-I, 50 MHz-Q).
>>> Thank you in advance.
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 
Martin K.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Issue with Pybombs installation

[Erislandy Mozo Bigñotte]

Hello Ravi Sharan,

Thank you for your comment,  Where can I  find the commit associated with a
release ?


Regards...

2018-04-25 20:05 GMT+02:00 Ravi Sharan :

> Hi Sumit,
>
> Q1 - You might have installed libuhd-dev as a system-wide package
> using apt-get (if you're using ubuntu). Removing/uninstalling that
> should work.
>
> Q2 - To install other tags/releases of a package in your desired
> prefix (in your case uhd):
>
> 0) Check if the package is already installed and uninstall it using pybombs
>
> 1) Find the commit associated with the release
> - In your case it is f072067
>
> 2) Edit the following lines in the ~/.pybombs/recipes/gr-recipes/uhd.lwr
> #gnuradio: master
> gitrev: f072067
>
> 3) Install the package using:
>  pybombs -p  install 
>
> Cheers,
> R
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Issue with Pybombs installation

[Sumit Kumar]

Ok it works!

Thanks

Sumit


On 25/04/2018 20:05, Ravi Sharan wrote:

Hi Sumit,

Q1 - You might have installed libuhd-dev as a system-wide package
using apt-get (if you're using ubuntu). Removing/uninstalling that
should work.

Q2 - To install other tags/releases of a package in your desired
prefix (in your case uhd):

0) Check if the package is already installed and uninstall it using pybombs

1) Find the commit associated with the release
 - In your case it is f072067

2) Edit the following lines in the ~/.pybombs/recipes/gr-recipes/uhd.lwr
 #gnuradio: master
 gitrev: f072067

3) Install the package using:
  pybombs -p  install 

Cheers,
R

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Fundamental question on Sampling rate

[Derek Kozel]

Hello Mehtap,

There will have some filter roll off as well, so the rule of thumb is to
have a margin in your sample rates. A safe margin is that your bandwidth of
interest be no more than 80% of the theoretical bandwidth of your sample
rate, so your recommended rate would be 62.5 MS/s. Helpfully 61.44 MS/s is
a common rate due to it being a telecom rate. That's only 1.7% off your
target, not a problem. One of the USB3 based SDRs would work in that case,
at least as far as sample rate goes.

Regards,
Derek


On Thu, Apr 26, 2018 at 10:47 AM, Jeff Long  wrote:

> Correct, you need at least 50 MS/s complex (I+Q) which is 100 MS/s or 400
> MB/s from an I/O point of view. GNU Radio blocks can be used for real time
> decoding. Depending on what kind of "decoding" you want to do, the
> processor may not be able to keep up.
>
>
> On 04/26/2018 04:05 AM, mehtap özkan wrote:
>
>> Dear All,
>>   Mine is more of a fundamental question.
>> I have a 50 MHz (3 db bandwidth) wide QPSK signal.
>> I am aware that Gnuradio blocks can not be used for real time decoding.
>> In order to record the signal and demodulate it correctly, what should
>> the minimum sampling rate be?
>>   If the minimum sampling rate is 100 MSPS, then I am pretty much stuck
>> with USRP x310 as the only selection available.(or maybe LIMESDR-PCIe)
>> I am also not sure  if the source block streams 100 MSPS sampled signal
>> or I+Q (50 MHz-I, 50 MHz-Q).
>> Thank you in advance.
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Fundamental question on Sampling rate

[Jeff Long]

Correct, you need at least 50 MS/s complex (I+Q) which is 100 MS/s or 
400 MB/s from an I/O point of view. GNU Radio blocks can be used for 
real time decoding. Depending on what kind of "decoding" you want to do, 
the processor may not be able to keep up.


On 04/26/2018 04:05 AM, mehtap özkan wrote:

Dear All,
  Mine is more of a fundamental question.
I have a 50 MHz (3 db bandwidth) wide QPSK signal.
I am aware that Gnuradio blocks can not be used for real time decoding.
In order to record the signal and demodulate it correctly, what should 
the minimum sampling rate be?
  If the minimum sampling rate is 100 MSPS, then I am pretty much stuck 
with USRP x310 as the only selection available.(or maybe LIMESDR-PCIe)
I am also not sure  if the source block streams 100 MSPS sampled signal 
or I+Q (50 MHz-I, 50 MHz-Q).

Thank you in advance.


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Fundamental question on Sampling rate

[mehtap özkan]

Dear All,
 Mine is more of a fundamental question.
I have a 50 MHz (3 db bandwidth) wide QPSK signal.
I am aware that Gnuradio blocks can not be used for real time decoding.
In order to record the signal and demodulate it correctly, what should the
minimum sampling rate be?
 If the minimum sampling rate is 100 MSPS, then I am pretty much stuck with
USRP x310 as the only selection available.(or maybe LIMESDR-PCIe)
I am also not sure  if the source block streams 100 MSPS sampled signal or
I+Q (50 MHz-I, 50 MHz-Q).
Thank you in advance.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio, peak values, export into a file

[PRIYANKA PRIYADARSHINI]

You can use file sink to store your peak value. It will continuously store the 
values until you close your program.

Alternatively you can use head before file sink to limit your to program to 
specific time.

Hope this helps!

Priyanka



> On 26. Apr 2018, at 01:42, ALEJANDRO RAMIRO MUNOZ <100314...@alumnos.uc3m.es> 
> wrote:
> 
> Hey all!
> 
> I started working with GNU Radio and HackRF One SDR for an university project 
> but I'm completely complete new and I'm still a little bit lost. 
> 
> I'm using the HackRF One as a spectrum analyzer, specifically at 120.457 KHz. 
> That signal source comes from an Avalanche Transceiver upconverted into HF 
> and it's a powerful periodic signal peak at this frequency.
> 
> With GNU Radio I'm just trying to capture and later export into a file the 
> peak power values of this signal. So I want to set a threshold, capture the 
> peak values of this signal continuously until I stop the programme and store 
> them in a file.
> 
> I've tried to follow some similar tutorials but I'm not able to get a proper 
> solution.
> 
> If someone could help me, I'll be so grateful! Thank you in advance!
> 
> 
> 
> 
> -- 
> Alejandro Ramiro Muñoz
> NIA: 100314975
> 
> Grado en Ingeniería de Sistemas de Comunicaciones
> (Bachelor's Degree in Communication System Engineering)
> 
> Universidad Carlos III de Madrid
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio