Hi Marcus
Thanks for your reply.
Since I thought it works in the case using channel 0,4 with default subdev
spec setup(“A:0 A:1 B:0 B:1”), so I ignore setting the subdev spec.
However, I add the subdev spec setting and test again, but still failed to
transmit synchronized signal from 2 N310s.
Any
On 02/22/2019 08:15 AM, Jorge Chen wrote:
Hi Marcus
Thanks for your reply.
Since I thought it works in the case using channel 0,4 with default
subdev spec setup(“A:0 A:1 B:0 B:1”), so I ignore setting the subdev spec.
However, I add the subdev spec setting and test again, but still
failed to
Hi Marcus
Sorry for the confusion, the problem is no signal at all, and the
application just hang without any message.
Thanks
Jorge
Marcus D. Leech 於 2019年2月22日 週五，下午10:09寫道：
> On 02/22/2019 08:15 AM, Jorge Chen wrote:
>
> Hi Marcus
>
> Thanks for your reply.
>
> Since I thought it works in th
On 02/22/2019 08:15 AM, Jorge Chen wrote:
Hi Marcus
Thanks for your reply.
Since I thought it works in the case using channel 0,4 with default
subdev spec setup(“A:0 A:1 B:0 B:1”), so I ignore setting the subdev spec.
However, I add the subdev spec setting and test again, but still
failed to
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 elab
Rob,
yes, you can query UHD_RFNOC_FOUND. Check out this example:
https://github.com/EttusResearch/gr-ettus/blob/dcb780b77a114a265bb355fdba4f24033c3412c4/CMakeLists.txt#L138-L141
-- M
On Wed, Feb 20, 2019 at 8:52 AM Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi,
> I have a
You can feed the OctoClock from the X310, and then use the OctoClock's
output to drive the N210. All devices will be synchronized, in frequency,
and the N210s will be synchronized in time, but the X310 and N210s will not
be synchronized in time. However, that timing offset you might able to
calibra
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 <
> jonathon.pend
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 t
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 elim
Make sure the driver is running:
$ lsmod | grep niusrp
niusrpriok421888 0
nistreamk 139264 2 niusrpriok,NiRioSrv
nibds 57344 2 niusrpriok,NiRioSrv
nikal 118784 4 niusrpriok,nibds,NiRioSrv,nistreamk
If not, check the output of niusrprio_
Janos,
the purpose of the the API call is to configure analog filters, and not the
sampling rate. If your analog bandwidth is lower than the sampling rate,
there's nothing wrong with that. In fact, for the AD9361-based devices,
this is not unusual, since the analog bandwidth is 56 MHz, but the max
12 matches
Mail list logo
