On 02/13/2014 11:19 AM, Matt Ettus wrote:
Piotr,
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.
Matt
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 <per...@o2.pl
<mailto:per...@o2.pl>> 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
blocks?
In my case it would often make many things I do easier.
--
Best Regards,
Piotr Krysik
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org <mailto: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
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
