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 > > > > 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 > > > > > > _______________________________________________ > > 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 _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
