Marcus, You were right, it is LO leakage. Is there anyway to reduce it or am I stuck with it?
Thanks for the help. On Sun, Sep 30, 2018 at 9:07 PM Mitchell J Grabner <[email protected]> wrote: > Im trying to send 10,000 samples and it looks like I'm receiving the > 10,000 samples; I will double check tomorrow morning and post some > graphs of what I'm receiving. > > On 9/30/2018 8:46 PM, Marcus D. Leech via USRP-users wrote: > > On 09/30/2018 06:34 PM, Mitchell J Grabner via USRP-users 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 > > How are you confirming that this is what's happening? > > > > There will be LO leakage happening before your actual signal is > > transmitted, so if you're just looking at the spectrum, you might be > > fooled into thinking that it was sending the actual data, just from > > the LO leakage. Just a thought. Trying to puzzle this out. > > > > > >> > >> 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 > > > > > > _______________________________________________ > > 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
