[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Idea of a USRP UHD block that fills gaps in trans

From: Marcus D. Leech
Subject: Re: [Discuss-gnuradio] Idea of a USRP UHD block that fills gaps in transmission from USRP
Date: Thu, 13 Feb 2014 11:41:43 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16

On 02/13/2014 11:19 AM, Matt Ettus wrote:


One problem is that if you cannot keep up, adding in all-zeros data will just make it harder to keep up.  In general, modern PCs should be able to keep up with 25 MS/s without problem unless you are doing a lot of processing.  We are actually able to keep up with 300 MS/s on the X300.  So the question is more about why the app can't keep up.

An alternative might be to stream to a file.  That should keep up without dropping as long as you have a fast drive.  Then you can process samples from that file at the pace your app can keep up with.


And on a tangentially-related note, SSDs aren't necessarily fast writers.   Particularly if they aren't using an AHCI interface and/or, they're
  early-generation.  I found this out the hard way...

On Sun, Feb 9, 2014 at 1:19 AM, Perper <address@hidden> wrote:
Hi all,

Interruptions transmission over Gigabit Ethernet when receiving samples
from USRP can happen at highest data rates no matter how many tricks you
use with your network card (I have experience with N200/N210).

The loss of part of the signal results with synchronization loss in data
transmission systems. There is possibility to handle this problem by
catching rx_time stream tags.

But there might be a solution to keep synchronization that might work
quite well with gr-blocks that don't handle stream tags.

What if USRP UHD Source gave user an option to fill all of the gaps in
signal with exact number of lost samples (for example with zeros).
Additionally it could produce stream tags with position and length of
each gap so it would be easy to store a file with continuous signal
stream paired with a file containing metadata describing where and for
how long the signal samples were lost.

Is it possible to do exactly what I'm describing with current gnuradio
In my case it would often make many things I do easier.

Best Regards,
Piotr Krysik

Discuss-gnuradio mailing list

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

Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

reply via email to

[Prev in Thread] Current Thread [Next in Thread]