usrp-users@lists.ettus.com

Discussion and technical support related to USRP, UHD, RFNoC

View all threads

Re: [USRP-users] R: X300 STREAM_MODE_NUM_SAMPS_AND_DONE length limitation

V
Vladimir
Mon, Oct 2, 2017 5:23 PM

Daniele,

Thank you for your advice! The problem here (not so big though) is that upon receiving of needed number of samps you need to stop streaming and that implies waiting for some timeout while excess samps being flushed (as I understood, after issuing STREAM_MODE_STOP_CONTINUOUS you have to clear input buffers using something like streamer->flush_all(0.01);). I'm trying to estimate how long that timeout should be, and in some cases it obviously would be more or less worse than a possible scenario without timeouting.

Vladimir

Понедельник,  2 октября 2017, 16:05 +03:00 от Disco Daniele daniele.disco@telecomitalia.it:

I have the same problem.
In the generation of the streamer
uhd::stream_cmd_t stream_cmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
erase the instruction stream_cmd.num_amps = total_num_samps; (or similar)
 
and instead to use a counter over the samples use a counter over the blocks of data that the streamer acquires.
 
In b210 each acquisition is of 2044 samples
In E310 is of 1016 (samps_per_buff)
 
 
You can divide the number of samples (>0xfffffff) for samps_per_buff and make a for loop to acquire all the data that you need
rx_stream->revc(buff_ptrs, samps_per_buff, md, timeout)
 
I hope this help you
 
Da: USRP-users [mailto:usrp-users-bounces@lists.ettus.com] Per conto di  Vladimir via USRP-users
Inviato: venerdì 29 settembre 2017 16:53
A: usrp-users
Oggetto: [USRP-users] X300 STREAM_MODE_NUM_SAMPS_AND_DONE length limitation
 
Hello,

Trying to save more than 2 sec trace with X300 at Fsamp = 100MHz, I encounter some block length limit of 0x0fffffff = 268.4 MSamps, which means only 2.6 sec of time. A bit surprised to see this in 64-bit environment... The assertion is in module rx_vita_core_3000.cpp:

UHD_ASSERT_THROW(stream_cmd.num_samps <= 0x0fffffff);

Is this some physical limit, or it can be patched to a larger value? It's kind of inconvenient to solve this through continuous streaming when you need a trace of a certain length...

Vladimir

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may  contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return  e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

Daniele, Thank you for your advice! The problem here (not so big though) is that upon receiving of needed number of samps you need to stop streaming and that implies waiting for some timeout while excess samps being flushed (as I understood, after issuing STREAM_MODE_STOP_CONTINUOUS you have to clear input buffers using something like streamer->flush_all(0.01);). I'm trying to estimate how long that timeout should be, and in some cases it obviously would be more or less worse than a possible scenario without timeouting. Vladimir >Понедельник, 2 октября 2017, 16:05 +03:00 от Disco Daniele <daniele.disco@telecomitalia.it>: > >I have the same problem. >In the generation of the streamer >uhd::stream_cmd_t stream_cmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS); >erase the instruction stream_cmd.num_amps = total_num_samps; (or similar) >  >and instead to use a counter over the samples use a counter over the blocks of data that the streamer acquires. >  >In b210 each acquisition is of 2044 samples >In E310 is of 1016 (samps_per_buff) >  >  >You can divide the number of samples (>0xfffffff) for samps_per_buff and make a for loop to acquire all the data that you need >rx_stream->revc(buff_ptrs, samps_per_buff, md, timeout) >  >I hope this help you >  >Da: USRP-users [mailto:usrp-users-bounces@lists.ettus.com] Per conto di Vladimir via USRP-users >Inviato: venerdì 29 settembre 2017 16:53 >A: usrp-users >Oggetto: [USRP-users] X300 STREAM_MODE_NUM_SAMPS_AND_DONE length limitation >  >Hello, > >Trying to save more than 2 sec trace with X300 at Fsamp = 100MHz, I encounter some block length limit of 0x0fffffff = 268.4 MSamps, which means only 2.6 sec of time. A bit surprised to see this in 64-bit environment... The assertion is in module rx_vita_core_3000.cpp: > >UHD_ASSERT_THROW(stream_cmd.num_samps <= 0x0fffffff); > >Is this some physical limit, or it can be patched to a larger value? It's kind of inconvenient to solve this through continuous streaming when you need a trace of a certain length... > >Vladimir > >Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. > > >This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. > > >Rispetta l'ambiente. Non stampare questa mail se non è necessario.