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. SPI Access to AD9361 on B200 (Brandon Jasionowski via USRP-users)
2. usrp N210 antenna selection (sreena pathangalil via USRP-users)
3. Re: SPI Access to AD9361 on B200 (Ian Buckley via USRP-users)
4. Using PPS input on N210 as a simple arbitrary time trigger
(Kevin Klug via USRP-users)
5. Re: usrp N210 antenna selection (Marcus M?ller via USRP-users)
6. Re: UHD from within linux vmware/windows host
(Marcus M?ller via USRP-users)
7. Re: Using PPS input on N210 as a simple arbitrary time
trigger (Marcus M?ller via USRP-users)
8. Re: Which approach to use for adding new components in USRP's
FPGA ? (Patrick Sisterhen via USRP-users)
----------------------------------------------------------------------
Message: 1
Date: Tue, 29 Apr 2014 19:28:22 -0700 (PDT)
From: Brandon Jasionowski via USRP-users <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] SPI Access to AD9361 on B200
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
According to the schematic it appears that the Cypress USB chip is SPI master
to the FPGA and the FPGA is master to the PLL chip and AD9361. After looking at
the verilog in the FPGA project, there appear to be some SPI settings registers
available to perform SPI transactions. Is it possible to use these to
read/write SPI registers on the AD9361. If so, do you have examples?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140429/dd36da2a/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 30 Apr 2014 15:59:42 +0530
From: sreena pathangalil via USRP-users <[email protected]>
To: [email protected]
Subject: [USRP-users] usrp N210 antenna selection
Message-ID:
<CAB-3VOwwWhj=mmu7jxub5kbejctbgg1y9z97bpzva5t8ncd...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi
I am working with the LFRX, LFTx daughter boards (0- 30MHz) . what should
be the antenna specifications to be used for transmission and reception.
also what should be the centre frequency of the uhd-source/sink ?.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140430/d8c3abb5/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 30 Apr 2014 11:11:29 -0700
From: Ian Buckley via USRP-users <[email protected]>
To: Brandon Jasionowski <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] SPI Access to AD9361 on B200
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
The FX3 is indeed a SPI master, but there are no SPI slave targets on the FPGA.
The FPGA has it's own internal SPI master and also simple logic that allows
either master to address the AD9361. The FPGA can also exclusively master the
SPI interface of the ADF4001 PLL.
The current public code does not use the FPGA to configure and control the
AD9361, all SPI transactions to the AD9361 originate in the FX3. This will
change in the future.
For an example of how to use the SPI master on the FPGA refer to the source
code used to configure the ADF4001?.recursive grep is your friend.
-Ian
On Apr 29, 2014, at 7:28 PM, Brandon Jasionowski via USRP-users
<[email protected]> wrote:
> According to the schematic it appears that the Cypress USB chip is SPI master
> to the FPGA and the FPGA is master to the PLL chip and AD9361. After looking
> at the verilog in the FPGA project, there appear to be some SPI settings
> registers available to perform SPI transactions. Is it possible to use these
> to read/write SPI registers on the AD9361. If so, do you have examples?
> _______________________________________________
> 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/20140430/0a7deb0f/attachment-0001.html>
------------------------------
Message: 4
Date: Wed, 30 Apr 2014 17:13:51 -0700
From: Kevin Klug via USRP-users <[email protected]>
To: [email protected]
Subject: [USRP-users] Using PPS input on N210 as a simple arbitrary
time trigger
Message-ID:
<CAAPc99G78U-QrEc=ad3m3veio2foad1ew7wd33enosck8zo...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
It is my understanding that the USRP's PPS input is only really used to
initialize the sample time to 0 or absolute time once and then uses the
external reference to count further seconds.
If this is indeed the case, would it be possible to use the PPS input as a
simple trigger for some event at an arbitrary time?
For Example:
...
// sync time to first PPS trigger
...
uhd::time_spec_t last_pps_time = usrp->get_time_last_pps();
while( 1 ){
if( last_pps_time != usrp->get_time_last_pps() ){
last_pps_time = usrp->get_time_last_pps();
// Code to transmit/receive/do something goes here
}
}
Thanks for help,
Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140430/65b5115b/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 01 May 2014 15:56:45 +0200
From: Marcus M?ller via USRP-users <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] usrp N210 antenna selection
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi Sreena,
the choice of an antenna completely depends on your application, mainly
on your carrier frequency.
That is (most probably) the same frequency you set as center frequency
for your uhd_source/sink;
that choice is completely yours (within the 0-30MHz range, though).
Note however that antennas for such low frequencies tend to be large if
they need to achieve reasonable reception.
Again, "reasonable reception", your choice of frequency and antenna
design are completely up to you and
depend heavily on your intended application.
Greetings,
Marcus
On 30.04.2014 12:29, sreena pathangalil via USRP-users wrote:
> Hi
>
> I am working with the LFRX, LFTx daughter boards (0- 30MHz) . what should
> be the antenna specifications to be used for transmission and reception.
> also what should be the centre frequency of the uhd-source/sink ?.
>
>
>
> _______________________________________________
> 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/20140501/b509b1a7/attachment-0001.html>
------------------------------
Message: 6
Date: Thu, 01 May 2014 16:07:12 +0200
From: Marcus M?ller via USRP-users <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] UHD from within linux vmware/windows host
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Hi Tech,
in my experience, UHD works even over masquerading routers reasonably well.
However, one has to realize that NAT actually introduces non-negligible
computational overhead -- thus I'd expect bridging to be less of a
hassle (I actually was assuming you were doing bridging). The 'D'
actually indicates an system-dropped network packet -- most probably
that means that VMware is either dropping packets in its virtual network
interface or is not granting your VM enough CPU to process the incoming
packets.
Each 'O' when using USB indicates that your application did not empty
the UHD receive buffers often enough and an overflow occurred.
Summing things up, I'd say your VM and/or your host seems to be
computationally underpowered.
The stalling of your flowgraph might simply be a result of these broken
signals, or (especially in the 'D' case) the fact that command/status
carrying packets got lost, and UHD ends up in a undefined state.
Greetings,
Marcus
On 30.04.2014 14:08, Tech via USRP-users wrote:
> On Tue, Apr 29, 2014 at 11:00 AM, Tech <[email protected]> wrote:
>> I've had a problem for several years across many versions of UHD and
>> gnuradio. I have a USB to gigE dongle that I use to attach to the N210. I
>> run gnuradio/uhd in vmware. If I connect the usb to gigE device in windows
>> and run apps like uhd_fft in the vmware it works as long as I specify the IP
>> address but it prints multiple Ds over ~30 seconds and then stops. However,
>> if I load the usb to gigE dongle inside vmware it also works except that it
>> stops after one O is printed.
>>
>> So it must be something to do with the routing of the messages that cause
>> the stream to restart after an overload. Any ideas what this might be or how
>> to debug are appreciated.
>>
>> Thanks,
>> Clark
> Some additional info: I found that if I put the USRP on the native
> ethernet interface I get the same behavior so USB has a performance
> penalty but it seems the root cause is something to do with how vmware
> handles networking combined with what exactly happens when overruns
> are detected. Maybe the restart stream message is at an odd port
> number or something?
>
> I did finally have some luck by using the native ethernet interface in
> bridged mode. Formerly I was in NAT mode. It eventually stalled but
> ran about half an hour.
>
> Yes, I understand the performance penalty using VM but I'm mostly
> doing narrowband stuff and most of my tools are windows based. I've
> not had much luck with gnuradio/uhd in windows in the past plus I like
> being able to lock down particular versions in a vm image. Thanks
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 7
Date: Thu, 01 May 2014 16:11:05 +0200
From: Marcus M?ller via USRP-users <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Using PPS input on N210 as a simple
arbitrary time trigger
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi Kevin,
many devices support timed commands[1], which --possibly together with
set_time_next_pps()-- might be exactly what you actually want to do.
Greetings,
Marcus
[1] look at the documentation for "set_command_time()",
http://files.ettus.com/uhd_docs/doxygen/html/classuhd_1_1usrp_1_1multi__usrp.html#a191b78b00d051d3d51c2f719361c1fb5
On 01.05.2014 02:13, Kevin Klug via USRP-users wrote:
> Hi all,
>
> It is my understanding that the USRP's PPS input is only really used to
> initialize the sample time to 0 or absolute time once and then uses the
> external reference to count further seconds.
>
> If this is indeed the case, would it be possible to use the PPS input as a
> simple trigger for some event at an arbitrary time?
>
> For Example:
>
> ...
> // sync time to first PPS trigger
> ...
> uhd::time_spec_t last_pps_time = usrp->get_time_last_pps();
>
> while( 1 ){
> if( last_pps_time != usrp->get_time_last_pps() ){
> last_pps_time = usrp->get_time_last_pps();
> // Code to transmit/receive/do something goes here
>
> }
> }
>
> Thanks for help,
> Kevin
>
>
>
> _______________________________________________
> 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/20140501/ebb7fa28/attachment-0001.html>
------------------------------
Message: 8
Date: Thu, 1 May 2014 09:49:51 -0500
From: Patrick Sisterhen via USRP-users <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Which approach to use for adding new
components in USRP's FPGA ?
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Anum,
One more thing to add to Matt's points: Consider the driver software
support associated with your decision.
A FPGA image for the X300/X310 built using LabVIEW FPGA will not be
compatible with the UHD driver stack. However, the FPGA libraries included
with the LV-FPGA support for these products include frequency shifting
blocks, fractional decimators and interpolators, and impairment
correction, so you will find a very similar set of features if you want to
customize your device with LV-FPGA. The driver experience will similarly
be purely LabVIEW.
Good luck,
Patrick Sisterhen
National Instruments
> Hi,
>
> 1. Changing HDL codes directly from source file (verilog).
> 2. Using LABView FPGA for this ?
> 3. Using MATLAB Simulink approach ?
>
> As the default FPGA source code also contains the UHD drivers
controllers,
> so
> we wont erase the existing code. for this reason, the (number 1)
approach
> can
> be used.
>
> but I was thinking that if i need to add some additional functions to
the
> FPGA
> block of USRP. can i use LABView FPGA or SIMULINK (Xilinx System
> Generator) to
> make the design first, convert it into HDL codes, create bit file and
> upload
> its image into the USRP's FPGA. Will that be possible ?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140501/12256d6e/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 45, Issue 1
*****************************************
