The Nyquist theorem says in general your sample rate equals your two sided
bandwidth, i.e. Fs=10 MHz -> BW = 10 MHz. In general, your samples are complex.
As soon as you restrict samples to be real in time, you cut the useable
bandwidth in half. This is because real time samples imply conjugate
Gerome,
if you set a sampling rate of 4 MHz, you will have 4 MHz of usable
bandwidth (complex baseband). This is how it's supposed to be.
M
On 16.09.2015 09:27, Gerome Jan L wrote:
> Hi guys,
>
> Actually, that's what I thought too. If I set the UHD: USRP Source
> samp_rate to 400 Msps, I shoul
It sets the output sampling rate of the USRP, and hence the usable
bandwidth. Internally, it sets the DDC chain's decimation, so if you
request 1 Msps, it will decimate from 100 MHz sampling rate by a factor
of 100.
The rate at which the IF is sampled from the TVRX2 is, as you point out,
fixed to
Hi guys,
What does the sampling rate in this usrp block does?i'm talking about the
uhd:usrp source block. Is this the one that samples the IF from my TVRX2
daughterboard? Or is this the bandwidth that is displayed on the QT Sink?
Or is this the bandwidth that needs to be sample. As far as I know,
I have 5 blocks in my flowgraph:
USRP Src -> PFB Decim by 2 -> Mult 32768 -> Cplx-iShort -> FileSink
I am running 14 MS/s x 2 x 32 bits from the USRP, 7 MS/s x 2 x 16 bits
to the disk.
Previously, even setting the USRP num_recv_frames=512 or 1024, it
would run for about a minute fine then print 1-4
Date: Sun, 10 May 2015 17:18:58 -0400
From: "Marcus D. Leech"
You could try a simple experiment that tests your disk subsystem write
performance without SDR stuff at all. Something like:
time dd if=/dev/zero of=some-file-on-your-disk bs=200 count=15000
This should write a 30GB file. The 'ti
On 05/09/2015 09:02 AM, Murphy, John wrote:
Marcus et al,
Had to drop this to do some work on another project yesterday, but
still want to pursue this just a little further if you don't mind,
because the numbers you are giving all look to me like it should be
able to be made to work.
You found
Marcus et al,
Had to drop this to do some work on another project yesterday, but
still want to pursue this just a little further if you don't mind,
because the numbers you are giving all look to me like it should be
able to be made to work.
You found my SDD sequential sustained write speed of 69
On 05/07/2015 04:12 PM, Murphy, John wrote:
So /dev/null works, I do not know what that really says about this
though. Is there a difference between using dev/null and just running
any non-disk-write flowgraph? Because I know I can run a flowgraph at
16 MS/s decimated to 8 MS/s, with never a sing
So /dev/null works, I do not know what that really says about this
though. Is there a difference between using dev/null and just running
any non-disk-write flowgraph? Because I know I can run a flowgraph at
16 MS/s decimated to 8 MS/s, with never a single O even for hours of
operation.
With 16 GByt
It'll be under /usr/local/lib{64}/uhd/examples
I looked at their blurb on that drive, and its *sustained* rate comes
out to about 69Mbyte/second. Sure, it'll take bursts at screaming-fast
rates, because, like the Linux kernel, it has a whacking great
write-behind buffer.
Try specifying a fil
The sequential rates I gave are the published rates for the SSD. Maybe
(probably?) specsmanship, sure.
But since it does mostly keep up, isn't this a case of just needing
the correct buffer set-up to allow it to ride through the worst of the
hiccups?
I am going to have to find and figure out how t
For the record and completeness I tried again with just the complex
int16 USRP Source and File Sink, setting "Unbuffered = off", and it
still bahaved the same. It may matter but it is not enough to make a
noticeable difference in this case.
- John
On Thu, May 7, 2015 at 2:27 PM, wrote:
> Leave
Hi Marcus,
I am using num_recv_frames=512 but I have no idea why 512 or what the
ideal value should be for a system that has a lion's share of 16 GB of
RAM to burn.
In terms of the disk hardware sequential writes are up to 520
MBytes/sec. While there may still be some moments where things fall
beh
On Thu, May 7, 2015 at 2:01 PM, Murphy, John wrote:
> Transition bandwidth is sloppy, double the (sample rate minus
> two-sided passband width), or in this case something on the order of
> 1/4 the input sample rate.
Okay, actually I do have a tighter width, because with the decimation
by 2 it wra
Leave "unbuffered" = OFF. This flag was added for "slow" file-sinks,
when, for example, you're writing slow data to an external process via
somehthing like FIFO, and you don't want the default stdio buffering to
get in the way. The default, if you leave it off, is to use stdio
buffering.
The "
On Thu, May 7, 2015 at 1:01 PM, wrote:
> If you want high file-write performance, leave it in buffered mode.
> Also, a 175-tap filter, running at 16Msps is going to chew up a lot of CPU.
> How about a simple low-pass filter, decim=2? Make the transition bandwidth
> fairly sloppy.
> Or alterna
Or alternatively, just run the USRP at your desired sample-rate into the
file-sink.
On 2015-05-07 12:48, Murphy, John wrote:
> How would I best set up a UHD Source block for USRP B2x0 devices to
> output to a flowgraph that uses a File Sink block to write to disk
> without overflows (and how
If you want high file-write performance, leave it in buffered mode.
Also, a 175-tap filter, running at 16Msps is going to chew up a lot of
CPU.
How about a simple low-pass filter, decim=2? Make the transition
bandwidth fairly sloppy.
On 2015-05-07 12:48, Murphy, John wrote:
> How would I
How would I best set up a UHD Source block for USRP B2x0 devices to
output to a flowgraph that uses a File Sink block to write to disk
without overflows (and how would I best set up the File Sink block)?
This is the attached system hardware, dedicated to GR...
Gigabyte GB-BXi7-4770R Brix Pro PC
Cr
On 04/25/2015 04:40 PM, Gerome Jan L wrote:
Hello,
What I was trying to say is, how related is the sampling rate in the
uhd: usrp source to the sampling rate in the adc which is 100MSPS? Thanks.
That sets the rate that samples are delivered to the host PC. Said rate
must be an integer frac
Hello,
What I was trying to say is, how related is the sampling rate in the uhd:
usrp source to the sampling rate in the adc which is 100MSPS? Thanks.
--
*Gerome Jan M. Llames *
Engineering Research and Development for Technology (ERDT) Scholar
University of San Carlos - Technological Campus
N
Hello Gerome,
to the center frequency of your TV channel, probably. You'd set the
sampling rate to 6MHz, or something higher, depending on what bandwidth
you want to observe and which sampling rates your USRP support.
Greetings,
Marcus
On 04/25/2015 04:43 AM, Gerome Jan L wrote:
> Hello,
>
> I'
Hello,
I'm trying to receive a 6 MHz TV signal. What frequency should I set
my UHD: USRP Source in the GRC?
Thanks.
*Gerome Jan M. Llames *
Engineering Research and Development for Technology (ERDT) Scholar
University of San Carlos - Technological Campus
Nasipit Talamban, Cebu City, Philippines,
Hi,
On 05/23/2013 12:34 AM, Josh Blum wrote:
This worked on ubuntu 12.10 x64 and ubuntu 11.04 x86
https://github.com/guruofquality/gnuradio/commit/fa75f18dc4d347bd7d5a1595b162395f773858d3
The error is reproducible without the changset for both machines
mentioned. Hope that fixes it.
I'm not
On Wed, May 22, 2013 at 3:34 PM, Josh Blum wrote:
> This worked on ubuntu 12.10 x64 and ubuntu 11.04 x86
>
>
> https://github.com/guruofquality/gnuradio/commit/fa75f18dc4d347bd7d5a1595b162395f773858d3
>
> The error is reproducible without the changset for both machines
> mentioned. Hope that fix
On 05/22/2013 02:50 PM, Johnathan Corgan wrote:
> On Wed, May 22, 2013 at 12:47 PM, Josh Blum wrote:
>
>
>> Oh, the swig file is missing a %template export for a vector of size_t.
>> It probably doesnt know how to deal with the channel list in the
>> stream_args_t class -- hence the error. Is
On Wed, May 22, 2013 at 12:47 PM, Josh Blum wrote:
> Oh, the swig file is missing a %template export for a vector of size_t.
> It probably doesnt know how to deal with the channel list in the
> stream_args_t class -- hence the error. Is that correct?
>
On the next branch, the %template export f
On Wed, May 22, 2013 at 12:42 PM, Josh Blum wrote:
> There are some additions on "next" related to channel mapping. But that
> should be all internal to the cpp files and not causing this issue. Not
> sure yet...
>
I haven't merged that in yet.
> Can you post the source code thats calling in
On 05/22/2013 02:32 PM, Johnathan Corgan wrote:
> On Wed, May 22, 2013 at 11:53 AM, Bastian Bloessl <
> bastian.bloe...@uibk.ac.at> wrote:
>
>
>> I installed todays next branch and get the following error when I try to
>> use a UHD: USRP Source.
>>
>> File "/usr/local/lib/python2.7/**dist-packa
On 05/22/2013 01:53 PM, Bastian Bloessl wrote:
> Hi all,
>
> I installed todays next branch and get the following error when I try to
> use a UHD: USRP Source.
>
> File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
> line 72, in __init__
> for v in val: self.channels.ap
On Wed, May 22, 2013 at 11:53 AM, Bastian Bloessl <
bastian.bloe...@uibk.ac.at> wrote:
> I installed todays next branch and get the following error when I try to
> use a UHD: USRP Source.
>
> File "/usr/local/lib/python2.7/**dist-packages/gnuradio/uhd/__**init__.py",
> line 72, in __init__
>
Hi all,
I installed todays next branch and get the following error when I try to
use a UHD: USRP Source.
File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
line 72, in __init__
for v in val: self.channels.append(v)
SystemError: error return without exception set
It
33 matches
Mail list logo
