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: USRP B200mini and additionnal LNA: fear the blue smoke!
(Marcus D. Leech)
2. Re: USRP B200mini and additionnal LNA: fear the blue smoke!
(Martin Braun)
3. Re: USRP B200mini and additionnal LNA: fear the blue smoke!
(Antoto Antoine)
4. Re: USRP B200mini and additionnal LNA: fear the blue smoke!
(Marcus D. Leech)
5. Re: JTAG debugging on the E310 (Martin Braun)
6. Re: Adding list of files to RFNoC build (Jason Matusiak)
7. Re: USRP B200mini and additionnal LNA: fear the blue smoke!
(Andy Walls)
8. Announcing NEWSDR at NEU on Thr-Fri June 2-3 (Neel Pandeya)
9. Re: USRP B200mini and additionnal LNA: fear the blue smoke!
(Antoto Antoine)
10. Re: Feedback with Transmitters and Receiver (Pavan Yedavalli)
11. Re: USRP B200mini and additionnal LNA: fear the blue smoke!
(Marcus M?ller)
12. Re: USRP B200mini and additionnal LNA: fear the blue smoke!
(Andy Walls)
13. Re: UHD? installation problems (James Humphries)
14. Re: switching between TX/RX and RX2 for SBX-120 (Derek Kozel)
15. Re: Feedback with Transmitters and Receiver (Derek Kozel)
16. How to use DDR memory on E310 RFNOC version (Weidong Wang)
17. Re: X310 UBX Tx issues (Neel Pandeya)
18. Re: Feedback with Transmitters and Receiver (Pavan Yedavalli)
19. Re: Feedback with Transmitters and Receiver (Derek Kozel)
----------------------------------------------------------------------
Message: 1
Date: Fri, 29 Apr 2016 12:01:46 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP B200mini and additionnal LNA: fear the
blue smoke!
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 04/29/2016 11:37 AM, Antoto Antoine via USRP-users wrote:
> Hello everyone,
>
> I'm considering using a B200mini for the implementation of an ADS-B
> receiver but something in the documentation is a bit puzzling (page 2):
>
> http://files.ettus.com/b2xx_resources/B200mini%20Getting%20Started%20Guide.pdf
>
> *"Never apply more than -15dBm of power into any RF input!"*
>
> 15dBm is crazy low for a receiver! but would this mean that a LNA like
> this one: (Mini circuits) http://194.75.38.69/pdfs/ZX60-P162LN+.pdf
> would put the receiving end at risk as the *output power at 1dB
> compression is at 20dB*?
>
>
> This seems rather strange, unless the B200mini already has it's own
> LNA onboard but never seen anything about that.
>
> PS: I'm still a "RF beginner" and may just be completery wrong.
>
>
> Best
>
> Antoine
>
> More on the project if you guys are interested: this is about using
> the onboard FPGA to process as much as possible of the 1090MHz channel
> and use a Raspberry-Pi in order to receive the decoded stream and
> package it.
> Then load all these frames on a small database of aircrafts currently
> in the sky.
>
> I would hope to take advantage of the quality of the USRP to dive into
> multilateration as well if this first part works out.
>
>
> For now my preffered software package is the Matlab communication
> toolbox, but if I encounter too much difficulties I may switch to
> GNUradio (I fear issues with loading the FPGA from the raspberry pi
> using a matlab base HDL architecture)
>
>
"Typical" signals at a receiver (or LNA input) are usually -60dBm or
lower. If you're presenting 20dBm to a receiver input, regardless of
protection, it may well destroy the receiver front end.
The 1dB compression point is the power (either stated at the input or
output) where the gain response is no longer linear. If that point is
stated as output power, then you subtract the gain of the device to
determine what the corresponding input power would be.
Over-the-air RF signals are tiny, typically. One would not expect an
over-the-air signal to exceed -15dBm except in unusual circumstances.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160429/918cfb68/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 29 Apr 2016 09:08:47 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP B200mini and additionnal LNA: fear the
blue smoke!
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 04/29/2016 09:01 AM, Marcus D. Leech via USRP-users wrote:
> "Typical" signals at a receiver (or LNA input) are usually -60dBm or
> lower. If you're presenting 20dBm to a receiver input, regardless of
> protection, it may well destroy the receiver front end.
>
> The 1dB compression point is the power (either stated at the input or
> output) where the gain response is no longer linear. If that point is
> stated as output power, then you subtract the gain of the device to
> determine what the corresponding input power would be.
>
> Over-the-air RF signals are tiny, typically. One would not expect an
> over-the-air signal to exceed -15dBm except in unusual circumstances.
Hah, I was just typing out an email along the same lines :) I'll add,
just for the list archives, that while it is pretty unlikely to receive
a signal of that strength over an antenna, it is easily possible to
provide that kind of input power through a cabled connection, the most
likely case being when directly looping back a tx port to an rx port.
Hence the warning, and at this point we usually add a paragraph saying
you should be using attenuators for loopback.
Cheers,
M
------------------------------
Message: 3
Date: Fri, 29 Apr 2016 16:48:23 +0000
From: Antoto Antoine <[email protected]>
To: Martin Braun <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP B200mini and additionnal LNA: fear the
blue smoke!
Message-ID:
<he1pr04mb1562bed03b4d2ff3061e8d6be5...@he1pr04mb1562.eurprd04.prod.outlook.com>
Content-Type: text/plain; charset="iso-8859-1"
Great thanks!
I guess the 22.5dB from this LNA will be a good help then!
I'll keep you up with the project.
Best
Antoine
________________________________________
De : USRP-users <[email protected]> de la part de Martin Braun
via USRP-users <[email protected]>
Envoy? : vendredi 29 avril 2016 18:08
? : [email protected]
Objet : Re: [USRP-users] USRP B200mini and additionnal LNA: fear the blue smoke!
On 04/29/2016 09:01 AM, Marcus D. Leech via USRP-users wrote:
> "Typical" signals at a receiver (or LNA input) are usually -60dBm or
> lower. If you're presenting 20dBm to a receiver input, regardless of
> protection, it may well destroy the receiver front end.
>
> The 1dB compression point is the power (either stated at the input or
> output) where the gain response is no longer linear. If that point is
> stated as output power, then you subtract the gain of the device to
> determine what the corresponding input power would be.
>
> Over-the-air RF signals are tiny, typically. One would not expect an
> over-the-air signal to exceed -15dBm except in unusual circumstances.
Hah, I was just typing out an email along the same lines :) I'll add,
just for the list archives, that while it is pretty unlikely to receive
a signal of that strength over an antenna, it is easily possible to
provide that kind of input power through a cabled connection, the most
likely case being when directly looping back a tx port to an rx port.
Hence the warning, and at this point we usually add a paragraph saying
you should be using attenuators for loopback.
Cheers,
M
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 4
Date: Fri, 29 Apr 2016 12:53:49 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP B200mini and additionnal LNA: fear the
blue smoke!
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 04/29/2016 12:48 PM, Antoto Antoine via USRP-users wrote:
> Great thanks!
> I guess the 22.5dB from this LNA will be a good help then!
> I'll keep you up with the project.
>
> Best
> Antoine
You usually don't need an exterior LNA unless you're dealing with very
weak signals, and/or you have a long cable run between your
antenna, and you're operating at higher frequencies (above 200-300Mhz).
Weak signals would include things like satellite work, etc.
>
> ________________________________________
> De : USRP-users <[email protected]> de la part de Martin
> Braun via USRP-users <[email protected]>
> Envoy? : vendredi 29 avril 2016 18:08
> ? : [email protected]
> Objet : Re: [USRP-users] USRP B200mini and additionnal LNA: fear the blue
> smoke!
>
> On 04/29/2016 09:01 AM, Marcus D. Leech via USRP-users wrote:
>> "Typical" signals at a receiver (or LNA input) are usually -60dBm or
>> lower. If you're presenting 20dBm to a receiver input, regardless of
>> protection, it may well destroy the receiver front end.
>>
>> The 1dB compression point is the power (either stated at the input or
>> output) where the gain response is no longer linear. If that point is
>> stated as output power, then you subtract the gain of the device to
>> determine what the corresponding input power would be.
>>
>> Over-the-air RF signals are tiny, typically. One would not expect an
>> over-the-air signal to exceed -15dBm except in unusual circumstances.
> Hah, I was just typing out an email along the same lines :) I'll add,
> just for the list archives, that while it is pretty unlikely to receive
> a signal of that strength over an antenna, it is easily possible to
> provide that kind of input power through a cabled connection, the most
> likely case being when directly looping back a tx port to an rx port.
> Hence the warning, and at this point we usually add a paragraph saying
> you should be using attenuators for loopback.
>
> Cheers,
> M
>
>
> _______________________________________________
> 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
------------------------------
Message: 5
Date: Fri, 29 Apr 2016 10:00:20 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] JTAG debugging on the E310
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Yes, the Vivado ILA integration works fine if you have a JTAG connector.
We do that a lot for testing and developing RFNoC and other FPGA stuff.
Cheers,
Martin
On 04/28/2016 06:40 PM, Long, Jeffrey P. via USRP-users wrote:
> Ed-
>
> I have done it. You have to build up a cable. You also need to pop the case
> to get the cable on.
> You build the fpga image with the chipscope ILA and controller and then the
> Ettus API loads it normally. Once its up and running you fire up chipscope
> (or vivado) and then try to connect to it.
>
> If you search the list history on this:
> "E310 jtag and gpio connector"
> You will see my question and response from Neel on what to buy. I bought the
> cable and wired it to a platform USB. At the time I was using ISE (pre vivado
> UHD version) so I did a coregen to create the ILA and then handwired it in.
> I have not tried now that we are working in vivado. There is probably a
> similar path.
>
> Jeff
>
>
> -----Original Message-----
> From: USRP-users [mailto:[email protected]] On Behalf Of
> Seger, Edward H via USRP-users
> Sent: Thursday, April 28, 2016 7:58 PM
> To: '[email protected]'
> Subject: [USRP-users] JTAG debugging on the E310
>
> Is anybody using chipscope to debug the E310 FPGA? I'd like to kno what this
> is like, if there are any issues with the fact that there is an ARM in the
> thing. Also, how do you attach to the E310 MOBO? The JTAG connector on the
> E310 is non-standard.
>
> Any help, ideas, or experiences are appreciated....
>
> Thanks
> Ed
>
>
> _______________________________________________
> 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
>
------------------------------
Message: 6
Date: Fri, 29 Apr 2016 13:02:44 -0400
From: Jason Matusiak <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Adding list of files to RFNoC build
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
OK, thanks Jonathon, makes sense.
Is there something that helps get the process started? I am thinking
maybe adding things via the GUI and then pulling a list out of some file
or log and adding it into the Makefile.srcs.
On 04/29/2016 11:32 AM, Jonathon Pendlum wrote:
> Hey Jason,
>
> Unfortunately you will have to manually add each file. Eventually I
> would like to have a script that can determine which files to include
> in a build, but that is very low on the priority list.
>
>
>
> Jonathon
>
> On Thu, Apr 28, 2016 at 10:10 AM, Jason Matusiak via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> I am trying to incorporate a previously created VHDL module into
> RFNoC, but am a little confused. My previous custom blocks have
> been two files only (the module, and the noc_block_module). What
> I did in that case was to include the two new verilog files in the
> Makefile.srcs and rebuild; this new block has a lot of files that
> need to be included though. Do I need to go through and figure
> out the file names and add them one-by-one? Or is there a way to
> include a folder in the Makefile.srcs file so it will just suck
> everything in?
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[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/20160429/65e5dd65/attachment-0001.html>
------------------------------
Message: 7
Date: Fri, 29 Apr 2016 13:08:14 -0400
From: Andy Walls <[email protected]>
To: [email protected], Antoto Antoine <[email protected]>
Subject: Re: [USRP-users] USRP B200mini and additionnal LNA: fear the
blue smoke!
Message-ID: <1461949694.2852.24.camel@localhost>
Content-Type: text/plain; charset="UTF-8"
On Fri, 2016-04-29 at 12:00 -0400, [email protected]
wrote:
> Date: Fri, 29 Apr 2016 15:37:05 +0000
> From: Antoto Antoine <[email protected]>
> Subject:
> Message-ID:
>
> <he1pr04mb15626368d2bb0fbc0366cc1ee5...@he1pr04mb1562.eurprd04.prod.outlook.com>
>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hello everyone,
>
> I'm considering using a B200mini for the implementation of an ADS-B
> receiver but something in the documentation is a bit puzzling (page
> 2):
>
> http://files.ettus.com/b2xx_resources/B200mini%20Getting%20Started%
> 20Guide.pdf
>
> "Never apply more than -15dBm of power into any RF input!"
>
> 15dBm is crazy low for a receiver!
Aircraft unit peak power maximum is 27.0 dBW or 57 dBm.
So with a Tx antenna gain of 0 dB, an Rx antenna gain of 3 dB,
and a distance of 1.0 nmi (1852 m or 6.076 feet):
Pr = 57 dBm + 0 dB + 3 dB + 20*log10((3e8/1090e6)/(4*pi*1852))
Pr = -38.5 dBm (if I have my math right)
And that's without any losses except free space path loss.
I'm not sure why you need an LNA; unless you like the magic blue
smoke. ;)
> but would this mean that a LNA like this one: (Mini circuits)
> http://194.75.38.69/pdfs/ZX60-P162LN+.pdf
> would put the receiving end at risk as the output power at 1dB
> compression is at 20dB?
>
> This seems rather strange, unless the B200mini already has it's own
> LNA onboard but never seen anything about that.
>
> PS: I'm still a "RF beginner" and may just be completery wrong.
>
>
> Best
>
> Antoine
>
> More on the project if you guys are interested: this is about using
> the onboard FPGA to process as much as possible of the 1090MHz channel
> and use a Raspberry-Pi in order to receive the decoded stream and
> package it.
> Then load all these frames on a small database of aircrafts currently
> in the sky.
>
> I would hope to take advantage of the quality of the USRP to dive into
> multilateration as well if this first part works out.
The gr-air-modes out of tree module already has ADS-B multi-lateration
done, I thought.
https://github.com/bistromath/gr-air-modes
Regards
-Andy
> For now my preffered software package is the Matlab communication
> toolbox, but if I encounter too much difficulties I may switch to
> GNUradio (I fear issues with loading the FPGA from the raspberry pi
> using a matlab base HDL architecture)
------------------------------
Message: 8
Date: Fri, 29 Apr 2016 10:38:38 -0700
From: Neel Pandeya <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] Announcing NEWSDR at NEU on Thr-Fri June 2-3
Message-ID:
<cacaxmv_x2q-poo39u0hm-1kibk1wap61wp15k9zjrr3jxvw...@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 to 18:00 Early Sessions for Workshop Setup and Prerequisites
18:00 to 21:00 Workshop Events
Two workshops are being offered:
* "Introduction to SDR with Matlab and RTL-SDR Dongle"
by MathWorks
* "Hands-On Introduction to Doing SDR in FPGA with RFNoC"
by Ettus Research
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:00
Raytheon Amphitheater
Egan Research Center
120 Forsyth Street
AGENDA
08:00 to 08:30 Coffee and Light Refreshments
08:30 to 08:40 Welcome and Introduction
08:40 to 10:00 Sponsor Flash Talks (20 minutes each)
10:00 to 11:00 Coffee, Attendee Networking, Poster Sessions,
Sponsor Exhibits and Demos
11:00 to 12:00 Invited Talk: Mr Richard Reinhart,
NASA Glenn Research Center
12:00 to 13:00 Lunch and Attendee Networking
13:00 to 14:00 Invited Talk: Dr Tommaso Melodia,
Northeastern University
14:00 to 15:00 Coffee, Attendee Networking, Poster Sessions,
Sponsor Exhibits and Demos
15:00 to 16:00 Sponsor Short Course by Analog Devices
16:00 to 16:15 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.
*********************************************************************
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/20160429/9cfb0434/attachment-0001.html>
------------------------------
Message: 9
Date: Fri, 29 Apr 2016 18:05:50 +0000
From: Antoto Antoine <[email protected]>
To: Andy Walls <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP B200mini and additionnal LNA: fear the
blue smoke!
Message-ID:
<he1pr04mb15629197d7db1ca3cd510165e5...@he1pr04mb1562.eurprd04.prod.outlook.com>
Content-Type: text/plain; charset="iso-8859-1"
@1nm with your calculations it gets really close (4dB difference) to the -15dBm
limit!
Thanks to point that out
But even worse, the receiver is meant to be placed near an active airfield so I
guess that the distance will be even shorter!
So the LNA idea is scrapped for now.
But now I can freak out and look for a power limiter or attenuator
Thanks!
________________________________________
De : Andy Walls <[email protected]>
Envoy? : vendredi 29 avril 2016 19:08
? : [email protected]; Antoto Antoine
Objet : Re: [USRP-users] USRP B200mini and additionnal LNA: fear the blue smoke!
On Fri, 2016-04-29 at 12:00 -0400, [email protected]
wrote:
> Date: Fri, 29 Apr 2016 15:37:05 +0000
> From: Antoto Antoine <[email protected]>
> Subject:
> Message-ID:
>
> <he1pr04mb15626368d2bb0fbc0366cc1ee5...@he1pr04mb1562.eurprd04.prod.outlook.com>
>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hello everyone,
>
> I'm considering using a B200mini for the implementation of an ADS-B
> receiver but something in the documentation is a bit puzzling (page
> 2):
>
> http://files.ettus.com/b2xx_resources/B200mini%20Getting%20Started%
> 20Guide.pdf
>
> "Never apply more than -15dBm of power into any RF input!"
>
> 15dBm is crazy low for a receiver!
Aircraft unit peak power maximum is 27.0 dBW or 57 dBm.
So with a Tx antenna gain of 0 dB, an Rx antenna gain of 3 dB,
and a distance of 1.0 nmi (1852 m or 6.076 feet):
Pr = 57 dBm + 0 dB + 3 dB + 20*log10((3e8/1090e6)/(4*pi*1852))
Pr = -38.5 dBm (if I have my math right)
And that's without any losses except free space path loss.
I'm not sure why you need an LNA; unless you like the magic blue
smoke. ;)
> but would this mean that a LNA like this one: (Mini circuits)
> http://194.75.38.69/pdfs/ZX60-P162LN+.pdf
> would put the receiving end at risk as the output power at 1dB
> compression is at 20dB?
>
> This seems rather strange, unless the B200mini already has it's own
> LNA onboard but never seen anything about that.
>
> PS: I'm still a "RF beginner" and may just be completery wrong.
>
>
> Best
>
> Antoine
>
> More on the project if you guys are interested: this is about using
> the onboard FPGA to process as much as possible of the 1090MHz channel
> and use a Raspberry-Pi in order to receive the decoded stream and
> package it.
> Then load all these frames on a small database of aircrafts currently
> in the sky.
>
> I would hope to take advantage of the quality of the USRP to dive into
> multilateration as well if this first part works out.
The gr-air-modes out of tree module already has ADS-B multi-lateration
done, I thought.
https://github.com/bistromath/gr-air-modes
Regards
-Andy
> For now my preffered software package is the Matlab communication
> toolbox, but if I encounter too much difficulties I may switch to
> GNUradio (I fear issues with loading the FPGA from the raspberry pi
> using a matlab base HDL architecture)
------------------------------
Message: 10
Date: Fri, 29 Apr 2016 11:32:36 -0700
From: Pavan Yedavalli <[email protected]>
To: Derek Kozel <[email protected]>
Cc: "[email protected]" <[email protected]>,
GNURadio Discussion List <[email protected]>
Subject: Re: [USRP-users] Feedback with Transmitters and Receiver
Message-ID:
<cacax0_oufh7ty392whj7msh5++zqnfht6qx-ecfezwm7ygc...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Derek,
I made all the changes, and the Tx error as well as the warnings are now
gone. However, the Rx error still remains:
File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
line 2168, in set_samp_rate
return _uhd_swig.usrp_source_sptr_set_samp_rate(self, *args, **kwargs)
RuntimeError: LookupError: IndexError: multi_usrp: RX channel 1 out of
range for configured RX frontends
I'm not entirely sure what the problem is here. Attached are the flowgraph
pictures. In addition, I am using Rev 5.1 SBX daughterboards. Thanks again.
On Thu, Apr 28, 2016 at 4:21 PM, Pavan Yedavalli <[email protected]>
wrote:
> Hi Derek,
>
> I appreciate it. Okay, I will change all of those. I am using the SBX
> daughterboards - the ones that support phase sync.
>
> On Thu, Apr 28, 2016 at 3:55 PM, Derek Kozel <[email protected]>
> wrote:
>
>> Hello Pavan,
>>
>> You do not need Ethernet connected to the Octoclock, so that's ok. Your
>> cabling sounds correct. Can you please combine both UHD Sinks? Just
>> increase the number of motherboards and channels to 2 and copy the MIMO
>> attached USRP's settings into channel 2.
>>
>> Your sample rate for the receive side is very very low. I suspect that
>> will throw a warning if you read the log output at the bottom of GRC. Try
>> raising that to 500kHz or more. Also the WX Scope Sink can be changed to
>> complex inputs so you don't need the converter blocks. You are also setting
>> a custom clock rate. The N200 has a fixed master clock rate of 100 MHz so
>> this is likely also throwing a warning in the log messages. Definitely look
>> through those and make changes as needed.
>>
>> What daughterboards are you using? On the N200 series motherboards only
>> the SBX daughterboards supports phase synchronization. What you should see
>> is frequency and time synchronization between the MIMO N210s.
>>
>> Regards,
>> Derek
>>
>> On Thu, Apr 28, 2016 at 12:22 PM, Pavan Yedavalli <[email protected]>
>> wrote:
>>
>>> Hi Derek,
>>>
>>> Sorry - just another quick addition. When I run the Tx flowgraph, I get
>>> this error:
>>>
>>> Board 0 May not be getting a PPS signal! No PPS detected within the time
>>> interval.
>>>
>>> This definitely tells me something is wrong with the Octoclock-G setup.
>>>
>>> On Thu, Apr 28, 2016 at 12:18 PM, Pavan Yedavalli <[email protected]>
>>> wrote:
>>>
>>>> Hi Derek,
>>>>
>>>> I am trying to do (3), as you noted above, and my test to see whether
>>>> the Tx USRPs are transmitting at the same time is to directly connect them
>>>> to the Rx USRP and plot the real components of each one and see whether
>>>> they are in phase (or at least with some constant random offset). In
>>>> theory, I believe this is a good test to see that the Octoclock-G is
>>>> working its magic.
>>>>
>>>> The setup:
>>>>
>>>> *Octoclock*: Two of the three boards (Master Tx USRP and 1 Rx USRP)
>>>> are connected to the Octoclock-G (one cable each from PPS out to PPS in,
>>>> and one cable each from 10 MHz out to Ref in, so 4 total cables). The
>>>> primary ref knob is set to Internal, and the PPS blinks green, while
>>>> Internal, Status, and Power are all steady greens. I do *not* have the
>>>> ethernet of the Octoclock connected, however. When I connected it to my Gb
>>>> Ethernet switch, the indicator was orange, while all the other working ones
>>>> are green, so I decided not to connect it for now. Does this matter?
>>>>
>>>> *Tx side*: I have both Tx USRPs connected to each other via the MIMO
>>>> cable, and one of them is connected to the Octoclock, as mentioned above.
>>>> In tx_mimo_setup_octoclock.png, we can see that I have two USRP sinks
>>>> connected via MIMO cable, and one of them has time and clock set to
>>>> External, and the other has time and clock set to MIMO cable. Both have
>>>> sync set to Unknown PPS.
>>>>
>>>> *Between Tx and Rx*: I have an SMA cable from one Tx USRP connected to
>>>> a 20 dB attenuator, and then connected to the Tx/Rx port of the Rx USRP. I
>>>> have another SMA cable from the other Tx USRP connected to a 20 dB
>>>> attenuator, and then connected to the Rx2 port of the Rx USRP. No antennas
>>>> are connected.
>>>>
>>>> *Rx side*: In receiver_recvng_on_both_ports.png, we can see that I
>>>> have a USRP source with two channels. The time and clock are set to
>>>> External, and the sync is set to Unknown PPS. I run this, but I get the
>>>> following error:
>>>>
>>>> RuntimeError: LookupError: IndexError: multi_usrp: RX channel 1 out of
>>>> range for configured RX frontends
>>>>
>>>> I tried looking up what this error is, and apparently there was a fix
>>>> in a branch years ago, but I'm assuming I have that fix already? I have a
>>>> feeling something is wrong with the Octoclock setup that is causing this,
>>>> but I'm not sure. I believe the setup I mentioned above makes sense, right?
>>>>
>>>> Obviously, I will look into timed commands in UHD and tags in GNU Radio
>>>> after I get all of this set up and working. Thank you so much again for the
>>>> help.
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Apr 21, 2016 at 3:52 PM, Derek Kozel <[email protected]>
>>>> wrote:
>>>>
>>>>> Hi Pavan,
>>>>>
>>>>> This is a USRP/UHD question really so I'm including the usrp-users
>>>>> mailing list. If you're not already the list already then you should
>>>>> certainly join as that's a better resource for questions about UHD/USRPs.
>>>>>
>>>>> 1) Any SMA cable will work. For the best performance their electrical
>>>>> lengths should be the same. In practice this usually means equal physical
>>>>> lengths of the same type of coax. This ensures that the signals arrive at
>>>>> the same time (and phase).
>>>>>
>>>>> 2) Most radio systems don't have GPS timebases available and use
>>>>> various protocol level methods for aligning their clocks, if needed. In a
>>>>> very simple system the receiver could simply listen continuously until it
>>>>> receives a full message, then transmits a response if needed. Look up Time
>>>>> Division Multiplexing and Frequency Division Multiplexing. This is an area
>>>>> where there are nearly as many possibilities as there are radio systems.
>>>>>
>>>>> 3) Once you connect all the Octoclock signals then in GNU Radio you
>>>>> can select the Clock and Time sources to be External and the Sync to be
>>>>> Unknown PPS. Your pair of units connected via a MIMO cable are special,
>>>>> the
>>>>> master should have the External time and clock sources, the companion USRP
>>>>> should have MIMO selected for time and clock. The Sync should still be
>>>>> Unknown PPS.
>>>>>
>>>>> Here's a page that talks about synchronization of USRPs. Read this,
>>>>> get your hardware all setup, and try setting up a basic GRC flowgraph with
>>>>> your three radios. Think of what tests you could use to verify that both
>>>>> your MIMO cabled radios are transmitting at the same time. You should look
>>>>> into timed commands in UHD and tags in GNU Radio.
>>>>>
>>>>> http://files.ettus.com/manual/page_sync.html
>>>>>
>>>>> https://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp_updated.pdf
>>>>>
>>>>> If this is your first use of USRPs and GNU Radio then I'd suggest
>>>>> reading through the tutorials available online and not get too focused on
>>>>> MIMO until you feel comfortable with the basics of the environment and
>>>>> tools that you have.
>>>>>
>>>>> http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials
>>>>>
>>>>> Once you've given this a try let us know if you have additional
>>>>> questions.
>>>>>
>>>>> Regards,
>>>>> Derek
>>>>>
>>>>>
>>>>> On Thu, Apr 21, 2016 at 3:27 PM, Pavan Yedavalli <[email protected]
>>>>> > wrote:
>>>>>
>>>>>> Hi Derek,
>>>>>>
>>>>>> Thanks for getting back to me. So, I do have an Octoclock, so I think
>>>>>> we're getting somewhere and this is starting to make more sense. A few
>>>>>> follow up questions:
>>>>>>
>>>>>> 1.) Do I need special cables to connect all of the units to the
>>>>>> Octoclock, or are they robust SMA cables?
>>>>>>
>>>>>> 2.) I feel like this seems particularly involved to send a signal
>>>>>> from a transmitter to a receiver. I am assuming most non-MIMO,
>>>>>> non-beamforming related tasks have always used your second option of
>>>>>> using
>>>>>> the GPSDO kits? I purchased an Octoclock knowing I would do MIMO
>>>>>> experiments, but obviously I'm guessing more conventional communication
>>>>>> techniques (like a simple BPSK or QPSK between tx and rx) would have
>>>>>> probably used the GPSDO kits?
>>>>>>
>>>>>> 3.) Once I connect them all to the Octoclock, then I don't need to a
>>>>>> protocol level time synchronization, right? Once they're all synchronized
>>>>>> and I see that in the plots, then I guess the next step would be to
>>>>>> figure
>>>>>> out how to implement my actual feedback loop. At that point, then I would
>>>>>> need to figure out how to do burst mode to transmit and receiver timed
>>>>>> signals? Would this end up needing to be one flow graph or would I have
>>>>>> to
>>>>>> use two flow graphs? (One for to and one for rx, the way I am doing it
>>>>>> now)
>>>>>>
>>>>>> Thank you again for all the help. I think I'm starting to understand
>>>>>> what I need in the setup.
>>>>>>
>>>>>> On Thu, Apr 21, 2016 at 4:56 PM, Derek Kozel <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>>> Hello Pavan,
>>>>>>>
>>>>>>> I think we both are starting to understand the setup and the
>>>>>>> problem. Here are the two hardware solutions:
>>>>>>>
>>>>>>> Connect a shared 1PPS signal to *both* the master USRP of your MIMO
>>>>>>> cabled pair and to the receiver (For example using an octoclock:
>>>>>>> https://www.ettus.com/product/details/OctoClock-G)
>>>>>>>
>>>>>>> OR
>>>>>>>
>>>>>>> Connect GPS referenced 1PPS signals to both the master USRP of your
>>>>>>> MIMO cabled pair and the receiver (For example using two of the GPSDO
>>>>>>> kits:
>>>>>>> https://www.ettus.com/product/details/GPSDO-KIT)
>>>>>>>
>>>>>>>
>>>>>>> There are many ways of implementing a protocol level time
>>>>>>> synchronization in software/DSP. The paper I linked to talks about one
>>>>>>> way,
>>>>>>> there are certainly others. I do not know of any example projects
>>>>>>> implementing them though so you would have to develop your own.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Derek
>>>>>>>
>>>>>>> On Thu, Apr 21, 2016 at 8:04 AM, Pavan Yedavalli <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>> Hi Derek,
>>>>>>>>
>>>>>>>> I'll answer your questions in-line, because I think what you are
>>>>>>>> saying is beginning to make me understand what I need:
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Apr 20, 2016 at 9:03 PM, Derek Kozel <[email protected]
>>>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> Hello Pavan,
>>>>>>>>>
>>>>>>>>> Are you trying to create a shared timebase between the two USRPs
>>>>>>>>> without having a shared 1PPS or GPS reference? You are still not using
>>>>>>>>> enough detail for us to understand fully.
>>>>>>>>>
>>>>>>>>
>>>>>>>> To clarify, my setup is two USRPs connected via MIMO cable, and
>>>>>>>> then another USRP acting as a receiver. So are you asking whether I'm
>>>>>>>> trying to create a shared timebase between the two-USRP *unit* (because
>>>>>>>> they are MIMO cabled) and the receiving USRP without having a shared 1
>>>>>>>> PPS
>>>>>>>> or GPS reference? I think my answer to that must be yes, because I
>>>>>>>> have not
>>>>>>>> done anything else but connect them to the computer via ethernet and
>>>>>>>> just
>>>>>>>> have two of them connected via MIMO cable and the other one by itself.
>>>>>>>> I'm
>>>>>>>> assuming I need to have a shared reference between the transmit USRPs
>>>>>>>> and
>>>>>>>> the receive USRP, so how would I be able to do that? This could
>>>>>>>> certainly
>>>>>>>> be one of my problems.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> In Figure 5 both USRPs are connected with a MIMO cable and so have
>>>>>>>>> both shared frequency and time bases. What is your weight block doing
>>>>>>>>> to
>>>>>>>>> the sample stream? Is it a time delay block? I don't know what
>>>>>>>>> gnuradio
>>>>>>>>> would do if you specified 10*sample_rate as the delay there as that's
>>>>>>>>> likely to be a very large number of samples.
>>>>>>>>>
>>>>>>>>
>>>>>>>> My weight block is applying a normalized magnitude phase correction
>>>>>>>> to each antenna's transmitted signal, so, yes, it is essentially
>>>>>>>> creating a
>>>>>>>> time delay. Each weight is a complex value with magnitude 1 and a
>>>>>>>> calculated phase. You are saying this could be a problem if it's
>>>>>>>> calculating a value that is too high?
>>>>>>>>
>>>>>>>>>
>>>>>>>>> If you have both USRPs connected with a time synchronization
>>>>>>>>> (shared 1PPS, GPSDO, or MIMO cable) and have your flowgraph configured
>>>>>>>>> correctly, then you can just use timed commands to the USRP_alpha to
>>>>>>>>> start
>>>>>>>>> transmitting at time X and USRP_beta to start receiving at time X and
>>>>>>>>> you
>>>>>>>>> will see your signal. You can then move to using burst mode using
>>>>>>>>> tags to
>>>>>>>>> define the number of samples to send/receive along with timed
>>>>>>>>> commands to
>>>>>>>>> send/receive bursts of samples. This works because the clocks in both
>>>>>>>>> USRPs
>>>>>>>>> will be aligned to each other.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I feel like there are two steps here. First, I need to get the
>>>>>>>> transmitting USRPs (which are conneced via MIMO cable) to time sync to
>>>>>>>> each
>>>>>>>> other (which I believe I have done through using USRP sink in GRC and
>>>>>>>> setting the second channels time and clock to MIMO cable?), and
>>>>>>>> second, I
>>>>>>>> need to get the receive USRP to receive at the same time. So, just as
>>>>>>>> above, I need to get my receive USRP to be on the same time as my
>>>>>>>> transmit
>>>>>>>> USRPs? Once I'm able to do that, then I can do burst mode to transmit
>>>>>>>> and
>>>>>>>> receive timed signals, as you are mentioning?
>>>>>>>>
>>>>>>>>>
>>>>>>>>> If you do *NOT* have a shared time source for each radio, for
>>>>>>>>> instance they are far apart and do not have GPS references, then you
>>>>>>>>> need
>>>>>>>>> to do some sort of protocol level alignment to create a shared
>>>>>>>>> understanding of time between them. A frequently used method is for
>>>>>>>>> USRP_alpha to transmit a beacon with a known period (say once every 10
>>>>>>>>> seconds). All other USRPs then receive for longer than 10 seconds to
>>>>>>>>> be
>>>>>>>>> guaranteed to receive the beacon (assuming they're within range of the
>>>>>>>>> transmission). When the receiving USRPs detect the incoming beacon
>>>>>>>>> they
>>>>>>>>> align their local time to the master (Beacon transmitting) USRP.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I guess a similar question to the above: can I have a shared time
>>>>>>>> source between the transmit USRPs (which are already MIMO cabled to
>>>>>>>> each
>>>>>>>> other) and the receive USRP? It seems like that would be easier to do
>>>>>>>> than
>>>>>>>> going through this protocol level alignment, but maybe it's not
>>>>>>>> possible
>>>>>>>> given my setup.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Here's a quick paper talking about this topic. The technique is
>>>>>>>>> widely used.
>>>>>>>>> http://www.ece.uah.edu/~milenka/docs/dc_ssst05_synch.pdf
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I hope this helps and is applicable to your need. If you have more
>>>>>>>>> questions please try drawing your desired system and maybe include a
>>>>>>>>> timeline of events that you expect the radios to do. Attaching your
>>>>>>>>> existing flowgraphs, either as photos using GRC's screen capture
>>>>>>>>> feature
>>>>>>>>> (file>screen capture) or the actual GRC file, also helps us
>>>>>>>>> understand what
>>>>>>>>> exactly you are working with.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I had to take down the setup because I am moving labs, but I will
>>>>>>>> send some flowgraphs and the diagram of the system next week. Thank you
>>>>>>>> again for being so patient and trying to help me. I think I'm just a
>>>>>>>> bit
>>>>>>>> lost on a few of the simple things, but once those are figured out,
>>>>>>>> then I
>>>>>>>> think it should be smoother sailing.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Derek
>>>>>>>>>
>>>>>>>>> On Wed, Apr 20, 2016 at 4:05 PM, Pavan Yedavalli <
>>>>>>>>> [email protected]> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Martin,
>>>>>>>>>>
>>>>>>>>>> I guess I have a few questions:
>>>>>>>>>>
>>>>>>>>>> 1.) Are there any examples in the gnuradio codebase/flowgraph
>>>>>>>>>> repository that show how to do synchronized feedback between two
>>>>>>>>>> USRPs? In
>>>>>>>>>> other words, I send a signal from a transmit USRP, and then I
>>>>>>>>>> receive that
>>>>>>>>>> signal at the receive USRP, and then I send back something else from
>>>>>>>>>> the
>>>>>>>>>> receive USRP back to the transmit USRP, and this would be a
>>>>>>>>>> sequential
>>>>>>>>>> process in which they are aligned and know when to transmit and/or
>>>>>>>>>> receive?
>>>>>>>>>> I saw a post
>>>>>>>>>> <http://stackoverflow.com/questions/28710869/how-to-set-usrp-transmitting-time-and-receiving-time-in-gnu-radio>
>>>>>>>>>> that
>>>>>>>>>> I think would be relevant, but I'm not sure how to apply it.
>>>>>>>>>>
>>>>>>>>>> I believe this should be a pretty standard scenario in which you
>>>>>>>>>> want to have two USRPs communicate with each other synchronously. I
>>>>>>>>>> guess
>>>>>>>>>> I'm just having trouble finding an example of how to do this.
>>>>>>>>>>
>>>>>>>>>> 2.) Related to the above question, maybe there are no examples to
>>>>>>>>>> do feedback in one flowgraph, so what I have been doing is the
>>>>>>>>>> following in
>>>>>>>>>> my flowgraphs:
>>>>>>>>>>
>>>>>>>>>> Flowgraph A:
>>>>>>>>>>
>>>>>>>>>> The synchronized MIMO flowgraph (Figure 5) from this
>>>>>>>>>> <https://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp.pdf>,
>>>>>>>>>> so essentially I have two USRPs synchronized and transmitting out two
>>>>>>>>>> signals that should be offset but frequency aligned. In my own
>>>>>>>>>> flowgraph's
>>>>>>>>>> main(), instead of applying a "phase shift" block, I am applying my
>>>>>>>>>> own
>>>>>>>>>> "weights" block to both transmissions.
>>>>>>>>>>
>>>>>>>>>> So, I am now sending a signal that has those weights applied to
>>>>>>>>>> it. So, after I do tb.start(), then I sleep for 10 seconds (by doing
>>>>>>>>>> sleep(10)) hoping that in the 10 seconds my receiver will catch the
>>>>>>>>>> signal
>>>>>>>>>> that I'm transmitting and put it into file.
>>>>>>>>>>
>>>>>>>>>> Flowgraph B:
>>>>>>>>>>
>>>>>>>>>> My own receiver.py in which I have a USRP sink->FFT->Complex to
>>>>>>>>>> Mag->File sink. I also have a connection from FFT->QT GUI to see a
>>>>>>>>>> plot of
>>>>>>>>>> what is being captured.
>>>>>>>>>>
>>>>>>>>>> I now run Flowgraph A in one terminal and Flowgraph B in another
>>>>>>>>>> terminal. I need to capture A's transmission with the first weights
>>>>>>>>>> within
>>>>>>>>>> the 10 seconds (as it's sleeping) into the file sink. Then, A will
>>>>>>>>>> send a
>>>>>>>>>> signal with another set of weights applied, and I will need to
>>>>>>>>>> capture that
>>>>>>>>>> in the next 10 seconds, and so on. My problem is that I'm often
>>>>>>>>>> capturing
>>>>>>>>>> noise because my receive was not aligned with when I was
>>>>>>>>>> transmitting my
>>>>>>>>>> desired signal. So, I end up only capturing noise after the
>>>>>>>>>> transmission
>>>>>>>>>> stops as opposed to the actual signal when the transmission is
>>>>>>>>>> happening.
>>>>>>>>>>
>>>>>>>>>> Essentially, I am trying to mimic feedback by doing the above,
>>>>>>>>>> but I don't know how to align my transmitter and receiver, especially
>>>>>>>>>> because they are two different blocks. Is there a way to make both
>>>>>>>>>> the
>>>>>>>>>> transmission and reception one block so that I can do sleep(rx_time +
>>>>>>>>>> n_samples_since_tag/sampling_rate) (I think this could be right?) as
>>>>>>>>>> opposed to my static sleep(10) and pray for the best?
>>>>>>>>>>
>>>>>>>>>> Would it be helpful at all if I showed you my code? I still feel
>>>>>>>>>> like I'm not being clear. Sorry about that. If there were any
>>>>>>>>>> examples,
>>>>>>>>>> then I think that would be the best for me to look at.
>>>>>>>>>>
>>>>>>>>>> Thanks for any help again.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Pavan
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Discuss-gnuradio mailing list
>>>>>>>>>> [email protected]
>>>>>>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Pavan
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Pavan
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Pavan
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Pavan
>>>>
>>>
>>>
>>>
>>> --
>>> Pavan
>>>
>>
>>
>
>
> --
> Pavan
>
--
Pavan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160429/8fdd909c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tx_setup
Type: application/octet-stream
Size: 51801 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160429/8fdd909c/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rx_setup.png
Type: image/png
Size: 37389 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160429/8fdd909c/attachment-0001.png>
------------------------------
Message: 11
Date: Fri, 29 Apr 2016 20:35:37 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP B200mini and additionnal LNA: fear the
blue smoke!
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
I'd also like to explicitly add that the noise figures of the AD936x IC
used in B2xx and E3xx are pretty good - in fact, yes, you can
justifiably call that an integrated LNA.
Best regards,
Marcus
On 29.04.2016 18:53, Marcus D. Leech via USRP-users wrote:
> On 04/29/2016 12:48 PM, Antoto Antoine via USRP-users wrote:
>> Great thanks!
>> I guess the 22.5dB from this LNA will be a good help then!
>> I'll keep you up with the project.
>>
>> Best
>> Antoine
> You usually don't need an exterior LNA unless you're dealing with very
> weak signals, and/or you have a long cable run between your
> antenna, and you're operating at higher frequencies (above 200-300Mhz).
>
> Weak signals would include things like satellite work, etc.
>
>
>>
>> ________________________________________
>> De : USRP-users <[email protected]> de la part de
>> Martin Braun via USRP-users <[email protected]>
>> Envoy? : vendredi 29 avril 2016 18:08
>> ? : [email protected]
>> Objet : Re: [USRP-users] USRP B200mini and additionnal LNA: fear the
>> blue smoke!
>>
>> On 04/29/2016 09:01 AM, Marcus D. Leech via USRP-users wrote:
>>> "Typical" signals at a receiver (or LNA input) are usually -60dBm or
>>> lower. If you're presenting 20dBm to a receiver input, regardless of
>>> protection, it may well destroy the receiver front end.
>>>
>>> The 1dB compression point is the power (either stated at the input or
>>> output) where the gain response is no longer linear. If that point is
>>> stated as output power, then you subtract the gain of the device to
>>> determine what the corresponding input power would be.
>>>
>>> Over-the-air RF signals are tiny, typically. One would not expect an
>>> over-the-air signal to exceed -15dBm except in unusual circumstances.
>> Hah, I was just typing out an email along the same lines :) I'll add,
>> just for the list archives, that while it is pretty unlikely to receive
>> a signal of that strength over an antenna, it is easily possible to
>> provide that kind of input power through a cabled connection, the most
>> likely case being when directly looping back a tx port to an rx port.
>> Hence the warning, and at this point we usually add a paragraph saying
>> you should be using attenuators for loopback.
>>
>> Cheers,
>> M
>>
>>
>> _______________________________________________
>> 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 list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 12
Date: Fri, 29 Apr 2016 14:39:23 -0400
From: Andy Walls <[email protected]>
To: Antoto Antoine <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP B200mini and additionnal LNA: fear the
blue smoke!
Message-ID: <1461955163.2852.29.camel@localhost>
Content-Type: text/plain; charset="UTF-8"
On Fri, 2016-04-29 at 18:05 +0000, Antoto Antoine wrote:
> @1nm with your calculations it gets really close (4dB difference) to the
> -15dBm limit!
> Thanks to point that out
> But even worse, the receiver is meant to be placed near an active airfield so
> I guess that the distance will be even shorter!
> So the LNA idea is scrapped for now.
> But now I can freak out and look for a power limiter or attenuator
>
> Thanks!
You're welcome.
You should probably take a calibrated spectrum analyzer out to the
sensor sites, fitted with a representative antenna and maybe one of
these filters:
http://www.amazon.com/ADS-B-1090MHz-Band-pass-SMA-Filter/dp/B010GBQXK8
and take some long-term, peak-power measurements.
And hey, here's what looks to be an integrated 20 dB amplifier and
RTL-SDR receiver:
http://www.amazon.com/FlightAware-Pro-Stick-ADS-B-Receiver/dp/B01D1ZAP3C/ref=pd_bxgy_23_img_2?ie=UTF8&refRID=03ZWDJ6D2MMHDMAX8F8R
Regards,
Andy
------------------------------
Message: 13
Date: Fri, 29 Apr 2016 15:06:06 -0400
From: James Humphries <[email protected]>
To: Cherif Chibane <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] UHD? installation problems
Message-ID:
<CAEwGFhVzjxHputtiSOiHbF7NQfxFy7V2zJZzK0+iCuaSLPYX=w...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Cherif,
A colleague also noticed that you may be trying to use network mode on the
E310? If so, you will need to match UHD versions on the host PC and E310.
Which image are you using on the E310? If it is release-4, you will need
UHD 3.9.2 on the host PC to match. You will also have to enable network
mode when you build UHD. Please see the following link for details on how
to do that:
http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_network_mode
Let me know if you need any assistance with that process.
-Trip
On Fri, Apr 29, 2016 at 8:33 AM, James Humphries <[email protected]>
wrote:
> Hi Cherif,
>
> Did you upgrade your UHD installation recently? That error usually
> indicates that you updated UHD, but did not rebuild the gr-uhd module. This
> can be done by rebuilding gnu-radio or you can rebuild the gr-uhd module.
> You should be able to just rebuild the gr-uhd module like this:
>
> cd <gnuradio_source>/build/gr-uhd
> make clean
> make
> sudo make install
>
> -Trip
>
> On Thu, Apr 28, 2016 at 10:01 PM, Cherif Chibane via USRP-users <
> [email protected]> wrote:
>
>> Hello All,
>>
>> I am using a E310 connected to a linux machine. I can ping the E310 fine
>> I have ran uhd_find_devices and uhd_find_devices fine.
>>
>> I have some GRC programs that do not have the UHD:USRP Source. And they
>> ran fine
>>
>> However, whenever I ran a GRC program that has UHD:USRP Source, I get
>> the following message
>> --------------------------------------------------
>> traceback (most recent call last):
>> File
>> "/home/cherif/Downloads/grc_labs-master/section05_projects/fm_radio_receiver.py",
>> line 276, in <module>
>> main()
>> File
>> "/home/cherif/Downloads/grc_labs-master/section05_projects/fm_radio_receiver.py",
>> line 264, in main
>> tb = top_block_cls(audio_output=options.audio_output,
>> freq=options.freq, gain=options.gain, samp_rate=options.samp_rate)
>> File
>> "/home/cherif/Downloads/grc_labs-master/section05_projects/fm_radio_receiver.py",
>> line 98, in __init__
>> channels=range(1),
>> File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
>> line 122, in constructor_interceptor
>> return old_constructor(*args)
>> File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
>> line 2249, in make
>> return _uhd_swig.usrp_source_make(*args)
>> RuntimeError:
>> GR-UHD detected ABI compatibility mismatch with UHD library.
>> GR-UHD was build against ABI: 3.9.0-0,
>> but UHD library reports ABI: 3.10.0-0
>> Suggestion: install an ABI compatible version of UHD,
>> or rebuild GR-UHD component against this ABI version.
>> -------------------------------------
>>
>> Does I have an old version of UHD. Git does not show and UHD latest
>> version 3.9 branch
>>
>> Any help is greatly appreciated.
>>
>> Cherif
>> _______________________________________________
>> 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/20160429/6343ab4b/attachment-0001.html>
------------------------------
Message: 14
Date: Fri, 29 Apr 2016 12:09:01 -0700
From: Derek Kozel <[email protected]>
To: Sanjoy Basak <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] switching between TX/RX and RX2 for SBX-120
Message-ID:
<CAA+K=tv8xbjrwwypvb1heed1upvvlohaluszze_a--_vnhf...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Sanjoy,
The python in your first email looks reasonable. Try running it and see if
it works. I'd keep the setup and code as simple as possible while testing,
get each component working before trying to do the full MIMO radar setup.
Derek
On Fri, Apr 29, 2016 at 6:17 AM, Sanjoy Basak <[email protected]>
wrote:
> Sorry, I sent the incomplete email. I am attaching the python file here
> that I am using.
> modified_file_sink_cc is an OOT module, just to save the first few (for
> example 4 specified here) transmit frames.
>
> I tried to put a sleep time and then switch the antenna (to RX2) after
> set_start_time, but this did not work. Please let me know, if it is
> possible to do switching this way (using uhd source, sink and python
> files). Or I need to follow the C++ examples.
>
> Best regards
> Sanjoy Basak
>
> On Fri, Apr 29, 2016 at 3:03 PM, Sanjoy Basak <[email protected]>
> wrote:
>
>> Hi Derek,
>> Thanks a lot for the reply. I am using one TX/RX as transmitter from one
>> daughterboard and trying to use TX/RX and RX2 ports as receivers (of
>> another SBX) in a TDD manner. I am just trying increase the number of TX
>> and RX elements of my MIMO radar in a TDD manner.
>>
>> The switching time can be 1 second. I am doing offline processing. First
>> saving the binary file and then processing in Matlab. I am using the uhd
>> source and sink and then using it on python file. Is it somehow possible to
>> incorporate the switching command here.
>>
>> self.transmitter.set_clock_source("gpsdo", 0)
>> self.transmitter.set_time_source("gpsdo", 0)
>> self.transmitter.set_subdev_spec("A:0", 0)
>> self.receiver.set_clock_source("gpsdo", 0)
>> self.receiver.set_time_source("gpsdo", 0)
>> self.receiver.set_subdev_spec("B:0", 0)
>>
>> self.transmitter.set_time_unknown_pps(uhd.time_spec())
>>
>> self.transmitter.set_samp_rate(samp_rate)
>> self.receiver.set_samp_rate(samp_rate)
>>
>> self.transmitter.set_gain(txgain, 0)
>> self.receiver.set_gain(15, 0)
>>
>> self.transmitter.set_antenna("TX/RX", 0)
>> self.receiver.set_antenna("TX/RX", 0)
>>
>> now = self.transmitter.get_time_now()
>> starttime = now + uhd.time_spec(0.5)
>>
>>
>> self.receiver.set_start_time(starttime)
>> self.transmitter.set_start_time(starttime)
>>
>>
>>
>>
>> On Thu, Apr 28, 2016 at 3:38 AM, Derek Kozel <[email protected]>
>> wrote:
>>
>>> Hello Sanjoy,
>>>
>>> The command to change the RX antenna for a channel is set_rx_antenna.
>>>
>>> http://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a72b7947cb0c434b98e9915f91b8f8fe0
>>>
>>> Your application will have to detect the first burst and issue the
>>> command to change antennas. How much time do you have between bursts? Also,
>>> you must not transmit and receive simultaneously on the same antenna, you
>>> will damage the receive RF chain. If your transmit antenna is too close to
>>> the receive antenna that can also cause damage depending on your transmit
>>> power and receive gain. Can you describe more of your application?
>>>
>>> Regards,
>>> Derek
>>>
>>> On Wed, Apr 27, 2016 at 5:05 PM, Sanjoy Basak via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> Hi all,
>>>> I want to perform switching between TX/RX and RX2 port for a TDD kind
>>>> of operation with SBX-120 daughterboard. Here, the TX/RX and RX2 both will
>>>> be used as receiver.
>>>> The transmitted burst will first be received by the TX/RX port and then
>>>> switch to the RX2 port and the rest bursts will be received by the RX2
>>>> port.
>>>>
>>>> How can I perform such switching operation?
>>>>
>>>> My setup is X310/SBX-120/UHD 3.10
>>>>
>>>> Best regards
>>>> Sanjoy Basak
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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/20160429/19c2fe66/attachment-0001.html>
------------------------------
Message: 15
Date: Fri, 29 Apr 2016 12:21:07 -0700
From: Derek Kozel <[email protected]>
To: Pavan Yedavalli <[email protected]>
Cc: "[email protected]" <[email protected]>,
GNURadio Discussion List <[email protected]>
Subject: Re: [USRP-users] Feedback with Transmitters and Receiver
Message-ID:
<CAA+K=tso1hbnsnm0+rzdw85sf23khhsuqpeucpqokktx-ad...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Pavan,
I'm sorry, I didn't read your cabling closely enough or I would have
noticed this before. If you only have one SBX in the receive N210, then you
only have one possible receive channel! That is why you are seeing the
error that RX channel 1 (remember they're 0 indexed) is out of range. On
the SBX, and all other daughterboards, the TX/RX and RX2 ports are shared
by a single receive channel. They are setup with a switch to allow either
time divided transmit and receive on a single antenna (using the TX/RX
port) or having separate transmit and receive connections (transmit on
TX/RX and receive on RX2).
You will need to use a combiner to merge the two transmit signals into a
single receive connection, to either TX/RX or RX2. Or use antennas and let
the air do your combining. You may want to keep the attenuators in line
until you are comfortable with the power levels. You'll be able to see when
your receiver is clipping in the Scope GUI.
Derek
On Fri, Apr 29, 2016 at 11:32 AM, Pavan Yedavalli <[email protected]>
wrote:
> Hi Derek,
>
> I made all the changes, and the Tx error as well as the warnings are now
> gone. However, the Rx error still remains:
>
> File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
> line 2168, in set_samp_rate
> return _uhd_swig.usrp_source_sptr_set_samp_rate(self, *args, **kwargs)
> RuntimeError: LookupError: IndexError: multi_usrp: RX channel 1 out of
> range for configured RX frontends
>
> I'm not entirely sure what the problem is here. Attached are the flowgraph
> pictures. In addition, I am using Rev 5.1 SBX daughterboards. Thanks again.
>
>
>
> On Thu, Apr 28, 2016 at 4:21 PM, Pavan Yedavalli <[email protected]>
> wrote:
>
>> Hi Derek,
>>
>> I appreciate it. Okay, I will change all of those. I am using the SBX
>> daughterboards - the ones that support phase sync.
>>
>> On Thu, Apr 28, 2016 at 3:55 PM, Derek Kozel <[email protected]>
>> wrote:
>>
>>> Hello Pavan,
>>>
>>> You do not need Ethernet connected to the Octoclock, so that's ok. Your
>>> cabling sounds correct. Can you please combine both UHD Sinks? Just
>>> increase the number of motherboards and channels to 2 and copy the MIMO
>>> attached USRP's settings into channel 2.
>>>
>>> Your sample rate for the receive side is very very low. I suspect that
>>> will throw a warning if you read the log output at the bottom of GRC. Try
>>> raising that to 500kHz or more. Also the WX Scope Sink can be changed to
>>> complex inputs so you don't need the converter blocks. You are also setting
>>> a custom clock rate. The N200 has a fixed master clock rate of 100 MHz so
>>> this is likely also throwing a warning in the log messages. Definitely look
>>> through those and make changes as needed.
>>>
>>> What daughterboards are you using? On the N200 series motherboards only
>>> the SBX daughterboards supports phase synchronization. What you should see
>>> is frequency and time synchronization between the MIMO N210s.
>>>
>>> Regards,
>>> Derek
>>>
>>> On Thu, Apr 28, 2016 at 12:22 PM, Pavan Yedavalli <[email protected]>
>>> wrote:
>>>
>>>> Hi Derek,
>>>>
>>>> Sorry - just another quick addition. When I run the Tx flowgraph, I get
>>>> this error:
>>>>
>>>> Board 0 May not be getting a PPS signal! No PPS detected within the
>>>> time interval.
>>>>
>>>> This definitely tells me something is wrong with the Octoclock-G setup.
>>>>
>>>> On Thu, Apr 28, 2016 at 12:18 PM, Pavan Yedavalli <[email protected]
>>>> > wrote:
>>>>
>>>>> Hi Derek,
>>>>>
>>>>> I am trying to do (3), as you noted above, and my test to see whether
>>>>> the Tx USRPs are transmitting at the same time is to directly connect them
>>>>> to the Rx USRP and plot the real components of each one and see whether
>>>>> they are in phase (or at least with some constant random offset). In
>>>>> theory, I believe this is a good test to see that the Octoclock-G is
>>>>> working its magic.
>>>>>
>>>>> The setup:
>>>>>
>>>>> *Octoclock*: Two of the three boards (Master Tx USRP and 1 Rx USRP)
>>>>> are connected to the Octoclock-G (one cable each from PPS out to PPS in,
>>>>> and one cable each from 10 MHz out to Ref in, so 4 total cables). The
>>>>> primary ref knob is set to Internal, and the PPS blinks green, while
>>>>> Internal, Status, and Power are all steady greens. I do *not* have
>>>>> the ethernet of the Octoclock connected, however. When I connected it to
>>>>> my
>>>>> Gb Ethernet switch, the indicator was orange, while all the other working
>>>>> ones are green, so I decided not to connect it for now. Does this matter?
>>>>>
>>>>> *Tx side*: I have both Tx USRPs connected to each other via the MIMO
>>>>> cable, and one of them is connected to the Octoclock, as mentioned above.
>>>>> In tx_mimo_setup_octoclock.png, we can see that I have two USRP sinks
>>>>> connected via MIMO cable, and one of them has time and clock set to
>>>>> External, and the other has time and clock set to MIMO cable. Both have
>>>>> sync set to Unknown PPS.
>>>>>
>>>>> *Between Tx and Rx*: I have an SMA cable from one Tx USRP connected
>>>>> to a 20 dB attenuator, and then connected to the Tx/Rx port of the Rx
>>>>> USRP.
>>>>> I have another SMA cable from the other Tx USRP connected to a 20 dB
>>>>> attenuator, and then connected to the Rx2 port of the Rx USRP. No antennas
>>>>> are connected.
>>>>>
>>>>> *Rx side*: In receiver_recvng_on_both_ports.png, we can see that I
>>>>> have a USRP source with two channels. The time and clock are set to
>>>>> External, and the sync is set to Unknown PPS. I run this, but I get the
>>>>> following error:
>>>>>
>>>>> RuntimeError: LookupError: IndexError: multi_usrp: RX channel 1 out of
>>>>> range for configured RX frontends
>>>>>
>>>>> I tried looking up what this error is, and apparently there was a fix
>>>>> in a branch years ago, but I'm assuming I have that fix already? I have a
>>>>> feeling something is wrong with the Octoclock setup that is causing this,
>>>>> but I'm not sure. I believe the setup I mentioned above makes sense,
>>>>> right?
>>>>>
>>>>> Obviously, I will look into timed commands in UHD and tags in GNU
>>>>> Radio after I get all of this set up and working. Thank you so much again
>>>>> for the help.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Apr 21, 2016 at 3:52 PM, Derek Kozel <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> Hi Pavan,
>>>>>>
>>>>>> This is a USRP/UHD question really so I'm including the usrp-users
>>>>>> mailing list. If you're not already the list already then you should
>>>>>> certainly join as that's a better resource for questions about UHD/USRPs.
>>>>>>
>>>>>> 1) Any SMA cable will work. For the best performance their electrical
>>>>>> lengths should be the same. In practice this usually means equal physical
>>>>>> lengths of the same type of coax. This ensures that the signals arrive at
>>>>>> the same time (and phase).
>>>>>>
>>>>>> 2) Most radio systems don't have GPS timebases available and use
>>>>>> various protocol level methods for aligning their clocks, if needed. In a
>>>>>> very simple system the receiver could simply listen continuously until it
>>>>>> receives a full message, then transmits a response if needed. Look up
>>>>>> Time
>>>>>> Division Multiplexing and Frequency Division Multiplexing. This is an
>>>>>> area
>>>>>> where there are nearly as many possibilities as there are radio systems.
>>>>>>
>>>>>> 3) Once you connect all the Octoclock signals then in GNU Radio you
>>>>>> can select the Clock and Time sources to be External and the Sync to be
>>>>>> Unknown PPS. Your pair of units connected via a MIMO cable are special,
>>>>>> the
>>>>>> master should have the External time and clock sources, the companion
>>>>>> USRP
>>>>>> should have MIMO selected for time and clock. The Sync should still be
>>>>>> Unknown PPS.
>>>>>>
>>>>>> Here's a page that talks about synchronization of USRPs. Read this,
>>>>>> get your hardware all setup, and try setting up a basic GRC flowgraph
>>>>>> with
>>>>>> your three radios. Think of what tests you could use to verify that both
>>>>>> your MIMO cabled radios are transmitting at the same time. You should
>>>>>> look
>>>>>> into timed commands in UHD and tags in GNU Radio.
>>>>>>
>>>>>> http://files.ettus.com/manual/page_sync.html
>>>>>>
>>>>>> https://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp_updated.pdf
>>>>>>
>>>>>> If this is your first use of USRPs and GNU Radio then I'd suggest
>>>>>> reading through the tutorials available online and not get too focused on
>>>>>> MIMO until you feel comfortable with the basics of the environment and
>>>>>> tools that you have.
>>>>>>
>>>>>> http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials
>>>>>>
>>>>>> Once you've given this a try let us know if you have additional
>>>>>> questions.
>>>>>>
>>>>>> Regards,
>>>>>> Derek
>>>>>>
>>>>>>
>>>>>> On Thu, Apr 21, 2016 at 3:27 PM, Pavan Yedavalli <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> Hi Derek,
>>>>>>>
>>>>>>> Thanks for getting back to me. So, I do have an Octoclock, so I
>>>>>>> think we're getting somewhere and this is starting to make more sense. A
>>>>>>> few follow up questions:
>>>>>>>
>>>>>>> 1.) Do I need special cables to connect all of the units to the
>>>>>>> Octoclock, or are they robust SMA cables?
>>>>>>>
>>>>>>> 2.) I feel like this seems particularly involved to send a signal
>>>>>>> from a transmitter to a receiver. I am assuming most non-MIMO,
>>>>>>> non-beamforming related tasks have always used your second option of
>>>>>>> using
>>>>>>> the GPSDO kits? I purchased an Octoclock knowing I would do MIMO
>>>>>>> experiments, but obviously I'm guessing more conventional communication
>>>>>>> techniques (like a simple BPSK or QPSK between tx and rx) would have
>>>>>>> probably used the GPSDO kits?
>>>>>>>
>>>>>>> 3.) Once I connect them all to the Octoclock, then I don't need to a
>>>>>>> protocol level time synchronization, right? Once they're all
>>>>>>> synchronized
>>>>>>> and I see that in the plots, then I guess the next step would be to
>>>>>>> figure
>>>>>>> out how to implement my actual feedback loop. At that point, then I
>>>>>>> would
>>>>>>> need to figure out how to do burst mode to transmit and receiver timed
>>>>>>> signals? Would this end up needing to be one flow graph or would I have
>>>>>>> to
>>>>>>> use two flow graphs? (One for to and one for rx, the way I am doing it
>>>>>>> now)
>>>>>>>
>>>>>>> Thank you again for all the help. I think I'm starting to
>>>>>>> understand what I need in the setup.
>>>>>>>
>>>>>>> On Thu, Apr 21, 2016 at 4:56 PM, Derek Kozel <[email protected]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hello Pavan,
>>>>>>>>
>>>>>>>> I think we both are starting to understand the setup and the
>>>>>>>> problem. Here are the two hardware solutions:
>>>>>>>>
>>>>>>>> Connect a shared 1PPS signal to *both* the master USRP of your MIMO
>>>>>>>> cabled pair and to the receiver (For example using an octoclock:
>>>>>>>> https://www.ettus.com/product/details/OctoClock-G)
>>>>>>>>
>>>>>>>> OR
>>>>>>>>
>>>>>>>> Connect GPS referenced 1PPS signals to both the master USRP of your
>>>>>>>> MIMO cabled pair and the receiver (For example using two of the GPSDO
>>>>>>>> kits:
>>>>>>>> https://www.ettus.com/product/details/GPSDO-KIT)
>>>>>>>>
>>>>>>>>
>>>>>>>> There are many ways of implementing a protocol level time
>>>>>>>> synchronization in software/DSP. The paper I linked to talks about one
>>>>>>>> way,
>>>>>>>> there are certainly others. I do not know of any example projects
>>>>>>>> implementing them though so you would have to develop your own.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Derek
>>>>>>>>
>>>>>>>> On Thu, Apr 21, 2016 at 8:04 AM, Pavan Yedavalli <
>>>>>>>> [email protected]> wrote:
>>>>>>>>
>>>>>>>>> Hi Derek,
>>>>>>>>>
>>>>>>>>> I'll answer your questions in-line, because I think what you are
>>>>>>>>> saying is beginning to make me understand what I need:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Apr 20, 2016 at 9:03 PM, Derek Kozel <
>>>>>>>>> [email protected]> wrote:
>>>>>>>>>
>>>>>>>>>> Hello Pavan,
>>>>>>>>>>
>>>>>>>>>> Are you trying to create a shared timebase between the two USRPs
>>>>>>>>>> without having a shared 1PPS or GPS reference? You are still not
>>>>>>>>>> using
>>>>>>>>>> enough detail for us to understand fully.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> To clarify, my setup is two USRPs connected via MIMO cable, and
>>>>>>>>> then another USRP acting as a receiver. So are you asking whether I'm
>>>>>>>>> trying to create a shared timebase between the two-USRP *unit*
>>>>>>>>> (because
>>>>>>>>> they are MIMO cabled) and the receiving USRP without having a shared
>>>>>>>>> 1 PPS
>>>>>>>>> or GPS reference? I think my answer to that must be yes, because I
>>>>>>>>> have not
>>>>>>>>> done anything else but connect them to the computer via ethernet and
>>>>>>>>> just
>>>>>>>>> have two of them connected via MIMO cable and the other one by
>>>>>>>>> itself. I'm
>>>>>>>>> assuming I need to have a shared reference between the transmit USRPs
>>>>>>>>> and
>>>>>>>>> the receive USRP, so how would I be able to do that? This could
>>>>>>>>> certainly
>>>>>>>>> be one of my problems.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> In Figure 5 both USRPs are connected with a MIMO cable and so
>>>>>>>>>> have both shared frequency and time bases. What is your weight block
>>>>>>>>>> doing
>>>>>>>>>> to the sample stream? Is it a time delay block? I don't know what
>>>>>>>>>> gnuradio
>>>>>>>>>> would do if you specified 10*sample_rate as the delay there as that's
>>>>>>>>>> likely to be a very large number of samples.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> My weight block is applying a normalized magnitude phase
>>>>>>>>> correction to each antenna's transmitted signal, so, yes, it is
>>>>>>>>> essentially
>>>>>>>>> creating a time delay. Each weight is a complex value with magnitude
>>>>>>>>> 1 and
>>>>>>>>> a calculated phase. You are saying this could be a problem if it's
>>>>>>>>> calculating a value that is too high?
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> If you have both USRPs connected with a time synchronization
>>>>>>>>>> (shared 1PPS, GPSDO, or MIMO cable) and have your flowgraph
>>>>>>>>>> configured
>>>>>>>>>> correctly, then you can just use timed commands to the USRP_alpha to
>>>>>>>>>> start
>>>>>>>>>> transmitting at time X and USRP_beta to start receiving at time X
>>>>>>>>>> and you
>>>>>>>>>> will see your signal. You can then move to using burst mode using
>>>>>>>>>> tags to
>>>>>>>>>> define the number of samples to send/receive along with timed
>>>>>>>>>> commands to
>>>>>>>>>> send/receive bursts of samples. This works because the clocks in
>>>>>>>>>> both USRPs
>>>>>>>>>> will be aligned to each other.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I feel like there are two steps here. First, I need to get the
>>>>>>>>> transmitting USRPs (which are conneced via MIMO cable) to time sync
>>>>>>>>> to each
>>>>>>>>> other (which I believe I have done through using USRP sink in GRC and
>>>>>>>>> setting the second channels time and clock to MIMO cable?), and
>>>>>>>>> second, I
>>>>>>>>> need to get the receive USRP to receive at the same time. So, just as
>>>>>>>>> above, I need to get my receive USRP to be on the same time as my
>>>>>>>>> transmit
>>>>>>>>> USRPs? Once I'm able to do that, then I can do burst mode to transmit
>>>>>>>>> and
>>>>>>>>> receive timed signals, as you are mentioning?
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> If you do *NOT* have a shared time source for each radio, for
>>>>>>>>>> instance they are far apart and do not have GPS references, then you
>>>>>>>>>> need
>>>>>>>>>> to do some sort of protocol level alignment to create a shared
>>>>>>>>>> understanding of time between them. A frequently used method is for
>>>>>>>>>> USRP_alpha to transmit a beacon with a known period (say once every
>>>>>>>>>> 10
>>>>>>>>>> seconds). All other USRPs then receive for longer than 10 seconds to
>>>>>>>>>> be
>>>>>>>>>> guaranteed to receive the beacon (assuming they're within range of
>>>>>>>>>> the
>>>>>>>>>> transmission). When the receiving USRPs detect the incoming beacon
>>>>>>>>>> they
>>>>>>>>>> align their local time to the master (Beacon transmitting) USRP.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I guess a similar question to the above: can I have a shared time
>>>>>>>>> source between the transmit USRPs (which are already MIMO cabled to
>>>>>>>>> each
>>>>>>>>> other) and the receive USRP? It seems like that would be easier to do
>>>>>>>>> than
>>>>>>>>> going through this protocol level alignment, but maybe it's not
>>>>>>>>> possible
>>>>>>>>> given my setup.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Here's a quick paper talking about this topic. The technique is
>>>>>>>>>> widely used.
>>>>>>>>>> http://www.ece.uah.edu/~milenka/docs/dc_ssst05_synch.pdf
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I hope this helps and is applicable to your need. If you have
>>>>>>>>>> more questions please try drawing your desired system and maybe
>>>>>>>>>> include a
>>>>>>>>>> timeline of events that you expect the radios to do. Attaching your
>>>>>>>>>> existing flowgraphs, either as photos using GRC's screen capture
>>>>>>>>>> feature
>>>>>>>>>> (file>screen capture) or the actual GRC file, also helps us
>>>>>>>>>> understand what
>>>>>>>>>> exactly you are working with.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I had to take down the setup because I am moving labs, but I will
>>>>>>>>> send some flowgraphs and the diagram of the system next week. Thank
>>>>>>>>> you
>>>>>>>>> again for being so patient and trying to help me. I think I'm just a
>>>>>>>>> bit
>>>>>>>>> lost on a few of the simple things, but once those are figured out,
>>>>>>>>> then I
>>>>>>>>> think it should be smoother sailing.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Derek
>>>>>>>>>>
>>>>>>>>>> On Wed, Apr 20, 2016 at 4:05 PM, Pavan Yedavalli <
>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Martin,
>>>>>>>>>>>
>>>>>>>>>>> I guess I have a few questions:
>>>>>>>>>>>
>>>>>>>>>>> 1.) Are there any examples in the gnuradio codebase/flowgraph
>>>>>>>>>>> repository that show how to do synchronized feedback between two
>>>>>>>>>>> USRPs? In
>>>>>>>>>>> other words, I send a signal from a transmit USRP, and then I
>>>>>>>>>>> receive that
>>>>>>>>>>> signal at the receive USRP, and then I send back something else
>>>>>>>>>>> from the
>>>>>>>>>>> receive USRP back to the transmit USRP, and this would be a
>>>>>>>>>>> sequential
>>>>>>>>>>> process in which they are aligned and know when to transmit and/or
>>>>>>>>>>> receive?
>>>>>>>>>>> I saw a post
>>>>>>>>>>> <http://stackoverflow.com/questions/28710869/how-to-set-usrp-transmitting-time-and-receiving-time-in-gnu-radio>
>>>>>>>>>>> that
>>>>>>>>>>> I think would be relevant, but I'm not sure how to apply it.
>>>>>>>>>>>
>>>>>>>>>>> I believe this should be a pretty standard scenario in which you
>>>>>>>>>>> want to have two USRPs communicate with each other synchronously. I
>>>>>>>>>>> guess
>>>>>>>>>>> I'm just having trouble finding an example of how to do this.
>>>>>>>>>>>
>>>>>>>>>>> 2.) Related to the above question, maybe there are no examples
>>>>>>>>>>> to do feedback in one flowgraph, so what I have been doing is the
>>>>>>>>>>> following
>>>>>>>>>>> in my flowgraphs:
>>>>>>>>>>>
>>>>>>>>>>> Flowgraph A:
>>>>>>>>>>>
>>>>>>>>>>> The synchronized MIMO flowgraph (Figure 5) from this
>>>>>>>>>>> <https://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp.pdf>,
>>>>>>>>>>> so essentially I have two USRPs synchronized and transmitting out
>>>>>>>>>>> two
>>>>>>>>>>> signals that should be offset but frequency aligned. In my own
>>>>>>>>>>> flowgraph's
>>>>>>>>>>> main(), instead of applying a "phase shift" block, I am applying my
>>>>>>>>>>> own
>>>>>>>>>>> "weights" block to both transmissions.
>>>>>>>>>>>
>>>>>>>>>>> So, I am now sending a signal that has those weights applied to
>>>>>>>>>>> it. So, after I do tb.start(), then I sleep for 10 seconds (by doing
>>>>>>>>>>> sleep(10)) hoping that in the 10 seconds my receiver will catch the
>>>>>>>>>>> signal
>>>>>>>>>>> that I'm transmitting and put it into file.
>>>>>>>>>>>
>>>>>>>>>>> Flowgraph B:
>>>>>>>>>>>
>>>>>>>>>>> My own receiver.py in which I have a USRP sink->FFT->Complex to
>>>>>>>>>>> Mag->File sink. I also have a connection from FFT->QT GUI to see a
>>>>>>>>>>> plot of
>>>>>>>>>>> what is being captured.
>>>>>>>>>>>
>>>>>>>>>>> I now run Flowgraph A in one terminal and Flowgraph B in another
>>>>>>>>>>> terminal. I need to capture A's transmission with the first weights
>>>>>>>>>>> within
>>>>>>>>>>> the 10 seconds (as it's sleeping) into the file sink. Then, A will
>>>>>>>>>>> send a
>>>>>>>>>>> signal with another set of weights applied, and I will need to
>>>>>>>>>>> capture that
>>>>>>>>>>> in the next 10 seconds, and so on. My problem is that I'm often
>>>>>>>>>>> capturing
>>>>>>>>>>> noise because my receive was not aligned with when I was
>>>>>>>>>>> transmitting my
>>>>>>>>>>> desired signal. So, I end up only capturing noise after the
>>>>>>>>>>> transmission
>>>>>>>>>>> stops as opposed to the actual signal when the transmission is
>>>>>>>>>>> happening.
>>>>>>>>>>>
>>>>>>>>>>> Essentially, I am trying to mimic feedback by doing the above,
>>>>>>>>>>> but I don't know how to align my transmitter and receiver,
>>>>>>>>>>> especially
>>>>>>>>>>> because they are two different blocks. Is there a way to make both
>>>>>>>>>>> the
>>>>>>>>>>> transmission and reception one block so that I can do sleep(rx_time
>>>>>>>>>>> +
>>>>>>>>>>> n_samples_since_tag/sampling_rate) (I think this could be right?) as
>>>>>>>>>>> opposed to my static sleep(10) and pray for the best?
>>>>>>>>>>>
>>>>>>>>>>> Would it be helpful at all if I showed you my code? I still feel
>>>>>>>>>>> like I'm not being clear. Sorry about that. If there were any
>>>>>>>>>>> examples,
>>>>>>>>>>> then I think that would be the best for me to look at.
>>>>>>>>>>>
>>>>>>>>>>> Thanks for any help again.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Pavan
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Discuss-gnuradio mailing list
>>>>>>>>>>> [email protected]
>>>>>>>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Pavan
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Pavan
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Pavan
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Pavan
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Pavan
>>>>
>>>
>>>
>>
>>
>> --
>> Pavan
>>
>
>
>
> --
> Pavan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160429/81bd7c55/attachment-0001.html>
------------------------------
Message: 16
Date: Fri, 29 Apr 2016 19:37:12 +0000
From: Weidong Wang <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] How to use DDR memory on E310 RFNOC version
Message-ID:
<bl2pr03mb46652c4d553f67485989fc7f0...@bl2pr03mb466.namprd03.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
I want to access the DDR memory on E310 to store data in RFNOC blocs. I
only find these codes for general version of FPGA on this page:
https://github.com/EttusResearch/fpga/commit/1e6182463c7bf8ca534d91634f703d5dbfd820d6
Could I just add these codes to the same files of RFNOC to use the DDR
memory?
Thanks,
Weidong
------------------------------
Message: 17
Date: Fri, 29 Apr 2016 14:36:20 -0700
From: Neel Pandeya <[email protected]>
To: tilla <[email protected]>
Cc: Marcus M?ller <[email protected]>, usrp-users
<[email protected]>
Subject: Re: [USRP-users] X310 UBX Tx issues
Message-ID:
<CACaXmv_=TGu=Qi=jW=wr-vtxxwt5tbt_p7yojr+nd-zvck4...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Tilla:
I have reproduced this issue. By default UBX uses a performance mode, where
all the RF components are continuously powered on. This mode provides
faster tuning times, but can increase the noise floor. Alternatively, you
may use the powersave mode, which will power off components when not being
used, thus lowering power consumption and reducing the heat generated. You
can select this mode with the single line of code listed below, which uses
the property tree, and where <N> is the motherboard number, such as "0",
and <X> is the daughterboard slot, such as "B".
usrp->get_device()->get_tree()->access<std::string>("/mboards/<N>/dboards/<X>/rx_frontends/0/power_mode/value").set("powersave");
Please let us know if this fixes the issue for you. Thanks.
--Neel Pandeya
On 19 April 2016 at 14:10, <[email protected]> wrote:
> Probe output attached...
>
> As a bonus, on page 3, there is a spectrum analyzer screen shot of the
> output of uhd_usrp_probe...
>
> Yes, there is rf output similar to described within tx_waveforms original
> issue to start this thread.
>
> The lowest signal level is the noise floor, the second level is output
> during some of the startup of uhd_usrp_probe, the third level is output
> forever, even after the uhd_usrp_probe application has exited...
>
> ------------------------------
> *From: *"tilla--- via USRP-users" <[email protected]>
> *To: *"Marcus M?ller" <[email protected]>, "Neel Pandeya" <
> [email protected]>
> *Cc: *"usrp-users" <[email protected]>
> *Sent: *Tuesday, April 19, 2016 1:15:37 PM
> *Subject: *Re: [USRP-users] X310 UBX Tx issues
>
> Nothing yet.
>
> Neel, listed below, UHD 3.9.2...
>
> I can get you a probe output in a bit...
>
> ------------------------------
> *From: *"Marcus M?ller via USRP-users" <[email protected]>
> *To: *"usrp-users" <[email protected]>
> *Sent: *Tuesday, April 19, 2016 11:39:59 AM
> *Subject: *Re: [USRP-users] X310 UBX Tx issues
>
> Hi Tilla,
>
> I totally got lost in the discussions involving you, of which some were
> off-list; has this been addressed?
>
> Best regards,
> Marcus
>
> On 04/04/2016 05:59 PM, tilla--- via USRP-users wrote:
>
> Platform:
> Win 7 64 bit
> UHD 3.9.2
> Visual Studio 2015 Update 1
> X310 with UBX-160
> 10Gb interface
>
> I am porting my hardware platform from WBX-120 cards over to UBX-160.
>
> There are some strange things going on with UBX-160.
>
> Looking at the output signal on a spectrum analyzer zero span 1 MHz BW at
> center frequency, the noise floor is about -75 dbm.
>
> executing the command tx_waveforms --args addr=192.168.40.2 --rate
> 10000000 --freq 300000000
>
> When the app starts, signal level goes to about -70 dbm for 1 second, then
> -48 dbm for about 2 seconds, then to -15 dbm for the remainder of the
> application execution. Upon control-c of the application to halt, a signal
> is still being transmitted by the card at -53 dbm.
>
> When run on a WBX-120, none of these startup or shutdown artifacts are
> present.
>
> Seems to be present on all frequencies at varying amplitudes.
>
> I have tried this on multiple X310s and multiple UBX cards, all exhibit
> the same performance.
>
> Is this something you guys are aware of?
>
> Thanks,
>
>
>
> _______________________________________________
> 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/20160429/4c2d766d/attachment-0001.html>
------------------------------
Message: 18
Date: Fri, 29 Apr 2016 17:14:30 -0700
From: Pavan Yedavalli <[email protected]>
To: Derek Kozel <[email protected]>
Cc: "[email protected]" <[email protected]>,
GNURadio Discussion List <[email protected]>
Subject: Re: [USRP-users] Feedback with Transmitters and Receiver
Message-ID:
<CACaX0_OJCv1=h4nsxoo2bhsc5hiktgcbgg9ao35v44f0qgl...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Derek,
That makes sense. I will put a combiner and try this. However, now the test
is a bit different, right? The only way I could tell that the transmitters
are transmitting at the same time is if the power level is double what it
used to be, assuming they are actually fully in phase. Is there a
possibility that they are out of phase though, but there is a constant
random offset, so they add up slightly differently and not completely
coherently? (as shown in Figure 7 in this document
<https://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp_updated.pdf>
)
Thanks again.
On Fri, Apr 29, 2016 at 12:21 PM, Derek Kozel <[email protected]> wrote:
> Hi Pavan,
>
> I'm sorry, I didn't read your cabling closely enough or I would have
> noticed this before. If you only have one SBX in the receive N210, then you
> only have one possible receive channel! That is why you are seeing the
> error that RX channel 1 (remember they're 0 indexed) is out of range. On
> the SBX, and all other daughterboards, the TX/RX and RX2 ports are shared
> by a single receive channel. They are setup with a switch to allow either
> time divided transmit and receive on a single antenna (using the TX/RX
> port) or having separate transmit and receive connections (transmit on
> TX/RX and receive on RX2).
>
> You will need to use a combiner to merge the two transmit signals into a
> single receive connection, to either TX/RX or RX2. Or use antennas and let
> the air do your combining. You may want to keep the attenuators in line
> until you are comfortable with the power levels. You'll be able to see when
> your receiver is clipping in the Scope GUI.
>
> Derek
>
> On Fri, Apr 29, 2016 at 11:32 AM, Pavan Yedavalli <[email protected]>
> wrote:
>
>> Hi Derek,
>>
>> I made all the changes, and the Tx error as well as the warnings are now
>> gone. However, the Rx error still remains:
>>
>> File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
>> line 2168, in set_samp_rate
>> return _uhd_swig.usrp_source_sptr_set_samp_rate(self, *args,
>> **kwargs)
>> RuntimeError: LookupError: IndexError: multi_usrp: RX channel 1 out of
>> range for configured RX frontends
>>
>> I'm not entirely sure what the problem is here. Attached are the
>> flowgraph pictures. In addition, I am using Rev 5.1 SBX daughterboards.
>> Thanks again.
>>
>>
>>
>> On Thu, Apr 28, 2016 at 4:21 PM, Pavan Yedavalli <[email protected]>
>> wrote:
>>
>>> Hi Derek,
>>>
>>> I appreciate it. Okay, I will change all of those. I am using the SBX
>>> daughterboards - the ones that support phase sync.
>>>
>>> On Thu, Apr 28, 2016 at 3:55 PM, Derek Kozel <[email protected]>
>>> wrote:
>>>
>>>> Hello Pavan,
>>>>
>>>> You do not need Ethernet connected to the Octoclock, so that's ok. Your
>>>> cabling sounds correct. Can you please combine both UHD Sinks? Just
>>>> increase the number of motherboards and channels to 2 and copy the MIMO
>>>> attached USRP's settings into channel 2.
>>>>
>>>> Your sample rate for the receive side is very very low. I suspect that
>>>> will throw a warning if you read the log output at the bottom of GRC. Try
>>>> raising that to 500kHz or more. Also the WX Scope Sink can be changed to
>>>> complex inputs so you don't need the converter blocks. You are also setting
>>>> a custom clock rate. The N200 has a fixed master clock rate of 100 MHz so
>>>> this is likely also throwing a warning in the log messages. Definitely look
>>>> through those and make changes as needed.
>>>>
>>>> What daughterboards are you using? On the N200 series motherboards only
>>>> the SBX daughterboards supports phase synchronization. What you should see
>>>> is frequency and time synchronization between the MIMO N210s.
>>>>
>>>> Regards,
>>>> Derek
>>>>
>>>> On Thu, Apr 28, 2016 at 12:22 PM, Pavan Yedavalli <[email protected]
>>>> > wrote:
>>>>
>>>>> Hi Derek,
>>>>>
>>>>> Sorry - just another quick addition. When I run the Tx flowgraph, I
>>>>> get this error:
>>>>>
>>>>> Board 0 May not be getting a PPS signal! No PPS detected within the
>>>>> time interval.
>>>>>
>>>>> This definitely tells me something is wrong with the Octoclock-G setup.
>>>>>
>>>>> On Thu, Apr 28, 2016 at 12:18 PM, Pavan Yedavalli <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> Hi Derek,
>>>>>>
>>>>>> I am trying to do (3), as you noted above, and my test to see whether
>>>>>> the Tx USRPs are transmitting at the same time is to directly connect
>>>>>> them
>>>>>> to the Rx USRP and plot the real components of each one and see whether
>>>>>> they are in phase (or at least with some constant random offset). In
>>>>>> theory, I believe this is a good test to see that the Octoclock-G is
>>>>>> working its magic.
>>>>>>
>>>>>> The setup:
>>>>>>
>>>>>> *Octoclock*: Two of the three boards (Master Tx USRP and 1 Rx USRP)
>>>>>> are connected to the Octoclock-G (one cable each from PPS out to PPS in,
>>>>>> and one cable each from 10 MHz out to Ref in, so 4 total cables). The
>>>>>> primary ref knob is set to Internal, and the PPS blinks green, while
>>>>>> Internal, Status, and Power are all steady greens. I do *not* have
>>>>>> the ethernet of the Octoclock connected, however. When I connected it to
>>>>>> my
>>>>>> Gb Ethernet switch, the indicator was orange, while all the other working
>>>>>> ones are green, so I decided not to connect it for now. Does this matter?
>>>>>>
>>>>>> *Tx side*: I have both Tx USRPs connected to each other via the MIMO
>>>>>> cable, and one of them is connected to the Octoclock, as mentioned above.
>>>>>> In tx_mimo_setup_octoclock.png, we can see that I have two USRP sinks
>>>>>> connected via MIMO cable, and one of them has time and clock set to
>>>>>> External, and the other has time and clock set to MIMO cable. Both have
>>>>>> sync set to Unknown PPS.
>>>>>>
>>>>>> *Between Tx and Rx*: I have an SMA cable from one Tx USRP connected
>>>>>> to a 20 dB attenuator, and then connected to the Tx/Rx port of the Rx
>>>>>> USRP.
>>>>>> I have another SMA cable from the other Tx USRP connected to a 20 dB
>>>>>> attenuator, and then connected to the Rx2 port of the Rx USRP. No
>>>>>> antennas
>>>>>> are connected.
>>>>>>
>>>>>> *Rx side*: In receiver_recvng_on_both_ports.png, we can see that I
>>>>>> have a USRP source with two channels. The time and clock are set to
>>>>>> External, and the sync is set to Unknown PPS. I run this, but I get the
>>>>>> following error:
>>>>>>
>>>>>> RuntimeError: LookupError: IndexError: multi_usrp: RX channel 1 out
>>>>>> of range for configured RX frontends
>>>>>>
>>>>>> I tried looking up what this error is, and apparently there was a fix
>>>>>> in a branch years ago, but I'm assuming I have that fix already? I have a
>>>>>> feeling something is wrong with the Octoclock setup that is causing this,
>>>>>> but I'm not sure. I believe the setup I mentioned above makes sense,
>>>>>> right?
>>>>>>
>>>>>> Obviously, I will look into timed commands in UHD and tags in GNU
>>>>>> Radio after I get all of this set up and working. Thank you so much again
>>>>>> for the help.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Apr 21, 2016 at 3:52 PM, Derek Kozel <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Pavan,
>>>>>>>
>>>>>>> This is a USRP/UHD question really so I'm including the usrp-users
>>>>>>> mailing list. If you're not already the list already then you should
>>>>>>> certainly join as that's a better resource for questions about
>>>>>>> UHD/USRPs.
>>>>>>>
>>>>>>> 1) Any SMA cable will work. For the best performance their
>>>>>>> electrical lengths should be the same. In practice this usually means
>>>>>>> equal
>>>>>>> physical lengths of the same type of coax. This ensures that the signals
>>>>>>> arrive at the same time (and phase).
>>>>>>>
>>>>>>> 2) Most radio systems don't have GPS timebases available and use
>>>>>>> various protocol level methods for aligning their clocks, if needed. In
>>>>>>> a
>>>>>>> very simple system the receiver could simply listen continuously until
>>>>>>> it
>>>>>>> receives a full message, then transmits a response if needed. Look up
>>>>>>> Time
>>>>>>> Division Multiplexing and Frequency Division Multiplexing. This is an
>>>>>>> area
>>>>>>> where there are nearly as many possibilities as there are radio systems.
>>>>>>>
>>>>>>> 3) Once you connect all the Octoclock signals then in GNU Radio you
>>>>>>> can select the Clock and Time sources to be External and the Sync to be
>>>>>>> Unknown PPS. Your pair of units connected via a MIMO cable are special,
>>>>>>> the
>>>>>>> master should have the External time and clock sources, the companion
>>>>>>> USRP
>>>>>>> should have MIMO selected for time and clock. The Sync should still be
>>>>>>> Unknown PPS.
>>>>>>>
>>>>>>> Here's a page that talks about synchronization of USRPs. Read this,
>>>>>>> get your hardware all setup, and try setting up a basic GRC flowgraph
>>>>>>> with
>>>>>>> your three radios. Think of what tests you could use to verify that both
>>>>>>> your MIMO cabled radios are transmitting at the same time. You should
>>>>>>> look
>>>>>>> into timed commands in UHD and tags in GNU Radio.
>>>>>>>
>>>>>>> http://files.ettus.com/manual/page_sync.html
>>>>>>>
>>>>>>> https://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp_updated.pdf
>>>>>>>
>>>>>>> If this is your first use of USRPs and GNU Radio then I'd suggest
>>>>>>> reading through the tutorials available online and not get too focused
>>>>>>> on
>>>>>>> MIMO until you feel comfortable with the basics of the environment and
>>>>>>> tools that you have.
>>>>>>>
>>>>>>> http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials
>>>>>>>
>>>>>>> Once you've given this a try let us know if you have additional
>>>>>>> questions.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Derek
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Apr 21, 2016 at 3:27 PM, Pavan Yedavalli <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>> Hi Derek,
>>>>>>>>
>>>>>>>> Thanks for getting back to me. So, I do have an Octoclock, so I
>>>>>>>> think we're getting somewhere and this is starting to make more sense.
>>>>>>>> A
>>>>>>>> few follow up questions:
>>>>>>>>
>>>>>>>> 1.) Do I need special cables to connect all of the units to the
>>>>>>>> Octoclock, or are they robust SMA cables?
>>>>>>>>
>>>>>>>> 2.) I feel like this seems particularly involved to send a signal
>>>>>>>> from a transmitter to a receiver. I am assuming most non-MIMO,
>>>>>>>> non-beamforming related tasks have always used your second option of
>>>>>>>> using
>>>>>>>> the GPSDO kits? I purchased an Octoclock knowing I would do MIMO
>>>>>>>> experiments, but obviously I'm guessing more conventional communication
>>>>>>>> techniques (like a simple BPSK or QPSK between tx and rx) would have
>>>>>>>> probably used the GPSDO kits?
>>>>>>>>
>>>>>>>> 3.) Once I connect them all to the Octoclock, then I don't need to
>>>>>>>> a protocol level time synchronization, right? Once they're all
>>>>>>>> synchronized
>>>>>>>> and I see that in the plots, then I guess the next step would be to
>>>>>>>> figure
>>>>>>>> out how to implement my actual feedback loop. At that point, then I
>>>>>>>> would
>>>>>>>> need to figure out how to do burst mode to transmit and receiver timed
>>>>>>>> signals? Would this end up needing to be one flow graph or would I
>>>>>>>> have to
>>>>>>>> use two flow graphs? (One for to and one for rx, the way I am doing it
>>>>>>>> now)
>>>>>>>>
>>>>>>>> Thank you again for all the help. I think I'm starting to
>>>>>>>> understand what I need in the setup.
>>>>>>>>
>>>>>>>> On Thu, Apr 21, 2016 at 4:56 PM, Derek Kozel <[email protected]
>>>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> Hello Pavan,
>>>>>>>>>
>>>>>>>>> I think we both are starting to understand the setup and the
>>>>>>>>> problem. Here are the two hardware solutions:
>>>>>>>>>
>>>>>>>>> Connect a shared 1PPS signal to *both* the master USRP of your
>>>>>>>>> MIMO cabled pair and to the receiver (For example using an octoclock:
>>>>>>>>> https://www.ettus.com/product/details/OctoClock-G)
>>>>>>>>>
>>>>>>>>> OR
>>>>>>>>>
>>>>>>>>> Connect GPS referenced 1PPS signals to both the master USRP of
>>>>>>>>> your MIMO cabled pair and the receiver (For example using two of the
>>>>>>>>> GPSDO
>>>>>>>>> kits: https://www.ettus.com/product/details/GPSDO-KIT)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> There are many ways of implementing a protocol level time
>>>>>>>>> synchronization in software/DSP. The paper I linked to talks about
>>>>>>>>> one way,
>>>>>>>>> there are certainly others. I do not know of any example projects
>>>>>>>>> implementing them though so you would have to develop your own.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Derek
>>>>>>>>>
>>>>>>>>> On Thu, Apr 21, 2016 at 8:04 AM, Pavan Yedavalli <
>>>>>>>>> [email protected]> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Derek,
>>>>>>>>>>
>>>>>>>>>> I'll answer your questions in-line, because I think what you are
>>>>>>>>>> saying is beginning to make me understand what I need:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Apr 20, 2016 at 9:03 PM, Derek Kozel <
>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hello Pavan,
>>>>>>>>>>>
>>>>>>>>>>> Are you trying to create a shared timebase between the two USRPs
>>>>>>>>>>> without having a shared 1PPS or GPS reference? You are still not
>>>>>>>>>>> using
>>>>>>>>>>> enough detail for us to understand fully.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> To clarify, my setup is two USRPs connected via MIMO cable, and
>>>>>>>>>> then another USRP acting as a receiver. So are you asking whether I'm
>>>>>>>>>> trying to create a shared timebase between the two-USRP *unit*
>>>>>>>>>> (because
>>>>>>>>>> they are MIMO cabled) and the receiving USRP without having a shared
>>>>>>>>>> 1 PPS
>>>>>>>>>> or GPS reference? I think my answer to that must be yes, because I
>>>>>>>>>> have not
>>>>>>>>>> done anything else but connect them to the computer via ethernet and
>>>>>>>>>> just
>>>>>>>>>> have two of them connected via MIMO cable and the other one by
>>>>>>>>>> itself. I'm
>>>>>>>>>> assuming I need to have a shared reference between the transmit
>>>>>>>>>> USRPs and
>>>>>>>>>> the receive USRP, so how would I be able to do that? This could
>>>>>>>>>> certainly
>>>>>>>>>> be one of my problems.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> In Figure 5 both USRPs are connected with a MIMO cable and so
>>>>>>>>>>> have both shared frequency and time bases. What is your weight
>>>>>>>>>>> block doing
>>>>>>>>>>> to the sample stream? Is it a time delay block? I don't know what
>>>>>>>>>>> gnuradio
>>>>>>>>>>> would do if you specified 10*sample_rate as the delay there as
>>>>>>>>>>> that's
>>>>>>>>>>> likely to be a very large number of samples.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> My weight block is applying a normalized magnitude phase
>>>>>>>>>> correction to each antenna's transmitted signal, so, yes, it is
>>>>>>>>>> essentially
>>>>>>>>>> creating a time delay. Each weight is a complex value with magnitude
>>>>>>>>>> 1 and
>>>>>>>>>> a calculated phase. You are saying this could be a problem if it's
>>>>>>>>>> calculating a value that is too high?
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> If you have both USRPs connected with a time synchronization
>>>>>>>>>>> (shared 1PPS, GPSDO, or MIMO cable) and have your flowgraph
>>>>>>>>>>> configured
>>>>>>>>>>> correctly, then you can just use timed commands to the USRP_alpha
>>>>>>>>>>> to start
>>>>>>>>>>> transmitting at time X and USRP_beta to start receiving at time X
>>>>>>>>>>> and you
>>>>>>>>>>> will see your signal. You can then move to using burst mode using
>>>>>>>>>>> tags to
>>>>>>>>>>> define the number of samples to send/receive along with timed
>>>>>>>>>>> commands to
>>>>>>>>>>> send/receive bursts of samples. This works because the clocks in
>>>>>>>>>>> both USRPs
>>>>>>>>>>> will be aligned to each other.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I feel like there are two steps here. First, I need to get the
>>>>>>>>>> transmitting USRPs (which are conneced via MIMO cable) to time sync
>>>>>>>>>> to each
>>>>>>>>>> other (which I believe I have done through using USRP sink in GRC and
>>>>>>>>>> setting the second channels time and clock to MIMO cable?), and
>>>>>>>>>> second, I
>>>>>>>>>> need to get the receive USRP to receive at the same time. So, just as
>>>>>>>>>> above, I need to get my receive USRP to be on the same time as my
>>>>>>>>>> transmit
>>>>>>>>>> USRPs? Once I'm able to do that, then I can do burst mode to
>>>>>>>>>> transmit and
>>>>>>>>>> receive timed signals, as you are mentioning?
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> If you do *NOT* have a shared time source for each radio, for
>>>>>>>>>>> instance they are far apart and do not have GPS references, then
>>>>>>>>>>> you need
>>>>>>>>>>> to do some sort of protocol level alignment to create a shared
>>>>>>>>>>> understanding of time between them. A frequently used method is for
>>>>>>>>>>> USRP_alpha to transmit a beacon with a known period (say once every
>>>>>>>>>>> 10
>>>>>>>>>>> seconds). All other USRPs then receive for longer than 10 seconds
>>>>>>>>>>> to be
>>>>>>>>>>> guaranteed to receive the beacon (assuming they're within range of
>>>>>>>>>>> the
>>>>>>>>>>> transmission). When the receiving USRPs detect the incoming beacon
>>>>>>>>>>> they
>>>>>>>>>>> align their local time to the master (Beacon transmitting) USRP.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I guess a similar question to the above: can I have a shared time
>>>>>>>>>> source between the transmit USRPs (which are already MIMO cabled to
>>>>>>>>>> each
>>>>>>>>>> other) and the receive USRP? It seems like that would be easier to
>>>>>>>>>> do than
>>>>>>>>>> going through this protocol level alignment, but maybe it's not
>>>>>>>>>> possible
>>>>>>>>>> given my setup.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Here's a quick paper talking about this topic. The technique is
>>>>>>>>>>> widely used.
>>>>>>>>>>> http://www.ece.uah.edu/~milenka/docs/dc_ssst05_synch.pdf
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I hope this helps and is applicable to your need. If you have
>>>>>>>>>>> more questions please try drawing your desired system and maybe
>>>>>>>>>>> include a
>>>>>>>>>>> timeline of events that you expect the radios to do. Attaching your
>>>>>>>>>>> existing flowgraphs, either as photos using GRC's screen capture
>>>>>>>>>>> feature
>>>>>>>>>>> (file>screen capture) or the actual GRC file, also helps us
>>>>>>>>>>> understand what
>>>>>>>>>>> exactly you are working with.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I had to take down the setup because I am moving labs, but I will
>>>>>>>>>> send some flowgraphs and the diagram of the system next week. Thank
>>>>>>>>>> you
>>>>>>>>>> again for being so patient and trying to help me. I think I'm just a
>>>>>>>>>> bit
>>>>>>>>>> lost on a few of the simple things, but once those are figured out,
>>>>>>>>>> then I
>>>>>>>>>> think it should be smoother sailing.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Derek
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Apr 20, 2016 at 4:05 PM, Pavan Yedavalli <
>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Martin,
>>>>>>>>>>>>
>>>>>>>>>>>> I guess I have a few questions:
>>>>>>>>>>>>
>>>>>>>>>>>> 1.) Are there any examples in the gnuradio codebase/flowgraph
>>>>>>>>>>>> repository that show how to do synchronized feedback between two
>>>>>>>>>>>> USRPs? In
>>>>>>>>>>>> other words, I send a signal from a transmit USRP, and then I
>>>>>>>>>>>> receive that
>>>>>>>>>>>> signal at the receive USRP, and then I send back something else
>>>>>>>>>>>> from the
>>>>>>>>>>>> receive USRP back to the transmit USRP, and this would be a
>>>>>>>>>>>> sequential
>>>>>>>>>>>> process in which they are aligned and know when to transmit and/or
>>>>>>>>>>>> receive?
>>>>>>>>>>>> I saw a post
>>>>>>>>>>>> <http://stackoverflow.com/questions/28710869/how-to-set-usrp-transmitting-time-and-receiving-time-in-gnu-radio>
>>>>>>>>>>>> that
>>>>>>>>>>>> I think would be relevant, but I'm not sure how to apply it.
>>>>>>>>>>>>
>>>>>>>>>>>> I believe this should be a pretty standard scenario in which
>>>>>>>>>>>> you want to have two USRPs communicate with each other
>>>>>>>>>>>> synchronously. I
>>>>>>>>>>>> guess I'm just having trouble finding an example of how to do this.
>>>>>>>>>>>>
>>>>>>>>>>>> 2.) Related to the above question, maybe there are no examples
>>>>>>>>>>>> to do feedback in one flowgraph, so what I have been doing is the
>>>>>>>>>>>> following
>>>>>>>>>>>> in my flowgraphs:
>>>>>>>>>>>>
>>>>>>>>>>>> Flowgraph A:
>>>>>>>>>>>>
>>>>>>>>>>>> The synchronized MIMO flowgraph (Figure 5) from this
>>>>>>>>>>>> <https://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp.pdf>,
>>>>>>>>>>>> so essentially I have two USRPs synchronized and transmitting out
>>>>>>>>>>>> two
>>>>>>>>>>>> signals that should be offset but frequency aligned. In my own
>>>>>>>>>>>> flowgraph's
>>>>>>>>>>>> main(), instead of applying a "phase shift" block, I am applying
>>>>>>>>>>>> my own
>>>>>>>>>>>> "weights" block to both transmissions.
>>>>>>>>>>>>
>>>>>>>>>>>> So, I am now sending a signal that has those weights applied to
>>>>>>>>>>>> it. So, after I do tb.start(), then I sleep for 10 seconds (by
>>>>>>>>>>>> doing
>>>>>>>>>>>> sleep(10)) hoping that in the 10 seconds my receiver will catch
>>>>>>>>>>>> the signal
>>>>>>>>>>>> that I'm transmitting and put it into file.
>>>>>>>>>>>>
>>>>>>>>>>>> Flowgraph B:
>>>>>>>>>>>>
>>>>>>>>>>>> My own receiver.py in which I have a USRP sink->FFT->Complex to
>>>>>>>>>>>> Mag->File sink. I also have a connection from FFT->QT GUI to see a
>>>>>>>>>>>> plot of
>>>>>>>>>>>> what is being captured.
>>>>>>>>>>>>
>>>>>>>>>>>> I now run Flowgraph A in one terminal and Flowgraph B in
>>>>>>>>>>>> another terminal. I need to capture A's transmission with the
>>>>>>>>>>>> first weights
>>>>>>>>>>>> within the 10 seconds (as it's sleeping) into the file sink. Then,
>>>>>>>>>>>> A will
>>>>>>>>>>>> send a signal with another set of weights applied, and I will need
>>>>>>>>>>>> to
>>>>>>>>>>>> capture that in the next 10 seconds, and so on. My problem is that
>>>>>>>>>>>> I'm
>>>>>>>>>>>> often capturing noise because my receive was not aligned with when
>>>>>>>>>>>> I was
>>>>>>>>>>>> transmitting my desired signal. So, I end up only capturing noise
>>>>>>>>>>>> after the
>>>>>>>>>>>> transmission stops as opposed to the actual signal when the
>>>>>>>>>>>> transmission is
>>>>>>>>>>>> happening.
>>>>>>>>>>>>
>>>>>>>>>>>> Essentially, I am trying to mimic feedback by doing the above,
>>>>>>>>>>>> but I don't know how to align my transmitter and receiver,
>>>>>>>>>>>> especially
>>>>>>>>>>>> because they are two different blocks. Is there a way to make both
>>>>>>>>>>>> the
>>>>>>>>>>>> transmission and reception one block so that I can do
>>>>>>>>>>>> sleep(rx_time +
>>>>>>>>>>>> n_samples_since_tag/sampling_rate) (I think this could be right?)
>>>>>>>>>>>> as
>>>>>>>>>>>> opposed to my static sleep(10) and pray for the best?
>>>>>>>>>>>>
>>>>>>>>>>>> Would it be helpful at all if I showed you my code? I still
>>>>>>>>>>>> feel like I'm not being clear. Sorry about that. If there were any
>>>>>>>>>>>> examples, then I think that would be the best for me to look at.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for any help again.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Pavan
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Discuss-gnuradio mailing list
>>>>>>>>>>>> [email protected]
>>>>>>>>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Pavan
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Pavan
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Pavan
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Pavan
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Pavan
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Pavan
>>>
>>
>>
>>
>> --
>> Pavan
>>
>
>
--
Pavan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160429/f7eb2340/attachment-0001.html>
------------------------------
Message: 19
Date: Fri, 29 Apr 2016 17:37:47 -0700
From: Derek Kozel <[email protected]>
To: Pavan Yedavalli <[email protected]>
Cc: "[email protected]" <[email protected]>,
GNURadio Discussion List <[email protected]>
Subject: Re: [USRP-users] Feedback with Transmitters and Receiver
Message-ID:
<CAA+K=tu1Vbmpuj8Bfg9waFAcmBx_YQBN78j8_0e5a7M=7r9...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Pavan,
Yes, you are correct, this test won't show phase alignment. The most common
checks for phase alignment need a receiver able to do two simultaneous
channels, such as a high bandwidth oscilloscope, another N210/SBX that can
be setup the same as your transmitter pairing, or an X300 series USRP with
two SBXs. Perhaps others on the list will have less equipment ways of
verifying phase alignment.
Perhaps capturing the combined waveform at one frequency, tuning only the
transmitters to a different frequency and then back to the original and
comparing the waveforms would be sufficient? The phase alignment will be a
constant offset at a given frequency, assuming nothing else in the system
changes.
On Fri, Apr 29, 2016 at 5:14 PM, Pavan Yedavalli <[email protected]>
wrote:
> Hi Derek,
>
> That makes sense. I will put a combiner and try this. However, now the
> test is a bit different, right? The only way I could tell that the
> transmitters are transmitting at the same time is if the power level is
> double what it used to be, assuming they are actually fully in phase. Is
> there a possibility that they are out of phase though, but there is a
> constant random offset, so they add up slightly differently and not
> completely coherently? (as shown in Figure 7 in this document
> <https://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp_updated.pdf>
> )
>
> Thanks again.
>
> On Fri, Apr 29, 2016 at 12:21 PM, Derek Kozel <[email protected]>
> wrote:
>
>> Hi Pavan,
>>
>> I'm sorry, I didn't read your cabling closely enough or I would have
>> noticed this before. If you only have one SBX in the receive N210, then you
>> only have one possible receive channel! That is why you are seeing the
>> error that RX channel 1 (remember they're 0 indexed) is out of range. On
>> the SBX, and all other daughterboards, the TX/RX and RX2 ports are shared
>> by a single receive channel. They are setup with a switch to allow either
>> time divided transmit and receive on a single antenna (using the TX/RX
>> port) or having separate transmit and receive connections (transmit on
>> TX/RX and receive on RX2).
>>
>> You will need to use a combiner to merge the two transmit signals into a
>> single receive connection, to either TX/RX or RX2. Or use antennas and let
>> the air do your combining. You may want to keep the attenuators in line
>> until you are comfortable with the power levels. You'll be able to see when
>> your receiver is clipping in the Scope GUI.
>>
>> Derek
>>
>> On Fri, Apr 29, 2016 at 11:32 AM, Pavan Yedavalli <[email protected]>
>> wrote:
>>
>>> Hi Derek,
>>>
>>> I made all the changes, and the Tx error as well as the warnings are now
>>> gone. However, the Rx error still remains:
>>>
>>> File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
>>> line 2168, in set_samp_rate
>>> return _uhd_swig.usrp_source_sptr_set_samp_rate(self, *args,
>>> **kwargs)
>>> RuntimeError: LookupError: IndexError: multi_usrp: RX channel 1 out of
>>> range for configured RX frontends
>>>
>>> I'm not entirely sure what the problem is here. Attached are the
>>> flowgraph pictures. In addition, I am using Rev 5.1 SBX daughterboards.
>>> Thanks again.
>>>
>>>
>>>
>>> On Thu, Apr 28, 2016 at 4:21 PM, Pavan Yedavalli <[email protected]>
>>> wrote:
>>>
>>>> Hi Derek,
>>>>
>>>> I appreciate it. Okay, I will change all of those. I am using the SBX
>>>> daughterboards - the ones that support phase sync.
>>>>
>>>> On Thu, Apr 28, 2016 at 3:55 PM, Derek Kozel <[email protected]>
>>>> wrote:
>>>>
>>>>> Hello Pavan,
>>>>>
>>>>> You do not need Ethernet connected to the Octoclock, so that's ok.
>>>>> Your cabling sounds correct. Can you please combine both UHD Sinks? Just
>>>>> increase the number of motherboards and channels to 2 and copy the MIMO
>>>>> attached USRP's settings into channel 2.
>>>>>
>>>>> Your sample rate for the receive side is very very low. I suspect that
>>>>> will throw a warning if you read the log output at the bottom of GRC. Try
>>>>> raising that to 500kHz or more. Also the WX Scope Sink can be changed to
>>>>> complex inputs so you don't need the converter blocks. You are also
>>>>> setting
>>>>> a custom clock rate. The N200 has a fixed master clock rate of 100 MHz so
>>>>> this is likely also throwing a warning in the log messages. Definitely
>>>>> look
>>>>> through those and make changes as needed.
>>>>>
>>>>> What daughterboards are you using? On the N200 series motherboards
>>>>> only the SBX daughterboards supports phase synchronization. What you
>>>>> should
>>>>> see is frequency and time synchronization between the MIMO N210s.
>>>>>
>>>>> Regards,
>>>>> Derek
>>>>>
>>>>> On Thu, Apr 28, 2016 at 12:22 PM, Pavan Yedavalli <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> Hi Derek,
>>>>>>
>>>>>> Sorry - just another quick addition. When I run the Tx flowgraph, I
>>>>>> get this error:
>>>>>>
>>>>>> Board 0 May not be getting a PPS signal! No PPS detected within the
>>>>>> time interval.
>>>>>>
>>>>>> This definitely tells me something is wrong with the Octoclock-G
>>>>>> setup.
>>>>>>
>>>>>> On Thu, Apr 28, 2016 at 12:18 PM, Pavan Yedavalli <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> Hi Derek,
>>>>>>>
>>>>>>> I am trying to do (3), as you noted above, and my test to see
>>>>>>> whether the Tx USRPs are transmitting at the same time is to directly
>>>>>>> connect them to the Rx USRP and plot the real components of each one and
>>>>>>> see whether they are in phase (or at least with some constant random
>>>>>>> offset). In theory, I believe this is a good test to see that the
>>>>>>> Octoclock-G is working its magic.
>>>>>>>
>>>>>>> The setup:
>>>>>>>
>>>>>>> *Octoclock*: Two of the three boards (Master Tx USRP and 1 Rx USRP)
>>>>>>> are connected to the Octoclock-G (one cable each from PPS out to PPS in,
>>>>>>> and one cable each from 10 MHz out to Ref in, so 4 total cables). The
>>>>>>> primary ref knob is set to Internal, and the PPS blinks green, while
>>>>>>> Internal, Status, and Power are all steady greens. I do *not* have
>>>>>>> the ethernet of the Octoclock connected, however. When I connected it
>>>>>>> to my
>>>>>>> Gb Ethernet switch, the indicator was orange, while all the other
>>>>>>> working
>>>>>>> ones are green, so I decided not to connect it for now. Does this
>>>>>>> matter?
>>>>>>>
>>>>>>> *Tx side*: I have both Tx USRPs connected to each other via the
>>>>>>> MIMO cable, and one of them is connected to the Octoclock, as mentioned
>>>>>>> above. In tx_mimo_setup_octoclock.png, we can see that I have two USRP
>>>>>>> sinks connected via MIMO cable, and one of them has time and clock set
>>>>>>> to
>>>>>>> External, and the other has time and clock set to MIMO cable. Both have
>>>>>>> sync set to Unknown PPS.
>>>>>>>
>>>>>>> *Between Tx and Rx*: I have an SMA cable from one Tx USRP connected
>>>>>>> to a 20 dB attenuator, and then connected to the Tx/Rx port of the Rx
>>>>>>> USRP.
>>>>>>> I have another SMA cable from the other Tx USRP connected to a 20 dB
>>>>>>> attenuator, and then connected to the Rx2 port of the Rx USRP. No
>>>>>>> antennas
>>>>>>> are connected.
>>>>>>>
>>>>>>> *Rx side*: In receiver_recvng_on_both_ports.png, we can see that I
>>>>>>> have a USRP source with two channels. The time and clock are set to
>>>>>>> External, and the sync is set to Unknown PPS. I run this, but I get the
>>>>>>> following error:
>>>>>>>
>>>>>>> RuntimeError: LookupError: IndexError: multi_usrp: RX channel 1 out
>>>>>>> of range for configured RX frontends
>>>>>>>
>>>>>>> I tried looking up what this error is, and apparently there was a
>>>>>>> fix in a branch years ago, but I'm assuming I have that fix already? I
>>>>>>> have
>>>>>>> a feeling something is wrong with the Octoclock setup that is causing
>>>>>>> this,
>>>>>>> but I'm not sure. I believe the setup I mentioned above makes sense,
>>>>>>> right?
>>>>>>>
>>>>>>> Obviously, I will look into timed commands in UHD and tags in GNU
>>>>>>> Radio after I get all of this set up and working. Thank you so much
>>>>>>> again
>>>>>>> for the help.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Apr 21, 2016 at 3:52 PM, Derek Kozel <[email protected]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Pavan,
>>>>>>>>
>>>>>>>> This is a USRP/UHD question really so I'm including the usrp-users
>>>>>>>> mailing list. If you're not already the list already then you should
>>>>>>>> certainly join as that's a better resource for questions about
>>>>>>>> UHD/USRPs.
>>>>>>>>
>>>>>>>> 1) Any SMA cable will work. For the best performance their
>>>>>>>> electrical lengths should be the same. In practice this usually means
>>>>>>>> equal
>>>>>>>> physical lengths of the same type of coax. This ensures that the
>>>>>>>> signals
>>>>>>>> arrive at the same time (and phase).
>>>>>>>>
>>>>>>>> 2) Most radio systems don't have GPS timebases available and use
>>>>>>>> various protocol level methods for aligning their clocks, if needed.
>>>>>>>> In a
>>>>>>>> very simple system the receiver could simply listen continuously until
>>>>>>>> it
>>>>>>>> receives a full message, then transmits a response if needed. Look up
>>>>>>>> Time
>>>>>>>> Division Multiplexing and Frequency Division Multiplexing. This is an
>>>>>>>> area
>>>>>>>> where there are nearly as many possibilities as there are radio
>>>>>>>> systems.
>>>>>>>>
>>>>>>>> 3) Once you connect all the Octoclock signals then in GNU Radio you
>>>>>>>> can select the Clock and Time sources to be External and the Sync to be
>>>>>>>> Unknown PPS. Your pair of units connected via a MIMO cable are
>>>>>>>> special, the
>>>>>>>> master should have the External time and clock sources, the companion
>>>>>>>> USRP
>>>>>>>> should have MIMO selected for time and clock. The Sync should still be
>>>>>>>> Unknown PPS.
>>>>>>>>
>>>>>>>> Here's a page that talks about synchronization of USRPs. Read this,
>>>>>>>> get your hardware all setup, and try setting up a basic GRC flowgraph
>>>>>>>> with
>>>>>>>> your three radios. Think of what tests you could use to verify that
>>>>>>>> both
>>>>>>>> your MIMO cabled radios are transmitting at the same time. You should
>>>>>>>> look
>>>>>>>> into timed commands in UHD and tags in GNU Radio.
>>>>>>>>
>>>>>>>> http://files.ettus.com/manual/page_sync.html
>>>>>>>>
>>>>>>>> https://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp_updated.pdf
>>>>>>>>
>>>>>>>> If this is your first use of USRPs and GNU Radio then I'd suggest
>>>>>>>> reading through the tutorials available online and not get too focused
>>>>>>>> on
>>>>>>>> MIMO until you feel comfortable with the basics of the environment and
>>>>>>>> tools that you have.
>>>>>>>>
>>>>>>>> http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials
>>>>>>>>
>>>>>>>> Once you've given this a try let us know if you have additional
>>>>>>>> questions.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Derek
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Apr 21, 2016 at 3:27 PM, Pavan Yedavalli <
>>>>>>>> [email protected]> wrote:
>>>>>>>>
>>>>>>>>> Hi Derek,
>>>>>>>>>
>>>>>>>>> Thanks for getting back to me. So, I do have an Octoclock, so I
>>>>>>>>> think we're getting somewhere and this is starting to make more
>>>>>>>>> sense. A
>>>>>>>>> few follow up questions:
>>>>>>>>>
>>>>>>>>> 1.) Do I need special cables to connect all of the units to the
>>>>>>>>> Octoclock, or are they robust SMA cables?
>>>>>>>>>
>>>>>>>>> 2.) I feel like this seems particularly involved to send a signal
>>>>>>>>> from a transmitter to a receiver. I am assuming most non-MIMO,
>>>>>>>>> non-beamforming related tasks have always used your second option of
>>>>>>>>> using
>>>>>>>>> the GPSDO kits? I purchased an Octoclock knowing I would do MIMO
>>>>>>>>> experiments, but obviously I'm guessing more conventional
>>>>>>>>> communication
>>>>>>>>> techniques (like a simple BPSK or QPSK between tx and rx) would have
>>>>>>>>> probably used the GPSDO kits?
>>>>>>>>>
>>>>>>>>> 3.) Once I connect them all to the Octoclock, then I don't need to
>>>>>>>>> a protocol level time synchronization, right? Once they're all
>>>>>>>>> synchronized
>>>>>>>>> and I see that in the plots, then I guess the next step would be to
>>>>>>>>> figure
>>>>>>>>> out how to implement my actual feedback loop. At that point, then I
>>>>>>>>> would
>>>>>>>>> need to figure out how to do burst mode to transmit and receiver timed
>>>>>>>>> signals? Would this end up needing to be one flow graph or would I
>>>>>>>>> have to
>>>>>>>>> use two flow graphs? (One for to and one for rx, the way I am doing
>>>>>>>>> it now)
>>>>>>>>>
>>>>>>>>> Thank you again for all the help. I think I'm starting to
>>>>>>>>> understand what I need in the setup.
>>>>>>>>>
>>>>>>>>> On Thu, Apr 21, 2016 at 4:56 PM, Derek Kozel <
>>>>>>>>> [email protected]> wrote:
>>>>>>>>>
>>>>>>>>>> Hello Pavan,
>>>>>>>>>>
>>>>>>>>>> I think we both are starting to understand the setup and the
>>>>>>>>>> problem. Here are the two hardware solutions:
>>>>>>>>>>
>>>>>>>>>> Connect a shared 1PPS signal to *both* the master USRP of your
>>>>>>>>>> MIMO cabled pair and to the receiver (For example using an octoclock:
>>>>>>>>>> https://www.ettus.com/product/details/OctoClock-G)
>>>>>>>>>>
>>>>>>>>>> OR
>>>>>>>>>>
>>>>>>>>>> Connect GPS referenced 1PPS signals to both the master USRP of
>>>>>>>>>> your MIMO cabled pair and the receiver (For example using two of the
>>>>>>>>>> GPSDO
>>>>>>>>>> kits: https://www.ettus.com/product/details/GPSDO-KIT)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> There are many ways of implementing a protocol level time
>>>>>>>>>> synchronization in software/DSP. The paper I linked to talks about
>>>>>>>>>> one way,
>>>>>>>>>> there are certainly others. I do not know of any example projects
>>>>>>>>>> implementing them though so you would have to develop your own.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Derek
>>>>>>>>>>
>>>>>>>>>> On Thu, Apr 21, 2016 at 8:04 AM, Pavan Yedavalli <
>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Derek,
>>>>>>>>>>>
>>>>>>>>>>> I'll answer your questions in-line, because I think what you are
>>>>>>>>>>> saying is beginning to make me understand what I need:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Apr 20, 2016 at 9:03 PM, Derek Kozel <
>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hello Pavan,
>>>>>>>>>>>>
>>>>>>>>>>>> Are you trying to create a shared timebase between the two
>>>>>>>>>>>> USRPs without having a shared 1PPS or GPS reference? You are still
>>>>>>>>>>>> not
>>>>>>>>>>>> using enough detail for us to understand fully.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> To clarify, my setup is two USRPs connected via MIMO cable, and
>>>>>>>>>>> then another USRP acting as a receiver. So are you asking whether
>>>>>>>>>>> I'm
>>>>>>>>>>> trying to create a shared timebase between the two-USRP *unit*
>>>>>>>>>>> (because
>>>>>>>>>>> they are MIMO cabled) and the receiving USRP without having a
>>>>>>>>>>> shared 1 PPS
>>>>>>>>>>> or GPS reference? I think my answer to that must be yes, because I
>>>>>>>>>>> have not
>>>>>>>>>>> done anything else but connect them to the computer via ethernet
>>>>>>>>>>> and just
>>>>>>>>>>> have two of them connected via MIMO cable and the other one by
>>>>>>>>>>> itself. I'm
>>>>>>>>>>> assuming I need to have a shared reference between the transmit
>>>>>>>>>>> USRPs and
>>>>>>>>>>> the receive USRP, so how would I be able to do that? This could
>>>>>>>>>>> certainly
>>>>>>>>>>> be one of my problems.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> In Figure 5 both USRPs are connected with a MIMO cable and so
>>>>>>>>>>>> have both shared frequency and time bases. What is your weight
>>>>>>>>>>>> block doing
>>>>>>>>>>>> to the sample stream? Is it a time delay block? I don't know what
>>>>>>>>>>>> gnuradio
>>>>>>>>>>>> would do if you specified 10*sample_rate as the delay there as
>>>>>>>>>>>> that's
>>>>>>>>>>>> likely to be a very large number of samples.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> My weight block is applying a normalized magnitude phase
>>>>>>>>>>> correction to each antenna's transmitted signal, so, yes, it is
>>>>>>>>>>> essentially
>>>>>>>>>>> creating a time delay. Each weight is a complex value with
>>>>>>>>>>> magnitude 1 and
>>>>>>>>>>> a calculated phase. You are saying this could be a problem if it's
>>>>>>>>>>> calculating a value that is too high?
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> If you have both USRPs connected with a time synchronization
>>>>>>>>>>>> (shared 1PPS, GPSDO, or MIMO cable) and have your flowgraph
>>>>>>>>>>>> configured
>>>>>>>>>>>> correctly, then you can just use timed commands to the USRP_alpha
>>>>>>>>>>>> to start
>>>>>>>>>>>> transmitting at time X and USRP_beta to start receiving at time X
>>>>>>>>>>>> and you
>>>>>>>>>>>> will see your signal. You can then move to using burst mode using
>>>>>>>>>>>> tags to
>>>>>>>>>>>> define the number of samples to send/receive along with timed
>>>>>>>>>>>> commands to
>>>>>>>>>>>> send/receive bursts of samples. This works because the clocks in
>>>>>>>>>>>> both USRPs
>>>>>>>>>>>> will be aligned to each other.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I feel like there are two steps here. First, I need to get the
>>>>>>>>>>> transmitting USRPs (which are conneced via MIMO cable) to time sync
>>>>>>>>>>> to each
>>>>>>>>>>> other (which I believe I have done through using USRP sink in GRC
>>>>>>>>>>> and
>>>>>>>>>>> setting the second channels time and clock to MIMO cable?), and
>>>>>>>>>>> second, I
>>>>>>>>>>> need to get the receive USRP to receive at the same time. So, just
>>>>>>>>>>> as
>>>>>>>>>>> above, I need to get my receive USRP to be on the same time as my
>>>>>>>>>>> transmit
>>>>>>>>>>> USRPs? Once I'm able to do that, then I can do burst mode to
>>>>>>>>>>> transmit and
>>>>>>>>>>> receive timed signals, as you are mentioning?
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> If you do *NOT* have a shared time source for each radio, for
>>>>>>>>>>>> instance they are far apart and do not have GPS references, then
>>>>>>>>>>>> you need
>>>>>>>>>>>> to do some sort of protocol level alignment to create a shared
>>>>>>>>>>>> understanding of time between them. A frequently used method is for
>>>>>>>>>>>> USRP_alpha to transmit a beacon with a known period (say once
>>>>>>>>>>>> every 10
>>>>>>>>>>>> seconds). All other USRPs then receive for longer than 10 seconds
>>>>>>>>>>>> to be
>>>>>>>>>>>> guaranteed to receive the beacon (assuming they're within range of
>>>>>>>>>>>> the
>>>>>>>>>>>> transmission). When the receiving USRPs detect the incoming beacon
>>>>>>>>>>>> they
>>>>>>>>>>>> align their local time to the master (Beacon transmitting) USRP.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I guess a similar question to the above: can I have a shared
>>>>>>>>>>> time source between the transmit USRPs (which are already MIMO
>>>>>>>>>>> cabled to
>>>>>>>>>>> each other) and the receive USRP? It seems like that would be
>>>>>>>>>>> easier to do
>>>>>>>>>>> than going through this protocol level alignment, but maybe it's not
>>>>>>>>>>> possible given my setup.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Here's a quick paper talking about this topic. The technique is
>>>>>>>>>>>> widely used.
>>>>>>>>>>>> http://www.ece.uah.edu/~milenka/docs/dc_ssst05_synch.pdf
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I hope this helps and is applicable to your need. If you have
>>>>>>>>>>>> more questions please try drawing your desired system and maybe
>>>>>>>>>>>> include a
>>>>>>>>>>>> timeline of events that you expect the radios to do. Attaching your
>>>>>>>>>>>> existing flowgraphs, either as photos using GRC's screen capture
>>>>>>>>>>>> feature
>>>>>>>>>>>> (file>screen capture) or the actual GRC file, also helps us
>>>>>>>>>>>> understand what
>>>>>>>>>>>> exactly you are working with.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I had to take down the setup because I am moving labs, but I
>>>>>>>>>>> will send some flowgraphs and the diagram of the system next week.
>>>>>>>>>>> Thank
>>>>>>>>>>> you again for being so patient and trying to help me. I think I'm
>>>>>>>>>>> just a
>>>>>>>>>>> bit lost on a few of the simple things, but once those are figured
>>>>>>>>>>> out,
>>>>>>>>>>> then I think it should be smoother sailing.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Derek
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Apr 20, 2016 at 4:05 PM, Pavan Yedavalli <
>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Martin,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I guess I have a few questions:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1.) Are there any examples in the gnuradio codebase/flowgraph
>>>>>>>>>>>>> repository that show how to do synchronized feedback between two
>>>>>>>>>>>>> USRPs? In
>>>>>>>>>>>>> other words, I send a signal from a transmit USRP, and then I
>>>>>>>>>>>>> receive that
>>>>>>>>>>>>> signal at the receive USRP, and then I send back something else
>>>>>>>>>>>>> from the
>>>>>>>>>>>>> receive USRP back to the transmit USRP, and this would be a
>>>>>>>>>>>>> sequential
>>>>>>>>>>>>> process in which they are aligned and know when to transmit
>>>>>>>>>>>>> and/or receive?
>>>>>>>>>>>>> I saw a post
>>>>>>>>>>>>> <http://stackoverflow.com/questions/28710869/how-to-set-usrp-transmitting-time-and-receiving-time-in-gnu-radio>
>>>>>>>>>>>>> that
>>>>>>>>>>>>> I think would be relevant, but I'm not sure how to apply it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I believe this should be a pretty standard scenario in which
>>>>>>>>>>>>> you want to have two USRPs communicate with each other
>>>>>>>>>>>>> synchronously. I
>>>>>>>>>>>>> guess I'm just having trouble finding an example of how to do
>>>>>>>>>>>>> this.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2.) Related to the above question, maybe there are no examples
>>>>>>>>>>>>> to do feedback in one flowgraph, so what I have been doing is the
>>>>>>>>>>>>> following
>>>>>>>>>>>>> in my flowgraphs:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Flowgraph A:
>>>>>>>>>>>>>
>>>>>>>>>>>>> The synchronized MIMO flowgraph (Figure 5) from this
>>>>>>>>>>>>> <https://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp.pdf>,
>>>>>>>>>>>>> so essentially I have two USRPs synchronized and transmitting out
>>>>>>>>>>>>> two
>>>>>>>>>>>>> signals that should be offset but frequency aligned. In my own
>>>>>>>>>>>>> flowgraph's
>>>>>>>>>>>>> main(), instead of applying a "phase shift" block, I am applying
>>>>>>>>>>>>> my own
>>>>>>>>>>>>> "weights" block to both transmissions.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So, I am now sending a signal that has those weights applied
>>>>>>>>>>>>> to it. So, after I do tb.start(), then I sleep for 10 seconds (by
>>>>>>>>>>>>> doing
>>>>>>>>>>>>> sleep(10)) hoping that in the 10 seconds my receiver will catch
>>>>>>>>>>>>> the signal
>>>>>>>>>>>>> that I'm transmitting and put it into file.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Flowgraph B:
>>>>>>>>>>>>>
>>>>>>>>>>>>> My own receiver.py in which I have a USRP sink->FFT->Complex
>>>>>>>>>>>>> to Mag->File sink. I also have a connection from FFT->QT GUI to
>>>>>>>>>>>>> see a plot
>>>>>>>>>>>>> of what is being captured.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I now run Flowgraph A in one terminal and Flowgraph B in
>>>>>>>>>>>>> another terminal. I need to capture A's transmission with the
>>>>>>>>>>>>> first weights
>>>>>>>>>>>>> within the 10 seconds (as it's sleeping) into the file sink.
>>>>>>>>>>>>> Then, A will
>>>>>>>>>>>>> send a signal with another set of weights applied, and I will
>>>>>>>>>>>>> need to
>>>>>>>>>>>>> capture that in the next 10 seconds, and so on. My problem is
>>>>>>>>>>>>> that I'm
>>>>>>>>>>>>> often capturing noise because my receive was not aligned with
>>>>>>>>>>>>> when I was
>>>>>>>>>>>>> transmitting my desired signal. So, I end up only capturing noise
>>>>>>>>>>>>> after the
>>>>>>>>>>>>> transmission stops as opposed to the actual signal when the
>>>>>>>>>>>>> transmission is
>>>>>>>>>>>>> happening.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Essentially, I am trying to mimic feedback by doing the above,
>>>>>>>>>>>>> but I don't know how to align my transmitter and receiver,
>>>>>>>>>>>>> especially
>>>>>>>>>>>>> because they are two different blocks. Is there a way to make
>>>>>>>>>>>>> both the
>>>>>>>>>>>>> transmission and reception one block so that I can do
>>>>>>>>>>>>> sleep(rx_time +
>>>>>>>>>>>>> n_samples_since_tag/sampling_rate) (I think this could be right?)
>>>>>>>>>>>>> as
>>>>>>>>>>>>> opposed to my static sleep(10) and pray for the best?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Would it be helpful at all if I showed you my code? I still
>>>>>>>>>>>>> feel like I'm not being clear. Sorry about that. If there were any
>>>>>>>>>>>>> examples, then I think that would be the best for me to look at.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks for any help again.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Pavan
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> Discuss-gnuradio mailing list
>>>>>>>>>>>>> [email protected]
>>>>>>>>>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Pavan
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Pavan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Pavan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Pavan
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Pavan
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Pavan
>>>>
>>>
>>>
>>>
>>> --
>>> Pavan
>>>
>>
>>
>
>
> --
> Pavan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160429/2b00c5c6/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 68, Issue 31
******************************************
