Send USRP-users mailing list submissions to
usrp-users@lists.ettus.com
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
usrp-users-requ...@lists.ettus.com
You can reach the person managing the list at
usrp-users-ow...@lists.ettus.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: Mechanism to determine phase offset of two nearly equal
pieces of coax (John Shields)
2. Re: B210 dual channel (Martin Braun)
3. Re: Estimate the SNR at the receiver (Martin Braun)
4. Re: Ettus UBX-160 vs SBX-120 (Martin Braun)
5. Re: USRP B210 does not synchronize internal clock to
ClockTamer (Tom Tsou)
6. Re: Build RFNoC environment (Martin Braun)
7. Re: USRP B210 does not lock to external reference clock
(Martin Braun)
8. Re: E300 GPSD Enable issue in rfnoc-devel (Martin Braun)
9. Re: X310, 2 Basic RX and quad DDC (Martin Braun)
10. Re: rfnoc-ofdm (Martin Braun)
11. Re: X310, 2 Basic RX and quad DDC (Derek Kozel)
12. Antennas for LTE band 7 (Saeid Hashemi)
13. Sampling rates slower than 200 MSps on X310 (Leandro Echevarr?a)
14. Re: Antennas for LTE band 7 (Ron Economos)
15. Re: Problems duplicating rfnoc_rxtx.grc radios for two
UBX-160's in an X310 (Martin Braun)
16. Re: Frequency setting of USRP X300 with Basic TX (Martin Braun)
17. Re: PPS get_time_last_pps() (Martin Braun)
18. Re: Sampling rates slower than 200 MSps on X310 (Martin Braun)
19. Re: Synchronized tx/rx (Martin Braun)
20. Re: E310 gnuradio not showing RFNoC blocks (Martin Braun)
21. Re: start/stop usrp perfect (Martin Braun)
22. Re: Complex FFT display of Frequency offset. (Martin Braun)
23. Re: Use of the drone DJI Matrix 100 with a radio SDR B205
mini (Martin Braun)
24. Re: sensors values access when string representation in gnu
radio (Martin Braun)
25. Re: E310 Quickstart directions don't seem to work (Martin Braun)
26. Re: MIT Haystack Digital RF v2.5 open source release
(Martin Braun)
27. Re: PPS get_time_last_pps() (Dave NotTelling)
28. Re: MIT Haystack Digital RF v2.5 open source release
(Martin Braun)
29. Re: UHD support to Ubuntu 17.04 (Martin Braun)
30. Re: TDMA based Multiple Access Channel using NI USRP 2901
(Martin Braun)
31. Re: ADC self-test failed (Martin Braun)
32. Re: Difference between Clock Recovery and Audio rate
synchronization. (Martin Braun)
33. Re: ADC self-test failed (Sam Vogel)
34. Re: UHD support to Ubuntu 17.04 (Nate Temple)
35. Re: How to solve command timeout error? (Nate Temple)
36. Re: Issue running UHD via sshfs on E310 (Nate Temple)
37. Re: E312 SD Card File System Corruption (Nate Temple)
38. Re: E310 Cross-Compiled UHD Error - key "product" not found
(Nate Temple)
39. Re: USB 3.0 connection problems (USRP 205mini + ODROID XU4)
(Nate Temple)
40. Re: ADC self-test failed (Nate Temple)
41. Re: Pause after "Register loopback test passed" (Martin Braun)
42. Re: Time sync on wideband (Martin Braun)
43. Re: [N210] AD9510 Configuration Issues (Martin Braun)
44. Re: Porting UHD to Zedboard w/Petalinux 2016.4 (Nate Temple)
45. Re: E312 SD Card File System Corruption (Darek Kawamoto)
46. Re: ADC self-test failed (Sam Vogel)
47. Re: ADC self-test failed (Nate Temple)
48. B210 dual channel (?????? 1)
49. How to Compile rx_samples_to_file and Generate an Executable
(altu? kaya)
50. Re: How to Compile rx_samples_to_file and Generate an
Executable (Derek Kozel)
51. Re: How to Compile rx_samples_to_file and Generate an
Executable (altu? kaya)
52. Re: How to Compile rx_samples_to_file and Generate an
Executable (Jacob Knoles)
53. Re: How to Compile rx_samples_to_file and Generate an
Executable (Derek Kozel)
54. Re: ADC self-test failed (Sam Vogel)
----------------------------------------------------------------------
Message: 1
Date: Thu, 6 Jul 2017 05:38:27 +1200
From: "John Shields" <john.shie...@xtra.co.nz>
To: "Derek Kozel" <derek.ko...@ettus.com>, "Marcus D. Leech"
<mle...@ripnet.com>
Cc: <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Mechanism to determine phase offset of two
nearly equal pieces of coax
Message-ID: <FD4CCF87100145D48652DDA6A80DB904@JohnsHPLaptop>
Content-Type: text/plain; charset="utf-8"
Thanks very much Marcus and Derek.
Will have a look at the control port messaging concept and
investigate the custom block option.
Kind Regards,
John
From: Derek Kozel via USRP-users
Sent: Thursday, July 6, 2017 2:41 AM
To: Marcus D. Leech
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Mechanism to determine phase offset of two nearly
equal pieces of coax
As an extension to Marcus' answer, there is no built in support for timed
tuning in the USRP blocks, but we do include an example which shows tuning
using messages and the control port.
https://github.com/gnuradio/gnuradio/blob/master/gr-uhd/examples/grc/uhd_msg_tune.grc
It is also possible to write a custom block to generate command messages. This
can be done using the embedded python block within GRC.
Regards,
Derek
On Wed, Jul 5, 2017 at 2:58 PM, Marcus D. Leech via USRP-users
<usrp-users@lists.ettus.com> wrote:
On 07/05/2017 04:35 AM, John Shields via USRP-users wrote:
I have a couple of N200 with a MIMO cable (and one has a GPSDO but I don?t
think I need to worry about that for this setup) and propose feeding both
cables to RX port on an SBX in each N200. The other end of the coax will be
connected to a splitter and the ?sum? port will be connected to TX port on SBX
(of which only the TX portion works) on a USRP1 through 30dB attenuator.
The phase imbalance spec of this splitter is less than 1 degree but if I
wanted, I could calibrate that out and I could live with it anyway.
In order for this setup to allow me to determine the relative phase offset
( whose length can be calculated from the Velocity Factor of the RG 213) I need
to start up the SBXs on the N200 with zero differential phase offset.
I have seen the section for SBX where I need to execute :
//we will tune the frontends in 100ms from now
uhd::time_spec_t cmd_time = usrp->get_time_now() + uhd::time_spec_t(0.1);
//sets command time on all devices
//the next commands are all timed
usrp->set_command_time(cmd_time);
//tune channel 0 and channel 1
usrp->set_rx_freq(1.03e9, 0); // Channel 0
usrp->set_rx_freq(1.03e9, 1); // Channel 1
//end timed commands
usrp->clear_command_time();
So three questions:
1) am I missing something obvious?
2) is there a clever way in GRC to cause this code to be executed ? rather
than in a .py file?
3) what is the most effective phase comparator to use? I expect to use 400
Mhz to start with to minimise the chance of nx2*pi ambiguity.
Kind Regards,
John
So, in GRC you'd have to select "Unknown PPS" in the SYNC field, and select
MIMO for the clock and time sources for one of the devices.
Once that is done, you'll have to edit the generated code and wrap the
timed-commands around the tuning commands emitted by GRC--there is
currently no support for timed tuning in GRC itself.
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
--------------------------------------------------------------------------------
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170706/e0ca7ebf/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 5 Jul 2017 11:55:05 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] B210 dual channel
Message-ID: <9a865602-6772-8502-34ff-eda18a2cb...@ettus.com>
Content-Type: text/plain; charset=UTF-8
On 07/05/2017 02:14 AM, ?????? 1 via USRP-users wrote:
> Hello
>
> I use B210 device in UHD_STREAM_MODE_NUM_SAMPS_AND_DONE
> <file:///C:/Program%20Files/UHD/share/doc/uhd/doxygen/html/a00266.html#a4a343344e08a5a2b1314d191927f5132a2cff71688fb75e0503d1241f6e8156e8>
> mode
> with dual channel.
>
> Delay that is obtained after uhd_rx_streamer_issue_stream_cmd
> <file:///C:/Program%20Files/UHD/share/doc/uhd/doxygen/html/a00266.html#a820ffc1c99b083dd9eba0ab1ec118085>
> and
> receive first packet data in dual channel mode much more than with one
> channel.
>
> I use internal clock source. Time source I do not setup and nothing is
> sent to the connector 'pps' in device. Is that correct for dual channel?
>
> How i can minimize delay in dual channel mode?
>
> When I measure phase difference ?etween channels its value always near
> +-6 degree.If the delay is due to this is it possible to turn off
> phase-to-zero?
I assume delay and phase offset are the same in this question. Not using
a PPS is fine, but you should still go through the routing of running
set_time_next_pps(), and then using a good device time to get the
samples. After that, you might still see a phase offset based on your
setup. How did you determine the phase offset? What was your analog setup?
-- M
------------------------------
Message: 3
Date: Wed, 5 Jul 2017 11:59:23 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Estimate the SNR at the receiver
Message-ID: <8eab73bc-d704-abf3-64ba-66f626229...@ettus.com>
Content-Type: text/plain; charset=utf-8
On 07/04/2017 01:10 PM, ??????? ???????? via USRP-users wrote:
> Hello everyone,
>
> It's the third time that I post something here and I would like to
> express my thankfulness because reading Questions/Answers helped me in
> completing my bachelor thesis in MIMO-OFDM systems using USRP N210 and
> MATLAB.
>
> At the time, I have 3 final questions to solve (in MATLAB) and I would
> be glad if someone can help me.
> I am sending OFDM packets (bursts), receive them, keep one burst,
> synchronize (with preamble) and demodulate correctly.
>
> 1) I would like to know how to find SNR at the receiver without any
> build-in function of MATLAB. I came up with energy detector (I heard I
> can find SNR also with this) but it didn't help me so I use sync based
> on preamble.
> 2) What it the Transmin Power of USRP? I can only adjust Tx and Rx
> gain.. (Try to confirm Free Space Loss Model)
> 3) Is there an easy method to find Banwidth of transmitted signal?
Basil,
all three questions are not something we can answer for you,
unfortunately. Estimating SNR is a hard problem, and there are
algorithms, typically tied to the waveform you're receiving (e.g., OFDM
would have different algos than SC QPSK, etc.).
The transmit power depends on many things, and USRPs are not calibrated,
so you would need to measure the feed going into your antenna using a
calibrated power meter or spectrum analyzer (and then factor in data
from your antenna).
The bandwidth however is a function of the signal you provide. You
should be able to calculate that.
Cheers,
Martin
------------------------------
Message: 4
Date: Wed, 5 Jul 2017 12:02:37 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Ettus UBX-160 vs SBX-120
Message-ID: <9fef85ef-04d4-e6a7-ffb7-07d5afa9e...@ettus.com>
Content-Type: text/plain; charset=windows-1252
We do have DDCs on the FPGA though. Can you run at 100 MHz?
-- M
On 07/04/2017 01:36 AM, Marcus M?ller via USRP-users wrote:
> Exactly!
>
> So, if your ADC runs at 120 MHz, the unambiguously representable
> baseband is -60 MHz to +60MHz.
>
> Now you have a baseband signal at +65 MHz that (barely, but still)
> passes through the analog anti-aliasing filter, what happens?
>
> Exactly, it shows up at -55 MHz. If you had useful signal at -55 MHz,
> bad luck, it's now superimposed with the alias of the 65 MHz signal.
>
> Effectively, that means that if you use an anti-aliasing filter with a
> passband that is exactly as wide as the Nyquist bandwidth of the ADC
> you're dealing with, you can't really use the upper and lower part of
> the observed spectrum, because that is overlayed with the lower and
> upper transition width of the filter, respectively.
>
> "Can't use", "Passband", "Transition Width" are all relative to what
> distortions you're able to accept, by the way.
>
> Best regards,
>
> Marcus
>
>
> On 07/04/2017 10:26 AM, Simon Olvhammar via USRP-users wrote:
>> Thank you Keyong Su Shin,
>>
>> However I suppose you mean aliasing just at the band edges?
>> I get around 100 MHz of good data when using 120 MS/s on the SBX-120
>> daughterboard.
>>
>> Regards
>> Simon
>>
>> On Mon, Jul 3, 2017 at 3:18 PM, Kyeong Su Shin <kss...@uw.edu
>> <mailto:kss...@uw.edu>> wrote:
>>
>> Hello Simon Olvhammar:
>>
>> Just one more note:
>>
>> A relevant e-mail thread achieve, since you are apparently using
>> ADC sampling rate of 120MS/s on SBX-120 daughterboards:
>>
>>
>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-February/018075.html
>>
>> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-February/018075.html>
>>
>> To get better data quality, you may want to sample faster and then
>> do digital filtering -> decimation (USRP will do that for you, if
>> you are fine with integer decimators). This may prevent you from
>> using the 120MHz bandwidth, but improve the overall data quality.
>>
>> Regards,
>> Kyeong Su Shin
>>
>> On Mon, Jul 3, 2017 at 1:35 AM, Simon Olvhammar via USRP-users
>> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>>
>> wrote:
>>
>> Hi,
>>
>> I am not sure if I understand correctly.
>> How are the ADC to slow if I use a master clock rate of 120
>> MHz and sampling rate of 120 MHz on a UBX-160? I don't need
>> 160 MHz bandwidth only 120 MHz.
>>
>> Regards
>> Simon
>>
>> On 06/28/2017 04:12 PM, Sylvain Munaut wrote:
>>
>> Hi,
>>
>>
>> We currently running a system with a Ettus x310 and a
>> SBX-120.
>> We also a have UBX-160 daughter board.
>>
>> For several reasons, mainly due to computer
>> performance limitations, we can
>> only run with a complex sampling rate of 120 MHz.
>> My question is if I will see any improvement in
>> performance, e.g. filter
>> characteristics, if I instead use the UBX-160 and run
>> it at 120 MHz compared
>> to SBX-120 at 120 MHz or are they similar?
>>
>> You can't do that.
>>
>> If you have the master clock-rate at 120 MHz and use a 160
>> MHz wide
>> daugtherboard, you will get aliasing because the ADC are
>> too slow.
>> You'd have to go to a 100 MHz samplerate for it to work.
>> (200 MHz
>> sampled by the ADC then HW decimated by 2 to 100 Msps).
>>
>> Cheers,
>>
>> Sylvain
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>>
>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 5
Date: Wed, 5 Jul 2017 12:06:22 -0700
From: Tom Tsou <tom.t...@ettus.com>
To: George Vardakis <vardakis....@gmail.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] USRP B210 does not synchronize internal
clock to ClockTamer
Message-ID:
<cagniu+dbo12oxnthohw7dqrwh1fnq4wqtbbd4sdl-aog+0v...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hi George,
On Mon, Jun 12, 2017 at 4:38 AM, George Vardakis via USRP-users
<usrp-users@lists.ettus.com> wrote:
> I have two USRP B210 devices and a ClockTamer. For my MIMO application, i
> need the frequencies of the receiving streams of the two USRPs to match
> perfectly. I connect the ClockTamer to the devices, and set the output
> frequency of the clocktamer at 10MHz. To test whether it works properly, i
> transmit a sine wave from another device, and receive from my two USRPs. What
> i observe when i set the output frequency of the tamer, is that while at the
> first USRP the frequency of the received signal shifts (sign that the
> internal clock becomes in sync with the external), the signal received by the
> other USRP does not have the same behavior.
To clarify, are you simultaneously driving two B210 devices with a
single 10 MHz reference? How are the reference connections coupled?
If you test each single device individually with the 10 MHz source,
does each device lock to the reference?
-TT
------------------------------
Message: 6
Date: Wed, 5 Jul 2017 12:42:25 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Build RFNoC environment
Message-ID: <6ac17418-2213-29f8-382b-43cf9b032...@ettus.com>
Content-Type: text/plain; charset=utf-8
Hi Kim,
as Nicolas says, we had some issues with PyBOMBS recently. Those issues
were fixed, but if your prefix was broken due to bad PyBOMBS, updating
PyBOMBS alone won't fix your prefix. You can either hand-edit the
offending .yml file (if you know what it looks like), or simply update
PB and start from scratch.
-- M
On 07/03/2017 04:04 AM, Nicolas Cuervo via USRP-users wrote:
> Hello Kim,
>
> Are you still facing this problem while trying a pybombs installation?
> While looking at the previous commits from pybombs, there were a couple
> ruamel related that might have had something to do with API changes [1].
> There have been changes in PyBombs since then. So, if you are still
> facing this, could you please update your pybombs:
>
> $ [sudo] pip install [--upgrade] git+https://github.com/gnuradio/pybombs.git
>
> and try again?
>
> If you try this, please let us know if the issue persists as well.
>
> Regards,
> - Nicolas
>
>
> [1] Not completely sure, but might have to do with your specific issue:
> https://github.com/gnuradio/pybombs/commit/635a69c69109febcf9c800d6b5aaffa310712026
> https://github.com/gnuradio/pybombs/commit/62b6a01b841845ff34ba0e3d69d3248c7322e841
>
> On Fri, Jun 9, 2017 at 12:24 PM, ??? via USRP-users
> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote:
>
> Hi all.
>
>
>
> I installed GRC on Ubuntu 16.04 with <Software Development on the
> E310 and E312> procedure.
>
> after that I tried <Getting Started with RFNoC Development>
> procedure, and fail.
>
> I reinstall ubuntu and <Getting Started with RFNoC Development> again.
>
>
>
> I got this error message on "pybombs prefix init ~/rfnoc -R rfnoc -a
> rfnoc" step.
>
> I hope someone guide me to right procedure, or teach me what am i
> missing.
>
>
>
>
>
> Exception ruamel.yaml.constructor.ConstructorError:
> ConstructorError() in <generator object construct_undefined at
> 0x7fd5261ba0a0> ignored
> Traceback (most recent call last):
> File "/usr/local/bin/pybombs", line 9, in <module>
> load_entry_point('PyBOMBS==2.3.1a0', 'console_scripts', 'pybombs')()
> File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py",
> line 542, in load_entry_point
> return get_distribution(dist).load_entry_point(group, name)
> File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py",
> line 2569, in load_entry_point
> return ep.load()
> File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py",
> line 2229, in load
> return self.resolve()
> File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py",
> line 2235, in resolve
> module = __import__(self.module_name, fromlist=['__name__'],
> level=0)
> File "/usr/local/lib/python2.7/dist-packages/pybombs/main.py",
> line 26, in <module>
> from pybombs.commands import dispatch
> File
> "/usr/local/lib/python2.7/dist-packages/pybombs/commands/__init__.py",
> line 23, in <module>
> from .base import CommandBase, SubCommandBase, dispatch
> File
> "/usr/local/lib/python2.7/dist-packages/pybombs/commands/base.py",
> line 27, in <module>
> from pybombs.config_manager import config_manager
> File
> "/usr/local/lib/python2.7/dist-packages/pybombs/config_manager.py",
> line 654, in <module>
> config_manager = ConfigManager()
> File
> "/usr/local/lib/python2.7/dist-packages/pybombs/config_manager.py",
> line 330, in __init__
> self.load(select_prefix)
> File
> "/usr/local/lib/python2.7/dist-packages/pybombs/config_manager.py",
> line 370, in load
> if self._append_cfg_from_file(self.local_cfg):
> File
> "/usr/local/lib/python2.7/dist-packages/pybombs/config_manager.py",
> line 446, in _append_cfg_from_file
> cfg_data = PBConfigFile(cfg_filename).get()
> File
> "/usr/local/lib/python2.7/dist-packages/pybombs/config_file.py",
> line 42, in __init__
> raise PBException("Error loading {0}: {1}".format(filename, str(e)))
> pybombs.pb_exception.PBException: Error loading
> /home/duck4985/.pybombs/config.yml: could not determine a
> constructor for the tag '!!python/tuple'
> in "<byte string>", line 3, column 3:
> - !!python/tuple []
> ^ (line: 3)
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 7
Date: Wed, 5 Jul 2017 12:45:29 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP B210 does not lock to external
reference clock
Message-ID: <1603d0fc-4d1f-6988-ba9e-e58080ef5...@ettus.com>
Content-Type: text/plain; charset=utf-8
On 06/30/2017 01:44 AM, George Vardakis via USRP-users wrote:
> Hi all,
>
> It seems i have a problem with one of my two USRP B210 devices. I
> connect them both to my ClockTamer, external reference clock, and only
> one of them locks to the 10 MHz reference. The other one, always the
> same device, does not lock. Should i start worrying this is a hardware
> issue, or is there anything i can do to try to fix it?
Can you confirm the output levels of the clocktamer, and that you're
setting the clock source to external? And do you have a GPSDO on the board?
-- M
------------------------------
Message: 8
Date: Wed, 5 Jul 2017 12:48:55 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] E300 GPSD Enable issue in rfnoc-devel
Message-ID: <a32df824-e72b-7829-e972-acfc684f2...@ettus.com>
Content-Type: text/plain; charset=windows-1252
On 06/29/2017 03:45 PM, Prager, Samuel M (334E) via USRP-users wrote:
> Setting the time source to ?gpsdo? on our E312 running rfnoc fails. I
> believe this is due to the uhd/host/usrp/e300/CMakeLists.txt file
> missing the following line:
>
>
>
> IF(ENABLE_GPSD)
>
> SET_SOURCE_FILES_PROPERTIES(
>
> ${CMAKE_CURRENT_SOURCE_DIR}/e300_impl.cpp
>
> ${CMAKE_CURRENT_SOURCE_DIR}/e300_impl.hpp
>
> ${CMAKE_CURRENT_SOURCE_DIR}/e3xx_radio_ctrl_impl.cpp
>
> PROPERTIES COMPILE_DEFINITIONS "E300_GPSD=1"
>
> )
>
> ENDIF(ENABLE_GPSD)
Sam,
yes, thanks, that's a legit bug and the fix will be published very soon.
Thanks for pointing directly to the issue!
-- M
------------------------------
Message: 9
Date: Wed, 5 Jul 2017 12:51:19 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] X310, 2 Basic RX and quad DDC
Message-ID: <1a69ee4b-dfa2-3d6e-848d-518c18685...@ettus.com>
Content-Type: text/plain; charset=utf-8
On 06/29/2017 01:09 AM, gwenhael.goavec via USRP-users wrote:
> Hi,
>
> I use an x310 with 2 basic RX daughterboard.
>
> Currently I inject one "real" signal in channelA for side A and a
> second "real" signal in channelA for side B. Now I wish to inject 4
> "real" signals in my USRP and receiving 4 demodulated/filtered IQ
> dataflow on my computer. It's theorically possible because BasicRx
> daughterboard do nothing.
>
> I've read the Vivado design for this USRP and I've seen in x300_core.v
> (in fact rfnoc_ce_default_inst_x310.v) 2 x noc_block_ddc : I suppose
> (I'm wrong ?) each of them receive 2 dataflow of one ADC (chanA and
> chanB).
>
> In this module 2 DDC are instanciated. Consequently It's seems to have
> 4 demodulation using cordic24 and 4 CIC.
>
> Consequently, I suppose my need is possible with official X310 firmware
> but I'm don't know how to configure, through uhd or gnuradio, my USRP
> to provide I0Q0I1Q1I2Q2I3Q3 (this order is not mandatory).
>
> My assumption is true (or not)? If it's possible someone here could
> help me for this configuration?
Gwen,
this is not (currently) a supported configuration on the X300.
Regards,
Martin
------------------------------
Message: 10
Date: Wed, 5 Jul 2017 12:53:58 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] rfnoc-ofdm
Message-ID: <7a97420a-a1d0-ced4-3ece-cb503e8a2...@ettus.com>
Content-Type: text/plain; charset=utf-8
On 06/28/2017 07:55 PM, Walter Maguire via USRP-users wrote:
> Really just looking for clarification on this one.
>
> I am trying to locate the up to date files which support the GNU Radio
> Conference Tutorial 2015 tutorial
>
> "Building an OFDM Receiver with RFNoC".
>
>
> The reason I ask is that up to now I have been working with the
> rfnoc-devel branch which uses Vivado 2015.4. I don't see any available
> ofdm noc blocks in the usrp3_rfnoc/lib directory. If I checkout the
> rfnoc-ofdm I do see the following fpga files in the lib/rfnoc directory
>
> noc_block_ofdm_constellation_demapper_tb
> noc_block_ofdm_constellation_demapper.v
> noc_block_ofdm_tb
> ofdm_constellation_demapper.v
> ofdm_peak_detector.v
> ofdm_plateau_detector.v
>
>
> However the associated build environment seems to require the Vivado
> 2014.4 build system installed. The tutorial shows blocks for OFDM Sync
> and OFDM Equalizer. These don't appear to be present in the lib/rfnoc
> directory.
>
>
> I would be grateful if someone would clarify the build files and tools
> required.
Walter,
the tutorial is a bit outdated. Files are now in usrp3/lib/rfnoc, that's
correct. We'll need to spend some time on the tutorial to see what's
still valid and what needs updating.
Regards,
Martin
------------------------------
Message: 11
Date: Wed, 5 Jul 2017 21:20:16 +0100
From: Derek Kozel <derek.ko...@ettus.com>
To: Martin Braun <martin.br...@ettus.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] X310, 2 Basic RX and quad DDC
Message-ID:
<CAA+K=tshnS3TwSw8YnJEoCUrL-nPUzk=vnmc-mcypn3rext...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Gwen,
There is no currently supported way of obtaining four real valued sample
streams from a pair of BasicRX daughterboards. However, if you do not use
any DDC (CORDIC) frequency shift then there will be no energy transfer
between the I and Q values in the complex stream. You can then unpack the
complex samples into a pair of real valued samples on the host side
application.
Regards,
Derek
On Wed, Jul 5, 2017 at 8:51 PM, Martin Braun via USRP-users <
usrp-users@lists.ettus.com> wrote:
> On 06/29/2017 01:09 AM, gwenhael.goavec via USRP-users wrote:
> > Hi,
> >
> > I use an x310 with 2 basic RX daughterboard.
> >
> > Currently I inject one "real" signal in channelA for side A and a
> > second "real" signal in channelA for side B. Now I wish to inject 4
> > "real" signals in my USRP and receiving 4 demodulated/filtered IQ
> > dataflow on my computer. It's theorically possible because BasicRx
> > daughterboard do nothing.
> >
> > I've read the Vivado design for this USRP and I've seen in x300_core.v
> > (in fact rfnoc_ce_default_inst_x310.v) 2 x noc_block_ddc : I suppose
> > (I'm wrong ?) each of them receive 2 dataflow of one ADC (chanA and
> > chanB).
> >
> > In this module 2 DDC are instanciated. Consequently It's seems to have
> > 4 demodulation using cordic24 and 4 CIC.
> >
> > Consequently, I suppose my need is possible with official X310 firmware
> > but I'm don't know how to configure, through uhd or gnuradio, my USRP
> > to provide I0Q0I1Q1I2Q2I3Q3 (this order is not mandatory).
> >
> > My assumption is true (or not)? If it's possible someone here could
> > help me for this configuration?
>
> Gwen,
>
> this is not (currently) a supported configuration on the X300.
>
> Regards,
> Martin
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> 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/20170705/fb72399a/attachment-0001.html>
------------------------------
Message: 12
Date: Wed, 5 Jul 2017 16:08:26 -0400
From: Saeid Hashemi <sae...@gmail.com>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Antennas for LTE band 7
Message-ID:
<canq3h38ufvyiztjpz5xw+kxnn6zwdbhhtwd5a2ixdgrkcdg...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
For users with past experience, do you have any recommendations on antennas
for use with LTE band 7 (2.6 GHz) on the B210 USRP?
Regards,
Saeid
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170705/fde2fc50/attachment-0001.html>
------------------------------
Message: 13
Date: Wed, 05 Jul 2017 20:50:16 +0000
From: Leandro Echevarr?a <leoechevar...@gmail.com>
To: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] Sampling rates slower than 200 MSps on X310
Message-ID:
<caleoa2j-syed4mpesj05a96y+thcl+evmf+v6hd+ndr_lax...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello all again,
I've got a quick question: how does the FPGA core handle sample rates
slower than the max rate on the X310? I haven't found any strobe signal
that could indicate when there is valid data coming from the ADC and into
the x300_core.v: does this mean that it always samples at 200 MSps and then
downsamples using the DDC block whenever necessary? This comes from
understanding the radio_clk always stays at 200 MHz.
Thanks!
Leo
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170705/2e949b48/attachment-0001.html>
------------------------------
Message: 14
Date: Wed, 5 Jul 2017 13:53:40 -0700
From: Ron Economos <w...@comcast.net>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Antennas for LTE band 7
Message-ID: <04addf39-9953-bbbf-1586-e24c33772...@comcast.net>
Content-Type: text/plain; charset=utf-8; format=flowed
If you're looking for something with gain/directivity, the RFSPACE
TSA600 works well at 2.6 GHz.
http://rfspace.com/RFSPACE/Antennas_files/TSA600.pdf
https://www.amazon.com/Wideband-Antenna-600-6000-VIVALDI-TAPERED/dp/B0141KA6LM
Ron
On 07/05/2017 01:08 PM, Saeid Hashemi via USRP-users wrote:
> Hello,
>
> For users with past experience, do you have any recommendations on
> antennas for use with LTE band 7 (2.6 GHz) on the B210 USRP?
>
>
> Regards,
> Saeid
>
------------------------------
Message: 15
Date: Wed, 5 Jul 2017 14:07:51 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Problems duplicating rfnoc_rxtx.grc radios
for two UBX-160's in an X310
Message-ID: <d21d128f-05b6-24ac-b771-9a299bd87...@ettus.com>
Content-Type: text/plain; charset=windows-1252
On 06/27/2017 02:32 PM, Swanson, Craig via USRP-users wrote:
> Jonathon,
>
> I am able to successfully run the flowgraph from the
> gr-ettus/examples/rfnoc directory called rfnoc_rxtx.grc. This works
> great for a single UBX-160.
>
>
> But if I have two daughtercards, I am running into two problems:
>
> 1) It needs two dmafifos. How do I instantiate two dmafifos?
Craig,
why do you need 2 DMA FIFOs? It has 2 channels after all.
> 2) I get errors where it seems to be unable to grab ddc_1 and duc_1. It
> errors out because it says ddc_0 and duc_0 are already connected.
Are you using multi_usrp API?
-- M
>
>
> This is all happening with the HG or XG version of usrp_x310_fpga_HG.bit
> or usrp_x310_fpga_RFNOC_HG.bit found in the images directory.
>
>
> GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_4.0.0.rfnoc-devel-369-g1908672f]
>
>
> Craig
>
>
> *Craig F. Swanson*
> */Research Engineer II
> /*
> */Information and Communications Laboratory/*
> */Communications, Systems, and Spectrum Division/*
> /Georgia Tech Research Institute/
> /Room 560
> 250 14th St NW
> /
> /Atlanta, GA 30318/
> /Cell: 770.298.9156/
> http://www.gtri.gatech.edu
> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 16
Date: Wed, 5 Jul 2017 14:32:28 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Frequency setting of USRP X300 with Basic TX
Message-ID: <2dc2f061-12c3-ec93-ae7d-6d4423e9f...@ettus.com>
Content-Type: text/plain; charset=utf-8
On 06/26/2017 07:18 PM, Bright Cheng via USRP-users wrote:
>
> Hi,
>
> I am testing X300 with Basic TX.
> When I use "tx_waveform" to generate waveform at 220MHz, the "Actual TX
> Freq" displayed is 20.0 MHz.
> How can I actually configure the device to generate waveform at 220MHz?
> Thank so much.
Bright,
the BasicTX doesn't have an LO, so it can only digitally move the signal
within +- 100 MHz. If you measure at 220 MHz, you'll also see the signal
there... by the magic of aliasing!
-- M
------------------------------
Message: 17
Date: Wed, 5 Jul 2017 14:34:09 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] PPS get_time_last_pps()
Message-ID: <883e81b3-85a5-6a84-ddd0-f2eecb7e9...@ettus.com>
Content-Type: text/plain; charset=utf-8
On 06/28/2017 11:03 AM, Dave NotTelling via USRP-users wrote:
> I still think it's odd that the radio is drifting at 12-14 us per second
> when using the PPS to sample the time. Am I incorrect in my assumption
> that calls to get_time_last_pps() will work with just the PPS input and
> no 10 MHz reference? If that does work, and my 1 PPS reference is
> stable and accurate, then I would expect to see a very slow drift. In
> my mind the clock on the radio should be almost as accurate as my timing
> reference that is generating the 1 PPS output. Meaning that calls to
> get_time_last_pps() should be almost exactly 1 second apart and should
> show a time that is almost 1 second ahead of the last call. Granted, in
> the long run the time will be wonky since there is no 10 MHz reference
> to keep time rolling at an accurate rate, but in the short term (< 1
> minute) I feel like things should be pretty spot on.
It doesn't matter how stable your PPS is if your clock is not stable
though. Let's assume your PPS is *perfect*. How many times does your
clock toggle between two PPS flanks? That's unrelated. 10?s seems a lot
though....
But in general, a PPS by itself, and then using an internal clock
source, is not a useful combination.
Cheers,
Martin
>
> On Wed, Jun 28, 2017 at 1:16 PM, Dave NotTelling <dmp250...@gmail.com
> <mailto:dmp250...@gmail.com>> wrote:
>
> Just ran across an old version of this same question I asked a while
> back (sorry for the dupe)
>
> [post]
> To add to the comments, the USRP clock is virtually guaranteed to
> drift away from the host system time if the time is set once and the
> clocks on the host and USRP are left to run on their own oscillators
> with no PLL between them. To keep a USRP synchronized in time takes
> a 10 MHz reference to which the USRP can use to lock the PLL and
> a PPS to make sure the time on the USRP is set at a precise moment.
> Some USRPs (B2xxmini and E3xx) can lock the PLL to the PPS, so the
> 10 MHz is not necessary, but they are far less accurate. Unless
> your host system can put out a 10 MHz and PPS, the times will be
> off. This is why a GPSDO is commonly used to synchronize devices
> that are not close to each other and a common 10 MHz and PPS (i.e.
> distributed by an Octoclock) is used to synchronize devices that are
> close to each other.
>
> Also, the calls to getTime() and usrp->get_time_now() are not
> synchronous or atomic and will have varying amounts of latency
> between the return values so the accuracy of the measurement is
> probably not very good at trying to measure something less than a
> few milliseconds.
> [/post]
>
> Seems that I completely goofed and I need *both* 10 MHz and 1 PPS :(
>
>
> On Wed, Jun 28, 2017 at 12:57 PM, Dave NotTelling
> <dmp250...@gmail.com <mailto:dmp250...@gmail.com>> wrote:
>
> Also, I updated to UHD_003.010.001.HEAD-0-gc705922a and got the
> same issue of the time being off by ~ 14 us every second.
>
> On Wed, Jun 28, 2017 at 9:04 AM, Dave NotTelling
> <dmp250...@gmail.com <mailto:dmp250...@gmail.com>> wrote:
>
> I just recently hooked my N210 up to a 1 PPS source and was
> expecting that calls to radio->get_time_last_pps() would
> return a number really close to 1 second from the previous
> call. Instead I get the following:
>
> [output]
>
> $ g++ t.cc -o t -luhd -lboost_thread -lboost_system && ./t
> linux; GNU C++ version 4.8.4; Boost_105400;
> UHD_003.009.004-0-gfb928f42
>
> -- Opening a USRP2/N-Series device...
> -- Current recv frame size: 1472 bytes
> -- Current send frame size: 1472 bytes
>
> UHD Warning:
> Unable to set the thread priority. Performance may be
> negatively affected.
> Please see the general application notes in the manual
> for instructions.
> EnvironmentError: OSError: error in pthread_setschedparam
> 0.000012
> 0.000024
> 0.000035
> 0.000047
> 0.000059
> 0.000071
> 0.000083
> 0.000094
> 0.000106
> 0.000118
> 0.000130
> 0.000142
> 0.000153
> 0.000165
> 0.000177
> 0.000189
>
> [/output]
>
> The drift is fairly constant at ~ 11-12 us per second. It
> should be noted that I am not using a 10 MHz reference.
> Just the 1 PPS.
>
> Here is the code I'm using:
>
> [code]
>
> #include <boost/thread.hpp>
> #include <uhd/usrp/multi_usrp.hpp>
>
> int main(){
> uhd::usrp::multi_usrp::sptr radio =
> uhd::usrp::multi_usrp::make(std::string("addr=192.168.12.2"));
> radio->set_time_source("external");
> radio->set_time_next_pps(uhd::time_spec_t(0, 0));
> boost::this_thread::sleep_for(boost::chrono::seconds(2));
>
> while(1){
> uhd::time_spec_t t = radio->get_time_last_pps();
> fprintf(stderr, "%0.6f\n", t.get_frac_secs());
>
> boost::this_thread::sleep_for(boost::chrono::seconds(1));
> }
> }
>
> [/code]
>
> And here is the output of the test_pps_input command:
>
> [output]
>
> $ /tmp/test_pps_input --args addr=192.168.12.2
> linux; GNU C++ version 4.8.4; Boost_105400;
> UHD_003.009.004-0-gfb928f42
>
>
> UHD Warning:
> Unable to set the thread priority. Performance may be
> negatively affected.
> Please see the general application notes in the manual
> for instructions.
> EnvironmentError: OSError: error in pthread_setschedparam
>
> Creating the usrp device with: addr=192.168.12.2...
> -- Opening a USRP2/N-Series device...
> -- Current recv frame size: 1472 bytes
> -- Current send frame size: 1472 bytes
>
> UHD Warning:
> Unable to set the thread priority. Performance may be
> negatively affected.
> Please see the general application notes in the manual
> for instructions.
> EnvironmentError: OSError: error in pthread_setschedparam
> Using Device: Single USRP:
> Device: USRP2 / N-Series Device
> Mboard 0: N210r4
> RX Channel: 0
> RX DSP: 0
> RX Dboard: A
> RX Subdev: UBX RX
> TX Channel: 0
> TX DSP: 0
> TX Dboard: A
> TX Subdev: UBX TX
>
>
> Attempt to detect the PPS and set the time...
>
> -- 1) catch time transition at pps edge
> -- 2) set times next pps (synchronously)
>
> Success!
>
> [/output]
>
> Am I doing something wrong?
>
>
> Thanks!
>
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 18
Date: Wed, 5 Jul 2017 14:35:52 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Sampling rates slower than 200 MSps on X310
Message-ID: <6269095a-6e5e-f264-f42c-75f22927e...@ettus.com>
Content-Type: text/plain; charset=utf-8
On 07/05/2017 01:50 PM, Leandro Echevarr?a via USRP-users wrote:
> Hello all again,
>
> I've got a quick question: how does the FPGA core handle sample rates
> slower than the max rate on the X310? I haven't found any strobe signal
> that could indicate when there is valid data coming from the ADC and
> into the x300_core.v: does this mean that it always samples at 200 MSps
> and then downsamples using the DDC block whenever necessary? This comes
> from understanding the radio_clk always stays at 200 MHz.
Exactly right. We can tune and decimate (in integer factors) on the FPGA.
-- M
------------------------------
Message: 19
Date: Wed, 5 Jul 2017 14:40:05 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Synchronized tx/rx
Message-ID: <3ccf338a-6d54-1a65-e1c5-00976d3bf...@ettus.com>
Content-Type: text/plain; charset=utf-8
On 06/27/2017 05:29 AM, ROBIN TORTORA via USRP-users wrote:
> Windows 7, UHD 3.9.2, X310 with UBX daughtercard.
>
>
> I have an app that does time syncd tx/rx on the same daughtercard.
>
>
> When I schedule a timed transmit, what does the time spec actually
> represent?
>
>
> Is it the time that samples start through the Tx chain?
This depends. On your UHD version, yes, it's when it starts going into
the Tx chain. On newer UHDs, it's the time it gets sent to the DAC.
> Similarly on the recv side, what does the time spec actually represent?
>
>
> Is it the time samples start coming through the Rx chain?
Same answer, in reverse.
> Here is my issue: I have "calibrated" out the delay of the loopback by
> sending a test pulse through tx chain starting the tx at time T1 while
> simultaneously starting the Rx chain at T1 also. Lets call the measured
> delay 10 samples, i simply remove 10 samples form the beginning of the
> rx data and continue on merrily.
>
>
> 80% of the time, everything is completely syncd perfectly for the length
> of the Tx/Rx.
>
>
> 20% of the time, the rx is off by 1 sample, so the delay is actually 11
> samples rather than 10. Everything is syncd, just off by 1 sample.
>
>
> This is executed with the same freq and sample rate.
>
>
> Is there anything organically "wrong" with my approach?
It looks sensible. What's your CPU rate (i.e. what's your
interpolation/decimation)?
-- M
> Is there anything I can do differently to eliminate the 20% of the time
> 1 sample mismatch?
>
>
> It seems I am straddling some time bin and wondering if a different
> approach would more stable and looking for any suggestions...
>
>
> Thanks,
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 20
Date: Wed, 5 Jul 2017 14:41:40 -0700
From: Martin Braun <martin.br...@ettus.com>
To: "'USRP-users@lists.ettus.com'" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] E310 gnuradio not showing RFNoC blocks
Message-ID: <69ea88ec-f461-297d-9964-95e389b29...@ettus.com>
Content-Type: text/plain; charset=windows-1252
On 06/26/2017 07:53 AM, Jason Matusiak wrote:
> A little more info. I ran it through GDB (of which I am not
> proficient), and it errored out with this:
> Program received signal SIGILL, Illegal instruction.
> _armv7_tick () at armv4cpuid.S:94
> 94 mrrc p15,1,r0,r1,c14 @ CNTVCT
SIGILL typically means your x-compile failed to do the right thing (and
now it's, for example, trying to execute an x86 instruction on ARM).
I've seen this before, but clean re-compiles usually did the trick.
-- M
>
>
>
> On 06/26/2017 10:23 AM, Jason Matusiak wrote:
>> Ah, good thinking. I rebuilt it in cross-complile mode and installed
>> it, now I see the blocks. I couldn't get it to run a flowgraph, so I
>> decided to cross-compile GR and reinstall that and did. I can open
>> GRC and drop blocks in, but when I go to run my VERY simple flowgraph,
>> GRC (I am running it with the ssh -X command) reports: "Done (return
>> code -11)"
>>
>> Any idea what I am missing there?
------------------------------
Message: 21
Date: Wed, 5 Jul 2017 14:44:08 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] start/stop usrp perfect
Message-ID: <36fd1e3a-d575-2ba9-2403-ec37f1a40...@ettus.com>
Content-Type: text/plain; charset=windows-1252
On 06/23/2017 04:31 AM, carry chen via USRP-users wrote:
> hi,list,
> how can I stop usrp perfect?
> if I want to start and stop usrp period quick(for examble do rssi scan
> with diffrent freq),how to do that?
> I find that if start and stop usrp frequently,I get some usb error.
> I use b205mini.
> Thanks.
Carry,
you'll need to provide some more information here on what you're trying
to do, and how you're doing it.
-- M
------------------------------
Message: 22
Date: Wed, 5 Jul 2017 14:44:39 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Complex FFT display of Frequency offset.
Message-ID: <75b091a2-8ec9-d8f1-4183-39e8a6c6c...@ettus.com>
Content-Type: text/plain; charset=utf-8
On 06/22/2017 06:34 PM, Walter Maguire via USRP-users wrote:
> Hi all.
>
> We were performing some basic Receiver tests on the E310 in RFNoC mode.
>
> A snapshot of my simple grc and associated outputs are shown in the
> attached screen shots.
>
> The RX frequency of the E310 is set to 836.5MHz. The sample rate is set
> to 1MHz. The center frequency on the QT Frequency Sink is set to 836.5
> MHz. If I apply a carrier only frequency at 836.5MHz then it appears
> as expected in the center of the frequency display. However, if I
> change the frequency of the carrier by +100KHz to 836.6MHz I see the
> carrier displayed at +300kHz offset or 836.8MHz. This does not seem to
> be correct. We would expect it to be at 836.6MHz I might expect a
> halving or doubling due to complex I/Q signals being 1/2 the BW. I
> don't understand why we see times 3 for the offset.
>
> I tested the QTGUI display using a complex sine wave and it works as
> expected that is at 0Hz it is in the center and the frequency displayed
> on the FFT track the frequency of the complex sine wave. Therefore I
> think the issue (or understanding) is in the E310.
For the record: This was resolved in the following thread.
-- M
------------------------------
Message: 23
Date: Wed, 5 Jul 2017 14:45:46 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Use of the drone DJI Matrix 100 with a radio
SDR B205 mini
Message-ID: <f79683f7-ebda-5637-2eaa-fce762609...@ettus.com>
Content-Type: text/plain; charset=utf-8
On 06/21/2017 11:27 PM, gauthier duchene via USRP-users wrote:
> Hello guys,
>
>
> During the last months I had the opportunity to work on a exciting
> project, the purpose was to work with a drone DJI Matrix 100 and a
> radio ETTUS USRP B205 mini in the same source code to carry out a tracking.
>
> The goal is to have an autonomous drone that is able to locate a missing
> person, to provide video footages of his location to the rescue team and
> create a mobile network to communicate with him. I put the Github link
> for those who would be interested in running these two devices together,
> there are the CmakeList to compile both.
Gauthier,
pretty cool! Have you considered submitting a PyBOMBS recipe for this?
Cheers,
Martin
------------------------------
Message: 24
Date: Wed, 5 Jul 2017 14:46:46 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] sensors values access when string
representation in gnu radio
Message-ID: <fcf6fc0e-85c4-dc71-f3fe-39c35da3b...@ettus.com>
Content-Type: text/plain; charset=windows-1252
On 06/21/2017 07:23 AM, LEMENAGER Claude via USRP-users wrote:
> Some additional information:
>
> GR 3.7.12, UHD 3.11.0 BOOST 1.58
>
> Public members (type, value?) are available when accessors (.to_bool(),
> .to_pp_string()?) make python to fail.
>
>
>
> Claude
>
>
>
> Hello,
>
>
>
> Developing a control box under gnu radio, the sensor_value_t type seems
> not defined in.
>
> I have seen usage of boost bind() to recover lock (get_mboard_sensor())
> in USRP_SINK impl but what when I want to obtain gpgga message (e.g. to
> set the system time or issue timed commands)
Claude,
can you post some failing code?
- M
------------------------------
Message: 25
Date: Wed, 5 Jul 2017 14:53:51 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] E310 Quickstart directions don't seem to
work
Message-ID: <513fa4e4-30a9-e6da-cdfe-9ee55b361...@ettus.com>
Content-Type: text/plain; charset=utf-8
Looks like the sshfs command is going one directory to high on the
hosting side (e.g., sshfs user@host:path/ instead of sshfs
user@host:path/usr/).
Cheers,
Martin
On 06/20/2017 06:03 AM, Jason Matusiak via USRP-users wrote:
> I got it. I needed to go into ~/usr/usr and change set_env to have
> LOCALPREFIX=~/usr/usr. Then once i sourced that set_env all was good.
>
>
> On 06/20/2017 08:33 AM, Jason Matusiak wrote:
>> I was attempting to muck with one of my E310s and decided to follow
>> the directions from here:
>> https://kb.ettus.com/Software_Development_on_the_E310_and_E312#QUICKSTART
>> to set it up for RFNoC.
>>
>> I followed the directions, but when I source the setup_env.sh in
>> /home/root/usr, nothing happens. Looking into the file, I see that it
>> is setting up all the directories to be the same as my host machine
>> (/home/jmat/prefix) instead of where they should be on the E310
>> (/home/root/usr).
>>
>> Is there a step missing from the directions that keep the paths from
>> being absolute? Otherwise, I don't see how the setup can work as-is.
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 26
Date: Wed, 5 Jul 2017 14:54:54 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] MIT Haystack Digital RF v2.5 open source
release
Message-ID: <d378de75-98b0-c1c0-dfdd-22580e00a...@ettus.com>
Content-Type: text/plain; charset=utf-8
This is awesome work. Thanks for making it open source!
Cheers,
Martin
On 06/17/2017 04:09 PM, Frank Lind via USRP-users wrote:
> MIT Haystack Observatory is pleased to announce the formal open source
> release of Digital RF version 2.5 under a BSD license. The software
> implements a data recording format for scientific radio frequency (RF)
> instrumentation using the HDF5 scientific data format. The implementation is
> designed for the management of highly time-dependent data from a large number
> of radio sensors. Applications include radio science (e.g., radio astronomy,
> geospace radar) and any project requiring the capture and use of RF data as
> raw digital samples.
>
> Key Digital RF features include:
>
> 1. Data is written in a very deterministic way that allows for both
> high-speed linear recording of data and O(1) read-back of arbitrary data
> intervals.
>
> 2. Consistent metadata is provided and a sub-library offers a robust means of
> creating time-dependent metadata to annotate the raw RF data.
>
> 3. Tools, examples, and interfaces are provided to demonstrate use of the
> software and to allow basic manipulation and visualization of the data.
>
> 4. The Haystack Observatory Recorder (thor) is provided as a data recording
> example for use with Ettus software radios (i.e., X300, N200, B210,
> B200mini).
>
> 5. The core implementation is written in the C programming language with a
> Python wrapper.
>
> 6. A MATLAB interface is provided for reading data.
>
> 7. An interface to popular software radio systems is provided through a
> plugin for the GNU radio framework.
>
> This work was supported by the National Science Foundation under the Geospace
> Facilities and MRI programs, and by National Instruments/Ettus Corporation
> through the donation of software radio hardware. We are grateful for the
> support that made this development possible.
>
> Digital RF is available on GitHub:
>
> https://github.com/MITHaystack/digital_rf
>
> We hope you find the software useful and can contribute to its future
> development. For discussions related to Digital RF, please use our mailing
> lists (openradar-develop...@openradar.org and openradar-us...@openradar.org).
>
> Regards,
>
> Frank Lind, Bill Rideout, Juha Vierinen, Ryan Volz, John Swoboda, and Phil
> Erickson
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 27
Date: Wed, 5 Jul 2017 17:55:22 -0400
From: Dave NotTelling <dmp250...@gmail.com>
To: Martin Braun <martin.br...@ettus.com>
Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] PPS get_time_last_pps()
Message-ID:
<CAK6GVuPUF-ZWn1w6aQpx=qkfxtqLOAsxgbYxeaFGS1ePQ=w...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks for the reply Martin! I tried using an FPGA to generate a nice 10
MHz and 1 PPS output, but I guess my matching was terrible. Looked great
on the scope, but looked like poo over an SMA cable. Almost 2 Vpp of
ringing O.o Finally found a timing card on eBay and will be giving that a
go.
On Wed, Jul 5, 2017 at 5:34 PM, Martin Braun via USRP-users <
usrp-users@lists.ettus.com> wrote:
> On 06/28/2017 11:03 AM, Dave NotTelling via USRP-users wrote:
> > I still think it's odd that the radio is drifting at 12-14 us per second
> > when using the PPS to sample the time. Am I incorrect in my assumption
> > that calls to get_time_last_pps() will work with just the PPS input and
> > no 10 MHz reference? If that does work, and my 1 PPS reference is
> > stable and accurate, then I would expect to see a very slow drift. In
> > my mind the clock on the radio should be almost as accurate as my timing
> > reference that is generating the 1 PPS output. Meaning that calls to
> > get_time_last_pps() should be almost exactly 1 second apart and should
> > show a time that is almost 1 second ahead of the last call. Granted, in
> > the long run the time will be wonky since there is no 10 MHz reference
> > to keep time rolling at an accurate rate, but in the short term (< 1
> > minute) I feel like things should be pretty spot on.
>
> It doesn't matter how stable your PPS is if your clock is not stable
> though. Let's assume your PPS is *perfect*. How many times does your
> clock toggle between two PPS flanks? That's unrelated. 10?s seems a lot
> though....
>
> But in general, a PPS by itself, and then using an internal clock
> source, is not a useful combination.
>
> Cheers,
> Martin
>
>
>
>
> >
> > On Wed, Jun 28, 2017 at 1:16 PM, Dave NotTelling <dmp250...@gmail.com
> > <mailto:dmp250...@gmail.com>> wrote:
> >
> > Just ran across an old version of this same question I asked a while
> > back (sorry for the dupe)
> >
> > [post]
> > To add to the comments, the USRP clock is virtually guaranteed to
> > drift away from the host system time if the time is set once and the
> > clocks on the host and USRP are left to run on their own oscillators
> > with no PLL between them. To keep a USRP synchronized in time takes
> > a 10 MHz reference to which the USRP can use to lock the PLL and
> > a PPS to make sure the time on the USRP is set at a precise moment.
> > Some USRPs (B2xxmini and E3xx) can lock the PLL to the PPS, so the
> > 10 MHz is not necessary, but they are far less accurate. Unless
> > your host system can put out a 10 MHz and PPS, the times will be
> > off. This is why a GPSDO is commonly used to synchronize devices
> > that are not close to each other and a common 10 MHz and PPS (i.e.
> > distributed by an Octoclock) is used to synchronize devices that are
> > close to each other.
> >
> > Also, the calls to getTime() and usrp->get_time_now() are not
> > synchronous or atomic and will have varying amounts of latency
> > between the return values so the accuracy of the measurement is
> > probably not very good at trying to measure something less than a
> > few milliseconds.
> > [/post]
> >
> > Seems that I completely goofed and I need *both* 10 MHz and 1 PPS :(
> >
> >
> > On Wed, Jun 28, 2017 at 12:57 PM, Dave NotTelling
> > <dmp250...@gmail.com <mailto:dmp250...@gmail.com>> wrote:
> >
> > Also, I updated to UHD_003.010.001.HEAD-0-gc705922a and got the
> > same issue of the time being off by ~ 14 us every second.
> >
> > On Wed, Jun 28, 2017 at 9:04 AM, Dave NotTelling
> > <dmp250...@gmail.com <mailto:dmp250...@gmail.com>> wrote:
> >
> > I just recently hooked my N210 up to a 1 PPS source and was
> > expecting that calls to radio->get_time_last_pps() would
> > return a number really close to 1 second from the previous
> > call. Instead I get the following:
> >
> > [output]
> >
> > $ g++ t.cc -o t -luhd -lboost_thread -lboost_system && ./t
> > linux; GNU C++ version 4.8.4; Boost_105400;
> > UHD_003.009.004-0-gfb928f42
> >
> > -- Opening a USRP2/N-Series device...
> > -- Current recv frame size: 1472 bytes
> > -- Current send frame size: 1472 bytes
> >
> > UHD Warning:
> > Unable to set the thread priority. Performance may be
> > negatively affected.
> > Please see the general application notes in the manual
> > for instructions.
> > EnvironmentError: OSError: error in pthread_setschedparam
> > 0.000012
> > 0.000024
> > 0.000035
> > 0.000047
> > 0.000059
> > 0.000071
> > 0.000083
> > 0.000094
> > 0.000106
> > 0.000118
> > 0.000130
> > 0.000142
> > 0.000153
> > 0.000165
> > 0.000177
> > 0.000189
> >
> > [/output]
> >
> > The drift is fairly constant at ~ 11-12 us per second. It
> > should be noted that I am not using a 10 MHz reference.
> > Just the 1 PPS.
> >
> > Here is the code I'm using:
> >
> > [code]
> >
> > #include <boost/thread.hpp>
> > #include <uhd/usrp/multi_usrp.hpp>
> >
> > int main(){
> > uhd::usrp::multi_usrp::sptr radio =
> > uhd::usrp::multi_usrp::make(std::string("addr=192.168.12.
> 2"));
> > radio->set_time_source("external");
> > radio->set_time_next_pps(uhd::time_spec_t(0, 0));
> > boost::this_thread::sleep_for(
> boost::chrono::seconds(2));
> >
> > while(1){
> > uhd::time_spec_t t = radio->get_time_last_pps();
> > fprintf(stderr, "%0.6f\n", t.get_frac_secs());
> >
> > boost::this_thread::sleep_for(boost::chrono::seconds(1));
> > }
> > }
> >
> > [/code]
> >
> > And here is the output of the test_pps_input command:
> >
> > [output]
> >
> > $ /tmp/test_pps_input --args addr=192.168.12.2
> > linux; GNU C++ version 4.8.4; Boost_105400;
> > UHD_003.009.004-0-gfb928f42
> >
> >
> > UHD Warning:
> > Unable to set the thread priority. Performance may be
> > negatively affected.
> > Please see the general application notes in the manual
> > for instructions.
> > EnvironmentError: OSError: error in pthread_setschedparam
> >
> > Creating the usrp device with: addr=192.168.12.2...
> > -- Opening a USRP2/N-Series device...
> > -- Current recv frame size: 1472 bytes
> > -- Current send frame size: 1472 bytes
> >
> > UHD Warning:
> > Unable to set the thread priority. Performance may be
> > negatively affected.
> > Please see the general application notes in the manual
> > for instructions.
> > EnvironmentError: OSError: error in pthread_setschedparam
> > Using Device: Single USRP:
> > Device: USRP2 / N-Series Device
> > Mboard 0: N210r4
> > RX Channel: 0
> > RX DSP: 0
> > RX Dboard: A
> > RX Subdev: UBX RX
> > TX Channel: 0
> > TX DSP: 0
> > TX Dboard: A
> > TX Subdev: UBX TX
> >
> >
> > Attempt to detect the PPS and set the time...
> >
> > -- 1) catch time transition at pps edge
> > -- 2) set times next pps (synchronously)
> >
> > Success!
> >
> > [/output]
> >
> > Am I doing something wrong?
> >
> >
> > Thanks!
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> 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/20170705/c5e0b65f/attachment-0001.html>
------------------------------
Message: 28
Date: Wed, 5 Jul 2017 14:56:37 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] MIT Haystack Digital RF v2.5 open source
release
Message-ID: <84f2b92c-92f3-a3bb-302f-9dae1e82a...@ettus.com>
Content-Type: text/plain; charset=utf-8
Have you considered supporting SigMF format in addition to HDF5 (with
which I'm not at all familiar) for storing data?
https://github.com/gnuradio/SigMF
Cheers,
Martin
On 06/17/2017 04:09 PM, Frank Lind via USRP-users wrote:
> MIT Haystack Observatory is pleased to announce the formal open source
> release of Digital RF version 2.5 under a BSD license. The software
> implements a data recording format for scientific radio frequency (RF)
> instrumentation using the HDF5 scientific data format. The implementation is
> designed for the management of highly time-dependent data from a large number
> of radio sensors. Applications include radio science (e.g., radio astronomy,
> geospace radar) and any project requiring the capture and use of RF data as
> raw digital samples.
>
> Key Digital RF features include:
>
> 1. Data is written in a very deterministic way that allows for both
> high-speed linear recording of data and O(1) read-back of arbitrary data
> intervals.
>
> 2. Consistent metadata is provided and a sub-library offers a robust means of
> creating time-dependent metadata to annotate the raw RF data.
>
> 3. Tools, examples, and interfaces are provided to demonstrate use of the
> software and to allow basic manipulation and visualization of the data.
>
> 4. The Haystack Observatory Recorder (thor) is provided as a data recording
> example for use with Ettus software radios (i.e., X300, N200, B210,
> B200mini).
>
> 5. The core implementation is written in the C programming language with a
> Python wrapper.
>
> 6. A MATLAB interface is provided for reading data.
>
> 7. An interface to popular software radio systems is provided through a
> plugin for the GNU radio framework.
>
> This work was supported by the National Science Foundation under the Geospace
> Facilities and MRI programs, and by National Instruments/Ettus Corporation
> through the donation of software radio hardware. We are grateful for the
> support that made this development possible.
>
> Digital RF is available on GitHub:
>
> https://github.com/MITHaystack/digital_rf
>
> We hope you find the software useful and can contribute to its future
> development. For discussions related to Digital RF, please use our mailing
> lists (openradar-develop...@openradar.org and openradar-us...@openradar.org).
>
> Regards,
>
> Frank Lind, Bill Rideout, Juha Vierinen, Ryan Volz, John Swoboda, and Phil
> Erickson
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 29
Date: Wed, 5 Jul 2017 14:58:49 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] UHD support to Ubuntu 17.04
Message-ID: <bf9c4e85-69e4-7216-ac5a-9a23619f6...@ettus.com>
Content-Type: text/plain; charset=windows-1252
Carlos,
we'll be adding 17.04 to the PPA before the next release. You can build
debs from source, too.
Cheers,
Martin
On 06/14/2017 09:02 AM, Carlos Moriana Varo via USRP-users wrote:
> I am trying to install the UHD drivers in Ubuntu 17.04, but I get
> problems adding the ppa repository since it seems that the version for
> this distribution has not been released yet. Is there any idea of when
> this will be compatible? Otherwise I would be forced to downgrade to 16.04?
>
>
> PPlease consider the environment before printing this e-mail.
>
> ------------------------------------------------------------------------
> This message including any attachments may contain confidential
> information, according to our Information Security Management System,
> and intended solely for a specific individual to whom they are
> addressed. Any unauthorised copy, disclosure or distribution of this
> message is strictly forbidden. If you have received this transmission in
> error, please notify the sender immediately and delete it. Thank you.
> ------------------------------------------------------------------------
> Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede
> contener informaci?n clasificada por su emisor como confidencial en el
> marco de su Sistema de Gesti?n de Seguridad de la Informaci?n siendo
> para uso exclusivo del destinatario, quedando prohibida su divulgaci?n
> copia o distribuci?n a terceros sin la autorizaci?n expresa del
> remitente. Si Vd. ha recibido este mensaje err?neamente, se ruega lo
> notifique al remitente y proceda a su borrado. Gracias por su colaboraci?n.
> ------------------------------------------------------------------------
> Esta mensagem, incluindo qualquer ficheiro anexo, pode conter informa??o
> confidencial, de acordo com nosso Sistema de Gest?o de Seguran?a da
> Informa??o, sendo para uso exclusivo do destinat?rio e estando proibida
> a sua divulga??o, c?pia ou distribui??o a terceiros sem autoriza??o
> expressa do remetente da mesma. Se recebeu esta mensagem por engano, por
> favor avise de imediato o remetente e apague-a. Obrigado pela sua
> colabora??o.
> ------------------------------------------------------------------------
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 30
Date: Wed, 5 Jul 2017 14:59:57 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] TDMA based Multiple Access Channel using NI
USRP 2901
Message-ID: <ef805fa6-741d-deea-2dfe-1da968f58...@ettus.com>
Content-Type: text/plain; charset=utf-8
Ammar,
can you break this down into more specific requirements? Otherwise,
you'll probably not get a response.
Cheers,
Martin
On 06/13/2017 10:37 PM, Ammar Mahmood via USRP-users wrote:
> Hi,
>
> I am using an experimental setup using two transmitters and one
> receiver. I want only one transmitter to transmit at a given time so as
> to avoid collisions. For this purpose, I want to create a TDMA based
> multiple access channel using NI USRP 2901. How can I achieve this task?
>
> Best,
> Ammar
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 31
Date: Wed, 5 Jul 2017 15:01:15 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] ADC self-test failed
Message-ID: <70ef744e-cc04-0027-d96a-abcfce460...@ettus.com>
Content-Type: text/plain; charset=utf-8
Does this happen intermittently? Or every time?
-- M
On 06/13/2017 01:55 PM, Sam Vogel via USRP-users wrote:
> Hi All, I?m running into an issue with our x300 revision E. Any help
> resolving this is greatly appreciated.
>
> Following the procedure to recover the EEPROM yields a problem.
>
> [vogels@lprbld12 utils]$ ./usrp_burn_mb_eeprom
> --args="recover_mb_eeprom,addr=192.167.10.111" --values="revision=5"
>
> Creating USRP device from address: recover_mb_eeprom,addr=192.167.10.111
>
> -- X300 initialization sequence...
>
> -- Determining maximum frame size... 8000 bytes.
>
> -- Setup basic communication...
>
> -- Loading values from EEPROM...
>
>
>
> UHD Warning:
>
> UHD is operating in EEPROM Recovery Mode which disables hardware
> version checks.
>
> Operating in this mode may cause hardware damage and unstable radio
> performance!
>
> -- Setup RF frontend clocking...
>
>
>
> UHD Warning:
>
> Environment variable 'USRP_X300_REFERENCE_CLOCK_RATE_HZ' not found,
> defaulting to reference clock rate of 10000000.000000 Hz
>
> -- Using specified reference / master clock rates of 10.0 / 200.0 MHz
>
> -- Radio 1x clock:200
>
> -- Initialize Radio0 control...
>
> -- Performing register loopback test... pass
>
> -- Initialize Radio1 control...
>
> -- Performing register loopback test... pass
>
> Error: RuntimeError: ADC self-test failed! Ramp checker status:
> {ADC0_I=Bit Errors!, ADC0_Q=Bit Errors!, ADC1_I=Good, ADC1_Q=Good}
>
>
>
> Thanks !
>
> -Sam
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 32
Date: Wed, 5 Jul 2017 15:04:56 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Difference between Clock Recovery and Audio
rate synchronization.
Message-ID: <cf137d96-c928-27ed-c957-a5fc92c5c...@ettus.com>
Content-Type: text/plain; charset=windows-1252
On 06/10/2017 07:39 AM, Benny Alexandar via USRP-users wrote:
> Hi,
>
>
> If I understood correctly, clock recovery is for demodulation of
> digital signals,
>
> where as audio rate synchronization is matching the audio output
> frequency to transmitter
Ben,
was there a question here? If so, can you please elaborate?
-- M
------------------------------
Message: 33
Date: Wed, 5 Jul 2017 18:08:10 -0400
From: Sam Vogel <smvogel...@gmail.com>
To: Martin Braun <martin.br...@ettus.com>
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] ADC self-test failed
Message-ID:
<CACjmUqg=cYY57bD=Fb6SRH2D+tDf3eTMgXZydbA9=j00q1b...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
This happens every time.
Thanks,
Sam
On Wed, Jul 5, 2017 at 6:01 PM, Martin Braun via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Does this happen intermittently? Or every time?
>
> -- M
>
> On 06/13/2017 01:55 PM, Sam Vogel via USRP-users wrote:
> > Hi All, I?m running into an issue with our x300 revision E. Any help
> > resolving this is greatly appreciated.
> >
> > Following the procedure to recover the EEPROM yields a problem.
> >
> > [vogels@lprbld12 utils]$ ./usrp_burn_mb_eeprom
> > --args="recover_mb_eeprom,addr=192.167.10.111" --values="revision=5"
> >
> > Creating USRP device from address: recover_mb_eeprom,addr=192.167.10.111
> >
> > -- X300 initialization sequence...
> >
> > -- Determining maximum frame size... 8000 bytes.
> >
> > -- Setup basic communication...
> >
> > -- Loading values from EEPROM...
> >
> >
> >
> > UHD Warning:
> >
> > UHD is operating in EEPROM Recovery Mode which disables hardware
> > version checks.
> >
> > Operating in this mode may cause hardware damage and unstable radio
> > performance!
> >
> > -- Setup RF frontend clocking...
> >
> >
> >
> > UHD Warning:
> >
> > Environment variable 'USRP_X300_REFERENCE_CLOCK_RATE_HZ' not found,
> > defaulting to reference clock rate of 10000000.000000 Hz
> >
> > -- Using specified reference / master clock rates of 10.0 / 200.0 MHz
> >
> > -- Radio 1x clock:200
> >
> > -- Initialize Radio0 control...
> >
> > -- Performing register loopback test... pass
> >
> > -- Initialize Radio1 control...
> >
> > -- Performing register loopback test... pass
> >
> > Error: RuntimeError: ADC self-test failed! Ramp checker status:
> > {ADC0_I=Bit Errors!, ADC0_Q=Bit Errors!, ADC1_I=Good, ADC1_Q=Good}
> >
> >
> >
> > Thanks !
> >
> > -Sam
> >
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> 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/20170705/313909c1/attachment-0001.html>
------------------------------
Message: 34
Date: Wed, 5 Jul 2017 16:24:51 -0700
From: Nate Temple <nate.tem...@ettus.com>
To: Martin Braun <martin.br...@ettus.com>
Cc: USRP-users <usrp-users@lists.ettus.com>, cmori...@gmv.com
Subject: Re: [USRP-users] UHD support to Ubuntu 17.04
Message-ID: <7a0ba53a-c8d1-4e34-9a97-1c575ffb2...@ettus.com>
Content-Type: text/plain; charset=windows-1252
Hi Carlos,
You can also at this time build and install from source, which we have tested
on Ubuntu 17.04. The Application Note here [1] covers the process step-by-step.
Regards,
Nate Temple
[1] -
https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux
> On Jul 5, 2017, at 2:58 PM, Martin Braun via USRP-users
> <usrp-users@lists.ettus.com> wrote:
>
> Carlos,
>
> we'll be adding 17.04 to the PPA before the next release. You can build
> debs from source, too.
>
> Cheers,
> Martin
>
> On 06/14/2017 09:02 AM, Carlos Moriana Varo via USRP-users wrote:
>> I am trying to install the UHD drivers in Ubuntu 17.04, but I get
>> problems adding the ppa repository since it seems that the version for
>> this distribution has not been released yet. Is there any idea of when
>> this will be compatible? Otherwise I would be forced to downgrade to 16.04?
>>
>>
>> PPlease consider the environment before printing this e-mail.
>>
>> ------------------------------------------------------------------------
>> This message including any attachments may contain confidential
>> information, according to our Information Security Management System,
>> and intended solely for a specific individual to whom they are
>> addressed. Any unauthorised copy, disclosure or distribution of this
>> message is strictly forbidden. If you have received this transmission in
>> error, please notify the sender immediately and delete it. Thank you.
>> ------------------------------------------------------------------------
>> Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede
>> contener informaci?n clasificada por su emisor como confidencial en el
>> marco de su Sistema de Gesti?n de Seguridad de la Informaci?n siendo
>> para uso exclusivo del destinatario, quedando prohibida su divulgaci?n
>> copia o distribuci?n a terceros sin la autorizaci?n expresa del
>> remitente. Si Vd. ha recibido este mensaje err?neamente, se ruega lo
>> notifique al remitente y proceda a su borrado. Gracias por su colaboraci?n.
>> ------------------------------------------------------------------------
>> Esta mensagem, incluindo qualquer ficheiro anexo, pode conter informa??o
>> confidencial, de acordo com nosso Sistema de Gest?o de Seguran?a da
>> Informa??o, sendo para uso exclusivo do destinat?rio e estando proibida
>> a sua divulga??o, c?pia ou distribui??o a terceiros sem autoriza??o
>> expressa do remetente da mesma. Se recebeu esta mensagem por engano, por
>> favor avise de imediato o remetente e apague-a. Obrigado pela sua
>> colabora??o.
>> ------------------------------------------------------------------------
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 35
Date: Wed, 5 Jul 2017 16:54:15 -0700
From: Nate Temple <nate.tem...@ettus.com>
To: Haile Berhe <haile1...@gmail.com>
Cc: Zhihong Luo via USRP-users <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] How to solve command timeout error?
Message-ID:
<cal263iyo-cf5hy-5rv-rat04oevtyz7e-xqps8qprfdyb80...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Haile,
Sorry for missing this post. When you're stopping the flowgraph, are you
using the "X" in the corner of the running flowgraph, or are you using the
"Kill Flowgraph" button within GRC ? Using the "Kill flowgraph" button will
not properly free up the internal resources, and can cause this error.
However using the "X"/Close button in the corner within the running
flowgraph will allow the resources to be freed.
Regards,
Nate Temple
On Tue, May 9, 2017 at 1:36 AM, Haile Berhe via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Dear all,
> I have been working on my X310 USRP just fine. But after I have
> installed rfnoc modules and reload fpga images , the behavior of the
> device becomes unpredictable. It sometimes throws the following error
> message even if I run non rfnoc application:
>
> ?RuntimeError: EnvironmentError: IOError: Block ctrl (CE_00_Port_30)
> no response packet - AssertionError: bool(buff)
> in uint64_t ctrl_iface_impl::wait_for_ack(bool)
> at /home/haile/prefix/default/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:197?
>
> I have observed that the above error is not thrown in the first run
> after I power cycle the device. [1] seems to discuss the issue but the
> proposed solution is not clear. It says, check ce_clk/ce_rst are
> connected in the rfnoc_ce_auto_inst_<device>.v., etc .. How am I
> supposed to check?
>
> Thanks,
>
> [1] https://kb.ettus.com/RFNoC
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> 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/20170705/81fcb741/attachment-0001.html>
------------------------------
Message: 36
Date: Wed, 5 Jul 2017 17:03:51 -0700
From: Nate Temple <nate.tem...@ettus.com>
To: Jessica Iwamoto <jessica.iwam...@aero.org>
Cc: usrp-users <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Issue running UHD via sshfs on E310
Message-ID:
<cal263iwizj1ancss3qfq3xtzitq3kmvgddbly6nqb5eqjwt...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Jessica,
Sorry for missing this thread. If you init a new directory and build from
the current master sources, it should resolve this issue. This
initialization error for the E3xx was resolved with this commit:
https://github.com/EttusResearch/uhd/commit/b082aa444c126703980eb973c476767dce80c3ed
Regards,
Nate Temple
On Thu, Apr 27, 2017 at 3:37 PM, Jessica Iwamoto via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi all,
>
>
>
> I am following the instructions here (https://kb.ettus.com/
> Software_Development_on_the_E310_and_E312) to build the SDK and cross
> compiling setup for the E310, however, I am running into some issues with
> UHD. After following all the steps in the link above, up to installing UHD,
> I tried to run one of the UHD examples but it seems to get stuck. I got the
> following output when running the benchmark_rate example:
>
>
>
> ./benchmark_rate --tx_rate 1e6
>
> [INFO] [UHD] linux; GNU C++ version 4.9.2; Boost_105700;
> UHD_3.11.0.git-162-g2790b51f
>
>
>
> Creating the usrp device with: ...
>
> [INFO] [E300] Loading FPGA image: /usr/share/uhd/images/usrp_
> e310_fpga.bit...
>
> [INFO] [E300] FPGA image loaded
>
> [INFO] [E300] Initializing core control...
>
> [INFO] [E300] Performing register loopback test...
>
> [INFO] [E300] Register loopback test passed
>
>
>
> After this the program gets stuck and just hangs at this point. Any help
> would be appreciated!
>
>
>
> Thanks,
>
> Jessica
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> 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/20170705/2214df6c/attachment-0001.html>
------------------------------
Message: 37
Date: Wed, 5 Jul 2017 17:17:07 -0700
From: Nate Temple <nate.tem...@ettus.com>
To: Darek Kawamoto <darek.kawam...@gmail.com>
Cc: Zhihong Luo via USRP-users <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] E312 SD Card File System Corruption
Message-ID:
<CAL263iyZGuhVS7L225xfT9vBg=8f9ejrqdvb0j88r5j5mb9...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Darek,
Were you able to resolve this? Does the problematic E312 work with a fresh
release-4 image?
Are you trying to copy it to /prefix/ or to a subdirectory within your
/home/root (/home/root/prefix/) ?
What happens if you mount a remote file system via SSHFS and then copy the
files via the mounted location, to avoid scp ?
Regards,
Nate Temple
On Tue, May 16, 2017 at 2:49 PM, Darek Kawamoto via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hey all,
>
> I've got an E312 that I'm working on, and whenever I try to scp my working
> prefix onto the SD card I get a bunch of errors seemingly related to the SD
> card. In my scp output I get errors like this for each remaining file:
>
> scp: /prefix/lib/libgnuradio-runtime-3.7.12git.so.0.0.0: Read-only file
> system
>
> And the dmesg on the E312 says a ton stuff like this:
>
> [ 407.967600] end_request: I/O error, dev mmcblk0, sector 11386400
> [ 407.983805] mmc0: Controller never released inhibit bit(s).
> [ 407.991328] mmcblk0: error -5 sending status command, retrying
> [ 407.999109] mmcblk0: error -110 sending status command, retrying
> [ 408.007060] mmcblk0: error -110 sending status command, aborting
> [ 408.051219] mmc0: Controller never released inhibit bit(s).
> [ 408.058776] mmcblk0: error -5 sending status command, retrying
> [ 408.066598] mmcblk0: error -110 sending status command, retrying
> [ 408.074595] mmcblk0: error -110 sending status command, aborting
> [ 408.080598] EXT4-fs warning (device mmcblk0p2):
> __ext4_read_dirblock:908: error reading directory block (ino 1312422, block
> 0)
> [ 409.148499] mmc0: Controller never released inhibit bit(s).
> [ 409.156026] mmcblk0: error -5 sending status command, retrying
> [ 409.163825] mmcblk0: error -110 sending status command, retrying
> [ 409.171804] mmcblk0: error -110 sending status command, aborting
> [ 409.177727] blk_update_request: 2 callbacks suppressed
> [ 409.182862] end_request: I/O error, dev mmcblk0, sector 21140864
>
> etc. etc.
> I'm able to put this SD card into another E312 which doesn't have this
> problem and things work just fine. If I move a known-working SD card from
> the working E312 into the broken one, this problem happens. So this seems
> to indicate that the broken part is not the SD card.
>
> Has anyone seen this before / any ideas on how to fix this?
>
> Darek
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> 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/20170705/aa5716f3/attachment-0001.html>
------------------------------
Message: 38
Date: Wed, 5 Jul 2017 17:21:03 -0700
From: Nate Temple <nate.tem...@ettus.com>
To: Jane Abad Jaume <jjanea...@cls.fr>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] E310 Cross-Compiled UHD Error - key
"product" not found
Message-ID:
<cal263ixfwgsy5twarx7iodd09ecnftarhnjonmrwpnnwheb...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Jaume,
Can you please try rebuilding the cross-compiled environment with the
current master sources? Does the new build resolve the issue?
Regards,
Nate Temple
On Thu, May 18, 2017 at 2:57 AM, Jane Abad Jaume via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi,
>
> I'm trying to cross-compile the UHD for the E310 in a Ubuntu before
> cross-compiling OOT custom blocks.
>
> I've followed the instructions of
> https://kb.ettus.com/Software_Development_on_the_E310_and_E312. I've
> successfully mounted the prefix into the embedded device and set-up the
> enviroment variables with set_env.
>
> But when I run uhd_usrp_probe or any other example, it always returns
> Error: LookupError: KeyError: key "product" not found in dict(Ss, Ss).
> How can I solve that?
>
> Thanks!
>
>
> Regards,
>
> Jaume
>
>
> ## COMMANDS
>
> root@ettus-e3xx-sg3:~/usr/usr# cat set_env
> LOCALPREFIX=~/usr/usr
> export PATH=$LOCALPREFIX/bin:$PATH
> export LD_LOAD_LIBRARY=$LOCALPREFIX/lib:$LD_LOAD_LIBRARY
> export LD_LIBRARY_PATH=$LOCALPREFIX/lib:$LD_LIBRARY_PATH
> export PYTHONPATH=$LOCALPREFIX/lib/python2.7/site-packages:$PYTHONPATH
> export PKG_CONFIG_PATH=$LOCALPREFIX/lib/pkgconfig:$PKG_CONFIG_PATH
> export
> GRC_BLOCKS_PATH=$LOCALPREFIX/share/gnuradio/grc/blocks:$GRC_BLOCKS_PATH
> export UHD_RFNOC_DIR=$LOCALPREFIX/share/uhd/rfnoc/
> export UHD_IMAGES_DIR=$LOCALPREFIX/share/uhd/images
>
>
> root@ettus-e3xx-sg3:~/usr/usr/lib/uhd/examples# which uhd_find_devices
> /home/root/usr/usr/bin/uhd_find_devices
>
>
> root@ettus-e3xx-sg3:~/usr/usr/lib/uhd/examples# uhd_find_devices
> [INFO] [UHD] linux; GNU C++ version 4.9.2; Boost_105700;
> UHD_4.0.0.rfnoc-devel-316-g24b98579
> --------------------------------------------------
> -- UHD Device 0
> --------------------------------------------------
> Device Address:
> serial:
> name:
> node: /dev/axi_fpga
> type: e3x0
>
>
> root@ettus-e3xx-sg3:~/usr/usr/lib/uhd/examples# uhd_usrp_probe
> [INFO] [UHD] linux; GNU C++ version 4.9.2; Boost_105700;
> UHD_4.0.0.rfnoc-devel-316-g24b98579
> Error: LookupError: KeyError: key "product" not found in dict(Ss, Ss)
>
>
> ## SD IMAGE BUILD VERSION
>
> root@ettus-e3xx-sg3:~# cat /etc/version-image
> Timestamp: 201601150121
> Release: Release-4
> Image: gnuradio-dev-image
>
>
> root@ettus-e3xx-sg3:~# cat /etc/build
> -----------------------
> Build Configuration: |
> -----------------------
> DISTRO = nodistro
> DISTRO_VERSION = nodistro.0
> -----------------------
> Layer Revisions: |
> -----------------------
> meta = (nobranch):9f339f516ab03d598fae0e536b3a420ea4d8ee1a
> e100-bsp =
> (detachedfrom40cf300):40cf300296b889df5b8445bf7db457c160220919
> e300-bsp =
> (detachedfrom40cf300):40cf300296b889df5b8445bf7db457c160220919
> common =
> (detachedfrom40cf300):40cf300296b889df5b8445bf7db457c160220919
> meta-xilinx = (nobranch):13779b9254bab450875a60ed8f21edd0e8876a71
> meta-oe = (nobranch):e8a8e0be8e39dbb949bf0f0df90abe1c4e3f6470
> meta-networking = (nobranch):e8a8e0be8e39dbb949bf0f0df90abe1c4e3f6470
> meta-python = (nobranch):e8a8e0be8e39dbb949bf0f0df90abe1c4e3f6470
> meta-filesystems = (nobranch):e8a8e0be8e39dbb949bf0f0df90abe1c4e3f6470
> meta-sdr =
> (detachedfrom3d06bc0):3d06bc06e874dc3b8db64fc1bf838763f834d193
>
>
>
>
>
>
>
>
>
> ________________________________
>
> Ce message et toutes les pi?ces jointes (ci-apr?s le "message") sont
> ?tablis ? l'intention exclusive de ses destinataires et sont confidentiels.
> Si vous recevez ce message par erreur ou s'il ne vous est pas destin?,
> merci de le d?truire ainsi que toute copie de votre syst?me et d'en avertir
> imm?diatement l'exp?diteur. Toute lecture non autoris?e, toute utilisation
> de ce message qui n'est pas conforme ? sa destination, toute diffusion ou
> toute publication, totale ou partielle, est interdite. L'Internet ne
> permettant pas d'assurer l'int?grit? de ce message ?lectronique susceptible
> d'alt?ration, l?exp?diteur (et ses filiales) d?cline(nt) toute
> responsabilit? au titre de ce message dans l'hypoth?se o? il aurait ?t?
> modifi? ou falsifi?.
>
> This message and any attachments (the "message") is intended solely for
> the intended recipient(s) and is confidential. If you receive this message
> in error, or are not the intended recipient(s), please delete it and any
> copies from your systems and immediately notify the sender. Any
> unauthorized view, use that does not comply with its purpose, dissemination
> or disclosure, either whole or partial, is prohibited. Since the internet
> cannot guarantee the integrity of this message which may not be reliable,
> the sender (and its subsidiaries) shall not be liable for the message if
> modified or falsified.
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> 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/20170705/9ed2b5c1/attachment-0001.html>
------------------------------
Message: 39
Date: Wed, 5 Jul 2017 17:26:05 -0700
From: Nate Temple <nate.tem...@ettus.com>
To: Rom?n Rodr?guez P?rez <rrpe...@gmv.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] USB 3.0 connection problems (USRP 205mini +
ODROID XU4)
Message-ID:
<cal263iw1ohz7bjllutz-ua9xupyfhu1brgk3tk+ypqyxd39...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Rom?n,
I've seen previous mailing list / forum posts where users have had issues
with the XU4 USB controller. I've personally had success using the XU4 with
a B205mini, and others have as well.
Your uhd-usrp.rules file is fine to copy. However I suspect it might be a
power issue. I would suggest trying a USB3 Y cable that will allow an
additional power input to power the USRP, that may help.
Regards,
Nate Temple
On Thu, Jun 1, 2017 at 5:25 AM, Rom?n Rodr?guez P?rez via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi,
>
>
>
> We are having connectivity problems through USB 3.0 with an USRP 205 mini.
> We have successfully tested it in a laptop, and it is our intention to
> control the USRP with a Raspberry-like mini computer. We have chosen ODROID
> XU4 because it has USB3.0 ports available, and runs Ubuntu 16.04.
>
>
>
> The problem is that uhd_find_devices command does not find the USRP when
> connected to an USB3.0 port. It does find it when connected to a USB2.0
> port and works correctly (but obviously with limited velocity).
>
>
>
> I found out in ODROID forums that many XU4 devices came with an excess of
> flux in the USB 3.0 signal pads (https://forum.odroid.com/
> viewtopic.php?f=95&t=15302) but nothing changed after cleaning with
> alcohol.
>
>
>
> When I run ldusb and ldusb ?t commands, I get the following output:
>
> roman@odroid:~$ lsusb
>
> Bus 006 Device 002: ID 0bda:8153 Realtek Semiconductor Corp.
>
> Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
>
> Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>
> Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
>
> Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>
> Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
>
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>
> roman@odroid:~$ lsusb -t
>
> /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
>
> |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152,
> 5000M
>
> /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
>
> /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
>
> /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
>
> /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M
>
> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=exynos-ehci/3p, 480M
>
> roman@odroid:~$ uhd_find_devices
>
> linux; GNU C++ version 5.3.1 20151219; Boost_105800;
> UHD_003.009.002-0-unknown
>
>
>
> No UHD Devices Found
>
>
>
>
>
> On the other hand, I found this stackoverflow thread where Marcus M?ller
> answered (https://stackoverflow.com/questions/33304828/when-
> trying-to-use-my-usrp-in-gnu-radio-i-get-a-no-devices-found-for), which
> states that ?Some USB3 host controllers don't behave standards-conforming,
> and connectivity cannot be achieved. If your USRP is detected when plugged
> into a USB2 port (anyone that isn't blue, usually), you should be fine.?
>
>
>
> I also found this thread from this very same mailing list
> (http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-June/014598.html)
> which states that ?*there are USB-3.0 controllers that simply won't work
> with any FX3-based device, like the B210?. *ODROID user manual suggests that
> the USB 3.0 controller is a Genesys GL3521 , which I don?t know it it is
> compatible with USRP 205mini.
>
>
>
> Finally, following the instructions of the USRP manual
> (http://files.ettus.com/manual/page_transport.html#transport_usb) , I looked
> for uhd-usrp.rules file in /etc/udev/rules.d/, but did not find it. I tried
> copying the one at my Ubuntu laptop were I tested the USRP, which contains
> the following information:
>
>
>
> #USRP1
>
> SUBSYSTEMS=="usb", ATTRS{idVendor}=="fffe", ATTRS{idProduct}=="0002",
> MODE:="0666"
>
>
>
> #B100
>
> SUBSYSTEMS=="usb", ATTRS{idVendor}=="2500", ATTRS{idProduct}=="0002",
> MODE:="0666"
>
>
>
> #B200
>
> SUBSYSTEMS=="usb", ATTRS{idVendor}=="2500", ATTRS{idProduct}=="0020",
> MODE:="0666"
>
> SUBSYSTEMS=="usb", ATTRS{idVendor}=="2500", ATTRS{idProduct}=="0021",
> MODE:="0666"
>
> SUBSYSTEMS=="usb", ATTRS{idVendor}=="2500", ATTRS{idProduct}=="0022",
> MODE:="0666"
>
> SUBSYSTEMS=="usb", ATTRS{idVendor}=="3923", ATTRS{idProduct}=="7813",
> MODE:="0666"
>
> SUBSYSTEMS=="usb", ATTRS{idVendor}=="3923", ATTRS{idProduct}=="7814",
> MODE:="0666"
>
>
>
> Nevermind, it did not work either.
>
>
>
> Any suggestion of how to proceed?
>
> Best regards
>
> P Please consider the environment before printing this e-mail.
>
> ------------------------------
> This message including any attachments may contain confidential
> information, according to our Information Security Management System, and
> intended solely for a specific individual to whom they are addressed. Any
> unauthorised copy, disclosure or distribution of this message is strictly
> forbidden. If you have received this transmission in error, please notify
> the sender immediately and delete it. Thank you.
> ------------------------------
> Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede
> contener informaci?n clasificada por su emisor como confidencial en el
> marco de su Sistema de Gesti?n de Seguridad de la Informaci?n siendo para
> uso exclusivo del destinatario, quedando prohibida su divulgaci?n copia o
> distribuci?n a terceros sin la autorizaci?n expresa del remitente. Si Vd.
> ha recibido este mensaje err?neamente, se ruega lo notifique al remitente y
> proceda a su borrado. Gracias por su colaboraci?n.
> ------------------------------
> Esta mensagem, incluindo qualquer ficheiro anexo, pode conter informa??o
> confidencial, de acordo com nosso Sistema de Gest?o de Seguran?a da
> Informa??o, sendo para uso exclusivo do destinat?rio e estando proibida a
> sua divulga??o, c?pia ou distribui??o a terceiros sem autoriza??o expressa
> do remetente da mesma. Se recebeu esta mensagem por engano, por favor avise
> de imediato o remetente e apague-a. Obrigado pela sua colabora??o.
> ------------------------------
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> 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/20170705/492a2a40/attachment-0001.html>
------------------------------
Message: 40
Date: Wed, 5 Jul 2017 17:29:07 -0700
From: Nate Temple <nate.tem...@ettus.com>
To: Sam Vogel <smvogel...@gmail.com>
Cc: Martin Braun <martin.br...@ettus.com>, Zhihong Luo via USRP-users
<usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] ADC self-test failed
Message-ID:
<cal263ixsopispos1kp7zx0-9ryd0dwf5ftofgmssss6kvpd...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Sam,
Which version of UHD are you using? (uhd_usrp_probe --version)
Have you recently updated UHD, or has anything changed in your setup from
when it was previously work to now?
Regards,
Nate Temple
On Wed, Jul 5, 2017 at 3:08 PM, Sam Vogel via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi,
>
> This happens every time.
>
> Thanks,
> Sam
>
> On Wed, Jul 5, 2017 at 6:01 PM, Martin Braun via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Does this happen intermittently? Or every time?
>>
>> -- M
>>
>> On 06/13/2017 01:55 PM, Sam Vogel via USRP-users wrote:
>> > Hi All, I?m running into an issue with our x300 revision E. Any help
>> > resolving this is greatly appreciated.
>> >
>> > Following the procedure to recover the EEPROM yields a problem.
>> >
>> > [vogels@lprbld12 utils]$ ./usrp_burn_mb_eeprom
>> > --args="recover_mb_eeprom,addr=192.167.10.111" --values="revision=5"
>> >
>> > Creating USRP device from address: recover_mb_eeprom,addr=192.167
>> .10.111
>> >
>> > -- X300 initialization sequence...
>> >
>> > -- Determining maximum frame size... 8000 bytes.
>> >
>> > -- Setup basic communication...
>> >
>> > -- Loading values from EEPROM...
>> >
>> >
>> >
>> > UHD Warning:
>> >
>> > UHD is operating in EEPROM Recovery Mode which disables hardware
>> > version checks.
>> >
>> > Operating in this mode may cause hardware damage and unstable radio
>> > performance!
>> >
>> > -- Setup RF frontend clocking...
>> >
>> >
>> >
>> > UHD Warning:
>> >
>> > Environment variable 'USRP_X300_REFERENCE_CLOCK_RATE_HZ' not found,
>> > defaulting to reference clock rate of 10000000.000000 Hz
>> >
>> > -- Using specified reference / master clock rates of 10.0 / 200.0 MHz
>> >
>> > -- Radio 1x clock:200
>> >
>> > -- Initialize Radio0 control...
>> >
>> > -- Performing register loopback test... pass
>> >
>> > -- Initialize Radio1 control...
>> >
>> > -- Performing register loopback test... pass
>> >
>> > Error: RuntimeError: ADC self-test failed! Ramp checker status:
>> > {ADC0_I=Bit Errors!, ADC0_Q=Bit Errors!, ADC1_I=Good, ADC1_Q=Good}
>> >
>> >
>> >
>> > Thanks !
>> >
>> > -Sam
>> >
>> >
>> >
>> > _______________________________________________
>> > USRP-users mailing list
>> > USRP-users@lists.ettus.com
>> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> >
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> 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/20170705/5a52a1ae/attachment-0001.html>
------------------------------
Message: 41
Date: Wed, 5 Jul 2017 17:47:32 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Pause after "Register loopback test passed"
Message-ID: <123d50a4-83d2-22e4-e56a-8e11a78c4...@ettus.com>
Content-Type: text/plain; charset=windows-1252
Can you increase the log level and try again? You'll need to set
UHD_LOG_MIN_LEVEL to trace and then export UHD_LOG_LEVEL=trace in your bash.
-- M
On 05/25/2017 10:38 AM, Cho, Daniel J (332C) via USRP-users wrote:
>
>
>
>
> *From:* Cho, Daniel J (332C)
> *Sent:* Thursday, May 25, 2017 10:38 AM
> *To:* Cho, Daniel J (332C) <daniel.j....@jpl.nasa.gov>
> *Subject:* RE: Pause after "Register loopback test passed"
>
>
>
> When cross compiling, the instructions state that the example codes get
> installed in a lib directory. In ~/usr/ directory, I do not have a lib
> directory and my examples are getting installed in
> ~/usr/src/uhd/host/build/examples/.
>
>
>
> *From:* USRP-users [mailto:usrp-users-boun...@lists.ettus.com] *On
> Behalf Of *Cho, Daniel J (332C) via USRP-users
> *Sent:* Thursday, May 25, 2017 9:51 AM
> *To:* usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>
> *Subject:* [USRP-users] Pause after "Register loopback test passed"
>
>
>
> Hello ?
>
>
>
> I am trying to compile and run my own code by cross compiling as
> instructed here:
> https://kb.ettus.com/Software_Development_on_the_E310_and_E312
>
>
>
> Instead of using the e3xx-rfnoc recipe, I am using the e3xx-default
> and/or the e3xx-custom-uhd recipe. So after going through all the steps
> (I compile and link an executable of the example codes), I mount it onto
> the USRP and source the set_env file as instructed. When I try and run
> any of the example programs that I cross compiled, it goes down to
> ?register loopback test passed? and it just stops.
>
>
>
>
>
> I am initially trying to recompile the example code and see if I can run
> the recompiled code before trying to compile my own code. Anyone know
> why it is just stopping there?
>
>
>
> Thanks
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 42
Date: Wed, 5 Jul 2017 17:53:33 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Time sync on wideband
Message-ID: <ad7955b8-b9b9-b252-2c0b-f98814610...@ettus.com>
Content-Type: text/plain; charset=utf-8
On 06/08/2017 02:48 PM, ?????? ???? via USRP-users wrote:
> Hi,
>
> I'm using several b205mini and 1pps reference from the octoclock. My
> main goal is to synchronize the time of devices. When I make records at
> 10MHz everything is fine, but when I try up to 20-40MHz I see, as it
> seems to me, an explicit dissynchronization.
10 MHz sampling rate?
> Please, see code to review <https://pastebin.com/iujTrXYN>
>
> As a result,look at this output
> <https://www.dropbox.com/s/awnlj7nl02vigla/uht_time_sync_output.txt?dl=0>,
> where first column is the device, and second column - metadata timestamp.
>
> I see that the devices is being launched NOT simultaneously, although
> the timestamps of samples is given the same.
It's not quite clear how to read that file. What if you look at the
signals side-by-side?
-- M
------------------------------
Message: 43
Date: Wed, 5 Jul 2017 17:57:11 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] [N210] AD9510 Configuration Issues
Message-ID: <77795a30-00be-e88f-0935-edf7a173d...@ettus.com>
Content-Type: text/plain; charset=windows-1252
Florian,
you can fetch all the register reads from the appropriate files:
https://github.com/EttusResearch/uhd/blob/maint/host/lib/usrp/usrp2/clock_ctrl.cpp
would be a good place to start.
Cheers,
Martin
On 05/29/2017 06:13 AM, Galler Florian via USRP-users wrote:
> Hello all,
>
>
>
> I am running the N210 with a custom developed Fpga image, because I
> needed the full sampling rate of the ADC and DAC. However, I have
> problems with the configuration of the AD9510. With my settings, it
> seems that the PLL of the AD9510 needs 500ms to lock to the 10 MHz
> internal reference (5MHz PDF and 3mA CP current as stated in the N2XX
> schematics). Sometime it takes even longer. Could you please provide the
> register setting used with the UHD driver or other working register
> settings?
>
>
>
> I want to connect two USRPs with a MIMO cable and synchronize the
> sampling clocks. Could you please give me tips how to configure the
> AD9510s.
>
> I now have configured the master to provide a 100 MHz ref signal over
> the MIMO cable. The clock switch (U18) of the slave is configured to the
> Mimo cable input (clk_exp_in). The PLL?s phase detector runs at 5 MHz
> and all other settings like in the single unit case.
>
> To check the synchronization I have connected a scope to the testclk
> output of master and slave. I triggered on the clock of the master and
> activated persistence. At first, it seems that the two clocks are
> synchronized (see picture 1). However, after some time the phase lock is
> lost for short periods of time, which can be seen in the persistent
> trace (see picture 2).
>
>
>
> I also have tried to simulate/calculate the loop filter by ADIsim CLK
> but I didn?t managed to simulate the values of the schematic by entering
> the design parameters (3kHz BW, 45 deg Phase margin with 5 MHz compare
> freq and 3mA CP current).
>
>
>
> Looking forward to your reply
>
>
>
> Florian
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 44
Date: Wed, 5 Jul 2017 18:16:57 -0700
From: Nate Temple <nate.tem...@ettus.com>
To: Daryl Lee <d...@bluecomsystems.com>
Cc: Zhihong Luo via USRP-users <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Porting UHD to Zedboard w/Petalinux 2016.4
Message-ID:
<cal263izj237-1htu7qwqvfavtdespb2p+0adoqyrown1l8h...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Daryl,
I don't have any specific walk through guides for installing UHD onto
Petalinux 2016.4. The best resource for Yocto will be their documentation
[1]. In addition you can find all of the BSPs for the Ettus products here
[2]. In addition to those, you may find the writes / manifests by Philip
Balister useful to reference here [3][4].
[1] - https://www.yoctoproject.org/documentation
[2] - https://github.com/EttusResearch/meta-ettus
[3] - http://opensdr.com/
[4] - https://github.com/balister/oe-gnuradio-manifest
Regards,
Nate Temple
On Mon, May 8, 2017 at 8:03 AM, Daryl Lee via USRP-users <
usrp-users@lists.ettus.com> wrote:
> When I first started my UHD-on-Zynq journey in November, I was using
> Petalinux 2015.4. This meant that I was using Xilinx's proprietary tools,
> and it turns out that porting UHD to the Zedboard was straightforward: just
> build libusb, Boost, and UHD with the right compiler and copy the finished
> product to the target environment. Now that I have upgraded to Petalinux
> 2016.4, which is based on Yocto, the process seems a bit more obscure. I
> have no doubt it will be better once I make the transition, but getting
> there is a challenge. Can someone point me to a good resource for
> implementing UHD (which means also libusb-1.0 and Boost) to a Zedboard
> using Petalinux 2016.4?
>
> --
> *Daryl O. Lee*
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> 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/20170705/7b75249b/attachment-0001.html>
------------------------------
Message: 45
Date: Wed, 5 Jul 2017 22:19:14 -0400
From: Darek Kawamoto <darek.kawam...@gmail.com>
To: Nate Temple <nate.tem...@ettus.com>
Cc: Zhihong Luo via USRP-users <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] E312 SD Card File System Corruption
Message-ID:
<cafsrpedsxro8srtbzdyfyftqudq2hrbeo5_jqthlh_d_rfn...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Nate,
Yes we were!
We had tried to load a fresh release onto a new SD card and then copying
our /prefix on -- and even moved an SD card from a working E312 into our
problematic one -- to no avail. We opened up the case to switch out the
battery in case there was power problems of some sort but saw that it
wasn't connected (we must've taken it out at some point) -- plugging in the
battery fixed all of our issues.
I believe sshfs was working just fine, but for our use case we needed to
load the entire prefix on.
Thanks for checking up / hopefully this is useful to someone in the future.
Darek
On Wed, Jul 5, 2017 at 8:17 PM, Nate Temple <nate.tem...@ettus.com> wrote:
> Hi Darek,
>
> Were you able to resolve this? Does the problematic E312 work with a fresh
> release-4 image?
>
> Are you trying to copy it to /prefix/ or to a subdirectory within your
> /home/root (/home/root/prefix/) ?
>
> What happens if you mount a remote file system via SSHFS and then copy the
> files via the mounted location, to avoid scp ?
>
> Regards,
> Nate Temple
>
> On Tue, May 16, 2017 at 2:49 PM, Darek Kawamoto via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hey all,
>>
>> I've got an E312 that I'm working on, and whenever I try to scp my
>> working prefix onto the SD card I get a bunch of errors seemingly related
>> to the SD card. In my scp output I get errors like this for each remaining
>> file:
>>
>> scp: /prefix/lib/libgnuradio-runtime-3.7.12git.so.0.0.0: Read-only file
>> system
>>
>> And the dmesg on the E312 says a ton stuff like this:
>>
>> [ 407.967600] end_request: I/O error, dev mmcblk0, sector 11386400
>> [ 407.983805] mmc0: Controller never released inhibit bit(s).
>> [ 407.991328] mmcblk0: error -5 sending status command, retrying
>> [ 407.999109] mmcblk0: error -110 sending status command, retrying
>> [ 408.007060] mmcblk0: error -110 sending status command, aborting
>> [ 408.051219] mmc0: Controller never released inhibit bit(s).
>> [ 408.058776] mmcblk0: error -5 sending status command, retrying
>> [ 408.066598] mmcblk0: error -110 sending status command, retrying
>> [ 408.074595] mmcblk0: error -110 sending status command, aborting
>> [ 408.080598] EXT4-fs warning (device mmcblk0p2):
>> __ext4_read_dirblock:908: error reading directory block (ino 1312422, block
>> 0)
>> [ 409.148499] mmc0: Controller never released inhibit bit(s).
>> [ 409.156026] mmcblk0: error -5 sending status command, retrying
>> [ 409.163825] mmcblk0: error -110 sending status command, retrying
>> [ 409.171804] mmcblk0: error -110 sending status command, aborting
>> [ 409.177727] blk_update_request: 2 callbacks suppressed
>> [ 409.182862] end_request: I/O error, dev mmcblk0, sector 21140864
>>
>> etc. etc.
>> I'm able to put this SD card into another E312 which doesn't have this
>> problem and things work just fine. If I move a known-working SD card from
>> the working E312 into the broken one, this problem happens. So this seems
>> to indicate that the broken part is not the SD card.
>>
>> Has anyone seen this before / any ideas on how to fix this?
>>
>> Darek
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> 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/20170705/6023c086/attachment-0001.html>
------------------------------
Message: 46
Date: Thu, 6 Jul 2017 00:10:57 -0400
From: Sam Vogel <smvogel...@gmail.com>
To: Nate Temple <nate.tem...@ettus.com>
Cc: Martin Braun <martin.br...@ettus.com>, Zhihong Luo via USRP-users
<usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] ADC self-test failed
Message-ID:
<cacjmuqiatg0l-h8rhv0y1rq+ic0palnfkaeh0brzmylo0eo...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Nate,
Yes, there is a uhd_usrp_probe program in /examples/utils, perhaps this
means I'm using the 'uhd_usrp_probe' version? I can get more info on this
tomorrow when I'm in the office. We have two different X300 boards, let's
call them X300A and X300B. Each are a different H/W revision. We have been
using X300A for a while and the problem now occurs when I try to use X300B
with the same code base we use for X300A. The main difference in the setups
is the X300 board itself. A lot of the code we use is custom and I don't
know if starting from a fresh copy of the Ettus repository is feasible.
Thanks,
Sam
On Wed, Jul 5, 2017 at 8:29 PM, Nate Temple <nate.tem...@ettus.com> wrote:
> Hi Sam,
>
> Which version of UHD are you using? (uhd_usrp_probe --version)
>
> Have you recently updated UHD, or has anything changed in your setup from
> when it was previously work to now?
>
> Regards,
> Nate Temple
>
> On Wed, Jul 5, 2017 at 3:08 PM, Sam Vogel via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi,
>>
>> This happens every time.
>>
>> Thanks,
>> Sam
>>
>> On Wed, Jul 5, 2017 at 6:01 PM, Martin Braun via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Does this happen intermittently? Or every time?
>>>
>>> -- M
>>>
>>> On 06/13/2017 01:55 PM, Sam Vogel via USRP-users wrote:
>>> > Hi All, I?m running into an issue with our x300 revision E. Any help
>>> > resolving this is greatly appreciated.
>>> >
>>> > Following the procedure to recover the EEPROM yields a problem.
>>> >
>>> > [vogels@lprbld12 utils]$ ./usrp_burn_mb_eeprom
>>> > --args="recover_mb_eeprom,addr=192.167.10.111" --values="revision=5"
>>> >
>>> > Creating USRP device from address: recover_mb_eeprom,addr=192.167
>>> .10.111
>>> >
>>> > -- X300 initialization sequence...
>>> >
>>> > -- Determining maximum frame size... 8000 bytes.
>>> >
>>> > -- Setup basic communication...
>>> >
>>> > -- Loading values from EEPROM...
>>> >
>>> >
>>> >
>>> > UHD Warning:
>>> >
>>> > UHD is operating in EEPROM Recovery Mode which disables hardware
>>> > version checks.
>>> >
>>> > Operating in this mode may cause hardware damage and unstable radio
>>> > performance!
>>> >
>>> > -- Setup RF frontend clocking...
>>> >
>>> >
>>> >
>>> > UHD Warning:
>>> >
>>> > Environment variable 'USRP_X300_REFERENCE_CLOCK_RATE_HZ' not
>>> found,
>>> > defaulting to reference clock rate of 10000000.000000 Hz
>>> >
>>> > -- Using specified reference / master clock rates of 10.0 / 200.0 MHz
>>> >
>>> > -- Radio 1x clock:200
>>> >
>>> > -- Initialize Radio0 control...
>>> >
>>> > -- Performing register loopback test... pass
>>> >
>>> > -- Initialize Radio1 control...
>>> >
>>> > -- Performing register loopback test... pass
>>> >
>>> > Error: RuntimeError: ADC self-test failed! Ramp checker status:
>>> > {ADC0_I=Bit Errors!, ADC0_Q=Bit Errors!, ADC1_I=Good, ADC1_Q=Good}
>>> >
>>> >
>>> >
>>> > Thanks !
>>> >
>>> > -Sam
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > USRP-users mailing list
>>> > USRP-users@lists.ettus.com
>>> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>> >
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> 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/20170706/cd378219/attachment-0001.html>
------------------------------
Message: 47
Date: Wed, 5 Jul 2017 22:12:37 -0700
From: Nate Temple <nate.tem...@ettus.com>
To: Sam Vogel <smvogel...@gmail.com>
Cc: Martin Braun <martin.br...@ettus.com>, Zhihong Luo via USRP-users
<usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] ADC self-test failed
Message-ID: <32ff4f97-6655-4a7c-9022-ec3992870...@ettus.com>
Content-Type: text/plain; charset=utf-8
Hi Sam,
Can you run the following command send what it's output is? This will print out
the exact version of UHD you're using: uhd_usrp_probe --version
My second question was if you have changed any thing with your setup since the
X300 has became problematic ? Have you updated the UHD version at all recently?
Regards,
Nate Temple
> On Jul 5, 2017, at 9:10 PM, Sam Vogel <smvogel...@gmail.com> wrote:
>
> Hi Nate,
>
> Yes, there is a uhd_usrp_probe program in /examples/utils, perhaps this means
> I'm using the 'uhd_usrp_probe' version? I can get more info on this tomorrow
> when I'm in the office. We have two different X300 boards, let's call them
> X300A and X300B. Each are a different H/W revision. We have been using X300A
> for a while and the problem now occurs when I try to use X300B with the same
> code base we use for X300A. The main difference in the setups is the X300
> board itself. A lot of the code we use is custom and I don't know if
> starting from a fresh copy of the Ettus repository is feasible.
>
> Thanks,
> Sam
>
> On Wed, Jul 5, 2017 at 8:29 PM, Nate Temple <nate.tem...@ettus.com> wrote:
> Hi Sam,
>
> Which version of UHD are you using? (uhd_usrp_probe --version)
>
> Have you recently updated UHD, or has anything changed in your setup from
> when it was previously work to now?
>
> Regards,
> Nate Temple
>
> On Wed, Jul 5, 2017 at 3:08 PM, Sam Vogel via USRP-users
> <usrp-users@lists.ettus.com> wrote:
> Hi,
>
> This happens every time.
>
> Thanks,
> Sam
>
> On Wed, Jul 5, 2017 at 6:01 PM, Martin Braun via USRP-users
> <usrp-users@lists.ettus.com> wrote:
> Does this happen intermittently? Or every time?
>
> -- M
>
> On 06/13/2017 01:55 PM, Sam Vogel via USRP-users wrote:
> > Hi All, I?m running into an issue with our x300 revision E. Any help
> > resolving this is greatly appreciated.
> >
> > Following the procedure to recover the EEPROM yields a problem.
> >
> > [vogels@lprbld12 utils]$ ./usrp_burn_mb_eeprom
> > --args="recover_mb_eeprom,addr=192.167.10.111" --values="revision=5"
> >
> > Creating USRP device from address: recover_mb_eeprom,addr=192.167.10.111
> >
> > -- X300 initialization sequence...
> >
> > -- Determining maximum frame size... 8000 bytes.
> >
> > -- Setup basic communication...
> >
> > -- Loading values from EEPROM...
> >
> >
> >
> > UHD Warning:
> >
> > UHD is operating in EEPROM Recovery Mode which disables hardware
> > version checks.
> >
> > Operating in this mode may cause hardware damage and unstable radio
> > performance!
> >
> > -- Setup RF frontend clocking...
> >
> >
> >
> > UHD Warning:
> >
> > Environment variable 'USRP_X300_REFERENCE_CLOCK_RATE_HZ' not found,
> > defaulting to reference clock rate of 10000000.000000 Hz
> >
> > -- Using specified reference / master clock rates of 10.0 / 200.0 MHz
> >
> > -- Radio 1x clock:200
> >
> > -- Initialize Radio0 control...
> >
> > -- Performing register loopback test... pass
> >
> > -- Initialize Radio1 control...
> >
> > -- Performing register loopback test... pass
> >
> > Error: RuntimeError: ADC self-test failed! Ramp checker status:
> > {ADC0_I=Bit Errors!, ADC0_Q=Bit Errors!, ADC1_I=Good, ADC1_Q=Good}
> >
> >
> >
> > Thanks !
> >
> > -Sam
> >
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
------------------------------
Message: 48
Date: Thu, 6 Jul 2017 09:55:40 +0300
From: ?????? 1 <andrew4...@rambler.ru>
To: "Usrp Users" <usrp-users@lists.ettus.com>
Subject: [USRP-users] B210 dual channel
Message-ID: <1499324140.432195.21438.25...@mail.rambler.ru>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hello
For phase measure I use Agilent generator with spliter.
But my quession not about phase.I think the phase beetween channels should be
the
some ?onstant and that is normally.
I dont understand why time to get samples in dual channel mode much longer in
single channel mode and is it possible to reduce it for a fixed number of
samples.
In my application i use 2048 samples at 625kHz sample rate and ?xpected to
receive delay about 2048/625 ~ 5-6 ms but got 23-24 ms.
Can anyone deduce me about UHD_STREAM_MODE_NUM_SAMPS_AND_MORE.
How does it differ from the UHD_STREAM_MODE_NUM_SAMPS_AND_DONE and in what cases
it can be used?
Thank you
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170706/17221bd6/attachment-0001.html>
------------------------------
Message: 49
Date: Thu, 6 Jul 2017 12:23:46 +0200
From: altu? kaya <altugkaya1...@gmail.com>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] How to Compile rx_samples_to_file and Generate
an Executable
Message-ID:
<CAHq6UV-4N_EF8HVSs=mzxauoy5_5m-sr+gxhpspmomh7w5g...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello everyone,
I downloaded the uhd-master folder (
https://github.com/EttusResearch/uhd/tree/master) and I would like to edit
one of the example, called rx_samples_to_file. However when I try to
compile it by using cygwin on a windows machine, it cannot find the
necessary libraries, such as tune_request, etc.
How can I generate an executable from rx_samples_to_file.cpp?
Sincerely,
Altug
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170706/48b3fa77/attachment-0001.html>
------------------------------
Message: 50
Date: Thu, 6 Jul 2017 12:18:22 +0100
From: Derek Kozel <derek.ko...@ettus.com>
To: altu? kaya <altugkaya1...@gmail.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] How to Compile rx_samples_to_file and
Generate an Executable
Message-ID:
<CAA+K=tsw88uznmmbuzda5w1v26fg+txtufhahz8f3hycy8m...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Altug,
We have a guide for building UHD on Windows in the Knowledge Base. It
includes building and installing the library as well as examples.
https://kb.ettus.com/Building_and_Installing_the_USRP_Open_Source_Toolchain_(UHD_and_GNU_Radio)_on_Windows
Regards,
Derek
On Thu, Jul 6, 2017 at 11:23 AM, altu? kaya via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hello everyone,
>
> I downloaded the uhd-master folder (https://github.com/
> EttusResearch/uhd/tree/master) and I would like to edit one of the
> example, called rx_samples_to_file. However when I try to compile it by
> using cygwin on a windows machine, it cannot find the necessary libraries,
> such as tune_request, etc.
>
> How can I generate an executable from rx_samples_to_file.cpp?
>
> Sincerely,
> Altug
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> 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/20170706/df8c6368/attachment-0001.html>
------------------------------
Message: 51
Date: Thu, 6 Jul 2017 14:49:23 +0200
From: altu? kaya <altugkaya1...@gmail.com>
To: Derek Kozel <derek.ko...@ettus.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] How to Compile rx_samples_to_file and
Generate an Executable
Message-ID:
<cahq6uv9dxqsjrxuohz5wa10ncd5j7al2hpj3y6vhcfup8xv...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
First of all, thank you Derek.
According to some forums on the net Visual Studio 2017 is not supported by
Boost. Should I close my ears and download 1.64.0, or should I just skip
boost?
I am looking forward to your reply,
Altug
On Thu, Jul 6, 2017 at 1:18 PM, Derek Kozel <derek.ko...@ettus.com> wrote:
> Hello Altug,
>
> We have a guide for building UHD on Windows in the Knowledge Base. It
> includes building and installing the library as well as examples.
> https://kb.ettus.com/Building_and_Installing_the_USRP_Open_
> Source_Toolchain_(UHD_and_GNU_Radio)_on_Windows
>
> Regards,
> Derek
>
> On Thu, Jul 6, 2017 at 11:23 AM, altu? kaya via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hello everyone,
>>
>> I downloaded the uhd-master folder (https://github.com/EttusResea
>> rch/uhd/tree/master) and I would like to edit one of the example, called
>> rx_samples_to_file. However when I try to compile it by using cygwin on a
>> windows machine, it cannot find the necessary libraries, such as
>> tune_request, etc.
>>
>> How can I generate an executable from rx_samples_to_file.cpp?
>>
>> Sincerely,
>> Altug
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> 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/20170706/9c85e428/attachment-0001.html>
------------------------------
Message: 52
Date: Thu, 6 Jul 2017 08:01:10 -0700
From: Jacob Knoles <knole...@gmail.com>
To: altu? kaya <altugkaya1...@gmail.com>
Cc: Derek Kozel <derek.ko...@ettus.com>, "usrp-users@lists.ettus.com"
<usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] How to Compile rx_samples_to_file and
Generate an Executable
Message-ID:
<ca+z4yffqm2wj63nb-5-tyaxcfaw7gsgnwwbl-9chttv4dk6...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Altug,
Certainly cannot skip boost as UHD requires it. I have tried doing the
compilation using VS 2017 and could not get it to work, I believe that the
Ettus team will is working on 2017 support but as of right now, to my
knowledge, you will need to use VS 2015. As for boost, I am using 1.64.0
and it works just fine.
-----------------------------
Jacob Knoles
On Thu, Jul 6, 2017 at 5:49 AM, altu? kaya via USRP-users <
usrp-users@lists.ettus.com> wrote:
> First of all, thank you Derek.
>
> According to some forums on the net Visual Studio 2017 is not supported by
> Boost. Should I close my ears and download 1.64.0, or should I just skip
> boost?
>
> I am looking forward to your reply,
> Altug
>
> On Thu, Jul 6, 2017 at 1:18 PM, Derek Kozel <derek.ko...@ettus.com> wrote:
>
>> Hello Altug,
>>
>> We have a guide for building UHD on Windows in the Knowledge Base. It
>> includes building and installing the library as well as examples.
>> https://kb.ettus.com/Building_and_Installing_the_USRP_Open_S
>> ource_Toolchain_(UHD_and_GNU_Radio)_on_Windows
>>
>> Regards,
>> Derek
>>
>> On Thu, Jul 6, 2017 at 11:23 AM, altu? kaya via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hello everyone,
>>>
>>> I downloaded the uhd-master folder (https://github.com/EttusResea
>>> rch/uhd/tree/master) and I would like to edit one of the example,
>>> called rx_samples_to_file. However when I try to compile it by using cygwin
>>> on a windows machine, it cannot find the necessary libraries, such as
>>> tune_request, etc.
>>>
>>> How can I generate an executable from rx_samples_to_file.cpp?
>>>
>>> Sincerely,
>>> Altug
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> 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/20170706/23f0b000/attachment-0001.html>
------------------------------
Message: 53
Date: Thu, 6 Jul 2017 16:25:05 +0100
From: Derek Kozel <derek.ko...@ettus.com>
To: Jacob Knoles <knole...@gmail.com>
Cc: altu? kaya <altugkaya1...@gmail.com>, "usrp-users@lists.ettus.com"
<usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] How to Compile rx_samples_to_file and
Generate an Executable
Message-ID:
<CAA+K=ttx0pk94_uh3ccdgeoxxcoyljqf7gtwyk-ned8czmy...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Altug and Jacob,
Yes, the most recent Visual Studio we are actively supporting is 2015. We
will support 2017 with an upcoming release but as you note Jacob, Boost and
other dependencies are still catching up themselves.
Jacob, Boost 1.64 is not officially supported but great to hear it is
working. We'll be checking compatibility with it as well.
Regards,
Derek
On Thu, Jul 6, 2017 at 4:01 PM, Jacob Knoles <knole...@gmail.com> wrote:
> Altug,
>
> Certainly cannot skip boost as UHD requires it. I have tried doing the
> compilation using VS 2017 and could not get it to work, I believe that the
> Ettus team will is working on 2017 support but as of right now, to my
> knowledge, you will need to use VS 2015. As for boost, I am using 1.64.0
> and it works just fine.
>
> -----------------------------
> Jacob Knoles
>
>
> On Thu, Jul 6, 2017 at 5:49 AM, altu? kaya via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> First of all, thank you Derek.
>>
>> According to some forums on the net Visual Studio 2017 is not supported
>> by Boost. Should I close my ears and download 1.64.0, or should I just skip
>> boost?
>>
>> I am looking forward to your reply,
>> Altug
>>
>> On Thu, Jul 6, 2017 at 1:18 PM, Derek Kozel <derek.ko...@ettus.com>
>> wrote:
>>
>>> Hello Altug,
>>>
>>> We have a guide for building UHD on Windows in the Knowledge Base. It
>>> includes building and installing the library as well as examples.
>>> https://kb.ettus.com/Building_and_Installing_the_USRP_Open_S
>>> ource_Toolchain_(UHD_and_GNU_Radio)_on_Windows
>>>
>>> Regards,
>>> Derek
>>>
>>> On Thu, Jul 6, 2017 at 11:23 AM, altu? kaya via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
>>>> Hello everyone,
>>>>
>>>> I downloaded the uhd-master folder (https://github.com/EttusResea
>>>> rch/uhd/tree/master) and I would like to edit one of the example,
>>>> called rx_samples_to_file. However when I try to compile it by using cygwin
>>>> on a windows machine, it cannot find the necessary libraries, such as
>>>> tune_request, etc.
>>>>
>>>> How can I generate an executable from rx_samples_to_file.cpp?
>>>>
>>>> Sincerely,
>>>> Altug
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> USRP-users@lists.ettus.com
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> 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/20170706/0fade0e8/attachment-0001.html>
------------------------------
Message: 54
Date: Thu, 6 Jul 2017 11:39:14 -0400
From: Sam Vogel <smvogel...@gmail.com>
To: Nate Temple <nate.tem...@ettus.com>
Cc: Martin Braun <martin.br...@ettus.com>, Zhihong Luo via USRP-users
<usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] ADC self-test failed
Message-ID:
<cacjmuqjhenyab1qu-ib25ilgdbffwb+7ueh3z8nxt64g3-h...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Nate,
Sure, our company is using a custom UHD and I will have to redact part of
the text. When I run the command it outputs:
003.009.001*<this-is-redacted>*
This x300 has always been problematic. We have a different X300 that works
fine with this setup. The problem occurs when I duplicate the setup for use
with our second X300. We need the second setup running also. I have never
updated the UHD.
Hopefully this is helpful, I assume our custom UHD is built from
003.009.001.
Thanks so much,
Sam
On Thu, Jul 6, 2017 at 1:12 AM, Nate Temple <nate.tem...@ettus.com> wrote:
> Hi Sam,
>
> Can you run the following command send what it's output is? This will
> print out the exact version of UHD you're using: uhd_usrp_probe --version
>
> My second question was if you have changed any thing with your setup since
> the X300 has became problematic ? Have you updated the UHD version at all
> recently?
>
> Regards,
> Nate Temple
>
>
> > On Jul 5, 2017, at 9:10 PM, Sam Vogel <smvogel...@gmail.com> wrote:
> >
> > Hi Nate,
> >
> > Yes, there is a uhd_usrp_probe program in /examples/utils, perhaps this
> means I'm using the 'uhd_usrp_probe' version? I can get more info on this
> tomorrow when I'm in the office. We have two different X300 boards, let's
> call them X300A and X300B. Each are a different H/W revision. We have been
> using X300A for a while and the problem now occurs when I try to use X300B
> with the same code base we use for X300A. The main difference in the setups
> is the X300 board itself. A lot of the code we use is custom and I don't
> know if starting from a fresh copy of the Ettus repository is feasible.
> >
> > Thanks,
> > Sam
> >
> > On Wed, Jul 5, 2017 at 8:29 PM, Nate Temple <nate.tem...@ettus.com>
> wrote:
> > Hi Sam,
> >
> > Which version of UHD are you using? (uhd_usrp_probe --version)
> >
> > Have you recently updated UHD, or has anything changed in your setup
> from when it was previously work to now?
> >
> > Regards,
> > Nate Temple
> >
> > On Wed, Jul 5, 2017 at 3:08 PM, Sam Vogel via USRP-users <
> usrp-users@lists.ettus.com> wrote:
> > Hi,
> >
> > This happens every time.
> >
> > Thanks,
> > Sam
> >
> > On Wed, Jul 5, 2017 at 6:01 PM, Martin Braun via USRP-users <
> usrp-users@lists.ettus.com> wrote:
> > Does this happen intermittently? Or every time?
> >
> > -- M
> >
> > On 06/13/2017 01:55 PM, Sam Vogel via USRP-users wrote:
> > > Hi All, I?m running into an issue with our x300 revision E. Any help
> > > resolving this is greatly appreciated.
> > >
> > > Following the procedure to recover the EEPROM yields a problem.
> > >
> > > [vogels@lprbld12 utils]$ ./usrp_burn_mb_eeprom
> > > --args="recover_mb_eeprom,addr=192.167.10.111" --values="revision=5"
> > >
> > > Creating USRP device from address: recover_mb_eeprom,addr=192.
> 167.10.111
> > >
> > > -- X300 initialization sequence...
> > >
> > > -- Determining maximum frame size... 8000 bytes.
> > >
> > > -- Setup basic communication...
> > >
> > > -- Loading values from EEPROM...
> > >
> > >
> > >
> > > UHD Warning:
> > >
> > > UHD is operating in EEPROM Recovery Mode which disables hardware
> > > version checks.
> > >
> > > Operating in this mode may cause hardware damage and unstable radio
> > > performance!
> > >
> > > -- Setup RF frontend clocking...
> > >
> > >
> > >
> > > UHD Warning:
> > >
> > > Environment variable 'USRP_X300_REFERENCE_CLOCK_RATE_HZ' not
> found,
> > > defaulting to reference clock rate of 10000000.000000 Hz
> > >
> > > -- Using specified reference / master clock rates of 10.0 / 200.0 MHz
> > >
> > > -- Radio 1x clock:200
> > >
> > > -- Initialize Radio0 control...
> > >
> > > -- Performing register loopback test... pass
> > >
> > > -- Initialize Radio1 control...
> > >
> > > -- Performing register loopback test... pass
> > >
> > > Error: RuntimeError: ADC self-test failed! Ramp checker status:
> > > {ADC0_I=Bit Errors!, ADC0_Q=Bit Errors!, ADC1_I=Good, ADC1_Q=Good}
> > >
> > >
> > >
> > > Thanks !
> > >
> > > -Sam
> > >
> > >
> > >
> > > _______________________________________________
> > > USRP-users mailing list
> > > USRP-users@lists.ettus.com
> > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> > >
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > 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/20170706/bf46cc99/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 83, Issue 6
*****************************************
