Dear, Sylvain Munaut,
Thanks.I got a hint from your answer.
What about using moving average instead LPF?
I think moving average (MA) is much simpler than LPF if computational cost
is considered.
But, another issue is, precision on estimation A and A/2. In that case, LPF
would be better.
Anyway,
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 07.05.2015 10:56, Richard Bell wrote:
> Yes I agree. If it is the case that the Packet Header Parser does not
> output a message for every header it is given, would that produce the
> "backup" behavior I'm seeing? Backup meaning it looks like the buffers
> on all preceding blocks start to fill u
We wish to thank folks who have already submitted an abstract for a
presentation, tutorial, or poster to EasyChair <
https://easychair.org/conferences/?conf=grcon15 >. We realized that some
useful links to this website were missing until about a week ago, so
we're extending the deadline by a week t
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
Yes I agree. If it is the case that the Packet Header Parser does not
output a message for every header it is given, would that produce the
"backup" behavior I'm seeing? Backup meaning it looks like the buffers on
all preceding blocks start to fill up because the HPD block is stock in a
blocked sta
Hello,
I working on a project wireless channel emulator. I have to implement
multipath fading in gnu radio using signal source from usrp.
I have tried using the fading blocks but i am not able to identify whether
multipath fading is occuring in the output or not.
Regarding the top blocks i have
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 Wed, May 6, 2015 at 7:28 PM, Achilleas Anastasopoulos
wrote:
> OK, so cmake cannot find thrift, which is reasonable because i didn't
> build it...
>
> So, I followed the instructions on building thrift and
> configure returns
>
>
>
> thrift 0.9.2
>
> Building C++ Library . : no
>
Hello Ritvik,
I have a few questions, could you find a quick answer to each of them,
so that I understand the situation better?
I'm very confused, because you have a screenshot of a Flowgraph that has
multiple QT GUI sinks, but is set to WX. And then you have a screenshot
of QT Gui visualizations
19 matches
Mail list logo
