Hey Jason, Are you making sure that you're setting your TX time tag to be 2 seconds ahead of the USRP's sense of time? A late packet means that the time a packet should be executed on has already passed (as far as the USRP is concerned).
You can use calls like: get_time_now() get_time_last_pps() set_time_now() set_time_next_pps() To understand the radio's sense of time and reset it as you see fit. Having not seen your code, I'd recommend utilizing the above functions ( https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html) to align the times you use to populate the tx_time tag. -Sam On Sat, Oct 19, 2019 at 6:14 PM Jason McBride via USRP-users < [email protected]> wrote: > Hey everybody, I'm trying to put together a simple bursting example. In > gnuradio companion I'm generating a PDU, using the framer block, converting > to a tagged stream, and then inserting a tx_time tag in an OOT python > block. The tx_time tag is at the beginning of the streamed frame, just > prior to the packet_len tag. I send it to the USRP next. > > The USRP is sync'd to PC time at the beginning of the flowgraph, and I set > the tx_time tag for two seconds in the future. The USRP does seem to > transmit at that time, but it generates lots of L error symbols, and after > the initial transmission stops transmitting. I can see the stream sent to > the USRP via a tag debug block, so I know the stream is received by the > USRP significantly prior to transmittal. > > Any thoughts as to what's going on? is there something I need to configure > on the USRP? > > Thank you, > > Jason > _______________________________________________ > 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
