Hi David, so, NUM_SAMPS_AND_DONE sounds right for this application, and pre- determining the time at when the observation will start with time_specs sounds absolutely like what I'd recommend.
You say there's a "delay when leaving the recv function"; I'm not quite sure I understand what you're referring to, here? Recv() just takes the data coming in, takes it from the hardware buffer, converts it to the number format you requested, and writes it into the buffer you gave it, and repeats until the requested number of items have been received (or some timeout or extranormal condition happened). There's no delay that we added there! Note that these calculations might actually take some time. Hence, it's absolutely desirable to have two (or even more, but stick with two for now) threads that just call recv() in endless loops – recv() is thread- safe, and that way, you can already handle the next hardware buffer, while the first is still being processed (subject to CPU limitations). Best regards, Marcus On Thu, 2018-07-19 at 09:48 +0200, David Zamorano Fernández via USRP- users wrote: > Hi. > > We have implemented a TDMA receiver on an E310. We have to receive > slots of 40 ms duration and we must capture and process each of them. > These capture instants must be very precise, so we have used GPS to > discipline the internal clock of the E310. > > What is the most appropriate stream mode for this task? > > Currently, STREAM_MODE_START_CONTINUOUS is used but the first slot > has too much delay when leaving the recv function (about 14 ms). It > has also been tested with STREAM_MODE_NUM_SAMPS_AND_MORE, programming > the next slot time_spec each time. > > Thanks. > -- > > > > David Zamorano Fernández > Investigador - Desarrollador | Área de Comunicaciones Avanzadas > Researcher - Developer | Advanced Communications Department > > Ph. (+34) 986 120 430 Ext. 3012 > dzamor...@gradiant.org | www.gradiant.org > > > > Take care of the environment. Try not to print this email. > The information contained in this email message may be confidential > information, and may also be the subject of legal professional > privilege. If you are not the intended recipient, any use, > interference with, disclosure or copying of this material is > unauthorized and prohibited. Please inform us immediately and destroy > the email. Thank you for your cooperation. > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
