Moving to uhd-fpga and checking out 'ebf5eed' did the trick. Recompile the
fpga. In working order again.
Thank you for walking be through the rfnoc structure with respect to the
git repos.
I still think something is wrong with pybombs to cause this error in the
first place.
Corey
On Wed, Oct 10
Dear friends and fans of software defined radio and free/open source
radio topics in general,
next year's FOSDEM (the free and open source developer's meeting in
Brussels, Europe) will, once again, feature a track on Software Defined
Radio and other radio-related topics. To better capture the broa
On 10/10/2018 03:08 PM, Ali Dormiani via USRP-users wrote:
Hello,
We have the exact same problem. My lab is waiting on some sfp+ cables
so in a few days I will share our screenshots, code, and data binary
files in order to provide this thread with a second example of this
issue. For now, all
>
> 1) When each B210 syncs, the 1PPS pulse between each USRP would be aligned to
> +-50 nsec. Since they're only separated by a few km, I suspect the alignment
> might be better because of common errors (Ionosphere, orbits, clocks, etc) in
> the GPS solution
I think you will find that +/-50nS
Hi Mitch - Can you provide your code for us to review, to get an idea of
what you're doing that's causing this issue for you? Without specific
code, debugging is a little difficult ... And, no, I haven't seen this
issue to the best of my knowledge / understanding of what it might be.
Cheers! - ML
Hello,
I find that sometimes when I initialize a b200 and start streaming in
samples I will get buffers with values of infinity (especially at the last
sample in the buffer). Is this caused by a bad packet or overflow
condition? It also seems to happen randomly.
Thanks for your help,
- mitch
Hello,
We have the exact same problem. My lab is waiting on some sfp+ cables so in
a few days I will share our screenshots, code, and data binary files in
order to provide this thread with a second example of this issue. For now,
all I can say is this problem is not isolated to your N310 or Window
Hi,
When using the UHD "tx_waveforms" example, I can see that the signal
emitted by my N310 USRP is saturated when it’s not supposed to be.
Here's a snapshot of the signal when I set the amplitude to 0.003:
.\tx_waveforms.exe --rate 12.5e6 --nsamps 125000 --freq 1575.42e6
--ampl 0.003 --otw s
Hello Kostas,
NI branded USRPs are incompatible with MATLAB support packages. Can you use an
Ettus-branded radio?
Best,
Mike
From: USRP-users On Behalf Of Kostas
Malliaras via USRP-users
Sent: Wednesday, October 10, 2018 12:26 PM
To: usrp-users@lists.ettus.com
Subject: [USRP-users] The daug
Hello, i am trying to finish my thesis and i am using a NI USRP-2921 device. I
am trying to do some examples in Matlab but when i am trying to send or receive
something i get this error:
-- end libuhd error message output --
-- begin libuhd error message output
All,
I am using an Ettus x310 over PCIe and am noticing that there is a delay
from when my program finished sending to the radio and when the radio tells
me that transmission as ended ( the red Tx light turning off).
As I bump up the sample rate I notice this delay decreases until it is
nonexis
Perhaps the issue is related to pybombs. You mentioned that you completely
reinstalled via pybombs. I seem to recall that the pybombs installation
puts the fpga source into a folder called 'uhd-fpga' or something like
that. But, a manual UHD install puts the fpga source into a folder called
'fpg
I'm confused. If the 'fpga-src' folder is on commit 'ebf5eed', the compat
number should be 35.1. It wasn't changed to 36.0 until the following
commit. I'm pretty sure that I have built an fpga image from this source
and that it ran fine with the uhd 'master' branch.
Rob
On Wed, Oct 10, 2018 at
> No dice, same ver 35 and 36 mismatch error.
When looking at the commit you mention (
6af6ac32c30d2dc0efa6eab61e4a3920649e3e62 ), the expected compat number
is 35 :
https://github.com/EttusResearch/uhd/blob/master/host/lib/usrp/x300/x300_fw_common.h#L26
Looking at the latest FPGA sources on the
No dice, same ver 35 and 36 mismatch error.
On Tue, Oct 9, 2018 at 9:35 PM Corey Hahn wrote:
> Ok, I get it now. They are NOT suppose to match. Using the commands you
> laid out put me on the right branch for fpga-src. Place and Route ing
> again.
>
> Corey
>
> On Tue, Oct 9, 2018 at 9:27 PM
This is a very good point. Indeed my application is not in the same band as
GPS. I'll spend some more time to familiarize myself with the B210!
Stephan
On Wed, 10 Oct 2018 at 09:02, Sylvain Munaut <246...@gmail.com> wrote:
> Hi,
>
> > As a backup, since the B210 has 2 RX chains, I can do my appl
Hi,
> As a backup, since the B210 has 2 RX chains, I can do my application with RX1
> and record GPS L1 signals on RX2, then post-process the GPS data to solve for
> clock offset.
It has 2 RX chains with a single LO, you need to receive the _same_
frequency. (at least within the same RF bandwid
17 matches
Mail list logo
