Here is my transmit code... in setup I do
tx_usrp->set_time_now(uhd::time_spec_t(0.0));
// TRANSMIT
//setup metadata for the first packet
uhd::tx_metadata_t tx_md;
tx_md.start_of_burst = true;
tx_md.end_of_burst = false;
tx_md.has_time_spec = true;
tx_md.time_spec = uhd::time_spec_t(2.0);
//the first call to send() will block this many seconds before
sending:
double tx_timeout = std::max(rep_rate, seconds_in_future) + 0.1;
//timeout (delay before transmit + padding)
std::cout << boost::format("Transmitting %u samples at %0.9f device
time"
) % total_num_samps % (tx_md.time_spec.get_full_secs() +
tx_md.time_spec.get_frac_secs()) << std::endl;
size_t num_acc_samps = 0; //number of accumulated samples
while(num_acc_samps < total_num_samps){
size_t samps_to_send = total_num_samps - num_acc_samps;
if (samps_to_send > spb)
{
samps_to_send = spb;
} else {
tx_md.end_of_burst = true;
}
//fill the buffer with the samples
for (size_t n = 0; n < tx_buff.size(); n++){
//tx_buff[n] = wave_table(index += step);
tx_buff[n] = std::complex<float>(ampl, ampl);
}
//send a single packet
size_t num_tx_samps = tx_stream->send(
tx_buffs, samps_to_send, tx_md, tx_timeout
);
//do not use time spec for subsequent packets
tx_md.has_time_spec = false;
tx_md.start_of_burst = false;
if (num_tx_samps < samps_to_send)
{
std::cerr << "Send timeout..." << std::endl;
if (stop_signal_called)
{
exit(EXIT_FAILURE);
}
}
if(verbose)
{
std::cout << boost::format("Sent a packet of %u samples to
device") % num_tx_samps << std::endl;
}
num_acc_samps += num_tx_samps;
}
std::cout << std::endl << "Waiting for burst... " << std::flush;
uhd::async_metadata_t async_md;
size_t acks = 0;
//loop through all messages for the ACK packets (may have underflow
messages in queue)
while (acks < tx_channel_nums.size() and
tx_stream->recv_async_msg(async_md, 0.1))
{
if (async_md.event_code ==
uhd::async_metadata_t::EVENT_CODE_BURST_ACK)
{
acks++;
}
}
std::cout << (acks == tx_channel_nums.size() ? "success!" :
"failed!") << std::endl;
std::cout << boost::format("Finished transmitting at %0.9f device
time"
) % (tx_usrp->get_time_now().get_full_secs() +
tx_usrp->get_time_now().get_frac_secs()) << std::endl;
/*----------------------------------------------------------------------*/
On Sun, Sep 30, 2018 at 8:54 PM Mitchell J Grabner <[email protected]>
wrote:
> I'll be able to give you a copy tomorrow morning. Ok no rush, thank you
> for taking a look for me. Safe travels!
>
> On 9/30/2018 8:15 PM, Marcus Müller wrote:
> > 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
> >>
>
>
--
*Mitchell J Grabner*
*Student Member IEEE Communications Society*
*------------------------------------------------*
My Linkedin <http://www.linkedin.com/pub/mitch-grabner/43/23b/bb5>
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
