OK, this is alarming; could you be as nice as making a minimum piece of code that we can run locally to reproduce? I must admit I'm more or less in an international flight boarding line, so I might not be able to look at this for the next 72h.
Best regards, Marcus On Sun, 2018-09-30 at 18:34 -0400, Mitchell J Grabner wrote: > I've been testing with a long time_spec of 2.0 seconds. The weird > thing > is the device responds with an ack @ the specified 2.0 seconds that > the > burst left at that time... even though it indeed when to the RFIC > immediately when the send() is called. This is on uhd 3.10 and 3.14- > git. > > thanks, > Mitch > > On 9/30/2018 4:49 PM, Marcus Müller wrote: > > Shoot, there goes my hypothesis! > > But: how much time do you leave between set_time_now and then using > > md > > in a send() call? Maybe the setting happens concurrently... > > > > Best regards, > > Marcus > > > > On Sun, 2018-09-30 at 14:51 -0400, Mitchell J Grabner wrote: > > > Hi Marcus, > > > > > > I use set_time_now(). For my project the devices are assumed > > > un-synchronized. > > > > > > thanks > > > > > > On 9/30/2018 1:11 PM, Marcus Müller wrote: > > > > Hi Mitch, > > > > > > > > this is but a shot in the blue, but: > > > > How you're setting the device clock to 0? set_time_now() or > > > > _next_pps(), or _unknown_pps()? > > > > > > > > Best regards, > > > > Marcus the other > > > > On Thu, 2018-09-27 at 18:47 -0400, Mitchell J Grabner via USRP- > > > > users > > > > wrote: > > > > > I've used both 3.10.3 and 3.14 (latest git master) > > > > > > > > > > double time_to_transmit = 2.0; > > > > > > > > > > uhd::tx_metadata_t md; > > > > > md.start_of_burst = false; > > > > > md.end_of_burst = false; > > > > > md.has_time_spec = true; > > > > > md.time_spec = uhd::time_spec_t(time_to_transmit); > > > > > > > > > > //then while loop through samples > > > > > > > > > > //get burst ack > > > > > > > > > > On 9/27/2018 6:32 PM, Marcus D. Leech via USRP-users wrote: > > > > > > On 09/27/2018 06:27 PM, Mitchell J Grabner via USRP-users > > > > > > wrote: > > > > > > > I set the device time stamp to zero and immediately send > > > > > > > the > > > > > > > packets > > > > > > > to the device with a timestamp of 2.0 seconds. Also > > > > > > > wouldn't > > > > > > > a > > > > > > > past > > > > > > > timestamp give late packet error? > > > > > > > > > > > > > > Thanks, > > > > > > > Mitch > > > > > > > > > > > > Could you show us how you're setting the metadata? (Like, > > > > > > the > > > > > > code), > > > > > > and what version of UHD you're using? > > > > > > > > > > > > > > > > > > > On 9/27/2018 5:25 PM, Marcus D. Leech via USRP-users > > > > > > > wrote: > > > > > > > > On 09/27/2018 05:02 PM, Mitch Grabner via USRP-users > > > > > > > > wrote: > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > I'm trying to get a timed burst working on a B200 and > > > > > > > > > it > > > > > > > > > looks like > > > > > > > > > the device is transmitting the samples the instant > > > > > > > > > they > > > > > > > > > reach > > > > > > > > > the > > > > > > > > > device (tested by listening on a second device) > > > > > > > > > instead > > > > > > > > > of > > > > > > > > > holding > > > > > > > > > them until the time specified in md.time_spec. > > > > > > > > > I set up the first packet's metadata with > > > > > > > > > start_of_burst, > > > > > > > > > has_time_spec and give it time_spec = > > > > > > > > > uhd::time_spec_t(time_to_send); The following packets > > > > > > > > > have no > > > > > > > > > burst > > > > > > > > > metadata and the last has end_of_burst. I wait for > > > > > > > > > packet > > > > > > > > > ack > > > > > > > > > with > > > > > > > > > recv_async_msg and it is received after the time > > > > > > > > > specified > > > > > > > > > in > > > > > > > > > time_spec even though the samples left immediately. > > > > > > > > > There > > > > > > > > > are > > > > > > > > > no > > > > > > > > > other errors like underflow, overflow or late > > > > > > > > > packets. > > > > > > > > > Has > > > > > > > > > anyone > > > > > > > > > had this issue or has any idea how to fix it? I must > > > > > > > > > be > > > > > > > > > missing > > > > > > > > > something very simple. > > > > > > > > > > > > > > > > > > Thanks for the help, > > > > > > > > > Mitch > > > > > > > > > > > > > > > > > > > > > > > > > Keep in mind that the time-to-send is from the > > > > > > > > perspective > > > > > > > > of > > > > > > > > the > > > > > > > > device, so you have to make sure that your own flow is > > > > > > > > synchronized to > > > > > > > > the same time as the device. > > > > > > > > > > > > > > > > If a packet arrives with a time specified that is in > > > > > > > > the > > > > > > > > past, > > > > > > > > it > > > > > > > > gets sent immediately. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > USRP-users mailing list > > > > > > > > [email protected] > > > > > > > > > > > > > > > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > > > > > > _______________________________________________ > > > > > > > USRP-users mailing list > > > > > > > [email protected] > > > > > > > > > > > > > > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > > > > > _______________________________________________ > > > > > > USRP-users mailing list > > > > > > [email protected] > > > > > > > > > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > > > > _______________________________________________ > > > > > USRP-users mailing list > > > > > [email protected] > > > > > > > > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > > > > _______________________________________________ USRP-users mailing list [email protected] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
