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
