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. UnsatisfiedLinkError: no jniDeviceAddress in
java.library.path (jj08)
2. Re: UnsatisfiedLinkError: no jniDeviceAddress in
java.library.path (Martin Braun)
3. Re: E310 FPGA design_Loopback test (Martin Braun)
4. Re: How to know if a radio is currently in use? (Martin Braun)
5. Re: UnsatisfiedLinkError: no jniDeviceAddress in
java.library.path (Marcus M?ller)
6. Re: UnsatisfiedLinkError: no jniDeviceAddress in
java.library.path (jj08)
7. Re: UnsatisfiedLinkError: no jniDeviceAddress in
java.library.path (Marcus M?ller)
8. Re: UnsatisfiedLinkError: no jniDeviceAddress in
java.library.path (jj08)
9. Re: Feedback with Transmitters and Receiver (Pavan Yedavalli)
10. Re: Feedback with Transmitters and Receiver (Derek Kozel)
11. Re: Feedback with Transmitters and Receiver (Pavan Yedavalli)
12. JTAG debugging on the E310 (Seger, Edward H)
13. Re: JTAG debugging on the E310 (Long, Jeffrey P.)
14. N200 not syncing to external ref (Liwei)
15. UHD? installation problems (Cherif Chibane)
16. Re: How to know if a radio is currently in use?
(Claudio Cicconetti)
17. Re: UHD? installation problems (James Humphries)
18. B200 Mini or B200 Mini-i or B205 Mini-i (Sumit Kumar)
19. USRP E310_Overrun, Underrun and Latency. (BHUSHAN PAWAR)
20. Re: switching between TX/RX and RX2 for SBX-120 (Sanjoy Basak)
21. Re: B200 Mini or B200 Mini-i or B205 Mini-i (James Humphries)
22. Re: switching between TX/RX and RX2 for SBX-120 (Sanjoy Basak)
23. Vivado 2014.4 constraint bug (Long, Jeffrey P.)
24. Re: B200 Mini or B200 Mini-i or B205 Mini-i (Sumit Kumar)
25. USRP E310 max effective sample rate (Herv? BOEGLEN)
26. Re: B200 Mini or B200 Mini-i or B205 Mini-i (James Humphries)
27. Re: Vivado 2014.4 constraint bug (Jonathon Pendlum)
28. Re: Adding list of files to RFNoC build (Jonathon Pendlum)
29. Re: Is there an easy way to create a timestamp in a read only
register in rfnoc to verify the .bit file is what we just
generated? (Jonathon Pendlum)
30. USRP B200mini and additionnal LNA: fear the blue smoke!
(Antoto Antoine)
31. Re: Vivado 2014.4 constraint bug (Long, Jeffrey P.)
----------------------------------------------------------------------
Message: 1
Date: Thu, 28 Apr 2016 00:16:07 -0700
From: "jj08" <[email protected]>
To: [email protected]
Subject: [USRP-users] UnsatisfiedLinkError: no jniDeviceAddress in
java.library.path
Message-ID: <1071129461000000009736706@www>
Content-Type: text/plain; charset="utf-8"
Sorry, a bit long because I am trying to learn the basics and it doubles as a
kind of note to myself.
***
I am trying to write a Java program which reads data from USRP2 (or N210).
In Eclipse, I have installed uhd-java related files (org.anhonesteffort.*) and
javaCPP (org.bytedeco.*), thanks to https://github.com/rhodey/uhd-java.
I am using 64-bit Win-7 and have installed
uhd_003.009.003-release_Win64_VS2015 driver, and boost libraries (1_60_0).
In the folder org.anhonesteffort.uhd.RxStreamer, there is a file called
MultiUsrpTest.java.
I am trying to mimick that file and create a Java file that will connect to
and receive data from the device.
Now the problem:
I want to create "DeviceAddress" like this: (copied directly from
"MultiUsrpTest.java")
String DEVICE_ARGS= "name\n=,serial\n=ABC123DEF,type\n=usrp2";
//copied from theexample-usrp.properties file, I don't know what to put in name
and serial. For serial, may be I could put the serial number found at the back
of the device.)
DeviceAddress ADDRESS = new DeviceAddress(DEVICE_ARGS);
Even at this point, when I compile, I get this error:
Win32; Microsoft Visual C++ version 14.0; Boost_105800; UHD_003.009.003-release
Exception in thread "main" java.lang.UnsatisfiedLinkError: no
jniDeviceAddress in java.library.path
at org.bytedeco.javacpp.Loader.loadLibrary(Loader.java:637)
at org.bytedeco.javacpp.Loader.load(Loader.java:474)
at org.bytedeco.javacpp.Loader.load(Loader.java:411) at
org.anhonesteffort.uhd.types.DeviceAddress.<clinit>
(DeviceAddress.java:33) at usrp.USRPJReader.main(USRPJReader.java:53) <- my
program<br />
In my system path, I have C:\Program Files\UHD\bin, so it's not that.
I tried to find if there is any file called "jniDeviceAddress.dll"
in the system, but didn't find.
Google search also did not produce any result.
Please give me some idea what should I do to resolve this issue.
I don't even know if I need this "DeviceAddress". (may be if I want
to specify an IP for the device?)
A sample C++ program I am using (rx_sample_file.cpp by ER) is working fine- I
don't see any DeviceAddress in it. (default value is blank.)
Eventually, I want to translate that rx_sample_file.cpp file to Java.
For now, to understand how to proceed, I at least want to be able to:
(1)create a usrp device (2)create a receive streamer (3)receive data from
device, which all are all nicely done in the cpp file.</clinit> Thanks for
reading!
-------------------------
Online Storage & Sharing, Online Backup, FTP / Email Server Hosting and More.
Drive Headquarters. Top quality services designed for business! Sign up free
at: www.DriveHQ.com
.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160428/1982f2e7/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 28 Apr 2016 09:34:42 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] UnsatisfiedLinkError: no jniDeviceAddress in
java.library.path
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
This looks more like a Java issue than a UHD issue. First, are you able
to run example applications from the command line, and are you familiar
with the APIs?
If not, I suggest you put the Java aside for a minute, and make sure you
have the basics down and can run apps (such as rx_samples_to_file) with
your USRP. If you feel comfortable in this area, then you should
probably look into general methods of linking Java apps with other DLLs.
Regards,
M
On 04/28/2016 12:16 AM, jj08 via USRP-users wrote:
> Sorry, a bit long because I am trying to learn the basics and it doubles
> as a kind of note to myself.
>
> ***
>
> I am trying to write a Java program which reads data from USRP2 (or N210).
>
> In Eclipse, I have installed uhd-java related files
> (org.anhonesteffort.*) and javaCPP (org.bytedeco.*), thanks to
> https://github.com/rhodey/uhd-java.
>
> I am using 64-bit Win-7 and have installed
> uhd_003.009.003-release_Win64_VS2015 driver, and boost libraries (1_60_0).
>
> In the folder org.anhonesteffort.uhd.RxStreamer, there is a file called
> MultiUsrpTest.java.
> I am trying to mimick that file and create a Java file that will connect
> to and receive data from the device.
>
> Now the problem:
> I want to create "DeviceAddress" like this: (copied directly from
> "MultiUsrpTest.java")
>
> String DEVICE_ARGS= "name\n=,serial\n=ABC123DEF,type\n=usrp2"; //copied
> from theexample-usrp.properties file, I don't know what to put in name
> and serial. For serial, may be I could put the serial number found at
> the back of the device.)
> DeviceAddress ADDRESS = new DeviceAddress(DEVICE_ARGS);
>
> Even at this point, when I compile, I get this error:
>
> Win32; Microsoft Visual C++ version 14.0; Boost_105800;
> UHD_003.009.003-release
>
> Exception in thread "main" java.lang.UnsatisfiedLinkError: no
> jniDeviceAddress in java.library.path
> at org.bytedeco.javacpp.Loader.loadLibrary(Loader.java:637)
> at org.bytedeco.javacpp.Loader.load(Loader.java:474)
> at org.bytedeco.javacpp.Loader.load(Loader.java:411)
> at org.anhonesteffort.uhd.types.DeviceAddress.(DeviceAddress.java:33)
> at usrp.USRPJReader.main(USRPJReader.java:53) <- my program
>
> In my system path, I have C:\Program Files\UHD\bin, so it's not that.
> I tried to find if there is any file called "jniDeviceAddress.dll" in
> the system, but didn't find.
> Google search also did not produce any result.
>
> Please give me some idea what should I do to resolve this issue.
>
> I don't even know if I need this "DeviceAddress". (may be if I want to
> specify an IP for the device?)
> A sample C++ program I am using (rx_sample_file.cpp by ER) is working
> fine- I don't see any DeviceAddress in it. (default value is blank.)
>
> Eventually, I want to translate that rx_sample_file.cpp file to Java.
> For now, to understand how to proceed, I at least want to be able to:
> (1)create a usrp device (2)create a receive streamer (3)receive data
> from device, which all are all nicely done in the cpp file.
>
> Thanks for reading!
>
> -------------------------
> Online Storage & Sharing, Online Backup, FTP / Email Server Hosting and
> More.
> Drive Headquarters. Top quality services designed for business!
> Sign up free at: www.DriveHQ.com
> <http://www.drivehq.com/?refID=178949&refEmails=&refCode=>.
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 3
Date: Thu, 28 Apr 2016 09:38:04 -0700
From: Martin Braun <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: Re: [USRP-users] E310 FPGA design_Loopback test
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
On 04/27/2016 08:09 AM, BHUSHAN PAWAR wrote:
> * During initailiazation E310 performs few tests like register
> loopback test(3 times) and CODEC loopback (2 times) and Timer
> loopback test (2 times). Can you briefly explain each test or
> suggest some data to read to understand this issue?
This is a self-test. We write some random value into registers on the
FPGA (first test) and the RFIC (second test) to make sure our
communication is fine.
>
> * I am trying to achieve Rx to Tx loopback by editing current FPGA
> design. In the current FPGA, data is moved from E310_core --> FIFO
> --> Processing System --> FIFO --> E310_core. In the edited FPGA
> design, I am trying to bypass Processing system in the data path to
> reduce time delay. When I load the edited bit file on E310 it gives
> below errors,
This is not a feature that's yet exposed. Did you modify the FPGA code
for this? How did you set this up?
Cheers,
M
>
>
> [pawa_bh@ohff24 ~]$ ssh -X [email protected]
> <mailto:[email protected]> Last
> login: Fri Jan 22 00:54:11 2016 from ohff24.local
> root@ettus-e3xx-sg1:~# uhd_usrp_probe --args='fpga=/tmp/e300.bit'
> linux; GNU C++ version 4.9.2; Boost_105700; UHD_003.009.002-0-unknown
>
> -- Loading FPGA image: /tmp/e300.bit... done
> -- Detecting internal GPSDO .... found
> -- Initializing core control...
> -- Performing register loopback test... pass
> -- Performing register loopback test... Error: EnvironmentError:
> IOError: Radio ctrl (0) no response packet - AssertionError: bool(buff)
> in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
> at
> /home/balister/release-4/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/uhd/3.9.2-r0/uhd-3.9.2/lib/usrp/cores/radio_ctrl_core_3000.cpp:198
>
> Can you explain the reason for this error?
>
> * As I am looking for FPGA modification, I was reading about RFNOC. In
> the below mentioned link (https://github.com/EttusResearch/uhd/wiki)
> it is mentioned that Pure FPGA flow graphs are currently unsupported
> (i.e. RX->TX loopback). Can you briefly explain the reason for this?
>
>
>
> *Thanks & Regards,*
>
> *Bhushan R.V. Pawar.*
> //
------------------------------
Message: 4
Date: Thu, 28 Apr 2016 09:41:14 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] How to know if a radio is currently in use?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Claudio,
we don't have a dedicated API call for this. However, you might have
stumbled upon a bug. We'll need to investigate this.
It seems this is only the case for the N210, though, from your email.
How did you get your results? Just running uhd_find_devices?
Cheers,
Martin
On 04/11/2016 06:50 AM, Claudio Cicconetti via USRP-users wrote:
> Dear all,
> What is the official way to test from the command-line (or API) if an
> Ettus device is currently being used by another application on the same
> host?
>
> In the past I used to issue a uhd_find_devices command, which would
> return an empty list if the radio was in use, but it seems recent
> versions broke this opportunity with some device types.
>
> Even worse, if I try to use the radio while another application is
> already using it, the original application receives a TIMEOUT error and
> terminates abruptly.
>
> Based on my tests:
>
> - N210, UHD 3.8.5: broken
> - N210, UHD 3.9.2: broken
> - E310, UHD 3.9.2: broken
> - B210: UHD 3.9.2: works as expected
> - X300, UHD 3.9.2: works as expected
>
> Any ideas or suggestions?
>
> Best regards,
> Claudio
>
------------------------------
Message: 5
Date: Thu, 28 Apr 2016 18:42:49 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] UnsatisfiedLinkError: no jniDeviceAddress in
java.library.path
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi jj08,
I'd like to add:
I wasn't even aware of anyone having a Java wrapper for UHD :) That's
pretty exciting, though I must admit that Java isn't really my language
of choice, and even less so for high rate signal processing. But: I'm
very sure that there are excellent reasons to use it, especially if you
need to integrate it into a Java framework.
So, please excuse my curiosity: Can you tell us (as user community) a
bit about your application? What do you want to build?
Best regards,
Marcus
On 04/28/2016 06:34 PM, Martin Braun via USRP-users wrote:
> This looks more like a Java issue than a UHD issue. First, are you able
> to run example applications from the command line, and are you familiar
> with the APIs?
>
> If not, I suggest you put the Java aside for a minute, and make sure you
> have the basics down and can run apps (such as rx_samples_to_file) with
> your USRP. If you feel comfortable in this area, then you should
> probably look into general methods of linking Java apps with other DLLs.
>
> Regards,
> M
>
> On 04/28/2016 12:16 AM, jj08 via USRP-users wrote:
>> Sorry, a bit long because I am trying to learn the basics and it doubles
>> as a kind of note to myself.
>>
>> ***
>>
>> I am trying to write a Java program which reads data from USRP2 (or N210).
>>
>> In Eclipse, I have installed uhd-java related files
>> (org.anhonesteffort.*) and javaCPP (org.bytedeco.*), thanks to
>> https://github.com/rhodey/uhd-java.
>>
>> I am using 64-bit Win-7 and have installed
>> uhd_003.009.003-release_Win64_VS2015 driver, and boost libraries (1_60_0).
>>
>> In the folder org.anhonesteffort.uhd.RxStreamer, there is a file called
>> MultiUsrpTest.java.
>> I am trying to mimick that file and create a Java file that will connect
>> to and receive data from the device.
>>
>> Now the problem:
>> I want to create "DeviceAddress" like this: (copied directly from
>> "MultiUsrpTest.java")
>>
>> String DEVICE_ARGS= "name\n=,serial\n=ABC123DEF,type\n=usrp2"; //copied
>> from theexample-usrp.properties file, I don't know what to put in name
>> and serial. For serial, may be I could put the serial number found at
>> the back of the device.)
>> DeviceAddress ADDRESS = new DeviceAddress(DEVICE_ARGS);
>>
>> Even at this point, when I compile, I get this error:
>>
>> Win32; Microsoft Visual C++ version 14.0; Boost_105800;
>> UHD_003.009.003-release
>>
>> Exception in thread "main" java.lang.UnsatisfiedLinkError: no
>> jniDeviceAddress in java.library.path
>> at org.bytedeco.javacpp.Loader.loadLibrary(Loader.java:637)
>> at org.bytedeco.javacpp.Loader.load(Loader.java:474)
>> at org.bytedeco.javacpp.Loader.load(Loader.java:411)
>> at org.anhonesteffort.uhd.types.DeviceAddress.(DeviceAddress.java:33)
>> at usrp.USRPJReader.main(USRPJReader.java:53) <- my program
>>
>> In my system path, I have C:\Program Files\UHD\bin, so it's not that.
>> I tried to find if there is any file called "jniDeviceAddress.dll" in
>> the system, but didn't find.
>> Google search also did not produce any result.
>>
>> Please give me some idea what should I do to resolve this issue.
>>
>> I don't even know if I need this "DeviceAddress". (may be if I want to
>> specify an IP for the device?)
>> A sample C++ program I am using (rx_sample_file.cpp by ER) is working
>> fine- I don't see any DeviceAddress in it. (default value is blank.)
>>
>> Eventually, I want to translate that rx_sample_file.cpp file to Java.
>> For now, to understand how to proceed, I at least want to be able to:
>> (1)create a usrp device (2)create a receive streamer (3)receive data
>> from device, which all are all nicely done in the cpp file.
>>
>> Thanks for reading!
>>
>> -------------------------
>> Online Storage & Sharing, Online Backup, FTP / Email Server Hosting and
>> More.
>> Drive Headquarters. Top quality services designed for business!
>> Sign up free at: www.DriveHQ.com
>> <http://www.drivehq.com/?refID=178949&refEmails=&refCode=>.
>>
>>
>> _______________________________________________
>> 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: Thu, 28 Apr 2016 10:46:01 -0700
From: "jj08" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] UnsatisfiedLinkError: no jniDeviceAddress in
java.library.path
Message-ID: <1071547821000000009736706@www>
Content-Type: text/plain; charset="utf-8"
Hi there,
Thank you both for responding.
M:
I haven't found exact command line version of "DeviceAddress"
creation, so I couldn't test that, but system set-up wise, it seems to be
working.
Ex:
C:\Program Files\UHD\lib\uhd\examples>latency_test.exe
Win32; Microsoft Visual C++ version 14.0; Boost_105800; UHD_003.009.003-release
Error: LookupError: KeyError: No devices found for ----->
Empty Device Address
C:\Program Files\UHD\lib\uhd\examples>test_clock_synch.exe
Win32; Microsoft Visual C++ version 14.0; Boost_105800; UHD_003.009.003-release
Creating the Clock device with:
Error: LookupError: KeyError: No devices found for -----> Empty Device Address
The above error is due to the fact that I don't have the device connected to
my computer now.
My guess is that if I were to create DeviceAddress, I would face the same
UnsatisfiedLinkError.
What do you think?
While writing this message, I am thinking this:
It cannot be due to lack of C++ environment because the sample program (
rx_samples_to_file.exe). compiled using Visual Studio is working fine.
It could be the "bridge" that connects the Java world to the UHD
world is missing or not properly configured.
Marcus:
Yes, yes, there is a Java wrapper, thanks to rhodey of anhonesteffort.org.
Also, thanks to
Samuel Audet et al of bytedeco.org, so that the wrapper can be used.
Actually, my requirement is very, very basic. As a part of learning process, I
wanted to see some output from the USRP2, and since I already had a GUI to
display data (created for low rate streaming data for non-usrp application,
using libraries from http://ptolemy.eecs.berkeley.edu/java/ptplot/), I am
taking the easy way out for now.
I suspect (as you hinted) that as my requirements get more critical, the Java
solution may not be ideal, but let's see how things unfold.
Cheers,
jj
--From: [email protected]
--To: [email protected]
--Date: 4/28/2016 9:44:17 AM
--Subject: Re: [USRP-users] UnsatisfiedLinkError: no jniDeviceAddress in
java.library.path
Hi jj08,
I'd like to add:
I wasn't even aware of anyone having a Java wrapper for UHD :) That's
pretty exciting, though I must admit that Java isn't really my language
of choice, and even less so for high rate signal processing. But: I'm
very sure that there are excellent reasons to use it, especially if you
need to integrate it into a Java framework.
So, please excuse my curiosity: Can you tell us (as user community) a
bit about your application? What do you want to build?
Best regards,
Marcus
On 04/28/2016 06:34 PM, Martin Braun via USRP-users wrote:
> This looks more like a Java issue than a UHD issue. First, are you able
> to run example applications from the command line, and are you familiar
> with the APIs?
>
> If not, I suggest you put the Java aside for a minute, and make sure you
> have the basics down and can run apps (such as rx_samples_to_file) with
> your USRP. If you feel comfortable in this area, then you should
> probably look into general methods of linking Java apps with other DLLs.
>
> Regards,
> M
>
> On 04/28/2016 12:16 AM, jj08 via USRP-users wrote:
>> Sorry, a bit long because I am trying to learn the basics and it doubles
>> as a kind of note to myself.
>>
>> ***
>>
>> I am trying to write a Java program which reads data from USRP2 (or N210).
>>
>> In Eclipse, I have installed uhd-java related files
>> (org.anhonesteffort.*) and javaCPP (org.bytedeco.*), thanks to
>> https://github.com/rhodey/uhd-java.
>>
>> I am using 64-bit Win-7 and have installed
>> uhd_003.009.003-release_Win64_VS2015 driver, and boost libraries (1_60_0).
>>
>> In the folder org.anhonesteffort.uhd.RxStreamer, there is a file called
>> MultiUsrpTest.java.
>> I am trying to mimick that file and create a Java file that will connect
>> to and receive data from the device.
>>
>> Now the problem:
>> I want to create "DeviceAddress" like this: (copied directly from
>> "MultiUsrpTest.java")
>>
>> String DEVICE_ARGS= "name\n=,serial\n=ABC123DEF,type\n=usrp2";
>> //copied
>> from theexample-usrp.properties file, I don't know what to put in name
>> and serial. For serial, may be I could put the serial number found at
>> the back of the device.)
>> DeviceAddress ADDRESS = new DeviceAddress(DEVICE_ARGS);
>>
>> Even at this point, when I compile, I get this error:
>>
>> Win32; Microsoft Visual C++ version 14.0; Boost_105800;
>> UHD_003.009.003-release
>>
>> Exception in thread "main" java.lang.UnsatisfiedLinkError: no
>> jniDeviceAddress in java.library.path
>> at org.bytedeco.javacpp.Loader.loadLibrary(Loader.java:637)
>> at org.bytedeco.javacpp.Loader.load(Loader.java:474)
>> at org.bytedeco.javacpp.Loader.load(Loader.java:411)
>> at org.anhonesteffort.uhd.types.DeviceAddress.(DeviceAddress.java:33) >>
>> at usrp.USRPJReader.main(USRPJReader.java:53) <- my program <br />
>>
>> In my system path, I have C:\Program Files\UHD\bin, so it's not that.
>> I tried to find if there is any file called
>> "jniDeviceAddress.dll" in
>> the system, but didn't find.
>> Google search also did not produce any result.
>>
>> Please give me some idea what should I do to resolve this issue.
>>
>> I don't even know if I need this "DeviceAddress". (may be if I
>> want to
>> specify an IP for the device?)
>> A sample C++ program I am using (rx_sample_file.cpp by ER) is working
>> fine- I don't see any DeviceAddress in it. (default value is blank.)
>>
>> Eventually, I want to translate that rx_sample_file.cpp file to Java.
>> For now, to understand how to proceed, I at least want to be able to:
>> (1)create a usrp device (2)create a receive streamer (3)receive data
>> from device, which all are all nicely done in the cpp file.
>>
>> Thanks for reading!
>>
>> -------------------------
>> Online Storage & Sharing, Online Backup, FTP / Email Server Hosting and
>> More.
>> Drive Headquarters. Top quality services designed for business!
>> Sign up free at: www.DriveHQ.com >>
-------------------------
Online Storage & Sharing, Online Backup, FTP / Email Server Hosting and More.
Drive Headquarters. Top quality services designed for business! Sign up free
at: www.DriveHQ.com
.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160428/76e3ae04/attachment-0001.html>
------------------------------
Message: 7
Date: Thu, 28 Apr 2016 19:55:52 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] UnsatisfiedLinkError: no jniDeviceAddress in
java.library.path
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
No, that wouldn't happen - those are working C++ programs. So go ahead
and connect your USRP, try (why didn't you just try?! It's fun!).
> It could be the "bridge" that connects the Java world to the UHD world
> is missing or not properly configured.
are you *sure* you understand fully how to tell Java where to look for
native (JNI), and Java libraries and symbols?
>
> Actually, my requirement is very, very basic. As a part of learning
> process, I wanted to see some output from the USRP2, and since I
> already had a GUI to display data (created for low rate streaming data
> for non-usrp application, using libraries from
> http://ptolemy.eecs.berkeley.edu/java/ptplot/), I am taking the easy
> way out for now.
>
That's interesting!
So, I don't know, but if you really just want to stream samples: the
examples folder contains a rx_samples_to_udp, and if you can read
complex numbers from an UDP socket accepting samples coming from that
program (for more info, run it with "--help"), then you'd have a quick
and easy visualization.
Best regards,
Marcus
On 04/28/2016 07:46 PM, jj08 via USRP-users wrote:
>
> Hi there,
>
> Thank you both for responding.
>
> M:
>
> I haven't found exact command line version of "DeviceAddress"
> creation, so I couldn't test that, but system set-up wise, it seems to
> be working.
>
> Ex:
>
> C:\Program Files\UHD\lib\uhd\examples>latency_test.exe
> Win32; Microsoft Visual C++ version 14.0; Boost_105800;
> UHD_003.009.003-release
>
> Error: LookupError: KeyError: No devices found for ----->
> Empty Device Address
>
> C:\Program Files\UHD\lib\uhd\examples>test_clock_synch.exe
> Win32; Microsoft Visual C++ version 14.0; Boost_105800;
> UHD_003.009.003-release
>
>
> Creating the Clock device with:
> Error: LookupError: KeyError: No devices found for ----->
> Empty Device Address
>
> The above error is due to the fact that I don't have the device
> connected to my computer now.
>
> My guess is that if I were to create DeviceAddress, I would face the
> same UnsatisfiedLinkError.
>
> What do you think?
>
> While writing this message, I am thinking this:
>
> It cannot be due to lack of C++ environment because the sample program
> ( rx_samples_to_file.exe). compiled using Visual Studio is working fine.
>
> It could be the "bridge" that connects the Java world to the UHD world
> is missing or not properly configured.
>
>
>
>
>
> Marcus:
>
> Yes, yes, there is a Java wrapper, thanks to rhodey of
> anhonesteffort.org. Also, thanks to Samuel Audet et al of
> bytedeco.org, so that the wrapper can be used.
>
> Actually, my requirement is very, very basic. As a part of learning
> process, I wanted to see some output from the USRP2, and since I
> already had a GUI to display data (created for low rate streaming data
> for non-usrp application, using libraries from
> http://ptolemy.eecs.berkeley.edu/java/ptplot/), I am taking the easy
> way out for now.
>
> I suspect (as you hinted) that as my requirements get more critical,
> the Java solution may not be ideal, but let's see how things unfold.
>
> Cheers,
>
> jj
>
>
>
>
>
>
>
>
> --From: [email protected]
> --To: [email protected]
> --Date: 4/28/2016 9:44:17 AM
> --Subject: Re: [USRP-users] UnsatisfiedLinkError: no jniDeviceAddress
> in java.library.path
>
> Hi jj08,
>
> I'd like to add:
> I wasn't even aware of anyone having a Java wrapper for UHD :) That's
> pretty exciting, though I must admit that Java isn't really my language
> of choice, and even less so for high rate signal processing. But: I'm
> very sure that there are excellent reasons to use it, especially if you
> need to integrate it into a Java framework.
> So, please excuse my curiosity: Can you tell us (as user community) a
> bit about your application? What do you want to build?
>
> Best regards,
> Marcus
>
> On 04/28/2016 06:34 PM, Martin Braun via USRP-users wrote:
> > This looks more like a Java issue than a UHD issue. First, are you able
> > to run example applications from the command line, and are you familiar
> > with the APIs?
> >
> > If not, I suggest you put the Java aside for a minute, and make sure
> you
> > have the basics down and can run apps (such as rx_samples_to_file) with
> > your USRP. If you feel comfortable in this area, then you should
> > probably look into general methods of linking Java apps with other
> DLLs.
> >
> > Regards,
> > M
> >
> > On 04/28/2016 12:16 AM, jj08 via USRP-users wrote:
> >> Sorry, a bit long because I am trying to learn the basics and it
> doubles
> >> as a kind of note to myself.
> >>
> >> ***
> >>
> >> I am trying to write a Java program which reads data from USRP2 (or
> N210).
> >>
> >> In Eclipse, I have installed uhd-java related files
> >> (org.anhonesteffort.*) and javaCPP (org.bytedeco.*), thanks to
> >> https://github.com/rhodey/uhd-java.
> >>
> >> I am using 64-bit Win-7 and have installed
> >> uhd_003.009.003-release_Win64_VS2015 driver, and boost libraries
> (1_60_0).
> >>
> >> In the folder org.anhonesteffort.uhd.RxStreamer, there is a file
> called
> >> MultiUsrpTest.java.
> >> I am trying to mimick that file and create a Java file that will
> connect
> >> to and receive data from the device.
> >>
> >> Now the problem:
> >> I want to create "DeviceAddress" like this: (copied directly from
> >> "MultiUsrpTest.java")
> >>
> >> String DEVICE_ARGS= "name\n=,serial\n=ABC123DEF,type\n=usrp2";
> //copied
> >> from theexample-usrp.properties file, I don't know what to put in name
> >> and serial. For serial, may be I could put the serial number found at
> >> the back of the device.)
> >> DeviceAddress ADDRESS = new DeviceAddress(DEVICE_ARGS);
> >>
> >> Even at this point, when I compile, I get this error:
> >>
> >> Win32; Microsoft Visual C++ version 14.0; Boost_105800;
> >> UHD_003.009.003-release
> >>
> >> Exception in thread "main" java.lang.UnsatisfiedLinkError: no
> >> jniDeviceAddress in java.library.path
> >> at org.bytedeco.javacpp.Loader.loadLibrary(Loader.java:637)
> >> at org.bytedeco.javacpp.Loader.load(Loader.java:474)
> >> at org.bytedeco.javacpp.Loader.load(Loader.java:411)
> >> at org.anhonesteffort.uhd.types.DeviceAddress.(DeviceAddress.java:33)
> >> at usrp.USRPJReader.main(USRPJReader.java:53) <- my program
> >>
> >> In my system path, I have C:\Program Files\UHD\bin, so it's not that.
> >> I tried to find if there is any file called "jniDeviceAddress.dll" in
> >> the system, but didn't find.
> >> Google search also did not produce any result.
> >>
> >> Please give me some idea what should I do to resolve this issue.
> >>
> >> I don't even know if I need this "DeviceAddress". (may be if I want to
> >> specify an IP for the device?)
> >> A sample C++ program I am using (rx_sample_file.cpp by ER) is working
> >> fine- I don't see any DeviceAddress in it. (default value is blank.)
> >>
> >> Eventually, I want to translate that rx_sample_file.cpp file to Java.
> >> For now, to understand how to proceed, I at least want to be able to:
> >> (1)create a usrp device (2)create a receive streamer (3)receive data
> >> from device, which all are all nicely done in the cpp file.
> >>
> >> Thanks for reading!
> >>
> >> -------------------------
> >> Online Storage & Sharing, Online Backup, FTP / Email Server Hosting
> and
> >> More.
> >> Drive Headquarters. Top quality services designed for business!
> >> Sign up free at: www.DriveHQ.com
> >>
>
>
>
>
> -------------------------
> Online Storage & Sharing, Online Backup, FTP / Email Server Hosting
> and More.
> Drive Headquarters. Top quality services designed for business!
> Sign up free at: www.DriveHQ.com
> <http://www.drivehq.com/?refID=178949&refEmails=&refCode=>.
>
>
> _______________________________________________
> 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/20160428/4b94e491/attachment-0001.html>
------------------------------
Message: 8
Date: Thu, 28 Apr 2016 11:51:05 -0700
From: "jj08" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] UnsatisfiedLinkError: no jniDeviceAddress in
java.library.path
Message-ID: <1071594991000000009736706@www>
Content-Type: text/plain; charset="utf-8"
Hi Marcus:
It is quite late or early morning here, about 3:50am, I am at home now, left
work at about 6pm "yesterday". No access to the device now :)
And next few days are holidays!
You got me there that I do not fully understand how to tell Java where to look
for the JNI.
It would be nice if you could give me some hints.
What I know and can do: If I had an external file (eg. a jar file) , I would
put that file somewhere, go to the project's property and there is a menu to
add that jar file.
But for dll, I don't know how to do.
Also, I can't find the "jniDeviceAddress.dll", if anything like that
exists and if I need that one to overcome this problem.
**
I have run and successfully tested rx_samples_to_file.cpp, seen data output
and plotted the points (real parts).
In the days ahead, I want to greate interactive GUI to write and read values
to and from the usrp, so I am taking this Java/GUI appreach.
Even if I will be using a high sampling rate, I will probably do some thinning
(is this the right word?) when it comes to display the signal, so that Java can
cope with it. Just an idea, don't know if it is doable.
Cheers,
jj
--From: [email protected]
--To: [email protected]
--Date: 4/28/2016 10:57:20 AM
--Subject: Re: [USRP-users] UnsatisfiedLinkError: no jniDeviceAddress in
java.library.path
No, that wouldn't happen - those are working C++ programs. So go ahead and
connect your USRP, try (why didn't you just try?! It's fun!). It could be the
"bridge" that connects the Java world to the UHD world is missing or
not properly configured.
are you *sure* you understand fully how to tell Java where to look for native
(JNI), and Java libraries and symbols?
Actually, my requirement is very, very basic. As a part of learning process, I
wanted to see some output from the USRP2, and since I already had a GUI to
display data (created for low rate streaming data for non-usrp application,
using libraries from http://ptolemy.eecs.berkeley.edu/java/ptplot/), I am
taking the easy way out for now.
That's interesting!
So, I don't know, but if you really just want to stream samples: the examples
folder contains a rx_samples_to_udp, and if you can read complex numbers from
an UDP socket accepting samples coming from that program (for more info, run it
with "--help"), then you'd have a quick and easy visualization.
Best regards,
Marcus On 04/28/2016 07:46 PM, jj08 via USRP-users wrote:
Hi there,
Thank you both for responding.
M:
I haven't found exact command line version of "DeviceAddress"
creation, so I couldn't test that, but system set-up wise, it seems to be
working.
Ex:
C:\Program Files\UHD\lib\uhd\examples>latency_test.exe
Win32; Microsoft Visual C++ version 14.0; Boost_105800; UHD_003.009.003-release
Error: LookupError: KeyError: No devices found for ----->
Empty Device Address
C:\Program Files\UHD\lib\uhd\examples>test_clock_synch.exe
Win32; Microsoft Visual C++ version 14.0; Boost_105800; UHD_003.009.003-release
Creating the Clock device with:
Error: LookupError: KeyError: No devices found for -----> Empty Device Address
The above error is due to the fact that I don't have the device connected to
my computer now.
My guess is that if I were to create DeviceAddress, I would face the same
UnsatisfiedLinkError.
What do you think?
While writing this message, I am thinking this:
It cannot be due to lack of C++ environment because the sample program (
rx_samples_to_file.exe). compiled using Visual Studio is working fine.
It could be the "bridge" that connects the Java world to the UHD
world is missing or not properly configured.
Marcus:
Yes, yes, there is a Java wrapper, thanks to rhodey of anhonesteffort.org.
Also, thanks to
Samuel Audet et al of bytedeco.org, so that the wrapper can be used.
Actually, my requirement is very, very basic. As a part of learning process, I
wanted to see some output from the USRP2, and since I already had a GUI to
display data (created for low rate streaming data for non-usrp application,
using libraries from http://ptolemy.eecs.berkeley.edu/java/ptplot/), I am
taking the easy way out for now.
I suspect (as you hinted) that as my requirements get more critical, the Java
solution may not be ideal, but let's see how things unfold.
Cheers,
jj
--From: [email protected]
--To: [email protected]
--Date: 4/28/2016 9:44:17 AM
--Subject: Re: [USRP-users] UnsatisfiedLinkError: no jniDeviceAddress in
java.library.path
Hi jj08,
I'd like to add:
I wasn't even aware of anyone having a Java wrapper for UHD :) That's
pretty exciting, though I must admit that Java isn't really my language
of choice, and even less so for high rate signal processing. But: I'm
very sure that there are excellent reasons to use it, especially if you
need to integrate it into a Java framework.
So, please excuse my curiosity: Can you tell us (as user community) a
bit about your application? What do you want to build?
Best regards,
Marcus
On 04/28/2016 06:34 PM, Martin Braun via USRP-users wrote:
> This looks more like a Java issue than a UHD issue. First, are you able
> to run example applications from the command line, and are you familiar
> with the APIs?
>
> If not, I suggest you put the Java aside for a minute, and make sure you
> have the basics down and can run apps (such as rx_samples_to_file) with
> your USRP. If you feel comfortable in this area, then you should
> probably look into general methods of linking Java apps with other DLLs.
>
> Regards,
> M
>
> On 04/28/2016 12:16 AM, jj08 via USRP-users wrote:
>> Sorry, a bit long because I am trying to learn the basics and it doubles
>> as a kind of note to myself.
>>
>> ***
>>
>> I am trying to write a Java program which reads data from USRP2 (or N210).
>>
>> In Eclipse, I have installed uhd-java related files
>> (org.anhonesteffort.*) and javaCPP (org.bytedeco.*), thanks to >>
>> https://github.com/rhodey/uhd-java
.
>>
>> I am using 64-bit Win-7 and have installed
>> uhd_003.009.003-release_Win64_VS2015 driver, and boost libraries (1_60_0).
>>
>> In the folder org.anhonesteffort.uhd.RxStreamer, there is a file called
>> MultiUsrpTest.java.
>> I am trying to mimick that file and create a Java file that will connect
>> to and receive data from the device.
>>
>> Now the problem:
>> I want to create "DeviceAddress" like this: (copied directly from
>> "MultiUsrpTest.java")
>>
>> String DEVICE_ARGS= "name\n=,serial\n=ABC123DEF,type\n=usrp2";
>> //copied
>> from theexample-usrp.properties file, I don't know what to put in name
>> and serial. For serial, may be I could put the serial number found at
>> the back of the device.)
>> DeviceAddress ADDRESS = new DeviceAddress(DEVICE_ARGS);
>>
>> Even at this point, when I compile, I get this error:
>>
>> Win32; Microsoft Visual C++ version 14.0; Boost_105800;
>> UHD_003.009.003-release
>>
>> Exception in thread "main" java.lang.UnsatisfiedLinkError: no
>> jniDeviceAddress in java.library.path
>> at org.bytedeco.javacpp.Loader.loadLibrary(Loader.java:637)
>> at org.bytedeco.javacpp.Loader.load(Loader.java:474)
>> at org.bytedeco.javacpp.Loader.load(Loader.java:411)
>> at org.anhonesteffort.uhd.types.DeviceAddress.(DeviceAddress.java:33) >>
>> at usrp.USRPJReader.main(USRPJReader.java:53) <- my program <br />
>>
>> In my system path, I have C:\Program Files\UHD\bin, so it's not that.
>> I tried to find if there is any file called
>> "jniDeviceAddress.dll" in
>> the system, but didn't find.
>> Google search also did not produce any result.
>>
>> Please give me some idea what should I do to resolve this issue.
>>
>> I don't even know if I need this "DeviceAddress". (may be if I
>> want to
>> specify an IP for the device?)
>> A sample C++ program I am using (rx_sample_file.cpp by ER) is working
>> fine- I don't see any DeviceAddress in it. (default value is blank.)
>>
>> Eventually, I want to translate that rx_sample_file.cpp file to Java.
>> For now, to understand how to proceed, I at least want to be able to:
>> (1)create a usrp device (2)create a receive streamer (3)receive data
>> from device, which all are all nicely done in the cpp file.
>>
>> Thanks for reading!
>>
>> -------------------------
>> Online Storage & Sharing, Online Backup, FTP / Email Server Hosting and
>> More.
>> Drive Headquarters. Top quality services designed for business! >> Sign up
>> free at: www.DriveHQ.com
>>
-------------------------
Online Storage & Sharing, Online Backup, FTP / Email Server Hosting and More.
Drive Headquarters. Top quality services designed for business! Sign up free
at: www.DriveHQ.com
.
_______________________________________________ USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------------------
Online Storage & Sharing, Online Backup, FTP / Email Server Hosting and More.
Drive Headquarters. Top quality services designed for business! Sign up free
at: www.DriveHQ.com
.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160428/acd2b712/attachment-0001.html>
------------------------------
Message: 9
Date: Thu, 28 Apr 2016 12:22:01 -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_PtQNqYMR=Bv+XO3=gd0wtr_uof+kft+5ptuhq_b2g...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160428/7a8d1263/attachment-0001.html>
------------------------------
Message: 10
Date: Thu, 28 Apr 2016 15:55:35 -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=tvWn7WGJq27X1n9wu+jeCXfzjvbxjFeLGt_e=mpl7c...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160428/5bc403ca/attachment-0001.html>
------------------------------
Message: 11
Date: Thu, 28 Apr 2016 16:21:17 -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_OA0qg0TV7mGUh0b4emPuP+SmPL81muAgGd+Ek=hhu...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160428/f6278a35/attachment-0001.html>
------------------------------
Message: 12
Date: Thu, 28 Apr 2016 23:57:30 +0000
From: "Seger, Edward H" <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: [USRP-users] JTAG debugging on the E310
Message-ID:
<b79379c8e247c54d9d1a503ed97cb3c0ec0...@msmr-gh1-uea10.corp.nsa.gov>
Content-Type: text/plain; charset="us-ascii"
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
------------------------------
Message: 13
Date: Fri, 29 Apr 2016 01:40:06 +0000
From: "Long, Jeffrey P." <[email protected]>
To: "Seger, Edward H" <[email protected]>,
"'[email protected]'" <[email protected]>
Subject: Re: [USRP-users] JTAG debugging on the E310
Message-ID:
<sn1pr09mb0831970368cb4af59449ad72d9...@sn1pr09mb0831.namprd09.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
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
------------------------------
Message: 14
Date: Fri, 29 Apr 2016 04:03:42 +0000
From: Liwei <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] N200 not syncing to external ref
Message-ID:
<cape0syzmaky0+t5v8q4fwtwurfes3awkadbpoj-df8suqvh...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi list,
I have 3 N200 (with WBX daughterboards) I'm trying to synchronise for
some phase measurements. Since I have a MIMO cable, two of them are
synchronised to each other via that, and they work well.
I then feed Ref and PPS signals to the third, and, one of the 2 N200
(which were connected to each other via MIMO). If I understand the
documentation correctly, this should sync up all three N200.
However, when I feed a single frequency source into all three N200 and
view their time plots, only the two connected via MIMO are synchronised.
The third always show the frequency source at a lower frequency than the
others.
I've tried disconnecting the Ref signals while the flowgraph is
running, and the frequency/time plots do change, indicating that the USRPs
are synchronising to the Ref signal.
The Ref and PPS signals are derived from a single timing source and
distributed by 1:2 splitters.
In addition, the documentation mentions the N200 should use square Ref
signals for best phase performance, but I've been unable to get the N200 to
synchronise when I use a square Ref signal.
Anyone can shed some light on why the above is happening?
Warm regards,
Liwei
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160429/37d1d8e8/attachment-0001.html>
------------------------------
Message: 15
Date: Fri, 29 Apr 2016 02:01:26 +0000
From: Cherif Chibane <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] UHD? installation problems
Message-ID:
<f4926999d0cb674eb83933850b495e554f025...@oc11expo28.exchange.mit.edu>
Content-Type: text/plain; charset="us-ascii"
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
------------------------------
Message: 16
Date: Fri, 29 Apr 2016 08:49:49 +0200
From: Claudio Cicconetti <[email protected]>
To: [email protected], [email protected]
Subject: Re: [USRP-users] How to know if a radio is currently in use?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Dear Martin,
Thank you for your feedback.
The issue showed up with both N210 and E310.
I agree this may be a bug (regression) since in previous versions
uhd_find_devices worked flawlessly (= not showing radios in use).
The issue is not critical since it can be worked around in the
application, e.g., by using a lock file.
Still, as a general remark, I think adding a management interface to the
USRP (either via C++ API or a dedicated protocol such as SNMP) would
greatly reduce the amount and amplitude of headaches when you want to
use the radios in a production environment.
Best regards,
Claudio
On 04/28/2016 06:41 PM, Martin Braun via USRP-users wrote:
> Claudio,
>
> we don't have a dedicated API call for this. However, you might have
> stumbled upon a bug. We'll need to investigate this.
>
> It seems this is only the case for the N210, though, from your email.
> How did you get your results? Just running uhd_find_devices?
>
> Cheers,
> Martin
>
> On 04/11/2016 06:50 AM, Claudio Cicconetti via USRP-users wrote:
>> Dear all,
>> What is the official way to test from the command-line (or API) if an
>> Ettus device is currently being used by another application on the same
>> host?
>>
>> In the past I used to issue a uhd_find_devices command, which would
>> return an empty list if the radio was in use, but it seems recent
>> versions broke this opportunity with some device types.
>>
>> Even worse, if I try to use the radio while another application is
>> already using it, the original application receives a TIMEOUT error and
>> terminates abruptly.
>>
>> Based on my tests:
>>
>> - N210, UHD 3.8.5: broken
>> - N210, UHD 3.9.2: broken
>> - E310, UHD 3.9.2: broken
>> - B210: UHD 3.9.2: works as expected
>> - X300, UHD 3.9.2: works as expected
>>
>> Any ideas or suggestions?
>>
>> Best regards,
>> Claudio
>>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 17
Date: Fri, 29 Apr 2016 08:33:51 -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:
<CAEwGFhWkRKOuWEV0Zidk=nxjw4fg4b_nxdrpbvj4kf2vhed...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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/c8c253bc/attachment-0001.html>
------------------------------
Message: 18
Date: Fri, 29 Apr 2016 14:56:27 +0200
From: Sumit Kumar <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] B200 Mini or B200 Mini-i or B205 Mini-i
Message-ID:
<caoextcqj-r44bxrmchrudkfjp_koisawne6+zkvvh68opao...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
My application demands modification of FPGA files to send ACK/NACK within
SIFS(802.11). I am already working on B210 and now planning to procure some
B200 Mini.
I see that 3 different models are available.
>From FPGA point of view I see that B205 Mini-i has a bigger one compared to
the rest two.
My questions are :
1. Does B205 Mini-i has more unused resources compared to the rest two ? So
that I can put some of my code there in the FPGA.
2. Will it be possible to MIMO lock two B205 Mini-i so that I can cover the
entire WiFi bandwidth of 80 MHz by locking two of them ?
3. Any other suggestion :)
TIA
--
--
Sumit kumar
Doctoral Student, UPMC
Eurecom, BIOT
France
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160429/1eb25126/attachment-0001.html>
------------------------------
Message: 19
Date: Fri, 29 Apr 2016 15:00:25 +0200
From: BHUSHAN PAWAR <[email protected]>
To: [email protected], [email protected]
Subject: [USRP-users] USRP E310_Overrun, Underrun and Latency.
Message-ID:
<cafvcn_8aqiuqol_ndash_nkgivkn7fqyyj-doddws-9zouk...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
I am trying to achieve MIMO Rx to Tx Loopback in E310 using Gnu-radio.
Please find attached herewith .png file to see my Gnu-radio design.
Settings for my UHD USRP Sink and Source blocks are as follows,
Samp_rate : 40e3
clock rate : default
BW ch0 & ch1 : 6e6
Center Freq. ch0 & ch1 : 500e6
The output of Gnu-radio is as follows,
Generating: '/home/root/top_block.py'
Executing: '/usr/bin/python -u /home/root/top_block.py'
linux; GNU C++ version 4.9.2; Boost_105700; UHD_003.009.002-0-unknown
-- Loading FPGA image: /usr/share/uhd/images/usrp_e310_fpga.bit... done
-- Detecting internal GPSDO .... found
-- Initializing core control...
-- Performing register loopback test... pass
-- Performing register loopback test... pass
-- Performing register loopback test... pass
-- Performing CODEC loopback test... pass
-- Performing CODEC loopback test... pass
-- Setting time source to internal
-- Asking for clock rate 16 MHz
-- Actually got clock rate 16 MHz
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
Using Volk machine: neon_hardfp
UULLLLLLLLLLLLLLLLLLLLLLLLLLLLLLUULLLLLLLLLLLLLLLLLLLLUULLLLLLL
LLLLLLLLLUULLLLLLLLLLLLLLLLLLLLLLLLUULLLLLLLLLLLLLLLLLLUULLLLLL
LLLLLLLLLLLLUULLLLLLLLLLLLLLLLLLLLLLLLUULLLLLLLLLLLLLLLLUULLUUL
LLLLLLLLLLLLLLLUULLLLLLLLLLLLLLUULLLLLLLLLLLLLLLLLLLLLLLLUULLLLL
LLLLLLLLLLLUULLLLLLLLLLLLLLLLLLLLLLUULLLLLLLLLLLLLLLLLLLLLLLLUUL
LLLLLLLLLLLLLLLLLLLUULLLLLLLLLLLLLLLLLUULL
1. What is the reason for so many overflows and latency in the output?
What changes are required to eliminate this? The Tx stops transmitting the
signal after one point due to this.
2. As selection of master clock is done automatically in E310, can you
explain how to find the minimum sampling rate for the system? or How the
Samp_rate (40e3) relate to the actual sampling frequency?
*Thanks & Regards,*
*Bhushan R.V. Pawar.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160429/4bfa0ab9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: E310.png
Type: image/png
Size: 29139 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160429/4bfa0ab9/attachment-0001.png>
------------------------------
Message: 20
Date: Fri, 29 Apr 2016 15:03:06 +0200
From: Sanjoy Basak <[email protected]>
To: Derek Kozel <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] switching between TX/RX and RX2 for SBX-120
Message-ID:
<cajpq1a2sq-_pf5arg3xezx2tm43ja+0amcvtmiowng0ggfa...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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/94ee9c61/attachment-0001.html>
------------------------------
Message: 21
Date: Fri, 29 Apr 2016 09:12:54 -0400
From: James Humphries <[email protected]>
To: Sumit Kumar <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] B200 Mini or B200 Mini-i or B205 Mini-i
Message-ID:
<CAEwGFhX3AJsWJ2nP=Vex92PtShxdpW1Z+pENqTyPc0pt3=h...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Sumit,
The B200mini and B205mini are essentially the same, just the larger FPGA on
the B205mini. The B210 has logic for the 2x2 transceiver on the AD9361,
while both the b200mini and b205mini only need to support 1x1 operation on
the AD9364. I don't have the numbers in front of me, but I believe that
b205mini has more resources available than the B210 for that reason.
The b200mini series has an input for 10MHz reference or a PPS signal for
synchronization.
-Trip
On Fri, Apr 29, 2016 at 8:56 AM, Sumit Kumar via USRP-users <
[email protected]> wrote:
> My application demands modification of FPGA files to send ACK/NACK within
> SIFS(802.11). I am already working on B210 and now planning to procure some
> B200 Mini.
>
> I see that 3 different models are available.
>
> From FPGA point of view I see that B205 Mini-i has a bigger one compared
> to the rest two.
>
> My questions are :
>
> 1. Does B205 Mini-i has more unused resources compared to the rest two ?
> So that I can put some of my code there in the FPGA.
>
> 2. Will it be possible to MIMO lock two B205 Mini-i so that I can cover
> the entire WiFi bandwidth of 80 MHz by locking two of them ?
>
> 3. Any other suggestion :)
>
>
> TIA
>
> --
> --
> Sumit kumar
> Doctoral Student, UPMC
> Eurecom, BIOT
> France
>
>
> _______________________________________________
> 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/1780d5cd/attachment-0001.html>
------------------------------
Message: 22
Date: Fri, 29 Apr 2016 15:17:22 +0200
From: Sanjoy Basak <[email protected]>
To: Derek Kozel <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] switching between TX/RX and RX2 for SBX-120
Message-ID:
<CAJPQ1a00shx2OvBR9iO1NznqfvJpbK9vQ2YmKBRdz0W=_+c...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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/6f27dd49/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1by1.py
Type: text/x-python
Size: 5981 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160429/6f27dd49/attachment-0001.py>
------------------------------
Message: 23
Date: Fri, 29 Apr 2016 13:19:04 +0000
From: "Long, Jeffrey P." <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Vivado 2014.4 constraint bug
Message-ID:
<sn1pr09mb0831ecbc4487ee14ca582bded9...@sn1pr09mb0831.namprd09.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
I am doing some custom FPGA development using the maint branch so I am stuck
with Vivado 2014.4. Evidently there is a known bug:
ERROR: [Shape Builder 18-138] during place_design in Vivado 2014.4
http://www.xilinx.com/support/answers/63784.html
Of course this is fixed in more modern versions of Vivado but their work around
is to apply the constraint yourself and not allow the tool to do it
erroneously. Can you please advise on where I could drop this constraint in the
Ettus build scripts?
ERROR: [Shape Builder 18-138] Cannot obey LUTNM/HLUTNM constraint for instances
x300_core/radio0/cust_rx.myrx_proc/rx_wfrm_core_inst/clk_recovery_inst_6/correlator_inst/tap[36].mult_arr[36][3]_i_2
and
x300_core/radio0/cust_rx.myrx_proc/rx_wfrm_core_inst/clk_recovery_inst_6/correlator_inst/tap[36].mult_arr[36][3]_i_5.
Reason: for bel A5LUT Element SLICE_X2Y0.A6LUT is not routable as there are 6
input pins and A6 cannot be used because of A5LUT usage..
Thanks
Jeff Long
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160429/f194aaea/attachment-0001.html>
------------------------------
Message: 24
Date: Fri, 29 Apr 2016 16:32:39 +0200
From: Sumit Kumar <[email protected]>
To: James Humphries <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] B200 Mini or B200 Mini-i or B205 Mini-i
Message-ID:
<caoextctfv9tahgnn0twjb1uitgqsomorfrqdw0s6z4baqv6...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
What does it mean by " input for 10MHz reference or a PPS signal for
synchronization"
I see that in all older models we had separate ports for 10MHz and PPS. For
synchronization, both are required right
(I am sorry, I have not done MIMO experiments with USRP, so have have less
practical knowledge of synchronization)
In my application I have to use two USRP(each of 56 MHz RF bandwidth) to
capture a 80MHz wide WiFi band.
Will it be possible with mini-series synchronization capabilities ?
On Fri, Apr 29, 2016 at 3:12 PM, James Humphries <[email protected]>
wrote:
> Hi Sumit,
>
> The B200mini and B205mini are essentially the same, just the larger FPGA
> on the B205mini. The B210 has logic for the 2x2 transceiver on the AD9361,
> while both the b200mini and b205mini only need to support 1x1 operation on
> the AD9364. I don't have the numbers in front of me, but I believe that
> b205mini has more resources available than the B210 for that reason.
>
> The b200mini series has an input for 10MHz reference or a PPS signal for
> synchronization.
>
> -Trip
>
> On Fri, Apr 29, 2016 at 8:56 AM, Sumit Kumar via USRP-users <
> [email protected]> wrote:
>
>> My application demands modification of FPGA files to send ACK/NACK within
>> SIFS(802.11). I am already working on B210 and now planning to procure some
>> B200 Mini.
>>
>> I see that 3 different models are available.
>>
>> From FPGA point of view I see that B205 Mini-i has a bigger one compared
>> to the rest two.
>>
>> My questions are :
>>
>> 1. Does B205 Mini-i has more unused resources compared to the rest two ?
>> So that I can put some of my code there in the FPGA.
>>
>> 2. Will it be possible to MIMO lock two B205 Mini-i so that I can cover
>> the entire WiFi bandwidth of 80 MHz by locking two of them ?
>>
>> 3. Any other suggestion :)
>>
>>
>> TIA
>>
>> --
>> --
>> Sumit kumar
>> Doctoral Student, UPMC
>> Eurecom, BIOT
>> France
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
--
--
Sumit kumar
Doctoral Student, UPMC
Eurecom, BIOT
France
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160429/f39af601/attachment-0001.html>
------------------------------
Message: 25
Date: Fri, 29 Apr 2016 17:17:45 +0200
From: Herv? BOEGLEN <[email protected]>
To: [email protected]
Subject: [USRP-users] USRP E310 max effective sample rate
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Dear all,
After some problems to get the max possible transfer rate from X310
radios (I still got some failures when writing on an SSD (at 200Mb/s)
but I overcame this with a ram disk), I would like to obtain at least
20Msps from an E310.
From what I have read on the list, if I use UHD it is not possible (I
tested a PC-E310 connection and I couldn't get more than 2Msps). Not
quite sure it would change much if I do the same from the embedded Linux?
My application concerns a channel sounder which we want to put on a
drone (thus the interest of the E310). If I look at a similar platform I
have been playing with (AD9361 ARRADIO + TERASIC SoCKit), I can achieve
30Msps from the embedded Linux without any problem (ADI libiio). More
precisely, what I want to do is just transmit continuously an OFDM
packet at a minimum rate of 20Msps. So basically, It is a matter of
initialising a FIFO with the OFDM IQ data and send it to the AD9361.
It look a bit of a silly question: what is the easiest way to do that?
To use RFNoC?
Thank you for your suggestions
Herv? Boeglen
------------------------------
Message: 26
Date: Fri, 29 Apr 2016 11:18:56 -0400
From: James Humphries <[email protected]>
To: Sumit Kumar <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] B200 Mini or B200 Mini-i or B205 Mini-i
Message-ID:
<CAEwGFhWURTqbp_XOe-o0k8ZWyjOhdZvdMqgrRbJM-Osb82A=6...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Sumit,
The PPS signal will allow you to have both a shared time reference and
frequency reference. The signal time counter in the FPGA so that you can
accurately time stamp the incoming samples. Can be used to time align
samples across multiple USRP's. It also acts as a very accurate 1Hz signal
that is (hopefully) derived from a very accurate frequency reference.
The 10 MHz reference input acts as a frequency reference. You may get some
better performance here in terms of phase noise. It seems that many users
have found that the PPS signal meet their needs, but it depends on your
application.
-Trip
On Fri, Apr 29, 2016 at 10:32 AM, Sumit Kumar <[email protected]> wrote:
> What does it mean by " input for 10MHz reference or a PPS signal for
> synchronization"
>
> I see that in all older models we had separate ports for 10MHz and PPS.
> For synchronization, both are required right
>
> (I am sorry, I have not done MIMO experiments with USRP, so have have less
> practical knowledge of synchronization)
>
> In my application I have to use two USRP(each of 56 MHz RF bandwidth) to
> capture a 80MHz wide WiFi band.
>
> Will it be possible with mini-series synchronization capabilities ?
>
>
>
>
> On Fri, Apr 29, 2016 at 3:12 PM, James Humphries <
> [email protected]> wrote:
>
>> Hi Sumit,
>>
>> The B200mini and B205mini are essentially the same, just the larger FPGA
>> on the B205mini. The B210 has logic for the 2x2 transceiver on the AD9361,
>> while both the b200mini and b205mini only need to support 1x1 operation on
>> the AD9364. I don't have the numbers in front of me, but I believe that
>> b205mini has more resources available than the B210 for that reason.
>>
>> The b200mini series has an input for 10MHz reference or a PPS signal for
>> synchronization.
>>
>> -Trip
>>
>> On Fri, Apr 29, 2016 at 8:56 AM, Sumit Kumar via USRP-users <
>> [email protected]> wrote:
>>
>>> My application demands modification of FPGA files to send ACK/NACK
>>> within SIFS(802.11). I am already working on B210 and now planning to
>>> procure some B200 Mini.
>>>
>>> I see that 3 different models are available.
>>>
>>> From FPGA point of view I see that B205 Mini-i has a bigger one compared
>>> to the rest two.
>>>
>>> My questions are :
>>>
>>> 1. Does B205 Mini-i has more unused resources compared to the rest two ?
>>> So that I can put some of my code there in the FPGA.
>>>
>>> 2. Will it be possible to MIMO lock two B205 Mini-i so that I can cover
>>> the entire WiFi bandwidth of 80 MHz by locking two of them ?
>>>
>>> 3. Any other suggestion :)
>>>
>>>
>>> TIA
>>>
>>> --
>>> --
>>> Sumit kumar
>>> Doctoral Student, UPMC
>>> Eurecom, BIOT
>>> France
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>
>
> --
> --
> Sumit kumar
> Doctoral Student, UPMC
> Eurecom, BIOT
> France
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160429/070d7314/attachment-0001.html>
------------------------------
Message: 27
Date: Fri, 29 Apr 2016 10:29:30 -0500
From: Jonathon Pendlum <[email protected]>
To: "Long, Jeffrey P." <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Vivado 2014.4 constraint bug
Message-ID:
<CAGdo0uTpKzdxx5YkaaFg9GjA3a9AD3vCtv0SztNzc0Cf2x1=p...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Jeff,
You have two options. You can create you own xdc file and add it to the
TOP_SRCS variable in usrp3/top/x300/Makefile.x300.inc. Or, you can place
your custom constraint in usrp3/top/x300/x300.xdc.
Jonathon
On Fri, Apr 29, 2016 at 8:19 AM, Long, Jeffrey P. via USRP-users <
[email protected]> wrote:
> I am doing some custom FPGA development using the maint branch so I am
> stuck with Vivado 2014.4. Evidently there is a known bug:
>
>
>
> ERROR: [Shape Builder 18-138] during place_design in Vivado 2014.4
>
> http://www.xilinx.com/support/answers/63784.html
>
>
>
> Of course this is fixed in more modern versions of Vivado but their work
> around is to apply the constraint yourself and not allow the tool to do it
> erroneously. Can you please advise on where I could drop this constraint in
> the Ettus build scripts?
>
>
>
> ERROR: [Shape Builder 18-138] Cannot obey LUTNM/HLUTNM constraint for
> instances
> x300_core/radio0/cust_rx.myrx_proc/rx_wfrm_core_inst/clk_recovery_inst_6/correlator_inst/tap[36].mult_arr[36][3]_i_2
> and
> x300_core/radio0/cust_rx.myrx_proc/rx_wfrm_core_inst/clk_recovery_inst_6/correlator_inst/tap[36].mult_arr[36][3]_i_5.
> Reason: for bel A5LUT Element SLICE_X2Y0.A6LUT is not routable as there
> are 6 input pins and A6 cannot be used because of A5LUT usage..
>
>
>
> Thanks
>
> Jeff Long
>
>
>
> _______________________________________________
> 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/04d5586c/attachment-0001.html>
------------------------------
Message: 28
Date: Fri, 29 Apr 2016 10:32:36 -0500
From: Jonathon Pendlum <[email protected]>
To: Jason Matusiak <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Adding list of files to RFNoC build
Message-ID:
<CAGdo0uSNucJHS=hltsz-dvenyb8yvuuj-5wgoc7pnrepbs5...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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]> 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]
> 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/8a0223a0/attachment-0001.html>
------------------------------
Message: 29
Date: Fri, 29 Apr 2016 10:37:31 -0500
From: Jonathon Pendlum <[email protected]>
To: "Swanson, Craig" <[email protected]>
Cc: Martin Braun <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Is there an easy way to create a timestamp
in a read only register in rfnoc to verify the .bit file is what we
just generated?
Message-ID:
<cagdo0us2w5+ziqrhjw6tzvr+l4kivkj0rzym4g-e+bzbhkh...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Craig,
You can still use the NOC ID. You have the option to match on the only the
upper 16 bits (instead of all 64) and you can use the lower bits for
whatever you want. Take a look at fft.xml, you can see that the NOC ID is
set to FF70 which will match any block's NOD ID starting with that value.
Also, if you are only modifying XML files, you do not need to crosscompile.
Jonathon
On Wed, Apr 27, 2016 at 1:33 PM, Swanson, Craig <
[email protected]> wrote:
> Jonathon,
>
> We are starting hardware in the loop debug of our fpga code in an E310 and
> gnuradio companion.
>
>
> Let's say I generated a new bit file on April 27 at 3:15 pm.
>
> I would would like to embed that day and possible time into a read
> only register in the E310 that could verify either in uhd_usrp_probe or
> while running a flowgraph or python file.
>
>
> I don't want to use NOC ID because then I have to load a different XML
> file each time as well, which also means I would need to re-cross compile
> each time.
>
>
> What do you suggest?
>
>
> Craig
>
>
> *Craig F. Swanson*
>
> *Research Engineer II *
> *Information and Communications Laboratory*
> *Communications, Systems, and Spectrum Division*
> *Georgia Tech Research Institute*
>
>
> *Room 560 250 14th St NW *
> *Atlanta, GA 30318*
> *Cell: 770.298.9156 <770.298.9156>*
> http://www.gtri.gatech.edu
> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160429/481c2c75/attachment-0001.html>
------------------------------
Message: 30
Date: Fri, 29 Apr 2016 15:37:05 +0000
From: Antoto Antoine <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] USRP B200mini and additionnal LNA: fear the blue
smoke!
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! 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160429/ce89948e/attachment-0001.html>
------------------------------
Message: 31
Date: Fri, 29 Apr 2016 15:47:43 +0000
From: "Long, Jeffrey P." <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Vivado 2014.4 constraint bug
Message-ID:
<sn1pr09mb0831bd771e540d408caa5e63d9...@sn1pr09mb0831.namprd09.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Jonathon-
Yes thanks. Just put it in x300.xdc and it worked. Evidently this is one of
those nightmare bugs that can pop up anywhere randomly. Today I squashed it but
it will come back as soon as I do something different. I realize the need for
stability and all in the maint branch but Vivado is a continuous work in
progress and Xilinx?s answer to problems like this is to use the latest
version. 2014 is really old and full of terrors.
Thanks
Jeff
From: Jonathon Pendlum [mailto:[email protected]]
Sent: Friday, April 29, 2016 11:30 AM
To: Long, Jeffrey P.
Cc: [email protected]
Subject: Re: [USRP-users] Vivado 2014.4 constraint bug
Hi Jeff,
You have two options. You can create you own xdc file and add it to the
TOP_SRCS variable in usrp3/top/x300/Makefile.x300.inc. Or, you can place your
custom constraint in usrp3/top/x300/x300.xdc.
Jonathon
On Fri, Apr 29, 2016 at 8:19 AM, Long, Jeffrey P. via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
I am doing some custom FPGA development using the maint branch so I am stuck
with Vivado 2014.4. Evidently there is a known bug:
ERROR: [Shape Builder 18-138] during place_design in Vivado 2014.4
http://www.xilinx.com/support/answers/63784.html
Of course this is fixed in more modern versions of Vivado but their work around
is to apply the constraint yourself and not allow the tool to do it
erroneously. Can you please advise on where I could drop this constraint in the
Ettus build scripts?
ERROR: [Shape Builder 18-138] Cannot obey LUTNM/HLUTNM constraint for instances
x300_core/radio0/cust_rx.myrx_proc/rx_wfrm_core_inst/clk_recovery_inst_6/correlator_inst/tap[36].mult_arr[36][3]_i_2
and
x300_core/radio0/cust_rx.myrx_proc/rx_wfrm_core_inst/clk_recovery_inst_6/correlator_inst/tap[36].mult_arr[36][3]_i_5.
Reason: for bel A5LUT Element SLICE_X2Y0.A6LUT is not routable as there are 6
input pins and A6 cannot be used because of A5LUT usage..
Thanks
Jeff Long
_______________________________________________
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/c4b6770e/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 30
******************************************
