Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: Does send block the thread? (Martin Braun)
2. Re: Time it takes to call get_time_now() (Martin Braun)
3. Re: Any EMI Information For the E310? Thanks (Robin Coxe)
4. Re: Time it takes to call get_time_now() ([email protected])
5. Re: Time it takes to call get_time_now() (Dave NotTelling)
6. Re: Help required in Setting up USRP N200 (Sumit Kumar)
7. Re: Help required in Setting up USRP N200 (Marcus M?ller)
----------------------------------------------------------------------
Message: 1
Date: Sat, 24 Jun 2017 09:39:06 -0700
From: Martin Braun <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Does send block the thread?
Message-ID: <20170624163906.GA5527@glad0s>
Content-Type: text/plain; charset="utf-8"
On Fri, Jun 23, 2017 at 03:25:40PM -0700, Jacob Knoles wrote:
> Hey Martin,??
> I am not sure I fully understand. I get that when the samples leave the
> buffer there will be a delay before they hit the antenna. But it seems to
> me that you are suggesting that send() will not return until the samples
> leave the buffer? This does not appear to be the case for me, as I am
> doing what you have described, the burst trigger time is well in the
> future but according to my diagnostic output send() returns almost
> instantly. By time stamping the diagnostic output I can clearly see when
> the buffer fills and send blocks the thread but it is not until many many
> many samples are sent.??
Jacob,
I'm talking about your buffer (the one you pass into send). It takes
some take to read data out of the buffer, convert it to what the device
expects, packetize and put on the transport. send() could in theory even
return before the samples leave the computer UHD is running on, but it
won't return until it's safe to re-use that buffer.
-- M
> -----------------------------
> Jacob Knoles
> Compliance Engineer / Software Developer
> MiCOM Labs Inc.
> Pleasanton, CA
> On Fri, Jun 23, 2017 at 3:00 PM, Martin Braun via USRP-users
> <[email protected]> wrote:
>
> On Fri, Jun 23, 2017 at 11:46:05AM -0700, Jacob Knoles via USRP-users
> wrote:
> >?? ?? Thank you Dave that makes a lot of sense and seems to be the case
> here. I
> >?? ?? am getting much better results by forcing my function thread to
> wait after
> >?? ?? issuing all of the transmit commands for all of my bursts and in
> my output
> >?? ?? I can clearly see where the usrp buffer is filling up and causing
> the
> >?? ?? thread to block!
> >?? ?? Thanks again!!
>
> For the record, send() will block until all the samples are released
> from the buffer, and on the way to the antenna. That doesn't mean
> they're sent. You could have a send time set that's way in the future,
> and as long as the device can buffer, it'll accept samples.
>
> However, it'll block until samples were read from the user buffer. That
> means when send() returns, you can overwrite the parts of the input
> buffer that were read (and you use the return value of send() to figure
> out how many samples were read exactly).
>
> -- M
>
> >
> >?? ?? On Fri, Jun 23, 2017 at 11:03 AM, Dave NotTelling
> <[email protected]>
> >?? ?? wrote:
> >
> >?? ?? ?? I think that the send() command will block until the data is
> transmitted
> >?? ?? ?? *or* until all of the data can be copied over to RAM on the
> radio.?*??
> >?? ?? ?? Check
> >?? ?? ??
>
> out?*??http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-November/022482.html.
> >?? ?? ?? On Fri, Jun 23, 2017 at 1:17 PM, Jacob Knoles via USRP-users
> >?? ?? ?? <[email protected]> wrote:
> >
> >?? ?? ?? ?? The UHD API and several examples indicate that
> tx_stream->send(...)
> >?? ?? ?? ?? will block the thread until the samples have been sent, and
> if the
> >?? ?? ?? ?? metadata provided has a time_spec then it will block until
> that time
> >?? ?? ?? ?? has come. I am not seeing this behavior at all, in fact if
> I do not
> >?? ?? ?? ?? manually block the thread it will fly through all the send
> commands
> >?? ?? ?? ?? and bursts I need to send, end the function, thus closing
> the stream,
> >?? ?? ?? ?? and I get no output at all...?
> >?? ?? ?? ?? What is going on here??*??
> >?? ?? ?? ?? How can I send multiple bursts that are time specific?
> >?? ?? ?? ?? Please help.
> >?? ?? ?? ?? -----------------------------
> >?? ?? ?? ?? Jacob Knoles
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170624/16fea0b7/attachment-0001.asc>
------------------------------
Message: 2
Date: Sat, 24 Jun 2017 09:44:52 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Time it takes to call get_time_now()
Message-ID: <20170624164452.GB5527@glad0s>
Content-Type: text/plain; charset="utf-8"
On Fri, Jun 23, 2017 at 01:56:00PM -0400, Dave NotTelling via USRP-users wrote:
> I noticed during some testing that the N210 takes almost exactly 3 times
> as long to call get_time_now() as an X310.?? Why is that, and can it be
> tuned on the N210??? I get that the X310 is a more powerful board as a
> whole.?? It's just strange that the difference is almost exactly 3x.
> Took 49.00670971163s to ask the X310 for time 1000000 times.?? Averaged
> 0.00004900671s/iter
> Took 147.02336484520s to ask the N210 for time 1000000 times.?? Averaged
> 0.00014702336s/iter
> Thanks!
I have no explanation for why it's close to 3x, but clocks on the N210
are slower than the clocks on the X310. However, I would expect most of
the delay to come from networking latency. To call get_time_now(), we
craft a packet in UHD, send it over the network to the radio, it returns
another packet holding the current timestamp.
Looks like average worst case is about 150 us, that's not unusual for
network traffic. We don't have any plans to tune the get_time_now()
speed for N210.
Cheers,
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170624/37fb296f/attachment-0001.asc>
------------------------------
Message: 3
Date: Sat, 24 Jun 2017 09:51:16 -0700
From: Robin Coxe <[email protected]>
To: Neel Pandeya <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] Any EMI Information For the E310? Thanks
Message-ID:
<cagvti8xjnhes4cx80wwrm_-jtilxfs12mcxoqjc5nrrxyn-...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Reposting previous response to usrp-users:
Hi Konstantin. The USRP E310 just completed EMC testing in the NI
compliance lab in Austin (and passed all tests), but the report has not
been finalized yet. If you email your request to [email protected], they
can send you additional information when the test report is released.
-Robin
On Sat, Jun 24, 2017 at 7:56 AM, Neel Pandeya via USRP-users <
[email protected]> wrote:
> Hello Konstantin Matheou:
>
> We do not have any EMI data published for the E310 at the moment, but we
> are in the process of testing now, and we will have some data shortly.
> Please contact me directly off-list, and I'll share with you whatever
> information we have currently.
>
> --?Neel Pandeya
>
>
>
> On 24 June 2017 at 05:19, Marcus M?ller via USRP-users <
> [email protected]> wrote:
>
>> Hi Matheou,
>>
>> hm, what specifically are you looking for? Considering the E310 is and
>> SDR, and can by principle emit any spectrum in any 56 MHz bandwidth between
>> 70 and 6000 MHz, plus spurs caused by unwanted effects depending on the
>> oscillators' frequencies involved and the signal you're transmitting, I'm
>> not quite sure anyone can give you the data you'd need, but maybe I'm
>> approaching this the wrong way around?
>>
>> Best regards,
>>
>> Marcus
>>
>> On 06/23/2017 09:00 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN
>> TECHNOLOGIES INC] via USRP-users wrote:
>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing
>> [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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170624/b84682c4/attachment-0001.html>
------------------------------
Message: 4
Date: Sat, 24 Jun 2017 13:16:19 -0400
From: [email protected]
To: [email protected]
Subject: Re: [USRP-users] Time it takes to call get_time_now()
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
ZPU-mediated "stuff" may not be as sprightly on the N210 as the
X310--that might be another reason.
On 2017-06-24 12:44, Martin Braun via USRP-users wrote:
> On Fri, Jun 23, 2017 at 01:56:00PM -0400, Dave NotTelling via USRP-users
> wrote:
>
>> I noticed during some testing that the N210 takes almost exactly 3 times
>> as long to call get_time_now() as an X310.? Why is that, and can it be
>> tuned on the N210?? I get that the X310 is a more powerful board as a
>> whole.? It's just strange that the difference is almost exactly 3x.
>> Took 49.00670971163s to ask the X310 for time 1000000 times.? Averaged
>> 0.00004900671s/iter
>> Took 147.02336484520s to ask the N210 for time 1000000 times.? Averaged
>> 0.00014702336s/iter
>> Thanks!
>
> I have no explanation for why it's close to 3x, but clocks on the N210
> are slower than the clocks on the X310. However, I would expect most of
> the delay to come from networking latency. To call get_time_now(), we
> craft a packet in UHD, send it over the network to the radio, it returns
> another packet holding the current timestamp.
> Looks like average worst case is about 150 us, that's not unusual for
> network traffic. We don't have any plans to tune the get_time_now()
> speed for N210.
>
> Cheers,
> Martin
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170624/3f3d6b95/attachment-0001.html>
------------------------------
Message: 5
Date: Sat, 24 Jun 2017 15:59:46 -0400
From: Dave NotTelling <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Time it takes to call get_time_now()
Message-ID:
<cak6gvuou8jxyh8vz6sntrogykjbncl2spqwzkooazk80gsp...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I hadn't thought about the ZPU. Thank you both very much for the
information!
On Sat, Jun 24, 2017 at 1:16 PM, Marcus D. Leech via USRP-users <
[email protected]> wrote:
> ZPU-mediated "stuff" may not be as sprightly on the N210 as the X310--that
> might be another reason.
>
>
>
>
>
>
> On 2017-06-24 12:44, Martin Braun via USRP-users wrote:
>
> On Fri, Jun 23, 2017 at 01:56:00PM -0400, Dave NotTelling via USRP-users
> wrote:
>
> I noticed during some testing that the N210 takes almost exactly 3 times
> as long to call get_time_now() as an X310.? Why is that, and can it be
> tuned on the N210?? I get that the X310 is a more powerful board as a
> whole.? It's just strange that the difference is almost exactly 3x.
> Took 49.00670971163s to ask the X310 for time 1000000 times.? Averaged
> 0.00004900671s/iter
> Took 147.02336484520s to ask the N210 for time 1000000 times.? Averaged
> 0.00014702336s/iter
> Thanks!
>
>
> I have no explanation for why it's close to 3x, but clocks on the N210
> are slower than the clocks on the X310. However, I would expect most of
> the delay to come from networking latency. To call get_time_now(), we
> craft a packet in UHD, send it over the network to the radio, it returns
> another packet holding the current timestamp.
> Looks like average worst case is about 150 us, that's not unusual for
> network traffic. We don't have any plans to tune the get_time_now()
> speed for N210.
>
> Cheers,
> Martin
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170624/7fdb79c1/attachment-0001.html>
------------------------------
Message: 6
Date: Sun, 25 Jun 2017 13:24:47 +0200
From: Sumit Kumar <[email protected]>
To: Rizwan Akram <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Help required in Setting up USRP N200
Message-ID:
<CAOExtcQqRydcuXCivpB4SiiSNebKLX+QP_G4f=j1t1wo7m4...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hey Rizwan,
N200 is an OLD Ettus product and not an NI product. I don't think you can
use is with Labview.
Sumit
On Fri, Jun 23, 2017 at 11:32 AM, Rizwan Akram via USRP-users <
[email protected]> wrote:
> Hi Everyone,
>
> I am using N200 USRP for radio direction finder project as a replacement
> of NI USRP 2920. I am unable to connect with N200. tried to ping as well.
> still can't detect. Also, it does not appear in NI USRP Configuration
> utility. only orange light is on of the LAN cable from the inside. i will
> appreciate a lot if someone can guide me on this as i am quite new to this
> area. thanks in advance
>
> Best Regard,
> Rizwan
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
--
--
Sumit kumar
Doctoral Student, UPMC
Eurecom, BIOT
France
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170625/f982fbeb/attachment-0001.html>
------------------------------
Message: 7
Date: Sun, 25 Jun 2017 14:32:15 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Help required in Setting up USRP N200
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Rizwan,
you'll need to set up the USRP's networking correctly first, then you'll
be able to ping it, and then you can make it work with LabVIEW. Note
that LabVIEW in theory only supports the NI-USRP products (of which the
N200 is none, but some N210+daughterboard combinations are), but in
practice I think it should work.
So, first correctly set up your N200 as explained in
http://files.ettus.com/manual/page_usrp2.html and especially the
troubleshooting section on there.
My gut feeling is that the IP address you set for the N200 isn't what
you're expecting it to be. Luckily, that's rather easy to fix
(especially under Linux).
Best regards,
Marcus
On 06/23/2017 11:32 AM, Rizwan Akram via USRP-users wrote:
> Hi Everyone,
>
> I am using N200 USRP for radio direction finder project as a
> replacement of NI USRP 2920. I am unable to connect with N200. tried
> to ping as well. still can't detect. Also, it does not appear in NI
> USRP Configuration utility. only orange light is on of the LAN cable
> from the inside. i will appreciate a lot if someone can guide me on
> this as i am quite new to this area. thanks in advance
>
> Best Regard,
> Rizwan
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170625/27319970/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 82, Issue 24
******************************************
