Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: UnsatisfiedLinkError: no jniDeviceAddress in
java.library.path (jj08)
2. Re: UnsatisfiedLinkError: no jniDeviceAddress in
java.library.path (jj08)
3. Re: B210: 20db difference between RX2 antenna on A:A and A:B
(Patrick Sathyanathan)
4. Re: B210: 20db difference between RX2 antenna on A:A and A:B
(Michael West)
5. Re: B210: 20db difference between RX2 antenna on A:A and A:B
(Michael West)
6. Re: B210: 20db difference between RX2 antenna on A:A and A:B
(Patrick Sathyanathan)
7. Using X310 as monostatic pulsed radar (Rob Kossler)
8. Re: Using X310 as monostatic pulsed radar (Ian Buckley)
9. Thunderbolt? 3 on Laptop to 10 Gigabit Ethernet (Zhihong Luo)
10. Re: B210: 20db difference between RX2 antenna on A:A and A:B
(Michael West)
11. Re: B210: 20db difference between RX2 antenna on A:A and A:B
(Ian Buckley)
12. Re: Thunderbolt? 3 on Laptop to 10 Gigabit Ethernet
(Claudio Cicconetti)
13. transmit the recieved data with rfnoc (Ekko)
14. Re: transmit the recieved data with rfnoc (Jonathon Pendlum)
15. make phase_inc dynamic in NCO part (mohammed aly)
16. RFNoC: RuntimeError: On node 0/CostasLoop_0, output port 0 is
already connected (Jason Matusiak)
17. Re: Using X310 as monostatic pulsed radar ([email protected])
18. Re: Using X310 as monostatic pulsed radar (Rob Kossler)
19. Customize FPGA on B2xx (hossein talaiee)
20. Re: Using X310 as monostatic pulsed radar (Marcus M?ller)
21. Re: RFNoC: RuntimeError: On node 0/CostasLoop_0, output port
0 is already connected (Sylvain Munaut)
22. uhd_find_devices causes no devices found or packet loss after
connecting mimo cable (avinash kalyanaraman)
23. Re: Customize FPGA on B2xx (Marcus D. Leech)
24. Re: uhd_find_devices causes no devices found or packet loss
after connecting mimo cable (Marcus D. Leech)
----------------------------------------------------------------------
Message: 1
Date: Wed, 04 May 2016 10:39:10 -0700
From: "jj08" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] UnsatisfiedLinkError: no jniDeviceAddress in
java.library.path
Message-ID: <1077431791000000009736706@www>
Content-Type: text/plain; charset="utf-8"
Hi Markus,
Thank you for the input.
Yes, I have realized that I need to install (build may be the right word) the
uhd-java. In fact, I have already started the process and now struggling to
configure Maven.
(1) Downloaded latest Maven and unzipped in C drive, put c:\mvn_dir\bin in
system path (to test if Maven is working or not, I typed "mvn
-version", and found it is working ok)
(2) Went to Visual Studio's developer command prompt (that's where I can have
access to C++ runtime libraries,
(3) cd to the folder where I have the uhd-java files (downloaded and unzipped
at c:\uhd-java)
(4) entered command "mvn install" as the author mentions.
(5) Got two errors as follows. I don't know how to specify the location of the
header files of uhd. (the uhd libraries, header files, etc, are under c:\uhd)
//----------------------
C:\uhd-java-master>mvn install
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building uhd-java 0.3.1
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-dependency-plugin:2.8:properties (default) @ uhd-java ---
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ uhd-java
-
--
[WARNING] Using platform encoding (MS932 actually) to copy filtered resources,
i
.e. build is platform dependent!
[INFO] skip non existing resourceDirectory
C:\uhd-java-master\src\main\resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ uhd-java ---
[INFO] Changes detected - recompiling the module!
[WARNING] File encoding has not been set, using platform encoding MS932, i.e.
bu
ild is platform dependent!
[INFO] Compiling 22 source files to C:\uhd-java-master\target\classes
[INFO]
[INFO] --- exec-maven-plugin:1.3.2:exec (build jni) @ uhd-java ---
Generating C:\uhd-java-master\target\classes\jniDevice.cpp
Compiling C:\uhd-java-master\target\classes\jniDevice.dll
cl /IC:\Java\jdk1.8.0_91\include /IC:\Java\jdk1.8.0_91\include\win32
C:\uhd-java
-master\target\classes\jniDevice.cpp /W3 /Oi /O2 /EHsc /Gy /GL /MD /LD /link
/OU
T:C:\uhd-java-master\target\classes\jniDevice.dll uhd.lib
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23918 for x86
Copyright (C) Microsoft Corporation. All rights reserved.
jniDevice.cpp
C:\uhd-java-master\target\classes\jniDevice.cpp(63): fatal error C1083: Cannot
o
pen include file: 'uhd/device.hpp': No such file or directory
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4.340 s
[INFO] Finished at: 2016-05-05T01:59:36+09:00
[INFO] Final Memory: 18M/196M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.3.2:exec
(b
uild jni) on project uhd-java: Command execution failed. Process exited with
an error: 2 (Exit value: 2) -> [Help 1]
//-----------------------------------------
(6) I copied the uhd folder that has all the uhd deader files to
c:\uhd-java-master, but still the Maven does not find the header file.
I suspect, I need to tell the location of the header file inside the pom.xml
file.
I will google and see what I can find out.
In the meantime, if any reader has some knowledge about it, I would be
spending less time understanding Maven and more time writing Java programa to
access the USRP device.
Cheers,
jj
--From: [email protected]
--To: [email protected]
--Date: 5/2/2016 10:56:29 AM
--Subject: Re: [USRP-users] UnsatisfiedLinkError: no jniDeviceAddress in
java.library.path
Hi jj08,
I really don't want to disappoint you, but: I'm pretty certain that you should
first follow the path the author recommends to install uhd-java. I (and pretty
certainly most of the others on here) don't really have that much experience
doing Java development – you really might be on your own on this one. I
don't really know a typical Eclipse work flow, but I'd imagine it'd be right to
build uhd-java separately from your own project (probably without Eclipse for
the time being), install it, and declare the result as library dependency of
your project. However – I don't have a clue how to do the latter in
Eclipse / JDT.
Best regards, Marcus On 02.05.2016 04:37, jj08 via USRP-users wrote:
Nope. Not so fast.
I connected my pc to the USRP this morning and ran
"uhd_find_devices". Works fine.
//---------------------------------------------------
C:\Users\User>uhd_find_devices
Win32; Microsoft Visual C++ version 14.0; Boost_105800; UHD_003.009.003-release
--------------------------------------------------
-- UHD Device 0
--------------------------------------------------
Device Address:
type: usrp2
addr: 192.168.10.2
name: sn014 serial: XXXX
//---------------------------------------------------------
I started Eclipse and tried to run the JUnit test file (DeviceAddressTest.java
in the org.anhonesteffort.uhd.types package), but got the same
UnsatisfiedLinkError: no jniDeviceAddress in java.library.path. The uhd-jave
creator says "mvn install". I have no experience with Maven and if
Eclipse can do the task, I want to do the Eclipse way. So the question is
that how to configure uhd-Java for Eclipse. I created a project for uhd-Java
in Eclipse, downloaded the src
(https://github.com/rhodey/uhd-java/tree/master/src) and placed them in
{project foler}/src folder. I also downloaded JavaCPP.jar and added that jar to
the project. Since Eclipse is not complaining (uhd-Java project does not
have any red [X] marks), the reference requirements should have been met,
right? Still no cigar.
--From: [email protected]
--To: [email protected]
--Date: 5/1/2016 11:55:23 AM --Subject: Re: [USRP-users] UnsatisfiedLinkError:
no jniDeviceAddress in java.library.path I just read that in the README.md
file of the uhd-java project (https://github.com/rhodey/uhd-java), the author
has written (under Test Configuration): "uhd-java contains integration
tests that must be run on your actual USRP hardware to verify proper
functionality of the library" Could it be that? I will find out tomorrow
as I go back to work. So far I had been testing this without connecting to the
hardware. Cheers.
--From: [email protected]
--To: [email protected]
--Date: 5/1/2016 10:35:45 AM --Subject: Re: [USRP-users] UnsatisfiedLinkError:
no jniDeviceAddress in java.library.path
Hi All,
Ref: https://github.com/bytedeco/javacpp
("The missing bridge between Java and native C++ libraries")...
From the documentation:
"To implement native methods, JavaCPP generates appropriate code for JNI,
and passes it to the C++ compiler to build a native library. At no point do we
need to get our hands dirty with JNI, makefiles, or other native tools..."
For the perceptine, may be there is the clue.
Inside the source, I found that a library (dll) name is created by prefixing
"jni" to the calling class and adding dll suffix.
(org.bytedeco.javacpp.ClassProperties file, line 181)
Yes, as Martin Braun noted before, it is Java/Eclipse issue rather than usrp
issue.
I suspect I am not telling what resources ("appropriate code for
JNI") take from where and pass them to where (where the C++ compiler
resides).
Then may be I need to find out where "jniDeviceAddress.dll" is
created, and I can set that directory as the "native library
location".
I found that in Eclipse, the native library location can be configured in
project properties -> java buildpath -> libraries -> JRE System libraries ->
native library location
As for C++ compilation, I do have Visual Studio 2015 (VC++ included) Community
Edition installed. I don't know how to tell Eclipse that.
When I go through Start -> all programs -> VS 2015 -> VS Tools -> Developer
Command Prompt for VS 2015, I get a command prompt (DOS shell) and I can
compile and run C++ program, so I do have C++ environment.
Someone with insight and/or experience in Java/Eclipe/C++, please give some
pointers.
Thanks,
jj
--From: [email protected]
--To: [email protected]
--Date: 4/28/2016 11:53:03 AM --Subject: Re: [USRP-users]
UnsatisfiedLinkError: no jniDeviceAddress in java.library.path
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.
-------------------------
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.
-------------------------
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/20160504/dab9ee76/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 04 May 2016 11:09:30 -0700
From: "jj08" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] UnsatisfiedLinkError: no jniDeviceAddress in
java.library.path
Message-ID: <1077454661000000009736706@www>
Content-Type: text/plain; charset="utf-8"
Got your name (spelling) wrong ..
There is a section to add dependencies in the pom.xml file.
Since my uhd indude header files are in C:\UHD\include\uhd, I contrived this
piece, but was rejected outright.
//----------------------------
<dependency>
<groupId>org.anhonesteffort.uhd</groupId>
<artifactId>uhd-java</artifactId>
<version>0.3.1</version>
<url>file://$C:\UHD\include\uhd</url>
</dependency>
//------------------------------
Search continues ....
--From: [email protected]
--To: [email protected]
--Date: 5/4/2016 10:40:54 AM --Subject: Re: [USRP-users] UnsatisfiedLinkError:
no jniDeviceAddress in java.library.path
Hi Markus,
Thank you for the input.
Yes, I have realized that I need to install (build may be the right word) the
uhd-java. In fact, I have already started the process and now struggling to
configure Maven.
(1) Downloaded latest Maven and unzipped in C drive, put c:\mvn_dir\bin in
system path (to test if Maven is working or not, I typed "mvn
-version", and found it is working ok)
(2) Went to Visual Studio's developer command prompt (that's where I can have
access to C++ runtime libraries,
(3) cd to the folder where I have the uhd-java files (downloaded and unzipped
at c:\uhd-java)
(4) entered command "mvn install" as the author mentions.
(5) Got two errors as follows. I don't know how to specify the location of the
header files of uhd. (the uhd libraries, header files, etc, are under c:\uhd)
//----------------------
C:\uhd-java-master>mvn install
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building uhd-java 0.3.1
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-dependency-plugin:2.8:properties (default) @ uhd-java ---
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ uhd-java
-
--
[WARNING] Using platform encoding (MS932 actually) to copy filtered resources,
i
.e. build is platform dependent!
[INFO] skip non existing resourceDirectory
C:\uhd-java-master\src\main\resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ uhd-java ---
[INFO] Changes detected - recompiling the module!
[WARNING] File encoding has not been set, using platform encoding MS932, i.e.
bu
ild is platform dependent!
[INFO] Compiling 22 source files to C:\uhd-java-master\target\classes
[INFO]
[INFO] --- exec-maven-plugin:1.3.2:exec (build jni) @ uhd-java ---
Generating C:\uhd-java-master\target\classes\jniDevice.cpp
Compiling C:\uhd-java-master\target\classes\jniDevice.dll
cl /IC:\Java\jdk1.8.0_91\include /IC:\Java\jdk1.8.0_91\include\win32
C:\uhd-java
-master\target\classes\jniDevice.cpp /W3 /Oi /O2 /EHsc /Gy /GL /MD /LD /link
/OU
T:C:\uhd-java-master\target\classes\jniDevice.dll uhd.lib
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23918 for x86
Copyright (C) Microsoft Corporation. All rights reserved.
jniDevice.cpp
C:\uhd-java-master\target\classes\jniDevice.cpp(63): fatal error C1083: Cannot
o
pen include file: 'uhd/device.hpp': No such file or directory
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4.340 s
[INFO] Finished at: 2016-05-05T01:59:36+09:00
[INFO] Final Memory: 18M/196M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.3.2:exec
(b
uild jni) on project uhd-java: Command execution failed. Process exited with
an error: 2 (Exit value: 2) -> [Help 1]
//-----------------------------------------
(6) I copied the uhd folder that has all the uhd deader files to
c:\uhd-java-master, but still the Maven does not find the header file.
I suspect, I need to tell the location of the header file inside the pom.xml
file.
I will google and see what I can find out.
In the meantime, if any reader has some knowledge about it, I would be
spending less time understanding Maven and more time writing Java programa to
access the USRP device.
Cheers,
jj
--From: [email protected]
--To: [email protected]
--Date: 5/2/2016 10:56:29 AM
--Subject: Re: [USRP-users] UnsatisfiedLinkError: no jniDeviceAddress in
java.library.path
Hi jj08,
I really don't want to disappoint you, but: I'm pretty certain that you should
first follow the path the author recommends to install uhd-java. I (and pretty
certainly most of the others on here) don't really have that much experience
doing Java development – you really might be on your own on this one. I
don't really know a typical Eclipse work flow, but I'd imagine it'd be right to
build uhd-java separately from your own project (probably without Eclipse for
the time being), install it, and declare the result as library dependency of
your project. However – I don't have a clue how to do the latter in
Eclipse / JDT.
Best regards, Marcus On 02.05.2016 04:37, jj08 via USRP-users wrote:
Nope. Not so fast.
I connected my pc to the USRP this morning and ran
"uhd_find_devices". Works fine.
//---------------------------------------------------
C:\Users\User>uhd_find_devices
Win32; Microsoft Visual C++ version 14.0; Boost_105800; UHD_003.009.003-release
--------------------------------------------------
-- UHD Device 0
--------------------------------------------------
Device Address:
type: usrp2
addr: 192.168.10.2
name: sn014 serial: XXXX
//---------------------------------------------------------
I started Eclipse and tried to run the JUnit test file (DeviceAddressTest.java
in the org.anhonesteffort.uhd.types package), but got the same
UnsatisfiedLinkError: no jniDeviceAddress in java.library.path. The uhd-jave
creator says "mvn install". I have no experience with Maven and if
Eclipse can do the task, I want to do the Eclipse way. So the question is
that how to configure uhd-Java for Eclipse. I created a project for uhd-Java
in Eclipse, downloaded the src
(https://github.com/rhodey/uhd-java/tree/master/src) and placed them in
{project foler}/src folder. I also downloaded JavaCPP.jar and added that jar to
the project. Since Eclipse is not complaining (uhd-Java project does not
have any red [X] marks), the reference requirements should have been met,
right? Still no cigar.
--From: [email protected]
--To: [email protected]
--Date: 5/1/2016 11:55:23 AM --Subject: Re: [USRP-users] UnsatisfiedLinkError:
no jniDeviceAddress in java.library.path I just read that in the README.md
file of the uhd-java project (https://github.com/rhodey/uhd-java), the author
has written (under Test Configuration): "uhd-java contains integration
tests that must be run on your actual USRP hardware to verify proper
functionality of the library" Could it be that? I will find out tomorrow
as I go back to work. So far I had been testing this without connecting to the
hardware. Cheers.
--From: [email protected]
--To: [email protected]
--Date: 5/1/2016 10:35:45 AM --Subject: Re: [USRP-users] UnsatisfiedLinkError:
no jniDeviceAddress in java.library.path
Hi All,
Ref: https://github.com/bytedeco/javacpp
("The missing bridge between Java and native C++ libraries")...
From the documentation:
"To implement native methods, JavaCPP generates appropriate code for JNI,
and passes it to the C++ compiler to build a native library. At no point do we
need to get our hands dirty with JNI, makefiles, or other native tools..."
For the perceptine, may be there is the clue.
Inside the source, I found that a library (dll) name is created by prefixing
"jni" to the calling class and adding dll suffix.
(org.bytedeco.javacpp.ClassProperties file, line 181)
Yes, as Martin Braun noted before, it is Java/Eclipse issue rather than usrp
issue.
I suspect I am not telling what resources ("appropriate code for
JNI") take from where and pass them to where (where the C++ compiler
resides).
Then may be I need to find out where "jniDeviceAddress.dll" is
created, and I can set that directory as the "native library
location".
I found that in Eclipse, the native library location can be configured in
project properties -> java buildpath -> libraries -> JRE System libraries ->
native library location
As for C++ compilation, I do have Visual Studio 2015 (VC++ included) Community
Edition installed. I don't know how to tell Eclipse that.
When I go through Start -> all programs -> VS 2015 -> VS Tools -> Developer
Command Prompt for VS 2015, I get a command prompt (DOS shell) and I can
compile and run C++ program, so I do have C++ environment.
Someone with insight and/or experience in Java/Eclipe/C++, please give some
pointers.
Thanks,
jj
--From: [email protected]
--To: [email protected]
--Date: 4/28/2016 11:53:03 AM --Subject: Re: [USRP-users]
UnsatisfiedLinkError: no jniDeviceAddress in java.library.path
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.
-------------------------
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.
-------------------------
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.
-------------------------
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/20160504/7d4476df/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 4 May 2016 15:40:15 -0700
From: Patrick Sathyanathan <[email protected]>
To: "Ralph A. Schmid, dk5ras" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] B210: 20db difference between RX2 antenna on
A:A and A:B
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Thanks, Ralph. That's an excellent idea. I don't need a combined RX and TX path
either so I will just bridge it. Now if only I could get the switch off the
board...
--Patrick
From: [email protected]
To: [email protected]; [email protected]
Subject: RE: [USRP-users] B210: 20db difference between RX2 antenna on A:A and
A:B
Date: Wed, 4 May 2016 15:25:42 +0200
Hi, I had it replaced once by a professional, and when it blew again, I just
removed it with a hot air gun and bridged it. For my use case I anyway need
separated RX and TX paths.
Ralph. From: Patrick Sathyanathan [mailto:[email protected]]
Sent: Wednesday, May 4, 2016 10:19 AM
To: Ralph A. Schmid, dk5ras; [email protected]
Subject: RE: [USRP-users] B210: 20db difference between RX2 antenna on A:A and
A:B Hi Ralph,
I see the same problem with the TX/RX antenna on A:B. So is this a symptom of
both the switches on A:B getting damaged ?
Also, I tried using my hot air gun to desolder the switch but have been
unsuccessful so far. All I managed to do was blow off some of the neighboring
SMD capacitors. It appears that melting the solder on the ground pad below the
chip is not easy.
How did you replace the switches ?
Thanks,
--Patrick
> From: [email protected]
> To: [email protected]; [email protected]
> Subject: RE: [USRP-users] B210: 20db difference between RX2 antenna on A:A
> and A:B
> Date: Wed, 6 Apr 2016 11:29:11 +0200
>
> The TX/RX switch is very sensitive to ESD :( I already killed two of them
> and don't know why...
>
> Ralph.
>
> >-----Original Message-----
> >From: USRP-users [mailto:[email protected]] On Behalf Of
> >Patrick Sathyanathan via USRP-users
> >Sent: Wednesday, April 6, 2016 11:22
> >To: [email protected]
> >Subject: [USRP-users] B210: 20db difference between RX2 antenna on A:A and
> >A:B
> >
> >Hi,
> >
> >I have been using my B210 for about a year now with GNUradio and a scanner
> >software that I wrote using UHD and other hardware libraries. Initially I
> used
> >cheap Nagoya telescopic antennas for both receive channels. When I ran
> uhd_fft
> >to observe a known local signal (I think a local HDTV channel) the spectrum
> was
> >more or less identical if I used the same parameters. Then I purchased a
> super M
> >ultra base antenna (25MHz-6GHz from mapantenna.com) which is a physically
> >larger wide band discone antenna and connected it to subdev A:B. For a
> while
> >uhd_fft and my own scanner software showed much higher signal strengths
> with
> >this. However, a few weeks earlier it started reporting lower signal
> strength even
> >for known local signals. And when I connected the Nagoya to A:B and ran
> uhd_fft
> >for the local TV signal it shows a spectrum whose shape looks correct but
> is 20db
> >lower than A:A for the same parameters.
> >
> >Could some transmission have overloaded the A:B receive with the larger
> >antenna and damaged some component ? If so what could be damaged and how
> >can I get it fixed ?
> >
> >Thanks for any help,
> >
> >--Patrick
> >
> >
> >_______________________________________________
> >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/20160504/9e664721/attachment-0001.html>
------------------------------
Message: 4
Date: Wed, 4 May 2016 16:01:27 -0700
From: Michael West <[email protected]>
To: Patrick Sathyanathan <[email protected]>
Cc: "Ralph A. Schmid, dk5ras" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] B210: 20db difference between RX2 antenna on
A:A and A:B
Message-ID:
<CAM4xKrqyEi9GL1tapoBSOqJKHc188g93xwYB7UExfOpto=h...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
There is no need to remove the RF switches to bypass them. There are
already bypass traces on the board.
On the A side:
1) Remove C834
2) Move C852 and C855 to the bypass path for TX
3) Move C854 and C856 to the bypass path for RX
On the B side:
1) Remove C809
2) Move C814 and C810 to the bypass path for TX
3) Move C851 and C812 to the bypass path for RX
Regards,
Michael
On Wed, May 4, 2016 at 3:40 PM, Patrick Sathyanathan via USRP-users <
[email protected]> wrote:
> Thanks, Ralph. That's an excellent idea. I don't need a combined RX and TX
> path either so I will just bridge it. Now if only I could get the switch
> off the board...
>
> --Patrick
>
> ------------------------------
> From: [email protected]
> To: [email protected]; [email protected]
> Subject: RE: [USRP-users] B210: 20db difference between RX2 antenna on A:A
> and A:B
> Date: Wed, 4 May 2016 15:25:42 +0200
>
>
> Hi,
>
>
>
> I had it replaced once by a professional, and when it blew again, I just
> removed it with a hot air gun and bridged it. For my use case I anyway need
> separated RX and TX paths.
>
>
> Ralph.
>
>
>
> *From:* Patrick Sathyanathan [mailto:[email protected]]
> *Sent:* Wednesday, May 4, 2016 10:19 AM
> *To:* Ralph A. Schmid, dk5ras; [email protected]
> *Subject:* RE: [USRP-users] B210: 20db difference between RX2 antenna on
> A:A and A:B
>
>
>
> Hi Ralph,
>
> I see the same problem with the TX/RX antenna on A:B. So is this a symptom
> of both the switches on A:B getting damaged ?
>
> Also, I tried using my hot air gun to desolder the switch but have been
> unsuccessful so far. All I managed to do was blow off some of the
> neighboring SMD capacitors. It appears that melting the solder on the
> ground pad below the chip is not easy.
>
> How did you replace the switches ?
>
> Thanks,
>
> --Patrick
>
>
> > From: [email protected]
> > To: [email protected]; [email protected]
> > Subject: RE: [USRP-users] B210: 20db difference between RX2 antenna on
> A:A and A:B
> > Date: Wed, 6 Apr 2016 11:29:11 +0200
> >
> > The TX/RX switch is very sensitive to ESD :( I already killed two of them
> > and don't know why...
> >
> > Ralph.
> >
> > >-----Original Message-----
> > >From: USRP-users [mailto:[email protected]
> <[email protected]>] On Behalf Of
> > >Patrick Sathyanathan via USRP-users
> > >Sent: Wednesday, April 6, 2016 11:22
> > >To: [email protected]
> > >Subject: [USRP-users] B210: 20db difference between RX2 antenna on A:A
> and
> > >A:B
> > >
> > >Hi,
> > >
> > >I have been using my B210 for about a year now with GNUradio and a
> scanner
> > >software that I wrote using UHD and other hardware libraries. Initially
> I
> > used
> > >cheap Nagoya telescopic antennas for both receive channels. When I ran
> > uhd_fft
> > >to observe a known local signal (I think a local HDTV channel) the
> spectrum
> > was
> > >more or less identical if I used the same parameters. Then I purchased a
> > super M
> > >ultra base antenna (25MHz-6GHz from mapantenna.com) which is a
> physically
> > >larger wide band discone antenna and connected it to subdev A:B. For a
> > while
> > >uhd_fft and my own scanner software showed much higher signal strengths
> > with
> > >this. However, a few weeks earlier it started reporting lower signal
> > strength even
> > >for known local signals. And when I connected the Nagoya to A:B and ran
> > uhd_fft
> > >for the local TV signal it shows a spectrum whose shape looks correct
> but
> > is 20db
> > >lower than A:A for the same parameters.
> > >
> > >Could some transmission have overloaded the A:B receive with the larger
> > >antenna and damaged some component ? If so what could be damaged and how
> > >can I get it fixed ?
> > >
> > >Thanks for any help,
> > >
> > >--Patrick
> > >
> > >
> > >_______________________________________________
> > >USRP-users mailing list
> > >[email protected]
> > >http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160504/c8de2914/attachment-0001.html>
------------------------------
Message: 5
Date: Wed, 4 May 2016 16:14:14 -0700
From: Michael West <[email protected]>
To: Patrick Sathyanathan <[email protected]>
Cc: "Ralph A. Schmid, dk5ras" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] B210: 20db difference between RX2 antenna on
A:A and A:B
Message-ID:
<cam4xkrrj-vt_3cckd8atpyud7xpnpqd7af-q0pl-z+fm1zq...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Small correction. There is no need to remove C834 or C809. Just move the
other capacitors to the respective bypass paths.
Regards,
Michael
On Wed, May 4, 2016 at 4:01 PM, Michael West <[email protected]> wrote:
> There is no need to remove the RF switches to bypass them. There are
> already bypass traces on the board.
>
> On the A side:
> 1) Remove C834
> 2) Move C852 and C855 to the bypass path for TX
> 3) Move C854 and C856 to the bypass path for RX
>
> On the B side:
> 1) Remove C809
> 2) Move C814 and C810 to the bypass path for TX
> 3) Move C851 and C812 to the bypass path for RX
>
> Regards,
> Michael
>
> On Wed, May 4, 2016 at 3:40 PM, Patrick Sathyanathan via USRP-users <
> [email protected]> wrote:
>
>> Thanks, Ralph. That's an excellent idea. I don't need a combined RX and
>> TX path either so I will just bridge it. Now if only I could get the switch
>> off the board...
>>
>> --Patrick
>>
>> ------------------------------
>> From: [email protected]
>> To: [email protected]; [email protected]
>> Subject: RE: [USRP-users] B210: 20db difference between RX2 antenna on
>> A:A and A:B
>> Date: Wed, 4 May 2016 15:25:42 +0200
>>
>>
>> Hi,
>>
>>
>>
>> I had it replaced once by a professional, and when it blew again, I just
>> removed it with a hot air gun and bridged it. For my use case I anyway need
>> separated RX and TX paths.
>>
>>
>> Ralph.
>>
>>
>>
>> *From:* Patrick Sathyanathan [mailto:[email protected]]
>> *Sent:* Wednesday, May 4, 2016 10:19 AM
>> *To:* Ralph A. Schmid, dk5ras; [email protected]
>> *Subject:* RE: [USRP-users] B210: 20db difference between RX2 antenna on
>> A:A and A:B
>>
>>
>>
>> Hi Ralph,
>>
>> I see the same problem with the TX/RX antenna on A:B. So is this a
>> symptom of both the switches on A:B getting damaged ?
>>
>> Also, I tried using my hot air gun to desolder the switch but have been
>> unsuccessful so far. All I managed to do was blow off some of the
>> neighboring SMD capacitors. It appears that melting the solder on the
>> ground pad below the chip is not easy.
>>
>> How did you replace the switches ?
>>
>> Thanks,
>>
>> --Patrick
>>
>>
>> > From: [email protected]
>> > To: [email protected]; [email protected]
>> > Subject: RE: [USRP-users] B210: 20db difference between RX2 antenna on
>> A:A and A:B
>> > Date: Wed, 6 Apr 2016 11:29:11 +0200
>> >
>> > The TX/RX switch is very sensitive to ESD :( I already killed two of
>> them
>> > and don't know why...
>> >
>> > Ralph.
>> >
>> > >-----Original Message-----
>> > >From: USRP-users [mailto:[email protected]
>> <[email protected]>] On Behalf Of
>> > >Patrick Sathyanathan via USRP-users
>> > >Sent: Wednesday, April 6, 2016 11:22
>> > >To: [email protected]
>> > >Subject: [USRP-users] B210: 20db difference between RX2 antenna on A:A
>> and
>> > >A:B
>> > >
>> > >Hi,
>> > >
>> > >I have been using my B210 for about a year now with GNUradio and a
>> scanner
>> > >software that I wrote using UHD and other hardware libraries.
>> Initially I
>> > used
>> > >cheap Nagoya telescopic antennas for both receive channels. When I ran
>> > uhd_fft
>> > >to observe a known local signal (I think a local HDTV channel) the
>> spectrum
>> > was
>> > >more or less identical if I used the same parameters. Then I purchased
>> a
>> > super M
>> > >ultra base antenna (25MHz-6GHz from mapantenna.com) which is a
>> physically
>> > >larger wide band discone antenna and connected it to subdev A:B. For a
>> > while
>> > >uhd_fft and my own scanner software showed much higher signal strengths
>> > with
>> > >this. However, a few weeks earlier it started reporting lower signal
>> > strength even
>> > >for known local signals. And when I connected the Nagoya to A:B and ran
>> > uhd_fft
>> > >for the local TV signal it shows a spectrum whose shape looks correct
>> but
>> > is 20db
>> > >lower than A:A for the same parameters.
>> > >
>> > >Could some transmission have overloaded the A:B receive with the larger
>> > >antenna and damaged some component ? If so what could be damaged and
>> how
>> > >can I get it fixed ?
>> > >
>> > >Thanks for any help,
>> > >
>> > >--Patrick
>> > >
>> > >
>> > >_______________________________________________
>> > >USRP-users mailing list
>> > >[email protected]
>> > >http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> >
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160504/b08d0559/attachment-0001.html>
------------------------------
Message: 6
Date: Wed, 4 May 2016 17:08:36 -0700
From: Patrick Sathyanathan <[email protected]>
To: Michael West <[email protected]>
Cc: "Ralph A. Schmid, dk5ras" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] B210: 20db difference between RX2 antenna on
A:A and A:B
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Shouldn't both A and B be symmetric ? Your lists below do not match for A and B.
Assuming B is correct:
C814/C810 on B:TX match C826/C832 on A:TX
C851/C812 on B:RX match C854/C833 on A:RX
Assuming A is correct:
C852/C855 on A:TX match C849/C847 on B:TX
C854/C856 on A:RX match C848/C851 on B:RX
Also, C851/C848/... are labeled as "DNP" in the schematic. What does this mean ?
Thanks,
--Patrick
Date: Wed, 4 May 2016 16:14:14 -0700
Subject: Re: [USRP-users] B210: 20db difference between RX2 antenna on A:A and
A:B
From: [email protected]
To: [email protected]
CC: [email protected]; [email protected]
Small correction. There is no need to remove C834 or C809. Just move the
other capacitors to the respective bypass paths.
Regards,
Michael
On Wed, May 4, 2016 at 4:01 PM, Michael West <[email protected]> wrote:
There is no need to remove the RF switches to bypass them. There are already
bypass traces on the board.
On the A side:
1) Remove C834
2) Move C852 and C855 to the bypass path for TX
3) Move C854 and C856 to the bypass path for RX
On the B side:
1) Remove C809
2) Move C814 and C810 to the bypass path for TX
3) Move C851 and C812 to the bypass path for RX
Regards,
Michael
On Wed, May 4, 2016 at 3:40 PM, Patrick Sathyanathan via USRP-users
<[email protected]> wrote:
Thanks, Ralph. That's an excellent idea. I don't need a combined RX and TX path
either so I will just bridge it. Now if only I could get the switch off the
board...
--Patrick
From: [email protected]
To: [email protected]; [email protected]
Subject: RE: [USRP-users] B210: 20db difference between RX2 antenna on A:A and
A:B
Date: Wed, 4 May 2016 15:25:42 +0200
Hi,
I had it replaced once by a professional, and when it blew again, I just
removed it with a hot air gun and bridged it. For my use case I anyway need
separated RX and TX paths.
Ralph.
From: Patrick Sathyanathan [mailto:[email protected]]
Sent: Wednesday, May 4, 2016 10:19 AM
To: Ralph A. Schmid, dk5ras; [email protected]
Subject: RE: [USRP-users] B210: 20db difference between RX2 antenna on A:A and
A:B
Hi Ralph,
I see the same problem with the TX/RX antenna on A:B. So is this a symptom of
both the switches on A:B getting damaged ?
Also, I tried using my hot air gun to desolder the switch but have been
unsuccessful so far. All I managed to do was blow off some of the neighboring
SMD capacitors. It appears that melting the solder on the ground pad below the
chip is not easy.
How did you replace the switches ?
Thanks,
--Patrick
> From: [email protected]
> To: [email protected]; [email protected]
> Subject: RE: [USRP-users] B210: 20db difference between RX2 antenna on A:A
> and A:B
> Date: Wed, 6 Apr 2016 11:29:11 +0200
>
> The TX/RX switch is very sensitive to ESD :( I already killed two of them
> and don't know why...
>
> Ralph.
>
> >-----Original Message-----
> >From: USRP-users [mailto:[email protected]] On Behalf Of
> >Patrick Sathyanathan via USRP-users
> >Sent: Wednesday, April 6, 2016 11:22
> >To: [email protected]
> >Subject: [USRP-users] B210: 20db difference between RX2 antenna on A:A and
> >A:B
> >
> >Hi,
> >
> >I have been using my B210 for about a year now with GNUradio and a scanner
> >software that I wrote using UHD and other hardware libraries. Initially I
> used
> >cheap Nagoya telescopic antennas for both receive channels. When I ran
> uhd_fft
> >to observe a known local signal (I think a local HDTV channel) the spectrum
> was
> >more or less identical if I used the same parameters. Then I purchased a
> super M
> >ultra base antenna (25MHz-6GHz from mapantenna.com) which is a physically
> >larger wide band discone antenna and connected it to subdev A:B. For a
> while
> >uhd_fft and my own scanner software showed much higher signal strengths
> with
> >this. However, a few weeks earlier it started reporting lower signal
> strength even
> >for known local signals. And when I connected the Nagoya to A:B and ran
> uhd_fft
> >for the local TV signal it shows a spectrum whose shape looks correct but
> is 20db
> >lower than A:A for the same parameters.
> >
> >Could some transmission have overloaded the A:B receive with the larger
> >antenna and damaged some component ? If so what could be damaged and how
> >can I get it fixed ?
> >
> >Thanks for any help,
> >
> >--Patrick
> >
> >
> >_______________________________________________
> >USRP-users mailing list
> >[email protected]
> >http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160504/6c05d108/attachment-0001.html>
------------------------------
Message: 7
Date: Wed, 4 May 2016 21:55:16 -0400
From: Rob Kossler <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Using X310 as monostatic pulsed radar
Message-ID:
<cab__htr5qhub+cbqm5smnnq2onthdb_jjefybdzcx+ji0ld...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I am investigating using the X310 (w/ UBX-160) as a monostatic pulsed CW
radar (single antenna shared between Tx and Rx). I am writing my own C++
application using UHD 3.9.2 under Ubuntu 14.04 LTS.
I hope to use a sample rate of 100 MS/s and transmit very short pulses
(perhaps only 4 non-zero values) at short repetition intervals (perhaps
~5us which equals 500 samples at this rate).
My idea was to use timed Tx bursts for the Tx pulses. I tried an
experiment using the tx_bursts example program to see if I could transmit
short pulses at short cycle times. I found that...
1) I needed a minimum of about 20 non-zero samples in order to see any
signal output (I think that this minimum is governed by the digital filters
in the FPGA based on this thread
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-November/011303.html
)
2) I ran into problems with Late errors for repetition intervals less than
about 10 us (I had to modify the example program to remove the synchronous
wait for the burst ACK in order to get these results)
I have several questions:
1) Is it wise to be considering timed bursts for my scenario? Or should I
plan to continuously stream the Tx with baseband zeros for my "off" periods?
2) Assuming timed bursts is appropriate
a) Is there a way to get around the filtering issues so that I can send
pulses shorter than 20 samples?
b) Is there a way to achieve repetition intervals shorter than 10 us? For
this question, it is worth noting that my PC is good enough to stream
continuously at this rate so you might expect that it could send bursts
(with less samples of course) at this rate. But, this does not appear to
be the case.
c) Given that this is a radar and that I want my Rx streamer to be ON for
the period that my Tx is OFF, I am wondering if I can just keep Rx
streaming continuously (even during the Tx Bursts). I realize that this
approach would cause the Rx streaming to be occurring even while the ATR
switch was in the Tx position, but this would be a simpler implementation
than having to coordinate the Rx and Tx streams such that one turns off
when the other turns on.
3) Assuming timed bursts is not appropriate
a) Could I run both Tx and Rx streamers continuously and modify the
behavior of the ATR switch such that it was in the Tx position only during
the sample times for which I know that the Tx stream contains non-zeros?
Or is this a bad (or dangerous) idea?
b) Or should I use an external TR switch such that I am using the USRP
Tx/Rx port for Tx and the Rx2 port for Rx? Of course, in this case I would
effectively be doing the same thing as I suggested above in (a) by
controlling the external TR switch to be in the Tx position only during the
non-zero portion of the Tx stream.
Sorry for the long post. Let me know if you have any suggestions.
Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160504/8f33a40b/attachment-0001.html>
------------------------------
Message: 8
Date: Wed, 4 May 2016 21:25:17 -0700
From: Ian Buckley <[email protected]>
To: Rob Kossler <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Using X310 as monostatic pulsed radar
Message-ID:
<CAM_0ocF9kfPSSx0x7she_PCdEcHqm+snQKMLw=g6m2vybil...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Rob, my off the cuff schwag at your idea..you already have my detailed
explanation of the way the TX works form the old thread:
The short pulses are very hard to do in S/W only. I've built entirely
custom images that discard pretty much all the default USRP design for
broadly analogous projects in the past. In your case the filtering can be
entirely discarded if you run your TX at 200Msps, but that probably isn't
the main problem. You also have the issue the radio state machine is
turning on and off RF components on the daughter board in response to
transition from an idle to active TX state. That isn't coordinated to this
level of precision in the design, nor do those components reach steady
state operating condition in such a short time. FWIW you could pre-fill
theTX buffer with quite a number of timed TX bursts before the initial
start time was reached unburdening your host form the TX side of things
I think if I were you I'd be looking at streaming continuously for both RX
and TX so that no nS level coordination is required in the switching of RF
circuits, You may have some residual Tx signal in "non-tx" (zero-filled)
periods due to real world DC offset/IQ imbalance/etc imperfections but
hopefully its of an order of magnitude that is much less than your received
signal. Hopefully your application allows the antennas to be arranged such
that there is good TX/RX isolation for the direct path.
You asked "Is it dangerous?". The daughter boards are all designed such
that the TX can never drive the RX directly *internal* to the board. If you
cable externally directly from TX/RX to RX2 you are entering the danger
zone. 2 adjacent omni antennas with no external PA will saturate the RX at
higher gains but not reach harmful levels of power in the sensitive LNA's.
if you were an adventurous FPGA design type then you might consider largely
ditching the TX radio design in the FPGA, and putting in its place
something very simple that repeatedly sends your pulse from a lookup table,
synchronized to the LSB's of the timestamp counter such that your RX
streams time metadata (which is derived from the same counter) would
unambiguously identify the associated range within the constraints of your
PRR.
-Ian
On Wed, May 4, 2016 at 6:55 PM, Rob Kossler via USRP-users <
[email protected]> wrote:
> Hi,
> I am investigating using the X310 (w/ UBX-160) as a monostatic pulsed CW
> radar (single antenna shared between Tx and Rx). I am writing my own C++
> application using UHD 3.9.2 under Ubuntu 14.04 LTS.
>
> I hope to use a sample rate of 100 MS/s and transmit very short pulses
> (perhaps only 4 non-zero values) at short repetition intervals (perhaps
> ~5us which equals 500 samples at this rate).
>
> My idea was to use timed Tx bursts for the Tx pulses. I tried an
> experiment using the tx_bursts example program to see if I could transmit
> short pulses at short cycle times. I found that...
> 1) I needed a minimum of about 20 non-zero samples in order to see any
> signal output (I think that this minimum is governed by the digital filters
> in the FPGA based on this thread
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-November/011303.html
> )
> 2) I ran into problems with Late errors for repetition intervals less than
> about 10 us (I had to modify the example program to remove the synchronous
> wait for the burst ACK in order to get these results)
>
> I have several questions:
>
> 1) Is it wise to be considering timed bursts for my scenario? Or should I
> plan to continuously stream the Tx with baseband zeros for my "off" periods?
>
> 2) Assuming timed bursts is appropriate
> a) Is there a way to get around the filtering issues so that I can send
> pulses shorter than 20 samples?
> b) Is there a way to achieve repetition intervals shorter than 10 us? For
> this question, it is worth noting that my PC is good enough to stream
> continuously at this rate so you might expect that it could send bursts
> (with less samples of course) at this rate. But, this does not appear to
> be the case.
> c) Given that this is a radar and that I want my Rx streamer to be ON for
> the period that my Tx is OFF, I am wondering if I can just keep Rx
> streaming continuously (even during the Tx Bursts). I realize that this
> approach would cause the Rx streaming to be occurring even while the ATR
> switch was in the Tx position, but this would be a simpler implementation
> than having to coordinate the Rx and Tx streams such that one turns off
> when the other turns on.
>
> 3) Assuming timed bursts is not appropriate
> a) Could I run both Tx and Rx streamers continuously and modify the
> behavior of the ATR switch such that it was in the Tx position only during
> the sample times for which I know that the Tx stream contains non-zeros?
> Or is this a bad (or dangerous) idea?
> b) Or should I use an external TR switch such that I am using the USRP
> Tx/Rx port for Tx and the Rx2 port for Rx? Of course, in this case I would
> effectively be doing the same thing as I suggested above in (a) by
> controlling the external TR switch to be in the Tx position only during the
> non-zero portion of the Tx stream.
>
> Sorry for the long post. Let me know if you have any suggestions.
>
> Rob
>
>
> _______________________________________________
> 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/20160504/02212918/attachment-0001.html>
------------------------------
Message: 9
Date: Thu, 5 May 2016 01:24:35 -0400
From: Zhihong Luo <[email protected]>
To: Zhihong Luo via USRP-users <[email protected]>
Subject: [USRP-users] Thunderbolt? 3 on Laptop to 10 Gigabit Ethernet
Message-ID:
<cah4wxlrwzq3nea1-oxal8y3re2702btkmrr1tkq0_of2gro...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
I am currently trying to set up 10 Gigabit Ethernet on laptop through a
Thunderbolt? 3 port. Thunderbolt? 3 supports up to 40Gbps, so that I
suppose it can be adapted to a 10 Gigabit Ethernet port (or PCI). But I am
not sure how to do it, and I didn't find any material on this yet.
Please let me know if you have any suggestions.
Thanks for any help,
Zhihong
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160505/1cc35b4f/attachment-0001.html>
------------------------------
Message: 10
Date: Wed, 4 May 2016 23:01:24 -0700
From: Michael West <[email protected]>
To: Patrick Sathyanathan <[email protected]>
Cc: "Ralph A. Schmid, dk5ras" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] B210: 20db difference between RX2 antenna on
A:A and A:B
Message-ID:
<CAM4xKrqhDYS-nofZ7HMrg-yaosB8bez0qriod=ivvwic0yk...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Patrick,
If you look at the board, you can see the bypass traces and the capacitors
that need to be rotated to bypass the switches.
C826 rotates 90 degrees to become C852
C832 rotates 90 degrees to become C855
C814 rotates 90 degrees to become C849
C810 rotates 90 degrees to become C847
C833 rotates 90 degrees to become C856
C829 rotates 90 degrees to become C854
C819 rotates 90 degrees to become C851
C812 rotates 90 degrees to become C848
Regards,
Michael
On Wed, May 4, 2016 at 5:08 PM, Patrick Sathyanathan <[email protected]>
wrote:
> Shouldn't both A and B be symmetric ? Your lists below do not match for A
> and B.
>
> Assuming B is correct:
> C814/C810 on B:TX match C826/C832 on A:TX
> C851/C812 on B:RX match C854/C833 on A:RX
>
> Assuming A is correct:
> C852/C855 on A:TX match C849/C847 on B:TX
> C854/C856 on A:RX match C848/C851 on B:RX
>
>
> Also, C851/C848/... are labeled as "DNP" in the schematic. What does this
> mean ?
>
> Thanks,
>
> --Patrick
>
> ------------------------------
> Date: Wed, 4 May 2016 16:14:14 -0700
> Subject: Re: [USRP-users] B210: 20db difference between RX2 antenna on A:A
> and A:B
> From: [email protected]
> To: [email protected]
> CC: [email protected]; [email protected]
>
>
> Small correction. There is no need to remove C834 or C809. Just move the
> other capacitors to the respective bypass paths.
>
> Regards,
> Michael
>
> On Wed, May 4, 2016 at 4:01 PM, Michael West <[email protected]>
> wrote:
>
> There is no need to remove the RF switches to bypass them. There are
> already bypass traces on the board.
>
> On the A side:
> 1) Remove C834
> 2) Move C852 and C855 to the bypass path for TX
> 3) Move C854 and C856 to the bypass path for RX
>
> On the B side:
> 1) Remove C809
> 2) Move C814 and C810 to the bypass path for TX
> 3) Move C851 and C812 to the bypass path for RX
>
> Regards,
> Michael
>
> On Wed, May 4, 2016 at 3:40 PM, Patrick Sathyanathan via USRP-users <
> [email protected]> wrote:
>
> Thanks, Ralph. That's an excellent idea. I don't need a combined RX and TX
> path either so I will just bridge it. Now if only I could get the switch
> off the board...
>
> --Patrick
>
> ------------------------------
> From: [email protected]
> To: [email protected]; [email protected]
> Subject: RE: [USRP-users] B210: 20db difference between RX2 antenna on A:A
> and A:B
> Date: Wed, 4 May 2016 15:25:42 +0200
>
>
> Hi,
>
> I had it replaced once by a professional, and when it blew again, I just
> removed it with a hot air gun and bridged it. For my use case I anyway need
> separated RX and TX paths.
>
> Ralph.
>
> *From:* Patrick Sathyanathan [mailto:[email protected]]
> *Sent:* Wednesday, May 4, 2016 10:19 AM
> *To:* Ralph A. Schmid, dk5ras; [email protected]
> *Subject:* RE: [USRP-users] B210: 20db difference between RX2 antenna on
> A:A and A:B
>
> Hi Ralph,
>
> I see the same problem with the TX/RX antenna on A:B. So is this a symptom
> of both the switches on A:B getting damaged ?
>
> Also, I tried using my hot air gun to desolder the switch but have been
> unsuccessful so far. All I managed to do was blow off some of the
> neighboring SMD capacitors. It appears that melting the solder on the
> ground pad below the chip is not easy.
>
> How did you replace the switches ?
>
> Thanks,
>
> --Patrick
>
> > From: [email protected]
> > To: [email protected]; [email protected]
> > Subject: RE: [USRP-users] B210: 20db difference between RX2 antenna on
> A:A and A:B
> > Date: Wed, 6 Apr 2016 11:29:11 +0200
> >
> > The TX/RX switch is very sensitive to ESD :( I already killed two of them
> > and don't know why...
> >
> > Ralph.
> >
> > >-----Original Message-----
> > >From: USRP-users [mailto:[email protected]
> <[email protected]>] On Behalf Of
> > >Patrick Sathyanathan via USRP-users
> > >Sent: Wednesday, April 6, 2016 11:22
> > >To: [email protected]
> > >Subject: [USRP-users] B210: 20db difference between RX2 antenna on A:A
> and
> > >A:B
> > >
> > >Hi,
> > >
> > >I have been using my B210 for about a year now with GNUradio and a
> scanner
> > >software that I wrote using UHD and other hardware libraries. Initially
> I
> > used
> > >cheap Nagoya telescopic antennas for both receive channels. When I ran
> > uhd_fft
> > >to observe a known local signal (I think a local HDTV channel) the
> spectrum
> > was
> > >more or less identical if I used the same parameters. Then I purchased a
> > super M
> > >ultra base antenna (25MHz-6GHz from mapantenna.com) which is a
> physically
> > >larger wide band discone antenna and connected it to subdev A:B. For a
> > while
> > >uhd_fft and my own scanner software showed much higher signal strengths
> > with
> > >this. However, a few weeks earlier it started reporting lower signal
> > strength even
> > >for known local signals. And when I connected the Nagoya to A:B and ran
> > uhd_fft
> > >for the local TV signal it shows a spectrum whose shape looks correct
> but
> > is 20db
> > >lower than A:A for the same parameters.
> > >
> > >Could some transmission have overloaded the A:B receive with the larger
> > >antenna and damaged some component ? If so what could be damaged and how
> > >can I get it fixed ?
> > >
> > >Thanks for any help,
> > >
> > >--Patrick
> > >
> > >
> > >_______________________________________________
> > >USRP-users mailing list
> > >[email protected]
> > >http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160504/4a555bc5/attachment-0001.html>
------------------------------
Message: 11
Date: Wed, 4 May 2016 23:31:14 -0700
From: Ian Buckley <[email protected]>
To: Michael West <[email protected]>
Cc: Patrick Sathyanathan <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] B210: 20db difference between RX2 antenna on
A:A and A:B
Message-ID:
<cam_0oceqfvoptnh6g3vqcsqbp5oyjvli+cmg+hmznlhbysn...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
>
> Also, C851/C848/... are labeled as "DNP" in the schematic. What does this
> mean ?
DNP = Do Not Populate. It's an annotation for the standard board assembly
configuration.
On Wed, May 4, 2016 at 11:01 PM, Michael West via USRP-users <
[email protected]> wrote:
> Hi Patrick,
>
> If you look at the board, you can see the bypass traces and the capacitors
> that need to be rotated to bypass the switches.
>
> C826 rotates 90 degrees to become C852
> C832 rotates 90 degrees to become C855
> C814 rotates 90 degrees to become C849
> C810 rotates 90 degrees to become C847
> C833 rotates 90 degrees to become C856
> C829 rotates 90 degrees to become C854
> C819 rotates 90 degrees to become C851
> C812 rotates 90 degrees to become C848
>
> Regards,
> Michael
>
>
>
>
> On Wed, May 4, 2016 at 5:08 PM, Patrick Sathyanathan <[email protected]>
> wrote:
>
>> Shouldn't both A and B be symmetric ? Your lists below do not match for A
>> and B.
>>
>> Assuming B is correct:
>> C814/C810 on B:TX match C826/C832 on A:TX
>> C851/C812 on B:RX match C854/C833 on A:RX
>>
>> Assuming A is correct:
>> C852/C855 on A:TX match C849/C847 on B:TX
>> C854/C856 on A:RX match C848/C851 on B:RX
>>
>>
>> Also, C851/C848/... are labeled as "DNP" in the schematic. What does this
>> mean ?
>>
>> Thanks,
>>
>> --Patrick
>>
>> ------------------------------
>> Date: Wed, 4 May 2016 16:14:14 -0700
>> Subject: Re: [USRP-users] B210: 20db difference between RX2 antenna on
>> A:A and A:B
>> From: [email protected]
>> To: [email protected]
>> CC: [email protected]; [email protected]
>>
>>
>> Small correction. There is no need to remove C834 or C809. Just move
>> the other capacitors to the respective bypass paths.
>>
>> Regards,
>> Michael
>>
>> On Wed, May 4, 2016 at 4:01 PM, Michael West <[email protected]>
>> wrote:
>>
>> There is no need to remove the RF switches to bypass them. There are
>> already bypass traces on the board.
>>
>> On the A side:
>> 1) Remove C834
>> 2) Move C852 and C855 to the bypass path for TX
>> 3) Move C854 and C856 to the bypass path for RX
>>
>> On the B side:
>> 1) Remove C809
>> 2) Move C814 and C810 to the bypass path for TX
>> 3) Move C851 and C812 to the bypass path for RX
>>
>> Regards,
>> Michael
>>
>> On Wed, May 4, 2016 at 3:40 PM, Patrick Sathyanathan via USRP-users <
>> [email protected]> wrote:
>>
>> Thanks, Ralph. That's an excellent idea. I don't need a combined RX and
>> TX path either so I will just bridge it. Now if only I could get the switch
>> off the board...
>>
>> --Patrick
>>
>> ------------------------------
>> From: [email protected]
>> To: [email protected]; [email protected]
>> Subject: RE: [USRP-users] B210: 20db difference between RX2 antenna on
>> A:A and A:B
>> Date: Wed, 4 May 2016 15:25:42 +0200
>>
>>
>> Hi,
>>
>> I had it replaced once by a professional, and when it blew again, I just
>> removed it with a hot air gun and bridged it. For my use case I anyway need
>> separated RX and TX paths.
>>
>> Ralph.
>>
>> *From:* Patrick Sathyanathan [mailto:[email protected]]
>> *Sent:* Wednesday, May 4, 2016 10:19 AM
>> *To:* Ralph A. Schmid, dk5ras; [email protected]
>> *Subject:* RE: [USRP-users] B210: 20db difference between RX2 antenna on
>> A:A and A:B
>>
>> Hi Ralph,
>>
>> I see the same problem with the TX/RX antenna on A:B. So is this a
>> symptom of both the switches on A:B getting damaged ?
>>
>> Also, I tried using my hot air gun to desolder the switch but have been
>> unsuccessful so far. All I managed to do was blow off some of the
>> neighboring SMD capacitors. It appears that melting the solder on the
>> ground pad below the chip is not easy.
>>
>> How did you replace the switches ?
>>
>> Thanks,
>>
>> --Patrick
>>
>> > From: [email protected]
>> > To: [email protected]; [email protected]
>> > Subject: RE: [USRP-users] B210: 20db difference between RX2 antenna on
>> A:A and A:B
>> > Date: Wed, 6 Apr 2016 11:29:11 +0200
>> >
>> > The TX/RX switch is very sensitive to ESD :( I already killed two of
>> them
>> > and don't know why...
>> >
>> > Ralph.
>> >
>> > >-----Original Message-----
>> > >From: USRP-users [mailto:[email protected]
>> <[email protected]>] On Behalf Of
>> > >Patrick Sathyanathan via USRP-users
>> > >Sent: Wednesday, April 6, 2016 11:22
>> > >To: [email protected]
>> > >Subject: [USRP-users] B210: 20db difference between RX2 antenna on A:A
>> and
>> > >A:B
>> > >
>> > >Hi,
>> > >
>> > >I have been using my B210 for about a year now with GNUradio and a
>> scanner
>> > >software that I wrote using UHD and other hardware libraries.
>> Initially I
>> > used
>> > >cheap Nagoya telescopic antennas for both receive channels. When I ran
>> > uhd_fft
>> > >to observe a known local signal (I think a local HDTV channel) the
>> spectrum
>> > was
>> > >more or less identical if I used the same parameters. Then I purchased
>> a
>> > super M
>> > >ultra base antenna (25MHz-6GHz from mapantenna.com) which is a
>> physically
>> > >larger wide band discone antenna and connected it to subdev A:B. For a
>> > while
>> > >uhd_fft and my own scanner software showed much higher signal strengths
>> > with
>> > >this. However, a few weeks earlier it started reporting lower signal
>> > strength even
>> > >for known local signals. And when I connected the Nagoya to A:B and ran
>> > uhd_fft
>> > >for the local TV signal it shows a spectrum whose shape looks correct
>> but
>> > is 20db
>> > >lower than A:A for the same parameters.
>> > >
>> > >Could some transmission have overloaded the A:B receive with the larger
>> > >antenna and damaged some component ? If so what could be damaged and
>> how
>> > >can I get it fixed ?
>> > >
>> > >Thanks for any help,
>> > >
>> > >--Patrick
>> > >
>> > >
>> > >_______________________________________________
>> > >USRP-users mailing list
>> > >[email protected]
>> > >http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> >
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160504/42dab27d/attachment-0001.html>
------------------------------
Message: 12
Date: Thu, 5 May 2016 08:57:34 +0200
From: Claudio Cicconetti <[email protected]>
To: Zhihong Luo <[email protected]>, [email protected]
Subject: Re: [USRP-users] Thunderbolt? 3 on Laptop to 10 Gigabit
Ethernet
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Dear Zhihong,
I have successfully set up a MacBook + X300 connected via 10 GbE.
I used this product:
http://www.sonnettech.com/product/echoexpresssel_10gbeadapter.html
to adapt Thunderbolt to 10 GbE. It worked out-of-the-box.
The only (major!) issue I have now is that the host cannot keep my
desired sampling rate (92.16 Msamples/s) without buffer underruns. Since
the CPU is far from being overloaded, I suspect it might have something
to do with interrupts and how the OS handles them.
If anyone has experience or guidelines on how to optimize host-to-radio
communication on Mac OS X I would appreciate it very much if you could
share.
Best regards,
Claudio
On 05/05/2016 07:24 AM, Zhihong Luo via USRP-users wrote:
> Hi all,
>
> I am currently trying to set up 10 Gigabit Ethernet on laptop through a
> Thunderbolt? 3 port. Thunderbolt? 3 supports up to 40Gbps, so that I
> suppose it can be adapted to a 10 Gigabit Ethernet port (or PCI). But I am
> not sure how to do it, and I didn't find any material on this yet.
>
> Please let me know if you have any suggestions.
>
> Thanks for any help,
> Zhihong
>
------------------------------
Message: 13
Date: Thu, 5 May 2016 17:41:07 +0800
From: Ekko <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] transmit the recieved data with rfnoc
Message-ID:
<caggob6yjf6zwwnfpulrlzphzfqiq_xq6mzfmavczn6iq_dp...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
hello all
i am using the rfnoc ,and i want to transmit the data that i recieved,just
like
when i running this grc , the device tx and rx led is not lighting,i think
that this mean the device is not transmit and recieve data ,
so i want ask whether that it is not ok to use two rfnoc:radio in one grc,
or how can i transmit the data from the recieve port.
thank you
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160505/1fc0180f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rfnoc.png
Type: image/png
Size: 7639 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160505/1fc0180f/attachment-0001.png>
------------------------------
Message: 14
Date: Thu, 5 May 2016 08:24:27 -0500
From: Jonathon Pendlum <[email protected]>
To: Ekko <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] transmit the recieved data with rfnoc
Message-ID:
<cagdo0utzjtplej1rzbpviarybgapnfemkqgfwr68gkigger...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Ekko,
Right now, RFNoC does not support "FGPA only" typologies where this is not
a connection back to the host such as the one in your post. However, Martin
is currently working on enabling it and support should come out very soon.
Jonathon
On Thu, May 5, 2016 at 4:41 AM, Ekko via USRP-users <
[email protected]> wrote:
> hello all
> i am using the rfnoc ,and i want to transmit the data that i recieved,just
> like
> when i running this grc , the device tx and rx led is not lighting,i think
> that this mean the device is not transmit and recieve data ,
> so i want ask whether that it is not ok to use two rfnoc:radio in one grc,
> or how can i transmit the data from the recieve port.
>
> thank you
> ?
>
> _______________________________________________
> 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/20160505/de37e291/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rfnoc.png
Type: image/png
Size: 7639 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160505/de37e291/attachment-0001.png>
------------------------------
Message: 15
Date: Wed, 4 May 2016 13:34:59 +0000
From: mohammed aly <[email protected]>
To: "[email protected]"
<[email protected]>, "[email protected]"
<[email protected]>
Subject: [USRP-users] make phase_inc dynamic in NCO part
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1256"
Dear All,
in E310 project.
i want to make the phase_inc in the attached file to be dynamic.
the part of the NCO.
in the equation: phase = phase + phase_inc.
line 82.
how can i make this value dynamic (phase_inc).
and the how i can control this change from the UHD driver.
Thanks,
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160504/428f527c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: duc_chain.v
Type: application/octet-stream
Size: 8369 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160504/428f527c/attachment-0001.v>
------------------------------
Message: 16
Date: Thu, 5 May 2016 09:45:44 -0400
From: Jason Matusiak <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] RFNoC: RuntimeError: On node 0/CostasLoop_0,
output port 0 is already connected
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Working on my new block and not getting any output (which is never
surprising when I am working). While taking a step back to see what I
messed up this time, I noticed the following output from GR when I run
my script (my new block is a Costas loop):
thread[thread-per-block[7]: <block uhd_rfnoc_CostasLoop (2)>]:
RuntimeError: On node 0/CostasLoop_0, output port 0 is already connected.
What I don't understand is what that message is trying to tell me. I
only have one thing connected to the output of my Costas block, so why
is it implying that I am trying to hook more than one thing up to it?
Both of my XML files have unique names for my three outputs (I also have
one input), and my noc_block_CostasLoop.v sets up the noc_shell with 1
input and 3 outputs.
------------------------------
Message: 17
Date: Thu, 5 May 2016 14:30:51 +0000 (UTC)
From: [email protected]
To: Rob Kossler <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] Using X310 as monostatic pulsed radar
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Rob,
A pulse every 10 usec is definitely not doable over ethernet using individual
timed commands for each pulse..
A "safe" region of all your processing is spot on is 300 usec. You can do
better down to around 200 usec with some falloff in reliability but still 90+%
success rate, after than, too many things can go wrong beyond your control.
I have been operating on win7 and have had decent success around these
timeframes. Windows 7 is sub-optimal to say the least, so my sense is you may
be able to do a bit better, but certainly not 10 usec...
Now what you could do is group up a bunch of pulses together and send the group
much less often. Say send 1000 pulses 1/1000 times less often. I suspect this
would be your best bet...
May also get around some of your other issues as well...
Keep us posted :)
----- Original Message -----
From: "Rob Kossler via USRP-users" <[email protected]>
To: "usrp-users" <[email protected]>
Sent: Wednesday, May 4, 2016 9:55:16 PM
Subject: [USRP-users] Using X310 as monostatic pulsed radar
Hi,
I am investigating using the X310 (w/ UBX-160) as a monostatic pulsed CW radar
(single antenna shared between Tx and Rx). I am writing my own C++ application
using UHD 3.9.2 under Ubuntu 14.04 LTS.
I hope to use a sample rate of 100 MS/s and transmit very short pulses (perhaps
only 4 non-zero values) at short repetition intervals (perhaps ~5us which
equals 500 samples at this rate).
My idea was to use timed Tx bursts for the Tx pulses. I tried an experiment
using the tx_bursts example program to see if I could transmit short pulses at
short cycle times. I found that...
1) I needed a minimum of about 20 non-zero samples in order to see any signal
output (I think that this minimum is governed by the digital filters in the
FPGA based on this thread
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-November/011303.html
)
2) I ran into problems with Late errors for repetition intervals less than
about 10 us (I had to modify the example program to remove the synchronous wait
for the burst ACK in order to get these results)
I have several questions:
1) Is it wise to be considering timed bursts for my scenario? Or should I plan
to continuously stream the Tx with baseband zeros for my "off" periods?
2) Assuming timed bursts is appropriate
a) Is there a way to get around the filtering issues so that I can send pulses
shorter than 20 samples?
b) Is there a way to achieve repetition intervals shorter than 10 us? For this
question, it is worth noting that my PC is good enough to stream continuously
at this rate so you might expect that it could send bursts (with less samples
of course) at this rate. But, this does not appear to be the case.
c) Given that this is a radar and that I want my Rx streamer to be ON for the
period that my Tx is OFF, I am wondering if I can just keep Rx streaming
continuously (even during the Tx Bursts). I realize that this approach would
cause the Rx streaming to be occurring even while the ATR switch was in the Tx
position, but this would be a simpler implementation than having to coordinate
the Rx and Tx streams such that one turns off when the other turns on.
3) Assuming timed bursts is not appropriate
a) Could I run both Tx and Rx streamers continuously and modify the behavior of
the ATR switch such that it was in the Tx position only during the sample times
for which I know that the Tx stream contains non-zeros? Or is this a bad (or
dangerous) idea?
b) Or should I use an external TR switch such that I am using the USRP Tx/Rx
port for Tx and the Rx2 port for Rx? Of course, in this case I would
effectively be doing the same thing as I suggested above in (a) by controlling
the external TR switch to be in the Tx position only during the non-zero
portion of the Tx stream.
Sorry for the long post. Let me know if you have any suggestions.
Rob
_______________________________________________
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/20160505/3d887acc/attachment-0001.html>
------------------------------
Message: 18
Date: Thu, 5 May 2016 10:40:17 -0400
From: Rob Kossler <[email protected]>
To: [email protected]
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] Using X310 as monostatic pulsed radar
Message-ID:
<CAB__hTQBKiutN5TLPP0h-GvsDw3yren-Aq=varo3taekkni...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks for the comments.
Based on Ian's email, I plan to stream Tx and Rx continuously for a given
channel with the Tx baseband I/Q data set to zero for the off periods. A
couple of questions:
1) For a given channel, is it possible to have both Tx and Rx streaming
continuously with the Rx antenna set to 'Tx/Rx'. That is, is there a UHD
limitation that will prevent me from running both Tx and Rx continuously
for a single antenna?
2) Along those same lines, is it possible to change the behavior of the ATR
switch so that I can used timed commands to put the ATR switch in the Tx
position during the non-zero Tx samples and then switch it to the Rx
position for the remaining samples even though both Tx and Rx would be
streaming continuously?
Rob
On Thu, May 5, 2016 at 10:30 AM, <[email protected]> wrote:
> Hi Rob,
>
> A pulse every 10 usec is definitely not doable over ethernet using
> individual timed commands for each pulse..
>
> A "safe" region of all your processing is spot on is 300 usec. You can do
> better down to around 200 usec with some falloff in reliability but still
> 90+% success rate, after than, too many things can go wrong beyond your
> control.
>
> I have been operating on win7 and have had decent success around these
> timeframes. Windows 7 is sub-optimal to say the least, so my sense is you
> may be able to do a bit better, but certainly not 10 usec...
>
> Now what you could do is group up a bunch of pulses together and send the
> group much less often. Say send 1000 pulses 1/1000 times less often. I
> suspect this would be your best bet...
>
> May also get around some of your other issues as well...
>
> Keep us posted :)
>
> ------------------------------
> *From: *"Rob Kossler via USRP-users" <[email protected]>
> *To: *"usrp-users" <[email protected]>
> *Sent: *Wednesday, May 4, 2016 9:55:16 PM
> *Subject: *[USRP-users] Using X310 as monostatic pulsed radar
>
>
> Hi,
> I am investigating using the X310 (w/ UBX-160) as a monostatic pulsed CW
> radar (single antenna shared between Tx and Rx). I am writing my own C++
> application using UHD 3.9.2 under Ubuntu 14.04 LTS.
>
> I hope to use a sample rate of 100 MS/s and transmit very short pulses
> (perhaps only 4 non-zero values) at short repetition intervals (perhaps
> ~5us which equals 500 samples at this rate).
>
> My idea was to use timed Tx bursts for the Tx pulses. I tried an
> experiment using the tx_bursts example program to see if I could transmit
> short pulses at short cycle times. I found that...
> 1) I needed a minimum of about 20 non-zero samples in order to see any
> signal output (I think that this minimum is governed by the digital filters
> in the FPGA based on this thread
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-November/011303.html
> )
> 2) I ran into problems with Late errors for repetition intervals less than
> about 10 us (I had to modify the example program to remove the synchronous
> wait for the burst ACK in order to get these results)
>
> I have several questions:
>
> 1) Is it wise to be considering timed bursts for my scenario? Or should I
> plan to continuously stream the Tx with baseband zeros for my "off" periods?
>
> 2) Assuming timed bursts is appropriate
> a) Is there a way to get around the filtering issues so that I can send
> pulses shorter than 20 samples?
> b) Is there a way to achieve repetition intervals shorter than 10 us? For
> this question, it is worth noting that my PC is good enough to stream
> continuously at this rate so you might expect that it could send bursts
> (with less samples of course) at this rate. But, this does not appear to
> be the case.
> c) Given that this is a radar and that I want my Rx streamer to be ON for
> the period that my Tx is OFF, I am wondering if I can just keep Rx
> streaming continuously (even during the Tx Bursts). I realize that this
> approach would cause the Rx streaming to be occurring even while the ATR
> switch was in the Tx position, but this would be a simpler implementation
> than having to coordinate the Rx and Tx streams such that one turns off
> when the other turns on.
>
> 3) Assuming timed bursts is not appropriate
> a) Could I run both Tx and Rx streamers continuously and modify the
> behavior of the ATR switch such that it was in the Tx position only during
> the sample times for which I know that the Tx stream contains non-zeros?
> Or is this a bad (or dangerous) idea?
> b) Or should I use an external TR switch such that I am using the USRP
> Tx/Rx port for Tx and the Rx2 port for Rx? Of course, in this case I would
> effectively be doing the same thing as I suggested above in (a) by
> controlling the external TR switch to be in the Tx position only during the
> non-zero portion of the Tx stream.
>
> Sorry for the long post. Let me know if you have any suggestions.
>
> Rob
>
>
> _______________________________________________
> 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/20160505/48d7e9e0/attachment-0001.html>
------------------------------
Message: 19
Date: Thu, 5 May 2016 19:45:00 +0430
From: hossein talaiee <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Customize FPGA on B2xx
Message-ID:
<CAAiBEBTe=hfmvwbmzsnagmzjw_t5eewsy2yk-uszbcqlusj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi
I want to send two independent signals over one B200-mini board, I know it
has only one channel but my signal specs are these:
Signal 1 :
Center Freq: 1400.0 MHz
Sample Rate: 2 MSPS
Signal 2 :
Center Freq: 1432 MHz
Sample Rate: 8 MSPS
Also attached as photo
I want to modify FPGA/Firmware code to get some sample from each signal
like 2000 samples from signal 1 and 8000 samples from signal two, and
up-convert them in FPGA and combine them.
Do you have any idea where I must start?
I know I must implement two different DUCs in FPGA to resample these
signals to 40 MSPS to include both signals and filter them separately and
them sum them up!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160505/bbcc05b6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: save.png
Type: image/png
Size: 31993 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160505/bbcc05b6/attachment-0001.png>
------------------------------
Message: 20
Date: Thu, 5 May 2016 17:20:50 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Using X310 as monostatic pulsed radar
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi Rob,
as Ian said:
On 05.05.2016 06:25, Ian Buckley via USRP-users wrote:
> if you were an adventurous FPGA design type then you might consider
> largely ditching the TX radio design in the FPGA, and putting in its
> place something very simple that repeatedly sends your pulse from a
> lookup table, synchronized to the LSB's of the timestamp counter such
> that your RX streams time metadata (which is derived from the same
> counter) would unambiguously identify the associated range within the
> constraints of your PRR.
my gut feeling tells me I'd start with just continously send 50MS/s =
MCR/4 and replace the two halfband FIRs hb1_{iq}0 and hb2_{iq}0 with
your four-tap pulse shape filter as a PoC first (hb47_ints are really
just two-phase polyphase FIR interpolators). If that works, I'd consider
using RF NoC to generate my pulses from a sample stream coming in from
your PC at a much lower rate (e.g. 200kHz), if necessary at all. Or you
just go ahead and replace the CIC interpolators, too, e.g. with
adjustable zero-padders.
Cheers,
Marcus
------------------------------
Message: 21
Date: Thu, 5 May 2016 17:23:33 +0200
From: Sylvain Munaut <[email protected]>
To: Jason Matusiak <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNoC: RuntimeError: On node 0/CostasLoop_0,
output port 0 is already connected
Message-ID:
<cahl+j08j4ukkn4rwdq8rhd3i2rlx5jpw2qom93+zdygmlms...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi,
> Working on my new block and not getting any output (which is never
> surprising when I am working). While taking a step back to see what I
> messed up this time, I noticed the following output from GR when I run my
> script (my new block is a Costas loop):
> thread[thread-per-block[7]: <block uhd_rfnoc_CostasLoop (2)>]: RuntimeError:
> On node 0/CostasLoop_0, output port 0 is already connected.
Interesting ... I'm actually hitting the same issue right now ...
Also with a block using 1 input and several outputs.
Haven't figured out what's wrong though, but if you do, please report here :p
Cheers,
Sylvain
------------------------------
Message: 22
Date: Thu, 5 May 2016 11:28:03 -0400
From: avinash kalyanaraman <[email protected]>
To: [email protected]
Subject: [USRP-users] uhd_find_devices causes no devices found or
packet loss after connecting mimo cable
Message-ID:
<cajpbu_gb6cmdca3h3yvc0yds5aung22ic0e39mkzouxwa0i...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
I have two USRP N210s with the WBX daughterboard connected to a switch. I
can see both the devices when I do a uhd_find_devices . Next, when I
connect them via a MIMO cable, uhd_find_devices returns one of two things:
(i) No UHD Devices Found
(or)
(ii) Packet losses
UHD Error:
Control packet attempt 0, sequence number 4:
RuntimeError: no control response, possible packet loss
UHD Error:
Control packet attempt 0, sequence number 9:
RuntimeError: no control response, possible packet loss
UHD Error:
Control packet attempt 0, sequence number 13:
RuntimeError: no control response, possible packet loss
Would you have any suggestions on how I might be able to fix this? Please
let me know if I am missing anything in this setup ?
Thanks,
--
Avinash
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160505/29067392/attachment-0001.html>
------------------------------
Message: 23
Date: Thu, 05 May 2016 11:47:15 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Customize FPGA on B2xx
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 05/05/2016 11:15 AM, hossein talaiee via USRP-users wrote:
> Hi
>
> I want to send two independent signals over one B200-mini board, I
> know it has only one channel but my signal specs are these:
>
> Signal 1 :
> Center Freq: 1400.0 MHz
> Sample Rate: 2 MSPS
>
> Signal 2 :
> Center Freq: 1432 MHz
> Sample Rate: 8 MSPS
>
>
> Also attached as photo
>
>
> I want to modify FPGA/Firmware code to get some sample from each
> signal like 2000 samples from signal 1 and 8000 samples from signal
> two, and up-convert them in FPGA and combine them.
>
> Do you have any idea where I must start?
>
> I know I must implement two different DUCs in FPGA to resample these
> signals to 40 MSPS to include both signals and filter them separately
> and them sum them up!
>
If you aren't familiar with Verilog and/or VHDL, it'll be a tough hill
to climb. Ian B worked on the FPGA code on the B2xx, so may have more
detailed comments.
Also, if these signals are *over the air*, be warned that the range
1400-1427 is allocated world-wide to radio astronomy, and no deliberate
transmissions in that band are allowed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160505/29ef361f/attachment-0001.html>
------------------------------
Message: 24
Date: Thu, 05 May 2016 11:51:49 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] uhd_find_devices causes no devices found or
packet loss after connecting mimo cable
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 05/05/2016 11:28 AM, avinash kalyanaraman via USRP-users wrote:
> Hi all,
>
> I have two USRP N210s with the WBX daughterboard connected to a
> switch. I can see both the devices when I do a uhd_find_devices .
> Next, when I connect them via a MIMO cable, uhd_find_devices returns
> one of two things:
>
> (i) No UHD Devices Found
>
> (or)
>
> (ii) Packet losses
>
> UHD Error:
> Control packet attempt 0, sequence number 4:
> RuntimeError: no control response, possible packet loss
>
> UHD Error:
> Control packet attempt 0, sequence number 9:
> RuntimeError: no control response, possible packet loss
>
> UHD Error:
> Control packet attempt 0, sequence number 13:
> RuntimeError: no control response, possible packet loss
>
>
> Would you have any suggestions on how I might be able to fix this?
> Please let me know if I am missing anything in this setup ?
>
> Thanks,
>
> --
> Avinash
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
See:
http://files.ettus.com/manual/page_usrp2.html#usrp2_mimocable_shared
IF the two N210 are connected via MIMO, and are on the same subnet, they
go into shared ethernet mode. Since both devices have an
ethernet connection as well, I'm sure things are getting confused.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160505/216484fd/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 69, Issue 5
*****************************************
