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_gener
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
wrote:
> Im trying to send 10,000 samples and it looks like I'm receiving the
> 10,000 samples; I will double check tomorrow mor
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;
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'v
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
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
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
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,
Mit
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 proj
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
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
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/20
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 met
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
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-u
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 speci
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 s
16 matches
Mail list logo
