Hi Marcus, First, I thought that recv() is not thread-safe (according to recv() section in UHD manual <https://files.ettus.com/manual/classuhd_1_1rx__streamer.html#af4e581b97d92553c6091108393a7da1b> ).
I understand the use of two or more threads with recv() in a loop. But, when do I program the time_spec for next slot? When I receive all the samples from a slot and I want to program the next time_spec, it is already obsolete because the recv() lasts slightly longer than the duration of a slot. The first slot starts at 0 and lasts 40 ms, and the next one starts at 40 ms and ends at 80 ms. And so it continues... The reception is all done on the same channel, so I can not create two rx_stream (or a multichannel rx_streamer) and do issue_stream_cmd with a different time_spec for each one. Best regards, David -- [image: logo_170x100px.png] <http://www.gradiant.org/> 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 <napell...@gradiant.org> | www.gradiant.org [image: Iconos Redes Sociales GRD Firma email-01] <https://www.facebook.com/GradiantNews/> [image: Iconos Redes Sociales GRD Firma email-02] <https://twitter.com/Gradiant> [image: Iconos Redes Sociales GRD Firma email-03] <https://www.linkedin.com/company-beta/769728> [image: Iconos Redes Sociales GRD Firma email-04] <https://www.youtube.com/user/ComunicacionGRD> 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. 2018-07-19 10:03 GMT+02:00 Marcus Müller <marcus.muel...@ettus.com>: > 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
