Hallo Martin,
Concerning the vanilla UHD-example: I'm just remember, that I've
couldn't find an example on your repository, where you used multi_usrp
in combination with RFNoC. Before we used our FPGA-Image in our
CPP-Application we tested it with GNU-Radio. But there we tested just
one channel
Hallo Martin,
So at the moment for testing the new RFNocC-designe I've used two USRP's
x310 synchronized with a octocklock from ettus.
In our real application we operate 5 or 6 USRP's in parallel, all
connected over the 1 gigabit-ethernet to our host-machine.
The problem described happens also
Armin,
I'd like to learn a little more about this failure. Here's a couple of
questions:
- How many USRPs are you running at once? Does this also happen with a
single USRP?
- Does this also happen when using a vanilla UHD example? Since you're
running a custom RFNOC block, it would be good to
On Fri, Feb 22, 2019 at 6:19 PM Martin Braun wrote:
> This pokes a register in the STC3. It'll pull the FPGA into reset. You
> then need to wait a bit before the FPGA is back up.
>
So it's a forced reload of the FPGA from the onboard image. To use this in
software, I'd issue the command, then
This pokes a register in the STC3. It'll pull the FPGA into reset. You then
need to wait a bit before the FPGA is back up.
-- M
On Fri, Feb 22, 2019 at 10:21 AM Brian Padalino via USRP-users <
usrp-users@lists.ettus.com> wrote:
> On Wed, Feb 20, 2019 at 7:45 PM Jonathon Pendlum <
>
On Wed, Feb 20, 2019 at 7:45 PM Jonathon Pendlum
wrote:
> Hi Armin,
>
> You can reset X3x0 series devices via a register write with the following
> command (this is in to your UHD src directory):
> firmware/usrp3/x300/x300_debug.py --addr 192.168.40.2 --poke=0x00100058
> --data=1.
>
Can you
Hi Armin,
You can reset X3x0 series devices via a register write with the following
command (this is in to your UHD src directory):
firmware/usrp3/x300/x300_debug.py --addr 192.168.40.2 --poke=0x00100058
--data=1.
When you kill your app and resume, how long do you wait before restarting?
Can you
Hm, does someone know if it is possible somehow to reset the FPGA over a
register? We see, that there exists a registers for resets of different
modules (SR_SW_RST), but don't know, if we could use this over the API.
Does somewhere exist a register-map? I think that should be the basis of
every
On Tue, Feb 19, 2019 at 12:07 PM Armin Schmidt wrote:
> Thanks for your replay! Hm, yes I've thought also about to use
> STREAM_MODE_STOP_CONTINUOUS, but I would like to be able to restart my app
> also after a crash. Ok, it should never happen, but one can never guarantee
> that case. Do you
Thanks for your replay! Hm, yes I've thought also about to use
STREAM_MODE_STOP_CONTINUOUS, but I would like to be able to restart my app
also after a crash. Ok, it should never happen, but one can never guarantee
that case. Do you have an idea, how to deal with such cases? I think it's a
bug in
On Tue, Feb 19, 2019 at 5:42 AM Armin Schmidt via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hallo,
> We're about to migrate from multi-usrp-application with UHD 3.9 and
> custome FPGA to UHD 3.14 with RFNoC. We are using the USRP x310 with
> daughterboards ubx-160. Everything seems to
Hallo,
We're about to migrate from multi-usrp-application with UHD 3.9 and custome
FPGA to UHD 3.14 with RFNoC. We are using the USRP x310 with daughterboards
ubx-160. Everything seems to work fine except that when we stop our
application in the terminal with ctrl-c, a new startup is only possible
12 matches
Mail list logo
