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: UHD compatibility with RF Boards (Martin Braun)
2. Data formatting questions for gnuradio complex to Q16 in
RFNOC (Swanson, Craig)
3. Re: UHD compatibility with RF Boards ([email protected])
4. Re: Data formatting questions for gnuradio complex to Q16 in
RFNOC (Martin Braun)
5. Re: X310 Temperature Sensor (Martin Braun)
6. Re: Data formatting questions for gnuradio complex to Q16 in
RFNOC (Marcus D. Leech)
7. Re: Data formatting questions for gnuradio complex to Q16 in
RFNOC (Ian Buckley)
8. Re: UBX can not transmit signal (Michael West)
9. daughtercard not recognized by LabVIEW fpga (apchar)
10. Re: daughtercard not recognized by LabVIEW fpga (Robin Coxe)
11. Re: abou LP0965 (john liu)
12. Re: abou LP0965 (Marcus D. Leech)
13. Re: UBX can not transmit signal (liu Jong)
14. Re: abou LP0965 (Ron Economos)
15. Re: abou LP0965 (Marcus D. Leech)
16. Announcing the new Ettus Research Knowledge Base (Neel Pandeya)
17. Re: Data formatting questions for gnuradio complex to Q16 in
RFNOC (Marcus M?ller)
18. Multiple B210s firmware update issue (Joshua Sendall)
19. Re: Decaying RX energy & oscillations on N210+RFX2450 Re:
Frequency synchronization problem (Marc Bauduin)
20. NEWSDR in Boston in Two Weeks (Neel Pandeya)
21. Pulse Radar (avinash kalyanaraman)
----------------------------------------------------------------------
Message: 1
Date: Tue, 17 May 2016 10:44:41 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] UHD compatibility with RF Boards
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Jonas,
UBX support was added in 3.8.2. Please note that we've fixed some issues
in the meantime, so I recommend going to the latest version (3.9.4) if
possible.
M
On 05/17/2016 12:30 AM, Schild Jonas via USRP-users wrote:
> Hi all
>
>
>
> I was trying to find some information about which UHD version is
> compatible with which RF Daughter board. Specifically, I?m wondering if
> the UBX 10-6000 MHz Rx/Tx (160MHz) is compatible with UHD 3.9.1.
>
> Any help is appreciated.
>
>
>
> Regards,
>
> Jonas
>
>
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 2
Date: Tue, 17 May 2016 17:57:48 +0000
From: "Swanson, Craig" <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: [USRP-users] Data formatting questions for gnuradio complex
to Q16 in RFNOC
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
?Jonathon,
I wanted to make sure I understood the data formatting issues from gnuradio
complex file sink to m_axis_data_tdata.
I generated a waveform in gnuradio that creates a file sink with what I believe
is IEEE 754 data. These are two 32 bit real and complex floating point data
values.
Which is sent first? The real or the imaginary value?
When the arm sends the data to noc_block_moving_avg, it sends 64 bits in Q16
format over i_tdata. Then RFNoC noc_shell and axi_wrapper sends two 16-bit Q16
values over the m_axis_data_tdata bus in pairs.
Is this correct?
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160517/9f77ab22/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 17 May 2016 14:02:03 -0400
From: [email protected]
To: Martin Braun <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] UHD compatibility with RF Boards
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
One can always check the git log and/or release notes to see when
support for a given board was added.
On 2016-05-17 13:44, Martin Braun via USRP-users wrote:
> Jonas,
>
> UBX support was added in 3.8.2. Please note that we've fixed some issues
> in the meantime, so I recommend going to the latest version (3.9.4) if
> possible.
>
> M
>
> On 05/17/2016 12:30 AM, Schild Jonas via USRP-users wrote:
>
>> Hi all
>>
>> I was trying to find some information about which UHD version is
>> compatible with which RF Daughter board. Specifically, I'm wondering if
>> the UBX 10-6000 MHz Rx/Tx (160MHz) is compatible with UHD 3.9.1.
>>
>> Any help is appreciated.
>>
>> Regards,
>>
>> Jonas
>>
>> _______________________________________________
>> 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/20160517/899608d2/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 17 May 2016 11:39:58 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Data formatting questions for gnuradio
complex to Q16 in RFNOC
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
Craig,
when we send integer data to the FPGA (sc16 format), the on-the-wire
format (in *little endian*) is 16 bits Q, 16 bits I. This is
unintuitive, and goes back to VITA-49, but the important thing is *you
don't need to care about it*. After the conversion, you'll either have a
valid std::complex<int16_t> (if your software uses sc16) or a valid
std::complex<float> (if your software uses fc32). (Note that the C++
standard defines std::complex<> such that it looks the same in memory as
an array, with index 0 being I, index 1 being Q).
If you want to send *float* data *to the FPGA*, I recommend sending
32-bits I, then 32-bits Q. Remember not only your FPGA will be more
heavily utilized, but also the I/Os will get heavier load.
In your Verilog, the output of the 32-bit output bus of AXI wrapper is
16-bit I, 16-bit Q.
Cheers,
Martin
On 05/17/2016 10:57 AM, Swanson, Craig via USRP-users wrote:
> ?Jonathon,
>
> I wanted to make sure I understood the data formatting issues from
> gnuradio complex file sink to m_axis_data_tdata.
>
>
> I generated a waveform in gnuradio that creates a file sink with what I
> believe is IEEE 754 data. These are two 32 bit real and complex
> floating point data values.
>
>
> Which is sent first? The real or the imaginary value?
>
>
> When the arm sends the data to noc_block_moving_avg, it sends 64 bits in
> Q16 format over i_tdata. Then RFNoC noc_shell and axi_wrapper sends two
> 16-bit Q16 values over the m_axis_data_tdata bus in pairs.
>
>
> Is this correct?
>
>
> Craig
>
>
> *Craig F. Swanson*
> */Research Engineer II
> /*
> */Information and Communications Laboratory/*
> */Communications, Systems, and Spectrum Division/*
> /Georgia Tech Research Institute/
> /Room 560
> 250 14th St NW
> /
> /Atlanta, GA 30318/
> /Cell: 770.298.9156/
> http://www.gtri.gatech.edu
> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 5
Date: Tue, 17 May 2016 14:10:58 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] X310 Temperature Sensor
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Simon,
no, we don't expose the Kintex7 temperature sensor through UHD. However,
are you trying to log the *die* temperature? Or a temperature inside the
case?
-- Martin
On 05/14/2016 09:07 AM, Simon Olvhammar via USRP-users wrote:
> Hi,
>
> I'm searching for a way to log temperature sensor readings on the Ettus
> X310 + UBX160/SBX120 in my software.
> As far as I know there is only a sensor on the FPGA?, and I can access
> it through xilinx software.
> However for several reasons I need it be exposed in my Python program.
> So I'm wondering if anyone know of a way to access the sensor through a
> shellscript or even directly in Python/GNURadio?
>
> Best regards
> Simon
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 6
Date: Tue, 17 May 2016 17:17:25 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Data formatting questions for gnuradio
complex to Q16 in RFNOC
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
On 05/17/2016 02:39 PM, Martin Braun via USRP-users wrote:
> Craig,
>
> when we send integer data to the FPGA (sc16 format), the on-the-wire
> format (in *little endian*) is 16 bits Q, 16 bits I. This is
> unintuitive, and goes back to VITA-49, but the important thing is *you
> don't need to care about it*. After the conversion, you'll either have a
> valid std::complex<int16_t> (if your software uses sc16) or a valid
> std::complex<float> (if your software uses fc32). (Note that the C++
> standard defines std::complex<> such that it looks the same in memory as
> an array, with index 0 being I, index 1 being Q).
>
> If you want to send *float* data *to the FPGA*, I recommend sending
> 32-bits I, then 32-bits Q. Remember not only your FPGA will be more
> heavily utilized, but also the I/Os will get heavier load.
>
> In your Verilog, the output of the 32-bit output bus of AXI wrapper is
> 16-bit I, 16-bit Q.
>
> Cheers,
> Martin
>
Hmmm, it is possible to do a table-drive float-to-short conversion.
That's not faster than the explicit conversion instructions on the x86
family,
but could be an approach in an FPGA. You only need 16-bits of the
32-bit IEEE floating-point word to get not-bad precision using this
approach.
------------------------------
Message: 7
Date: Tue, 17 May 2016 14:34:25 -0700
From: Ian Buckley <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Data formatting questions for gnuradio
complex to Q16 in RFNOC
Message-ID:
<CAM_0ocEn1fp4rrGLc8uWy0kTgGB99J_iZKhbZvwsaGrEaZ7=y...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
FC32 to SC16 conversion in the FPGA is very inexpensive, the cost is in the
doubled bandwidth in the transport.
https://github.com/EttusResearch/fpga/blob/b108e88865ee0fa68e685461681d8ca6a320b937/usrp3/lib/vita/chdr_32f_to_16sc.v
https://github.com/EttusResearch/fpga/blob/b108e88865ee0fa68e685461681d8ca6a320b937/usrp3/lib/vita/float_to_iq.v
On Tue, May 17, 2016 at 2:17 PM, Marcus D. Leech via USRP-users <
[email protected]> wrote:
> On 05/17/2016 02:39 PM, Martin Braun via USRP-users wrote:
>
>> Craig,
>>
>> when we send integer data to the FPGA (sc16 format), the on-the-wire
>> format (in *little endian*) is 16 bits Q, 16 bits I. This is
>> unintuitive, and goes back to VITA-49, but the important thing is *you
>> don't need to care about it*. After the conversion, you'll either have a
>> valid std::complex<int16_t> (if your software uses sc16) or a valid
>> std::complex<float> (if your software uses fc32). (Note that the C++
>> standard defines std::complex<> such that it looks the same in memory as
>> an array, with index 0 being I, index 1 being Q).
>>
>> If you want to send *float* data *to the FPGA*, I recommend sending
>> 32-bits I, then 32-bits Q. Remember not only your FPGA will be more
>> heavily utilized, but also the I/Os will get heavier load.
>>
>> In your Verilog, the output of the 32-bit output bus of AXI wrapper is
>> 16-bit I, 16-bit Q.
>>
>> Cheers,
>> Martin
>>
>> Hmmm, it is possible to do a table-drive float-to-short conversion.
> That's not faster than the explicit conversion instructions on the x86
> family,
> but could be an approach in an FPGA. You only need 16-bits of the
> 32-bit IEEE floating-point word to get not-bad precision using this
> approach.
>
>
>
>
> _______________________________________________
> 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/20160517/cab9ce80/attachment-0001.html>
------------------------------
Message: 8
Date: Tue, 17 May 2016 15:23:08 -0700
From: Michael West <[email protected]>
To: liu Jong <[email protected]>
Cc: "[email protected]" <[email protected]>, Ettus
Research Support <[email protected]>
Subject: Re: [USRP-users] UBX can not transmit signal
Message-ID:
<cam4xkrpew05sqed8mkuwboz2ohzjsjskoosh7+8boeuqoye...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Jon,
I was able to use UHD 3.9.4 and a 158277A-02L UBX board to transmit just
fine. Please provide more information about your set up. What type of
USRP are you using? What are your frequency and gain settings? What are
you using to transmit? What are you using to verify transmission?
Regards,
Michael
On Mon, May 16, 2016 at 5:57 PM, liu Jong <[email protected]> wrote:
> Hi,Michael,
> there is no error information,and the TX/RX port is also lighting.But it
> can not transmit signal.
> thank you.
> Jon
>
>
> 2016-05-16 21:56 GMT+08:00 Michael West <[email protected]>:
>
>> Hi Jon,
>>
>> There is no firmware on the UBX and there is no difference in software
>> for the different versions. What is the exact error you are seeing?
>>
>> Regards,
>> Michael
>>
>> On Sun, May 15, 2016 at 10:54 PM, liu Jong <[email protected]> wrote:
>>
>>> Hi Michael,
>>> thank you for your davices.i tried it,but no use.But if i change to
>>> 158277B-01L
>>> UBX,it works ok.Can UBX be flashed firmware,or some other measures i should
>>> take?
>>> best regards
>>> Jon
>>>
>>> 2016-05-13 22:42 GMT+08:00 Michael West <[email protected]>:
>>>
>>>> Hi Jon,
>>>>
>>>> There is an issue with some components on the bottom side of the UBX
>>>> being too close to the mounting holes and shorting out to the daughterboard
>>>> standoffs on the X300/X310. You can rotate the existing standoffs so they
>>>> provide more clearance for the components or install thinner standoffs.
>>>>
>>>> I'm not sure, but I thought the UBX shipped with the thinner
>>>> standoffs. If not, you can contact [email protected] to request them.
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>> On Thu, May 12, 2016 at 11:58 PM, liu Jong via USRP-users <
>>>> [email protected]> wrote:
>>>>
>>>>> Dear all,
>>>>> We have 3 pieces of UBX-40 board?one of which the part
>>>>> number is 158277B-01L and it send and receive signals normally.the others
>>>>> of part number are all 158277A-01L and they only received signal, but
>>>>> couldn't send out a signal. We tested this on the uhd3.9.4 . According
>>>>> to
>>>>> different part number, need we to do some special settings?
>>>>>
>>>>> thank you
>>>>> best regards
>>>>> Jon
>>>>>
>>>>> _______________________________________________
>>>>> 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/20160517/d56698a8/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 17 May 2016 22:23:20 +0000 (UTC)
From: apchar <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] daughtercard not recognized by LabVIEW fpga
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
We have an x310 with 2 ubx-160 daughtercards ?. I am trying to get it working
with LabVIEW FPGA. I have the new 15.5 drivers installed on a Windows 7 PC.
When I try the simple ni-usrp streaming project rx streaming (host) it gags
with an error message that the daughtercard is unsupported. Digging into the
LabVIEW internals I found "decode daughterboard names.vi " that is throwing the
error. The IDs listed for the ubx are 73..7a. Are these wrong? I tried short
circuiting this error check and I get past this but no data comes out. What
more can I do?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160517/bcca34ed/attachment-0001.html>
------------------------------
Message: 10
Date: Tue, 17 May 2016 16:23:54 -0700
From: Robin Coxe <[email protected]>
To: "[email protected]" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] daughtercard not recognized by LabVIEW fpga
Message-ID:
<cagvti8wvbpktmt-y0z39ug1n+jfn1+aw6bycvvp8dafz95r...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi apchar. We don't ordinarily provide LabVIEW support on the usrp-users
list, but our colleagues on the NI-USRP team have the following advice for
those who would like to run LabVIEW on an Ettus-branded USRP X310. The
UBX-160 is not officially supported in NI-USRP yet, but there is a beta
release available.
1) Make sure you have LV 2015 installed.
2) Download and install the 15.5 beta version of NI-USRP from
www.ni.com/beta.
3) Then, you have to run the X310 bringup utility. Ettus Research-branded
X310s are not shipped with LabVIEW support by default.
This tool resides right beside all the other tools in:
C:\Program Files (x86)\National Instruments\LabVIEW 2015\vi.lib\LabVIEW
Targets\FPGA\USRP\niusrprio_tools.llb
Named ?Initialize X310.vi?
The tool wants 3 things from the user
? The device name (RIO0, etc)
? The motherboard part number
? And finally both daughterboard part numbers. These much match
(I.e.: No mismatching DBs)
The user can also give their DBs a serial number if they wish.
Then they just hit go. As long as there are no error then everything will
be setup to use with LVFPGA.
Try to run the sample projects. For additional LabVIEW and LabVIEW FPGA
support, please direct your inquiries to ni.com/support.
-Robin
On Tue, May 17, 2016 at 3:23 PM, apchar via USRP-users <
[email protected]> wrote:
> We have an x310 with 2 ubx-160 daughtercards . I am trying to get it
> working with LabVIEW FPGA. I have the new 15.5 drivers installed on a
> Windows 7 PC. When I try the simple ni-usrp streaming project rx streaming
> (host) it gags with an error message that the daughtercard is unsupported.
> Digging into the LabVIEW internals I found "decode daughterboard names.vi
> " that is throwing the error. The IDs listed for the ubx are 73..7a. Are
> these wrong? I tried short circuiting this error check and I get past this
> but no data comes out. What more can I do?
>
> _______________________________________________
> 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/20160517/62c3fd5a/attachment-0001.html>
------------------------------
Message: 11
Date: Wed, 18 May 2016 09:29:04 +0800
From: john liu <[email protected]>
To: James Humphries <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] abou LP0965
Message-ID:
<CAF6NnT+3zsJyM4kVA=frr8dphxjtskkw4jw7k8aafrxr+vz...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,James,
thank you!
the typcial antenna factors:
900MHz 24.0
1.0GHz 24.2
the 24.0 and 24.2 means what?
best regards
John
On Tue, May 17, 2016 at 9:46 PM, James Humphries <[email protected]>
wrote:
> Hi John,
>
> Some information about the antenna here:
>
> http://www.wa5vjb.com/pcb-pdfs/LP8565.pdf
>
> I believe the direction of maximum gain is indicated next to the SMA
> connector on the PCB. There should be an arrow that points away from the
> narrower end of the antenna.
>
> -Trip
>
> On Tue, May 17, 2016 at 5:42 AM, john liu via USRP-users <
> [email protected]> wrote:
>
>> Dear all,
>> I need to know about the angle or direction parameter of LP0965.where can
>> i find it?
>> thank you
>> best regards
>> John
>>
>> _______________________________________________
>> 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/20160518/9841be00/attachment-0001.html>
------------------------------
Message: 12
Date: Tue, 17 May 2016 21:37:25 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] abou LP0965
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 05/17/2016 09:29 PM, john liu via USRP-users wrote:
> Hi,James,
> thank you!
> the typcial antenna factors:
> 900MHz 24.0
> 1.0GHz 24.2
> the 24.0 and 24.2 means what?
> best regards
> John
>
Forward-gain in linear units.
>
> On Tue, May 17, 2016 at 9:46 PM, James Humphries
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hi John,
>
> Some information about the antenna here:
>
> http://www.wa5vjb.com/pcb-pdfs/LP8565.pdf
>
> I believe the direction of maximum gain is indicated next to the
> SMA connector on the PCB. There should be an arrow that points
> away from the narrower end of the antenna.
>
> -Trip
>
> On Tue, May 17, 2016 at 5:42 AM, john liu via USRP-users
> <[email protected] <mailto:[email protected]>>
> wrote:
>
> Dear all,
> I need to know about the angle or direction parameter of
> LP0965.where can i find it?
> thank you
> best regards
> John
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160517/ddb5b3f5/attachment-0001.html>
------------------------------
Message: 13
Date: Wed, 18 May 2016 09:43:17 +0800
From: liu Jong <[email protected]>
To: Michael West <[email protected]>
Cc: "[email protected]" <[email protected]>, Ettus
Research Support <[email protected]>
Subject: Re: [USRP-users] UBX can not transmit signal
Message-ID:
<caeui2n1_1y_x4ufhi9zdofg+bazqbc0g43ucap5czj5z9we...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,Michael,
I uesd N210+UBX?and just transmit a sine signal.i tred the gain from 0 to
38 and the frequency 10M to 6GHz.i receive the signal when i used 158277B-01L
,but with 158277A-01L can not.
is it possible that there is some thing wrong with hardware?
thank you
best regards
Jon
2016-05-18 6:23 GMT+08:00 Michael West <[email protected]>:
> Hi Jon,
>
> I was able to use UHD 3.9.4 and a 158277A-02L UBX board to transmit just
> fine. Please provide more information about your set up. What type of
> USRP are you using? What are your frequency and gain settings? What are
> you using to transmit? What are you using to verify transmission?
>
> Regards,
> Michael
>
> On Mon, May 16, 2016 at 5:57 PM, liu Jong <[email protected]> wrote:
>
>> Hi,Michael,
>> there is no error information,and the TX/RX port is also lighting.But it
>> can not transmit signal.
>> thank you.
>> Jon
>>
>>
>> 2016-05-16 21:56 GMT+08:00 Michael West <[email protected]>:
>>
>>> Hi Jon,
>>>
>>> There is no firmware on the UBX and there is no difference in software
>>> for the different versions. What is the exact error you are seeing?
>>>
>>> Regards,
>>> Michael
>>>
>>> On Sun, May 15, 2016 at 10:54 PM, liu Jong <[email protected]>
>>> wrote:
>>>
>>>> Hi Michael,
>>>> thank you for your davices.i tried it,but no use.But if i change to
>>>> 158277B-01L
>>>> UBX,it works ok.Can UBX be flashed firmware,or some other measures i should
>>>> take?
>>>> best regards
>>>> Jon
>>>>
>>>> 2016-05-13 22:42 GMT+08:00 Michael West <[email protected]>:
>>>>
>>>>> Hi Jon,
>>>>>
>>>>> There is an issue with some components on the bottom side of the UBX
>>>>> being too close to the mounting holes and shorting out to the
>>>>> daughterboard
>>>>> standoffs on the X300/X310. You can rotate the existing standoffs so they
>>>>> provide more clearance for the components or install thinner standoffs.
>>>>>
>>>>> I'm not sure, but I thought the UBX shipped with the thinner
>>>>> standoffs. If not, you can contact [email protected] to request
>>>>> them.
>>>>>
>>>>> Regards,
>>>>> Michael
>>>>>
>>>>> On Thu, May 12, 2016 at 11:58 PM, liu Jong via USRP-users <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> Dear all,
>>>>>> We have 3 pieces of UBX-40 board?one of which the part
>>>>>> number is 158277B-01L and it send and receive signals normally.the others
>>>>>> of part number are all 158277A-01L and they only received signal, but
>>>>>> couldn't send out a signal. We tested this on the uhd3.9.4 . According
>>>>>> to
>>>>>> different part number, need we to do some special settings?
>>>>>>
>>>>>> thank you
>>>>>> best regards
>>>>>> Jon
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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/20160518/448b778d/attachment-0001.html>
------------------------------
Message: 14
Date: Tue, 17 May 2016 19:46:43 -0700
From: Ron Economos <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] abou LP0965
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
gain in dBi = 20log(MHz) - AF - 29.79
The gain of the antenna is 5.3 dBi at 900 MHz and 6.0 dBi at 1000 MHz.
Ron
On 05/17/2016 06:29 PM, john liu via USRP-users wrote:
> Hi,James,
> thank you!
> the typcial antenna factors:
> 900MHz 24.0
> 1.0GHz 24.2
> the 24.0 and 24.2 means what?
> best regards
> John
>
>
> On Tue, May 17, 2016 at 9:46 PM, James Humphries
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hi John,
>
> Some information about the antenna here:
>
> http://www.wa5vjb.com/pcb-pdfs/LP8565.pdf
>
> I believe the direction of maximum gain is indicated next to the
> SMA connector on the PCB. There should be an arrow that points
> away from the narrower end of the antenna.
>
> -Trip
>
> On Tue, May 17, 2016 at 5:42 AM, john liu via USRP-users
> <[email protected] <mailto:[email protected]>>
> wrote:
>
> Dear all,
> I need to know about the angle or direction parameter of
> LP0965.where can i find it?
> thank you
> best regards
> John
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160517/dbf125ab/attachment-0001.html>
------------------------------
Message: 15
Date: Tue, 17 May 2016 22:59:50 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] abou LP0965
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 05/17/2016 10:46 PM, Ron Economos via USRP-users wrote:
> gain in dBi = 20log(MHz) - AF - 29.79
>
> The gain of the antenna is 5.3 dBi at 900 MHz and 6.0 dBi at 1000 MHz.
>
> Ron
I was, clearly, asleep during electromagnetics....
I've always seen antennas quoted in either dBd, or dBi.
>
> On 05/17/2016 06:29 PM, john liu via USRP-users wrote:
>> Hi,James,
>> thank you!
>> the typcial antenna factors:
>> 900MHz 24.0
>> 1.0GHz 24.2
>> the 24.0 and 24.2 means what?
>> best regards
>> John
>>
>>
>> On Tue, May 17, 2016 at 9:46 PM, James Humphries
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> Hi John,
>>
>> Some information about the antenna here:
>>
>> http://www.wa5vjb.com/pcb-pdfs/LP8565.pdf
>>
>> I believe the direction of maximum gain is indicated next to the
>> SMA connector on the PCB. There should be an arrow that points
>> away from the narrower end of the antenna.
>>
>> -Trip
>>
>> On Tue, May 17, 2016 at 5:42 AM, john liu via USRP-users
>> <[email protected]> wrote:
>>
>> Dear all,
>> I need to know about the angle or direction parameter of
>> LP0965.where can i find it?
>> thank you
>> best regards
>> John
>>
>>
>
>
>
> _______________________________________________
> 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/20160517/e03356c4/attachment-0001.html>
------------------------------
Message: 16
Date: Tue, 17 May 2016 23:43:27 -0700
From: Neel Pandeya <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] Announcing the new Ettus Research Knowledge Base
Message-ID:
<cacaxmv8_rhcc7nncytn5+phwntdyj32dnvjt2-f3cldb60j...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Ettus Research would like to announce the launch of an all-new Knowledge
Base (KB) at the URL listed below. The KB is actively being developed, and
will continually be updated and expanded, especially over the next few
weeks and months. Please have a look, and thank you for your continued
support!
https://kb.ettus.com/
--Neel Pandeya
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160517/2c37cd7b/attachment-0001.html>
------------------------------
Message: 17
Date: Wed, 18 May 2016 11:56:31 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Data formatting questions for gnuradio
complex to Q16 in RFNOC
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Just wanting to add that you also probably don't save much on the host
side in terms of CPU ? the conversion between on-the-wire and host
format is also responsible for getting the data from the bus packets
into UHD buffers, and in reality, the bandwidth of that operation is
about as limiting as the CPU load caused by reordering a couple of bytes
and casting them to another format with SIMD instructions (which UHD
does, if you're on a CPU that has NEON or SSE2.
Best regards,
Marcus
On 17.05.2016 23:34, Ian Buckley via USRP-users wrote:
> FC32 to SC16 conversion in the FPGA is very inexpensive, the cost is
> in the doubled bandwidth in the transport.
> https://github.com/EttusResearch/fpga/blob/b108e88865ee0fa68e685461681d8ca6a320b937/usrp3/lib/vita/chdr_32f_to_16sc.v
> https://github.com/EttusResearch/fpga/blob/b108e88865ee0fa68e685461681d8ca6a320b937/usrp3/lib/vita/float_to_iq.v
>
> On Tue, May 17, 2016 at 2:17 PM, Marcus D. Leech via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> On 05/17/2016 02:39 PM, Martin Braun via USRP-users wrote:
>
> Craig,
>
> when we send integer data to the FPGA (sc16 format), the
> on-the-wire
> format (in *little endian*) is 16 bits Q, 16 bits I. This is
> unintuitive, and goes back to VITA-49, but the important thing
> is *you
> don't need to care about it*. After the conversion, you'll
> either have a
> valid std::complex<int16_t> (if your software uses sc16) or a
> valid
> std::complex<float> (if your software uses fc32). (Note that
> the C++
> standard defines std::complex<> such that it looks the same in
> memory as
> an array, with index 0 being I, index 1 being Q).
>
> If you want to send *float* data *to the FPGA*, I recommend
> sending
> 32-bits I, then 32-bits Q. Remember not only your FPGA will be
> more
> heavily utilized, but also the I/Os will get heavier load.
>
> In your Verilog, the output of the 32-bit output bus of AXI
> wrapper is
> 16-bit I, 16-bit Q.
>
> Cheers,
> Martin
>
> Hmmm, it is possible to do a table-drive float-to-short
> conversion. That's not faster than the explicit conversion
> instructions on the x86 family,
> but could be an approach in an FPGA. You only need 16-bits of
> the 32-bit IEEE floating-point word to get not-bad precision using
> this approach.
>
>
>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160518/644f6aa3/attachment-0001.html>
------------------------------
Message: 18
Date: Wed, 18 May 2016 13:25:16 +0200
From: Joshua Sendall <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Multiple B210s firmware update issue
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi Everyone,
I have found an issue upon trying to use multiple create multiple B210s. The
issue arises when the second multi_usrp object is created (I have to use 2,
because 2 B210s are not supported on a single multi_usrp object). After
searching for the GPSDO a libusb error is thrown (see the attached
screenshot). The issue arose upon updating UHD to version 3.9.x, but the
program continues to work with previous versions.
Has anyone else had success running multiple board configurations with the
newer software, or have any suggestions for a solution?
Kind regards,Joshua Sendall
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160518/b0900df6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: LIB usb error.PNG
Type: image/png
Size: 27459 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160518/b0900df6/attachment-0001.PNG>
------------------------------
Message: 19
Date: Wed, 18 May 2016 14:47:02 +0200
From: Marc Bauduin <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Decaying RX energy & oscillations on
N210+RFX2450 Re: Frequency synchronization problem
Message-ID:
<CA+ekp-YnjmK2bEDPgqnPGQ6Ukfv4uRx=y-J=lmjngb7r19u...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Marcus,
I disabled the dc offset filter in this scenario with
set_rx_dc_offset(false).
I would not be surprise to see some oscillations at the beginning of each
step because of the finite bandwidth of the front-end. But, in this case,
they would decrease to finally disappear in the noise of the communication.
But it is not the case.
Just to be sure that my scenario is clear. I do a communication between two
USRPs. The signal which is created by the Tx USRP is a step signal in
baseband.
For the synchronisation, I use a 10 MHz square wave. This one is generated
with a clock-tamer 1.30.
I sent you four figures. On the first one (stepSignal.png), you can see the
step signal for different interpolation factor when the signal is
transmitted around 2.43 GHz. The second one (stepSignal240.png) is also a
step signal but with a carrier frequency of 2.4 GHz.
The third figure (stepSpectre.png) is the spectrum of one step of my signal
transmitted with an amplitude of 0.5. I used different interpolation/
decimation factors. As you can see the received spectrum is very different
from the spectrum of constant signal. It can explain the degradation that I
observe on "stepSignal.png" when I reduce the interpolation factor. It
explain also the presence of these oscillations.
Finally, the fourth figure (stepSpectreAmp16.png) is the spectrum of some
steps with an interpolation factor of 16 and a carrier frequency of 2.43
GHz. We can see the spectrum of three different amplitudes. It is
interesting to see that the component around -2.85 MHz decreases in the
same proportion as the DC component (which is the amplitude of the step).
The amplitude of the component around -1.43 MHz does not depend on the
amplitude of the step (this is very strange). For the peak around 2.85 MHz,
it seems that it comes from the non-linear behavior of some components.
This one is not a surprise because, with an amplitude of 0.9, I am very
close to the saturation point of the power amplifier of the transmitter.
I also made an experiment where I removed the antenna from my Rx USRP and
evaluate the received spectrum. Normally, it should only be a white noise.
But I also observe a peak around -1.43 MHz. It seems that this component is
always present in the receiver. I tried with another USRP and I have the
same result. The position of the peak only changes with the carrier
frequency. It can explain why I have a so different result between these
two carrier frequencies.
Do you know the origin of this peak?
I hope that these results are easy to read.
Thanks in advance for your answers.
Marc
2016-05-13 13:06 GMT+02:00 Marcus M?ller <[email protected]>:
> Hi Marc,
>
> On 13.05.2016 10:55, Marc Bauduin via USRP-users wrote:
>
> Thanks for the information.
>
> I reduced decimation and interpolation factor to 4. In this case, the CIC
> filter is bypassed and the decimation is only done with the help of two
> half-band filters. Is that right?
>
> yes!
>
>
> In that case, I don't observe the decay anymore but each step are affected
> by an important oscillation. I checked the spectrum of each step and I can
> see some important peak for some specific frequencies. I still need to find
> their origin.
>
> can you give us plots or samples? What kind of oscillation, is it
> decaying, constant in frequency?
>
> Like Marcus L., my first suspicion here is the rx_dc_offset filter; did
> you disable that in this case?
> Oscillations at a step wouldn't surprise me; after all, all linear systems
> have what is called a step response, and so do our halfband filters, and
> the analog baseband filters on the daughterboard.
>
>
> I also changed the carrier frequency. Previously, I worked around 2.4 GHz.
> Now I tried 2.43 GHz. In this case, I still observe important oscillations
> with an interpolation factor of 4. If I reduce the sampling frequency, I am
> now able to recover the step signal.
>
> How do you synchronize your signal generator to the USRP? What's the
> generators' bandwidth.
> Point is that you physically can't produce a proper step function without
> any oscillations ? that would simply have infinite bandwidth.
>
> My suspicion is that there might be analog non-perfections going on.
> Again, can you give us a plot of what you're seeing?
> How does your signal generator connect to the USRP?
> What happens if you reduce the power of the signal and the gain of the
> daughterboard?
>
> Best regards,
> Marcus
>
>
> Any idea of why the results are so different when I change the carrier
> frequency?
>
> 2016-05-10 16:17 GMT+02:00 <[email protected]>:
>
>> It's a CIC decimator with FIR-based clean-up filters, as far as I know.
>>
>>
>>
>>
>> On 2016-05-10 05:10, Marc Bauduin via USRP-users wrote:
>>
>> I increased the duration of each step to 1e4 samples. I made this
>> simulation for several interpolation factors. Each time, I can approximate
>> the decay with an exponential decay exp(-t/d) where d = 1.7e-4 seconds.
>> This value is a little bit lower (1.2e-4 seconds) for an interpolation
>> factor of 8.
>>
>> I am not surprised to see a peak at the beginning of each step. The
>> problem is that the decay always go back the same value. I expected that,
>> after some oscillation due to the decimation filter, I could observe the
>> different steps.
>>
>> What kind of filter is used for the decimation?
>>
>> 2016-05-06 16:51 GMT+02:00 <[email protected]>:
>>
>>> What is the period of the decay? This may just be the decimation
>>> filters reacting to a step change in the input, and it's just more obvious
>>> when the devices are strictly synchronous. That's just a guess.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 2016-05-06 05:09, Marc Bauduin via USRP-users wrote:
>>>
>>> Maybe I answered too quickly.
>>>
>>> I made a new test where I send a step signal (0.1, 0.2, ..., 1). Each
>>> value is maintained during 1e3 samples. If I look at the amplitude of the
>>> received signal in baseband, I am able to recover this step signal if the
>>> USRPs are not synchronized. But if I synchronize them with the 10MHz clock,
>>> I can see quick changes in amplitude followed by a decay. As if the radio
>>> still tried to compensate a DC offset.
>>>
>>> I used the function set_rx_dc_offset(false) or
>>> set_rx_dc_offset(false)(std::complex<double>(a,b)). The only difference is
>>> the value reached after the decay.
>>>
>>>
>>> 2016-04-27 22:24 GMT+02:00 Marc Bauduin < <[email protected]>
>>> [email protected]>:
>>>
>>>> Thank you for your answer. It was effectively that.I used the
>>>> function set_rx_dc_offset(false) to remove the algorithm and I don't
>>>> observe this effect anymore when I send a signal constant in baseband.
>>>>
>>>> 2016-04-27 15:39 GMT+02:00 Marcus D. Leech via USRP-users <
>>>> <[email protected]>[email protected]>:
>>>>
>>>>> On 04/27/2016 08:40 AM, Herlook Search via USRP-users wrote:
>>>>>
>>>>>> Hi everyone,
>>>>>>
>>>>>> I use two USRP N210 with the RFX2450. I manipulate them in C++.
>>>>>>
>>>>>> I would like to characterize the USRPs. In that way, I send very
>>>>>> simple signals, as a constant signal in baseband. When I send this
>>>>>> signal,
>>>>>> I observe a circle in baseband due to the CFO. This is what I expected.
>>>>>>
>>>>>> If I send the same signal when the USRPs are synchronized with the
>>>>>> same 10 MHz clock (I use an external square wave generator), I see that
>>>>>> the
>>>>>> amplitude of this sequence quickly decreases through time. If I use an
>>>>>> alternate sequence of {-1;+1}, I also observe that its amplitude
>>>>>> decreases.
>>>>>>
>>>>>> But it seems that the synchronisation works because, when I do an
>>>>>> OFDM communication or a single carrier communication with the 10 MHz
>>>>>> clock,
>>>>>> I can recover my QAM constellation without CFO.
>>>>>>
>>>>>> Can you confirm that these results are expected from such a
>>>>>> configuration? If it is the case, can we avoid them?
>>>>>>
>>>>>> Thanks in advance.
>>>>>>
>>>>>> Marc
>>>>>>
>>>>>> Make sure that your baseband tone is far enough away from DC so as
>>>>> not to get swallowed by the DC-offset compensation algorithm, which takes
>>>>> a
>>>>> while to converge.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> USRP-users mailing list
>>>>> <[email protected]>[email protected]
>>>>> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>>>>> 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
> [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/20160518/bd35ac02/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stepSignal.png
Type: image/png
Size: 24143 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160518/bd35ac02/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stepSignal240.png
Type: image/png
Size: 24416 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160518/bd35ac02/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stepSpectre.png
Type: image/png
Size: 27129 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160518/bd35ac02/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stepSpectreAmp16.png
Type: image/png
Size: 31391 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160518/bd35ac02/attachment-0007.png>
------------------------------
Message: 20
Date: Wed, 18 May 2016 08:45:23 -0700
From: Neel Pandeya <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] NEWSDR in Boston in Two Weeks
Message-ID:
<cacaxmv85d9pk_gxp7clekvf-mvc-uv+o-fkfl1s4ix41fyk...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
?*********************************************************************
NEWSDR 2016
New England Workshop on Software-Defined Radio
Sixth-Annual
Workshops
Thursday June 2
6:00 PM - 9:00 PM
Symposium
Friday June 3
8:00 AM - 4:00 PM
Northeastern University (NEU)
Boston, MA, USA
http://www.sdr-boston.org/
Free Registration
Poster Submissions Accepted Until Friday May 15
*********************************************************************
INVITATION TO PARTICIPATE
You are cordially invited to the 2016 New England Workshop on
Software Defined Radio (NEWSDR 2016), which is the sixth installment
of an annual series of symposium and workshop events organized by
the Boston SDR User Group (SDR-Boston).
This year, NEWSDR will be held at Northeastern University (NEU),
and consists of a day-long symposium on Friday, as well as several
hands-on workshops the evening before on Thursday. You are welcome
to attend either or both events, which are entirely free.
Attendance is typically about 100 people, and attendees are from
both academia and industry.
*********************************************************************
WORKSHOPS
THURSDAY JUNE 2
18:00 to 21:00
Forsyth Building
?70 Forsyth Street
Room 236 and 237
AGENDA
16:00 ? 18:00 Early Sessions for Workshop Setup and Prerequisites
18:00 ? 21:00 Workshop Events
Two workshops are being offered:
* "SDR Challenge ? Identifying Mystery Waveform Using Simulink
and RTL-SDR" by MathWorks (more details listed below)
* "Hands-On Tutorial on FPGA Computing for SDR with RFNoC"
by Ettus Research (more details listed below)
MathWorks and Ettus Research will each run a workshop on the evening
before the main event. Workshops are technical, practical, hands-on
activities in a group setting. Specific topics and further details
about the workshops will be announced shortly. Attendance is free,
but advance registration is required. Free pizza and soda will be
provided.
*********************************************************************
SYMPOSIUM
FRIDAY JUNE 3
08:00 to 16:30
Raytheon Amphitheater
Egan Research Center
120 Forsyth Street
AGENDA
08:00 ? 08:30 Coffee and Light Refreshments
08:30 ? 08:40 Welcome and Introduction
08:40 ? 10:00 Sponsor Flash Talks (20 minutes each)
10:00 ? 10:45 Coffee, Attendee Networking, Poster Sessions,
Sponsor Exhibits and Demos
10:45 ? 11:45 Invited Talk: Mr. Richard Reinhart,
NASA Glenn Research Center
11:45 ? 12:45 Lunch and Attendee Networking
12:45 ? 13:45 Invited Talk: Professor Tommaso Melodia,
Northeastern University
13:45 ? 14:15 Poster Session Elevator Pitches
14:15 ? 15:15 Coffee, Attendee Networking, Poster Sessions,
Sponsor Exhibits and Demos
15:15 ? 16:15 Sponsor Short Course by Analog Devices
16:15 ? 16:30 Closing Remarks
Plenary Speakers:
* Mr. Richard Reinhart, NASA Glenn Research Center
* Prof. Tommaso Melodia, Northeastern University
Technical Poster Presentations:
* Covering the recent work in SDR and cognitive radio technology
* Poster presentations are now being solicited
* See link at the bottom of this email to submit your abstract
Corporate Sponsors:
* Analog Devices
* Ettus Research / National Instruments
* MathWorks
* MediaTek Wireless
The symposium features plenary speakers, technical poster
presentation sessions, hardware and software demonstrations from the
event sponsors, and workshops from the event sponsors, all focusing
on recent work in SDR and cognitive radio technology. Free breakfast,
lunch, and coffee will be provided. Attendance is free, but advance
registration is required.
The symposium provides an excellent networking opportunity and a
terrific venue to exchange thoughts and ideas with other people
working in the SDR space.
*********************************************************************
WORKSHOP DESCRIPTION
SDR Challenge ? Identifying Mystery
Waveform Using Simulink and RTL-SDR
by MathWorks
During this evening event, the audience will be tasked with
identifying a ?mystery waveform? that is being generated in their
vicinity. Using MATLAB/Simulink and the RTL-SDR platform, both of
which will be provided during this event, each team will be given
several partially completed models and some details of the mystery
waveform. The objective of this challenge is to add the remaining
functionality to the models provided and leverage the RTL-SDR in
order to classify the received signal and potentially even decode
the signal.
The learning outcomes of this event include:
* Obtaining an understanding of the MATLAB/Simulink software
environment and its capabilities.
* Gaining knowledge on how MATLAB/Simulink interfaces with the
RTL-SDR device.
* Experience hands-on real-time wireless experimentation using
MATLAB/Simulink and the RTL-SDR in a controlled wireless scenario.
Given the limited number of computer workstations and RTL-SDR
platforms available, this event has a registration limit of 30
individuals (teams of 3 individuals will be formed at this event).
Facilitators: Mike McLernon, Dr Ethem Sozer
*********************************************************************
WORKSHOP DESCRIPTION
Hands-On Tutorial on FPGA Computing for SDR with RFNoC
by Ettus Research
Ettus Research has introduced a platform called RF Network-on-Chip
(RFNoC) which makes FPGA computing for SDR more accessible and
flexible. RFNoC is a new architecture for USRP devices that use
Xilinx 7-series FPGAs (E310, X300, and X310). RFNoC is built around
a packetized network infrastructure in the FPGA that handles the
transport of control and sample data between the host CPU and the
radio. Users target their custom algorithms to the FPGA in the form
of Computation Engines (CE), which are processing blocks that attach
to this network. CEs act as independent nodes on the network that can
receive and transmit data to any other node (e.g., another CE, the
radio block, or the host CPU). This architecture permits scalable
designs that can distribute processing across many nodes. Users can
create modular, FPGA-accelerated SDR applications by chaining CEs
into a flow graph. RFNoC is supported in UHD and GNU Radio. In this
workshop, we will present an interactive tutorial on RFNoC, including
a discussion on its design and capabilities, demonstrations of
several existing examples, and a walk-through on implementing a
user-defined CE and integrating the CE into GNU Radio.
Prerequisites:
* Attendees are expected to bring their own laptops to the workshop.
The laptop should have at least 2 GB memory, have at least one
Ethernet port and one USB 3.0 port, and be able to boot into a Linux
environment from a USB 3.0 flash drive.
* Attendees must create Xilinx user accounts at least three days
before the workshop, in order to obtain Xilinx licenses for the free
WebPack Edition of Vivado version 2015.4.
USB flash drives and USRP hardware will be provided in the workshop.
Enrollment is limited to 20 people.
Facilitators: Jonathon Pendlum, Wan Liu, Neel Pandeya
*********************************************************************
REGISTRATION
* Register for the Symposium, or the Workshop, or both
* Registration is required but is completely free
* Registration takes less than 5 minutes
* Registration includes free food
* Parking available
* You must register online for food and parking
* Attendance, food, parking are all limited, so please register
online as soon as possible to secure your spot
* Registration deadline is Friday May 20
* See link at the bottom of this announcement to register online
*********************************************************************
LINKS
Attendee Registration:
https://docs.google.com/forms/d/1QCIyKIVzpZfzh4ptim7zCIbcKvi2drDLurkptokdqN4
Poster Abstract Submission:
https://docs.google.com/forms/d/17faN0FQuifOHS4xX1TZWN9ABMlY__s3g81ZUfIwdtqE
*********************************************************************
ADDITIONAL INFORMATION
More information, and the event schedule,
for this event can be found at our website:
http://www.sdr-boston.org/
*********************************************************************
EOF
*********************************************************************
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160518/c581e04d/attachment-0001.html>
------------------------------
Message: 21
Date: Wed, 18 May 2016 11:54:36 -0400
From: avinash kalyanaraman <[email protected]>
To: [email protected]
Subject: [USRP-users] Pulse Radar
Message-ID:
<CAJpBU_Fy9znyOqZ=vgdmnwgvknpclncanubyr2a6ye5gtfg...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
I have a couple of USRP N210s with the WBX-daughter boards, and I want to
build a simple pulse radar with them- i.e. I want to be able to generate
and receive a pulse between them, and calculate the time delay. In this
regard I have a couple of questions:
(i) How do I generate a pulse? Is multiplying square waves my best option
in generating a pulse ? What would be the smallest pulse width I might be
able to get?
(ii) To get the two USRPs to synchronize in time so that the time of flight
can be calculated, I plan to use the GPSDO. What is the accuracy of the
GPSDO unit? I.e. what's the difference in absolute timestamps that I can
expect ?
Am I missing anything else here in getting this setup running ?
Please let me know,
Thanks,
--
Avinash
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160518/b4227308/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 69, Issue 18
******************************************
