Hi,
I would suggest reading the RFNoC getting started guide (
https://kb.ettus.com/Getting_Started_with_RFNoC_Development) and making
your correlator into a RFNoC block. Then it will be easy to include your
correlator in a GNU Radio flow graph.
1) Where exactly in the code is the ddc chain instan
Hi Scott,
What paths are failing timing? Also, the Schmidl Cox block has some design
issues that need fixed before it can be useful again. If I remember
correctly, I think there is an issue with the peak detection logic.
Jonathon
On Wed, Jul 17, 2019 at 2:28 AM Scott Mullin via USRP-users <
usrp
I've been testing RFNoC Blocks on the E310 using the SD image from
http://files.ettus.com/binaries/cache/e3xx/meta-ettus-v3.15.0.0-e310_prerelease/
and a recent pull from git: commit
6563c53743617215a18542db7d7050a04a0d409d (HEAD, tag: v3.15.0.0-
e310_prerelease).
I got my RFNoC images doing what
No. You'd need to rebuild it from source.
On Wed, 2019-07-17 at 16:27 -0400, Saeid Hashemi via USRP-users wrote:
> Can I modify it to link against the current version?
>
> On Tue, Jul 16, 2019 at 5:18 PM Marcus D Leech <
> patchvonbr...@gmail.com> wrote:
> > Yes so it’s very likely a compatibilit
Can I modify it to link against the current version?
On Tue, Jul 16, 2019 at 5:18 PM Marcus D Leech
wrote:
> Yes so it’s very likely a compatibility issue.
>
> Your GNURadio install would have installed uhd_fft and likely linked
> against a different UHD version
>
>
> Sent from my iPhone
>
> On
Hi Nate, I left office, so will be able to tell you tomorrow. It happened
in two laptops. One I remember is a brand new Dell latitude 5490. I will
let you know the details tomorrow.
Regards
Sumit
On Wed, Jul 17, 2019 at 6:27 PM Nate Temple wrote:
> Hi Sumit,
>
> What ethernet controller do you h
Hi Sumit,
What ethernet controller do you have in your laptop?
lspci | grep Ethernet
Regards,
Nate Temple
On Wed, Jul 17, 2019 at 9:16 AM Sumit Kumar wrote:
> Hi Nate,
>
> john@john-Precision-M4600:~/pybombs/src/uhd/host/build/examples$ sudo
> ./benchmark_rate --rx_rate 10e6 --tx_rate 10e6 --
Hi Nate,
john@john-Precision-M4600:~/pybombs/src/uhd/host/build/examples$ sudo
./benchmark_rate --rx_rate 10e6 --tx_rate 10e6 --duration 600
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_3.15.0.git-1-gf83faf28
[00:00:00.24] Creating the usrp device with: ...
[INFO] [US
On 07/17/2019 11:27 AM, Sumit Kumar via USRP-users wrote:
Ok I will do this.. but why the transmission with other USRP is
working fine ?
My guess is that you have different FPGA versions in the two devices.
Make sure that you're running a consistent version of UHD (both in your
Gnu Radio world
Hi Sumit,
Actually, I had a typo in the command, that previous benchmark_rate command
only tested RX, can you try passing the --tx_rate param and see if it will
produce sequence errors using benchmark_rate
./benchmark_rate --tx_rate 10e6 --duration 600
Regards,
Nate Temple
On Wed, Jul 17, 2019
Ok I will do this.. but why the transmission with other USRP is working
fine ?
On Wed, Jul 17, 2019 at 5:22 PM Nate Temple wrote:
> Hi Sumit,
>
> So it looks like you have multiple version of UHD installed:
>
> john@john-Precision-M4600:~/pybombs/src/gnuradio/gr-digital/examples/narrowband$
> su
Tried 3 different power supplies, still the same. SS :-/
On Wed, Jul 17, 2019 at 5:20 PM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:
> On 07/17/2019 11:10 AM, Sumit Kumar via USRP-users wrote:
>
> Sorry, here it is.
>
> Benchmark rate summary:
> Num received samples:
Hi Sumit,
So it looks like you have multiple version of UHD installed:
john@john-Precision-M4600:~/pybombs/src/gnuradio/gr-digital/examples/narrowband$
sudo ./benchmark_tx.py -f 2.45G -S 10
linux; GNU C++ version 5.3.1 20151219; Boost_105800;
UHD_003.009.002-0-unknown
john@john-Precision-M4600:
On 07/17/2019 11:10 AM, Sumit Kumar via USRP-users wrote:
Sorry, here it is.
Benchmark rate summary:
Num received samples: 586436
Num dropped samples: 0
Num overruns detected:0
Num transmitted samples: 0
Num sequence errors (Tx): 0
Num sequence errors (Rx): 0
Num
Sorry, here it is.
Benchmark rate summary:
Num received samples: 586436
Num dropped samples: 0
Num overruns detected:0
Num transmitted samples: 0
Num sequence errors (Tx): 0
Num sequence errors (Rx): 0
Num underruns detected: 0
Num late commands:0
Num
Hi Sumit,
It will take 10 minutes for that run to complete. Does it produce a report
at the end of the run?
Regards,
Nate Temple
On Wed, Jul 17, 2019 at 8:06 AM Sumit Kumar wrote:
> Hi Nate,
> No there are not. At the end of the last line, cursor keeps blinking, no
> sequence errors.
>
> john@
Hi Nate,
No there are not. At the end of the last line, cursor keeps blinking, no
sequence errors.
john@john-Precision-M4600:~/pybombs/src/uhd/host/build/examples$ sudo
./benchmark_rate --rx_rate 10e6 --duration 600
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_3.15.0.git-
Hi Sumit,
If you run benchmark_rate for an extend period of time, do you see any
sequence errors?
/usr/local/lib/uhd/examples/benchmark_rate --rx_rate 10e6 --duration 600
Regards,
Nate Temple
On Wed, Jul 17, 2019 at 7:34 AM Sumit Kumar wrote:
> Hi Nate,
> Yes I addressed the first 2 points y
Hi Nate,
Yes I addressed the first 2 points you mentioned.
john@john-Precision-M4600:~/pybombs/src/gnuradio/gr-digital/examples/narrowband$
sudo ./benchmark_tx.py -f 2.45G -S 10
linux; GNU C++ version 5.3.1 20151219; Boost_105800;
UHD_003.009.002-0-unknown
Using Volk machine: avx_64_mmx_orc
-- Op
Hi Sumit,
A couple things to address:
1) Enable Thread priority scheduling on your host
Note it is throwing a warning in the output: "[WARNING] [UHD] Unable to set
the thread priority. Performance may be negatively affected."
https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Too
Hi Robin,
By doing this, the warnings of buffer size are not coming but S
persists.
On Wed, Jul 17, 2019 at 4:10 PM Robin Coxe wrote:
> Try doing what UHD suggests and resizing the send buffer.
>
> *WARNING] [UDP] The send buffer could not be resized sufficiently.*
> *Target sock buff size:
Following is what I am getting after the command you asked to run. The
192.168.10.5 gives SSS.
john@john-Precision-M4600:~/pybombs/src/uhd/host/build/utils$
./usrp_burn_mb_eeprom --read-all --args "addr=192.168.10.5"
Creating USRP device from address: addr=192.168.10.5
[INFO] [UHD] linux; GNU
Yes already tried different cable. Same issue :(
One usrp is good but the other says S!.
On Wed, Jul 17, 2019 at 3:18 PM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:
> On 07/17/2019 07:45 AM, Sumit Kumar via USRP-users wrote:
>
> Hi Jason,
>
> Yes they are consistent,
I never got a response on this, but in case others have the same problems, I
use this command instead of the shutdown -h command: systemctl poweroff
It is a small sample size, but it seems to work every time.
From: Jason Matusiak
Sent: Monday, July 1, 2019 12:03
You are right, the table of revisions was for the X-series
try running the command from your prefix:
src/uhd/host/build/utils/usrp_burn_mb_eeprom --args="type=n200" --read-all
don't quote me on the type portion, I don't have a board in front of me to see
if it is n200 or something else. I //th
On 07/17/2019 07:45 AM, Sumit Kumar via USRP-users wrote:
Hi Jason,
Yes they are consistent, I mean the output of uhd_usrp_probe for both
N200 is exactly the same (except the ip, serial and mac addr).
I do not know where the problem is! Hardware or software
Regards
Sumit
My guess is that you
The sticker for sbx shows F33612 and F33814.
How will this help ?
On Wed, Jul 17, 2019 at 1:50 PM Jason Matusiak <
ja...@gardettoengineering.com> wrote:
> Sumit,
>
> OK, the last idea I have:
>
> There is a sticker on the back of the N-series devices it *usually* says
> the version there, but n
Sumit,
OK, the last idea I have:
There is a sticker on the back of the N-series devices it usually says the
version there, but not always. This has a little info:
https://kb.ettus.com/About_the_Motherboard_and_Daughtercard_EEPROM_on_USRP_Devices#N200.2F210_EEPROM
Do they match?
_
Hi Jason,
Yes they are consistent, I mean the output of uhd_usrp_probe for both N200
is exactly the same (except the ip, serial and mac addr).
I do not know where the problem is! Hardware or software
Regards
Sumit
On Wed, Jul 17, 2019 at 1:19 PM Jason Matusiak <
ja...@gardettoengineering.com> wr
I jost got a response from Ettus. The problem is fixed commit 5f75f73
(release 3.14.1.0). I tested it with my earlier supplied script and it
works.
Maybe this info will be helpful for someone else.
Am 04.06.2019 um 09:54 schrieb Fabian Schwartau via USRP-users:
Does anyone know if this problem
I am not really an N-series guy, so this probably won't be helpful. Have you
tried doing a uhd_usrp_probe on both devices and seen that the responses are
consistent?
From: USRP-users on behalf of Sumit Kumar
via USRP-users
Sent: Wednesday, July 17, 2019 7:15
Hi,
I am trying transmit using Ettus N200 (call it A) but getting this error
message on the console
SSU...
Hi all,
I developed a custom correlation module in Verilog and I would like to
insert it in the usrp x310 fpga image. My goal is to send a signal
(with a usrp b205 mini) at a sampling rate of 1M and to receive it with
the usrp x310. Inside the fpga, my block will look for a certain
sequence
33 matches
Mail list logo
