I have experienced the same issue on a couple of my newer E310s. I have not
been able to confirm yet, mainly because it is hard to reproduce, but from what
I can tell, most of the times I have seen it are when an E310 has been powered
off for a longer period of time. Not quite sure how to solve this one as not
being able to reliably power it on kind of causes issues.
________________________________________
From: USRP-users [usrp-users-boun...@lists.ettus.com] on behalf of
usrp-users-requ...@lists.ettus.com [usrp-users-requ...@lists.ettus.com]
Sent: Saturday, March 03, 2018 12:00 PM
To: usrp-users@lists.ettus.com
Subject: EXTERNAL: USRP-users Digest, Vol 91, Issue 3
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. Multi N200 issues (Keith k)
2. Re: E310 Power On/Off Behavior (Daniel May)
3. Re: set_rx_lo_source (?????? 1)
----------------------------------------------------------------------
Message: 1
Date: Fri, 2 Mar 2018 15:37:09 -0600
From: Keith k <keithko...@gmail.com>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Multi N200 issues
Message-ID:
<cafgmrucz131u-1zxqijs-yvzej4neo+ykth32qpktywkxde...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello all
I'm working on a project to use 16 N200s in a multi USRP configuration for
a radar project. They are synchronized using 3 Octoclocks (one master with
a GPSDO, and two slaves that drive the 16 N200s). I've been getting many
errors that I was hoping someone could help with. I have attached a sample
program that mimics how the USRPs are used. The basic goal here is to
sample a determined number of samples while transmitting some spaced pulses
(a "pulse sequence") and then repeat. It would be beneficial to have as
little delay as possible in between loops. I've been running into some
problems however.
BASIC INFO
We have 16 N200s + 1 spare
3 Octoclocks (1 has gps and it drives the other two)
LFTX and LFRX daughterboards in each N200
linux; GNU C++ version 4.8.5; Boost_105400;
UHD_003.010.002.000-0-gbd6e21dc
Intel Corporation Ethernet Controller 10-Gigabit X540-AT2
Devices are all connected via 3 daisy chained Netgear XS708E switches
Ideal sampling rates: 5-10MHz TX, 5-10MHz RX depending on
hardware/software limitations.
One of the issues I sometimes get after several minutes of runtime (or
several thousand pulse sequences) is the overflow(O) with the out of
sequence flag set in the rx metadata. I also get sequence errors(S) on the
tx side too. It seems to happen more often and faster with higher sampling
rate. I've gathered from other mailing list posts that this is likely a
network configuration issue. Can someone recommend a known working computer
build and network configuration that can handle the amount of USRPs and
data we are attempting to use?
Another major issue I eventually get during runtime is a slurry of lates(L)
on TX and then a LATE in the RX metadata. I've tried increasing the time in
the future that the TX/RX should start (from when the stream commands are
called) and I've tried to minimize the number of operations happening
between that calculation and when TX/RX start, but the lates still
eventually happen. I've tried to time profile what I can in my code and it
seems I should really only need about ~0.5ms of delay, but even at 3-10ms
of delay I have issues. I feel like 10ms of time should be more that plenty
of time for the host to issue stream commands. I don't seem to get lates if
I have test applications that individually test TX or RX, but when I put
them together using threads, I can't seem to find a way to eliminate the
lates. Any ideas on how I should set up what I'm trying to do here?
Here is the compiler line to make the test program:
g++ -o test_rx_tx -std=c++11 -Wall test_rx_tx.cpp -lboost_system -luhd
If I can explain anything in further detail please let me know.
Thank you for your time.
--
-Keith Kotyk
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20180302/4945fecc/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_rx_tx.cpp
Type: text/x-c++src
Size: 7447 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20180302/4945fecc/attachment-0001.cpp>
------------------------------
Message: 2
Date: Fri, 2 Mar 2018 16:50:36 -0600
From: Daniel May <danielma...@gmail.com>
To: Philip Balister <phi...@opensdr.com>,
"USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] E310 Power On/Off Behavior
Message-ID:
<CAKazox3p2N=u6k7q+9iua3yhsegrb_vj3+bglkc1ppe0v8q...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
Sorry to resurrect an old thread, but I am still having this issue with
most if not all of the newer E310's I've ordered. These devices have the
updated firmware for the axi_pmu device.
I write 1 to the "autoboot" file using the following command:
echo 1 > /sys/devices/axi_pmu.3/autoboot
And I check it just to make sure:
cat /sys/devices/axi_pmu.3/autoboot
and it shows "1".
After a random number of power cycles, the device will not power back on
when power is applied. When I boot it manually with the power button, I can
check the "autoboot" value:
cat /sys/devices/axi_pmu.3/autoboot
And it has returned to "0"
Does anyone know what could be causing this?
Thanks,
Daniel
On Mon, Sep 26, 2016 at 5:05 PM, Philip Balister <phi...@opensdr.com> wrote:
> I'm working in the Ettus office this week and discussed this issue with
> the engineers. To make a long story short, the easiest fix is send the
> unit to Robin Coxe (cc'd) and they will install firmware that corrects
> the issue. To do this yourself requires a custom cable that is not
> available for sale yet.
>
> Philip
>
>
> On 09/26/2016 11:13 AM, Daniel May via USRP-users wrote:
> > All,
> >
> > I'm also having this issue. I've tried both:
> >
> > https://files.ettus.com/e3xx_images/e3xx-release-4/
> >
> > and
> >
> > https://files.ettus.com/e3xx_images/beta/fido-test-2016.05/
> >
> > But they both contain firmware version 2.0. The device won't autoboot
> > after power cycling 3-4 times. How can I manually upgrade the firmware to
> > 2.2?
> >
> > On Fri, Jul 29, 2016 at 12:37 PM, LB Belella via USRP-users <
> > usrp-users@lists.ettus.com> wrote:
> >
> >> Neel-
> >>
> >> Thanks for your time. I appreciate it. In grepping dmesg it looks like
> >> our firmware version is 2.0:
> >>
> >> root@ettus-e3xx-sg1:~# dmesg | grep firmware
> >> [ 1.167308] e3xx-pmu axi_pmu.3: Found firmware version 2.0
> >>
> >> That said I'm running the E3XX-RELEASE-4 SG1 Demo Image (at least I
> >> thought I was) so I would have thought the latest firmware was in that
> >> image. Do I just need to verify that I'm running the latest image to
> get
> >> the up-to-date firmware? I don't have access to the user's manual right
> >> this second so I may be missing something obvious.
> >>
> >> Anyway, thanks again for the help!
> >>
> >> lb
> >>
> >> ------------------------------
> >> From: neel.pand...@ettus.com
> >> Date: Fri, 29 Jul 2016 10:01:44 -0700
> >> Subject: Re: [USRP-users] E310 Power On/Off Behavior
> >> To: lb.bele...@live.com
> >> CC: usrp-users@lists.ettus.com
> >>
> >>
> >> Hello LB Belella:
> >>
> >> Which firmware version is reported when you boot your unit? (run "dmesg
> |
> >> grep Firmware")
> >>
> >> Back in January, we fixed an issue with the autoboot value. The fix is
> in
> >> commit bbeacff2b1bc3a17254167a79a26a2a2c82e906c. If your firmware
> version
> >> is less than 2.2, then you might still be affected by that, so an
> upgrade
> >> of your firmware should fix the problem.
> >>
> >> --Neel Pandeya
> >>
> >>
> >>
> >> On 28 July 2016 at 06:51,
> >> ??
> >> LB Belella via USRP-users <usrp-users@lists.ettus.com> wrote:
> >>
> >> Greetings all-
> >>
> >> I have an E310 that is configured to power up automatically (1 is set in
> >> the autoboot file). When the receiver is powered down correctly
> (shutdown
> >> -h now) the unit has no problem powering up the next time power is
> >> applied. However, when the unit is shutdown improperly (i.e. power is
> >> removed from the device while it is powered up) the unit does not
> power-on
> >> until the power switch is pressed. Is this the expected behavior? If
> so
> >> what is the logic that prevents the unit from auto-powering? Our plan
> was
> >> to use the E310 in a truly embedded application where we can't guarantee
> >> the unit will be properly shut down. Any information or advice would be
> >> greatly appreciated. Thanks in advance!
> >>
> >> lb
> >>
> >> _______________________________________________
> >> 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/20180302/3a4f2b8a/attachment-0001.html>
------------------------------
Message: 3
Date: Sat, 3 Mar 2018 16:15:04 +0300
From: ?????? 1 <andrew4...@rambler.ru>
To: "derek.kozel" <derek.ko...@ettus.com>
Cc: "Usrp Users" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] set_rx_lo_source
Message-ID: <1520082904.11450.10338.34...@mail.rambler.ru>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hello
The attachment contains a test with the source.
Thank you
02.03.2018, 17:54, Derek Kozel <derek.ko...@ettus.com>Hello,
Setting the LO source does not tune the synthesizers so the actual command
duration should be very short. How are you measuring the durations?
I looked at why the twinrx_freq_hopping demo is not built by default on
Windows and it is because of an optional feature which requires a library
which Windows does not include, Curses. By removing the ascii_art_dft.hpp
include and the write_fft_to_file function the example should compile and run
with no other changes on Windows. Doing this would be a good test as it would
help isolate if there is a performance issue or an issue with how the API is
being used in your current test program. The example is very carefully
constructed so that there are minimal delays and so commands are already
queued on the FPGA before their scheduled execution time.
If you have a custom C program could you share the code? It would be useful
to see the order of operations.
Regards,
Derek
On Tue, Feb 27, 2018 at 3:08 PM, ?????? 1 via USRP-users
<usrp-users@lists.ettus.com>
wrote:
Hello
In the previous post(twinrx_freq_hopping example), I wrote that I could
not get time in 5 ms for example twinrx_freq_hopping.I measure the
commands execute time in the recieve loop and found with surprise that
the set_rx_lo_source function for the first time worked 0 ms and the next
time more than 40 ms.It is because of this that a large tuning time in
the frequency range is obtained.Can someone explain to me why this can
happen?
Thank you
_______________________________________________
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/20180303/57380091/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TestTwinRX.zip
Type: application/zip
Size: 490724 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20180303/57380091/attachment-0001.zip>
------------------------------
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 91, Issue 3
*****************************************
________________________________
This message is intended only for the use of the individual or entity to which
it is addressed and may contain ZETA Associates confidential or proprietary
information. If you are not the intended recipient, any use, dissemination, or
distribution of this communication is prohibited. If you have received this
communication in error, please notify the sender and delete all copies.
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
