On 10/01/2018 08:43 AM, Mitch Grabner via USRP-users wrote:
Marcus,
You were right, it is LO leakage. Is there anyway to reduce it or am I
stuck with it?
Thanks for the help.
You can use offset tuning to move the LO leakage outside of your passband.
https://files.ettus.com/manual/page_general.html#general_tuning
On Sun, Sep 30, 2018 at 9:07 PM Mitchell J Grabner
<[email protected] <mailto:[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]
<mailto:[email protected]>
>>>>>>>>>
>>>>>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>> _______________________________________________
>>>>>>>> USRP-users mailing list
>>>>>>>> [email protected]
<mailto:[email protected]>
>>>>>>>>
>>>>>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>> _______________________________________________
>>>>>>> USRP-users mailing list
>>>>>>> [email protected] <mailto:[email protected]>
>>>>>>>
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>> _______________________________________________
>>>>>> USRP-users mailing list
>>>>>> [email protected] <mailto:[email protected]>
>>>>>>
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[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
