[USRP-users] Multiple RFNoC blocks instantiated

[Mark Luscombe via USRP-users]

Hi,

I've found that if i add a second instance of the same RFNoC block to a GRC
signal flow it fails to compile, complaining that there are duplicate
connections to the first instance of the RFNoC block. This happens with
either my own RFNoC blocks or Ettus RFNoC blocks. Am i missing something as
it seems like the environment currently cannot handle multiple instances. I
guess worse case i could make duplicates of the RFNoC blocks i want
multiple instances of, so that each instance is unique but this is not
ideal.

Thanks, Mark.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Multiple RFNoC blocks instantiated

[Mark Luscombe via USRP-users]

P.S. Obviously i have compiled 2 instances of the block into the FPGA
image, maybe i need to add some unique identification at this point?

On 8 December 2017 at 12:42, Mark Luscombe  wrote:

> Hi,
>
> I've found that if i add a second instance of the same RFNoC block to a
> GRC signal flow it fails to compile, complaining that there are duplicate
> connections to the first instance of the RFNoC block. This happens with
> either my own RFNoC blocks or Ettus RFNoC blocks. Am i missing something as
> it seems like the environment currently cannot handle multiple instances. I
> guess worse case i could make duplicates of the RFNoC blocks i want
> multiple instances of, so that each instance is unique but this is not
> ideal.
>
> Thanks, Mark.
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] X310 degraded SNR

[Mark Koenig via USRP-users]

I am mainly looking at frequencies above 2 GHz, would adjusting the 
dB_clock_rate be something that may help with the noise floor and help my SNR?  
For reasons beyond my control, I am currently using UHD rev 003.009.007.  I 
hope this not an issue.

Thank you

Mark

From: Mark Koenig 
Date: Wednesday, December 6, 2017 at 10:24 AM
To: "usrp-users@lists.ettus.com" , 
"usrp-users@lists.ettus.com" 
Subject: X310 degraded SNR

I do see a slight change in SNR when moving to gain up and down, but nothing to 
give me a significant improvement.

I am very interested in the LO comment.  What does this mean?

Also, is there any front end filtering that may be different between the N210 
and the X310?  Or maybe the CBX 120 vs. the UBX 40?

Thanks

Mark

Get Outlook for iOS

From: USRP-users  on behalf of 
usrp-users-requ...@lists.ettus.com 
Sent: Tuesday, December 5, 2017 1:47:47 PM
To: usrp-users@lists.ettus.com
Subject: USRP-users Digest, Vol 88, Issue 5

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. UHD Errors (rjm96)
   2. Re: UHD Errors (Marcus D. Leech)
   3. Re: Error during synthesis (Andr? Gomes)
   4. Re: UHD Errors (Richard Mcallister)
   5. Decrease in SNR seen with X310 (Mark Koenig)
   6. Re: Decrease in SNR seen with X310 (Marcus D. Leech)
   7. Re: Decrease in SNR seen with X310 (ROBIN TORTORA)
   8. Re: Decrease in SNR seen with X310 (Mark Koenig)
   9. Re: UHD Errors (Richard Mcallister)
  10. Re: UHD Errors (Marcus D. Leech)
  11. Reminder -- USRP/GNU Radio and RFNoC Workshops in the Los
  Angeles Area (Neel Pandeya)


--

Message: 1
Date: Mon, 04 Dec 2017 16:11:40 -0500
From: rjm96 
To: "USRP-users@lists.ettus.com" 
Subject: [USRP-users] UHD Errors
Message-ID:

Content-Type: text/plain; charset="utf-8"

HI All,

I'm running the same setup as last time I emailed-4 X310s, 1gig ethernet, 
Ubuntu 17.04, UHD 3.96 and GNU Radio 3.7.12. My flowgraph is 8 complex inputs 
into a USRP sink, and I can attach it if need be. Each input is a some wave of 
different frequency, at a 2M sample rate.

Anyways, the new flowgraph solved the previous problem of not even starting and 
freezing almost immediately. However this one has 3 different errors that I 
can't pinpoint. I never get them at the same time, but i get them each about 
half of the time whenever I execute the flowgraph in grc or call top_block.py 
from the terminal. Here are the two errors copied and pasted below.

[WARNING] [X300] x300_dac_ctrl: front-end sync failed. unexpected FIFO depth 
[0x0]
?Or?
thread[thread-per-block[24]: ]: RuntimeError: 
x300_dac_ctrl: front-end sync failed. unexpected FIFO depth [0x0]
The 0x0 can be other hex values too, like 0x7 for example. The first error, it 
doesn't transmit but keeps running while on the second it just fails entirely. 
Note-I am not using RFNoC, it just a normal imahe downloaded with 
uhd_images_downloader The other error is:
terminate called after throwing an instance of 'uhd::io_error'
? what():? EnvironmentError: IOError: [1/DmaFIFO_0] sr_read64() failed: 
EnvironmentError: IOError: Block ctrl (CE_00_Port_30) no response packet - 
AssertionError: bool(buff)
? in uint64_t ctrl_iface_impl::wait_for_ack(bool)
? at 
/home/mcl-sdvlc/prefix/default_prefix/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:197
While I know the top one is a FPGA error, I'm not sure what the second is.

?Finally, when it does run, sometimes one of the USRPs is not transmitting or 
not transmitting on both channels, though there are no error messages.

Thanks,Rich
-- next part --
An HTML attachment was scrubbed...
URL: 


--

Message: 2
Date: Mon, 04 Dec 2017 16:20:24 -0500
From: "Marcus D. Leech" 
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] UHD Errors
Message-ID: <5a25bc18.3070...@ripnet.com>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"

On 12/04/2017 04:11 PM, rjm96 via USRP-users wrote:
> HI All,
>
> I'm running the same setup as last time I emailed-4 X310s, 1gig
> ethernet, Ubuntu 17.04, UHD 3.96 and GNU Radio 3.7.12. My flowgraph is
> 8 complex inputs into a USRP sink, and I can attach it if need be.
> Each input is a some wave of different frequency, at a 2M sample rate.
Could you try upgrading to a newer (3.10.X) re

[USRP-users] RFNoC Out-of-tree block controller setup

[EJ Kreinar via USRP-users]

Hi All,

I'm having trouble getting an OOT RFNoC block controller to register
correctly with the rfnoc block factory. The goal here is to create a block
controller class that attaches to the FPGA CE.

I've traced this operation down to the block_ctrl_base_factory.cpp, which
exposes the register_block(...) function that is called from RFNoC block
controllers using the UHD_RFNOC_BLOCK_REGISTER macro. When I add a debug
statement in the register_block function, I can see all of the block
controllers in the UHD repo getting registered at the start of a
uhd_usrp_probe, but my OOT block is not registered here.

Register block adding key: Block
Register block adding key: DDC
Register block adding key: DUC
Register block adding key: FIR
Register block adding key: NullSrcSink
Register block adding key: Window
Register block adding key: SigGen
Register block adding key: DmaFIFO
Register block adding key: X300Radio

If I take the SAME block controller cpp and hpp files from my OOT repo,
insert into the UHD repo with corresponding CMakeLists edits, and then
rerun, I can see the block controller get registered on startup.

Any suggestions how to register the blocks from the OOT repos??  Am I
missing something obvious?

Thanks!
EJ
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] X310 degraded SNR

[Marcus D. Leech via USRP-users]

On 12/08/2017 09:18 AM, Mark Koenig via USRP-users wrote:


I am mainly looking at frequencies above 2 GHz, would adjusting the 
dB_clock_rate be something that may help with the noise floor and help 
my SNR?  For reasons beyond my control, I am currently using UHD rev 
003.009.007.  I hope this not an issue.


Thank you

Mark


I rather doubt that changing clock rate would change your situation.

Do you have other UBX cards you can try?   Have you checked your 
connection integrity between the UBX and the front-panel?




*From: *Mark Koenig 
*Date: *Wednesday, December 6, 2017 at 10:24 AM
*To: *"usrp-users@lists.ettus.com" , 
"usrp-users@lists.ettus.com" 

*Subject: *X310 degraded SNR

I do see a slight change in SNR when moving to gain up and down, but 
nothing to give me a significant improvement.


I am very interested in the LO comment.  What does this mean?

Also, is there any front end filtering that may be different between 
the N210 and the X310?  Or maybe the CBX 120 vs. the UBX 40?


Thanks

Mark

Get Outlook for iOS 



*From:*USRP-users  on behalf of 
usrp-users-requ...@lists.ettus.com 

*Sent:* Tuesday, December 5, 2017 1:47:47 PM
*To:* usrp-users@lists.ettus.com
*Subject:* USRP-users Digest, Vol 88, Issue 5

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. UHD Errors (rjm96)
   2. Re: UHD Errors (Marcus D. Leech)
   3. Re: Error during synthesis (Andr? Gomes)
   4. Re: UHD Errors (Richard Mcallister)
   5. Decrease in SNR seen with X310 (Mark Koenig)
   6. Re: Decrease in SNR seen with X310 (Marcus D. Leech)
   7. Re: Decrease in SNR seen with X310 (ROBIN TORTORA)
   8. Re: Decrease in SNR seen with X310 (Mark Koenig)
   9. Re: UHD Errors (Richard Mcallister)
  10. Re: UHD Errors (Marcus D. Leech)
  11. Reminder -- USRP/GNU Radio and RFNoC Workshops in the Los
  Angeles Area (Neel Pandeya)


--

Message: 1
Date: Mon, 04 Dec 2017 16:11:40 -0500
From: rjm96 
To: "USRP-users@lists.ettus.com" 
Subject: [USRP-users] UHD Errors
Message-ID:

Content-Type: text/plain; charset="utf-8"

HI All,

I'm running the same setup as last time I emailed-4 X310s, 1gig 
ethernet, Ubuntu 17.04, UHD 3.96 and GNU Radio 3.7.12. My flowgraph is 
8 complex inputs into a USRP sink, and I can attach it if need be. 
Each input is a some wave of different frequency, at a 2M sample rate.


Anyways, the new flowgraph solved the previous problem of not even 
starting and freezing almost immediately. However this one has 3 
different errors that I can't pinpoint. I never get them at the same 
time, but i get them each about half of the time whenever I execute 
the flowgraph in grc or call top_block.py from the terminal. Here are 
the two errors copied and pasted below.


[WARNING] [X300] x300_dac_ctrl: front-end sync failed. unexpected FIFO 
depth [0x0]

?Or?
thread[thread-per-block[24]: ]: 
RuntimeError: x300_dac_ctrl: front-end sync failed. unexpected FIFO 
depth [0x0]
The 0x0 can be other hex values too, like 0x7 for example. The first 
error, it doesn't transmit but keeps running while on the second it 
just fails entirely. Note-I am not using RFNoC, it just a normal imahe 
downloaded with uhd_images_downloader The other error is:

terminate called after throwing an instance of 'uhd::io_error'
? what():? EnvironmentError: IOError: [1/DmaFIFO_0] sr_read64() 
failed: EnvironmentError: IOError: Block ctrl (CE_00_Port_30) no 
response packet - AssertionError: bool(buff)

? in uint64_t ctrl_iface_impl::wait_for_ack(bool)
? at 
/home/mcl-sdvlc/prefix/default_prefix/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:197

While I know the top one is a FPGA error, I'm not sure what the second is.

?Finally, when it does run, sometimes one of the USRPs is not 
transmitting or not transmitting on both channels, though there are no 
error messages.


Thanks,Rich
-- next part --
An HTML attachment was scrubbed...
URL: 



--

Message: 2
Date: Mon, 04 Dec 2017 16:20:24 -0500
From: "Marcus D. Leech" 
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] UHD Errors
Message-ID: <5a25bc18.3070...@ripnet.com>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"

On 12/04/2017 04:11 PM, rjm96 via USRP-users wrote:
> HI All,
>
> I'm run

Re: [USRP-users] UHD 3.10.2.0 | X300 - ERROR_CODE_TIMEOUT with low rates

[Michael West via USRP-users]

Hi Kyle,

Thank you for the good information.  We will be increasing the timeout in
the next release of UHD, so the issues should be resolved soon.

Regards,
Michael

On Wed, Nov 15, 2017 at 9:19 AM, Guilbert, Kyle J via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Greetings,
>
> I am experiencing a similar timeout problem to the one reported in the
> thread "UHD 3.10.2 | X300 - High CPU load even for low samples rate".
> I'm using an X310 with LFRX/LFTX and UHD 3.10.2.0 (maint) and can
> reproduce the issue with benchmark_rate for RX and TX somewhere under 10
> MS/s.
> When I use benchmark_rate with RX only as suggested by Michael West,
> there's no issue. But when I do simultaneous RX and TX I get a flurry of
> ERROR_CODE_TIMEOUT messages after a few seconds:
>
> benchmark_rate --rx_rate 20e6 --tx_rate 20e6 --duration 20: OK
> benchmark_rate --rx_rate 10e6 --tx_rate 10e6 --duration 20: OK
> benchmark_rate --rx_rate 5e6 --tx_rate 5e6 --duration 20:
> ERROR_CODE_TIMEOUT errors
> (failures continue for lower rates)
>
> benchmark_rate --rx_rate 20e6 --duration 20: OK
> benchmark_rate --rx_rate 10e6 --duration 20: OK
> benchmark_rate --rx_rate 5e6 --duration 20: OK
> benchmark_rate --rx_rate 1e6 --duration 20: OK
> (note: the same goes for tx only)
>
> Also I can confirm that when I change the timeout value in the
> get_recv_buff() call in device3_io_impl.cpp from 1 us to 10 ms,
> all these configurations work. Let me know if there's any more information
> I can provide.
>
> Regards,
> Kyle
>
> ___
> 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

Re: [USRP-users] RFNoC Out-of-tree block controller setup

[EJ Kreinar via USRP-users]

Well, per usual, I believe I've figured this out with some more digging...

1. If I run a python program that includes my OOT module, the blocks are
registered correctly with the block_ctrl_base_factory, and the
initialization call to ettus.device3 will correctly correlate my FPGA CE
with the OOT controller.

2. I assume that a C program will also register blocks correctly if it uses
the my class and links to the OOT module

3. But the uhd_usrp_probe is *not* linked to my OOT module, so I dont think
I should expect it to register my new controller class.

Conclusion #3 is sad because I like using uhd_usrp_probe as a debug tool to
evaluate whether blocks are configured and initialized correctly, but I'm
not sure if there's a way to get around this.. Maybe I could create an OOT
uhd_usrp_probe function that compiles/links with my OOT repo(s)?

Is this all correct?
EJ

On Fri, Dec 8, 2017 at 11:52 AM, EJ Kreinar  wrote:

> Hi All,
>
> I'm having trouble getting an OOT RFNoC block controller to register
> correctly with the rfnoc block factory. The goal here is to create a block
> controller class that attaches to the FPGA CE.
>
> I've traced this operation down to the block_ctrl_base_factory.cpp, which
> exposes the register_block(...) function that is called from RFNoC block
> controllers using the UHD_RFNOC_BLOCK_REGISTER macro. When I add a debug
> statement in the register_block function, I can see all of the block
> controllers in the UHD repo getting registered at the start of a
> uhd_usrp_probe, but my OOT block is not registered here.
>
> Register block adding key: Block
> Register block adding key: DDC
> Register block adding key: DUC
> Register block adding key: FIR
> Register block adding key: NullSrcSink
> Register block adding key: Window
> Register block adding key: SigGen
> Register block adding key: DmaFIFO
> Register block adding key: X300Radio
>
> If I take the SAME block controller cpp and hpp files from my OOT repo,
> insert into the UHD repo with corresponding CMakeLists edits, and then
> rerun, I can see the block controller get registered on startup.
>
> Any suggestions how to register the blocks from the OOT repos??  Am I
> missing something obvious?
>
> Thanks!
> EJ
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] X310 degraded SNR

[Radio User via USRP-users]

Note that the CBX lower frequency "limit" is around 1.2GHz
while the UBX is quite happy tuning down to 10MHz.

There are many powerful ambient signal sources between
10MHz and 1.2GHz.  I suspect you are seeing those.

Nonlinearity being what it is, I have seen AM broadcast signals
appear in the sample stream way up at 144MHz and beyond.
FM broadcast signals can easily make themselves apparent
above 1GHz...

Try a front-end filter.

matt
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Burst Transmit/Acquisition on X310 (or other USRP)

[John Malsbury via USRP-users]

I have an urgent need to do a quick finite burst/acquisition app with an
X310.  Basically, I'd like to perform a timed transmission of 2e6 complex
samples to the radio, and do an aligned acquisition of 2e6 samples from the
receiver at exactly the same sample clock cycle.  I need to do this from a
fairly lightweight and low performance machine (slightly less than a
typical laptop).Looking to do these at a 100 MS/s rate on X310 or
~60ish if B210/E310, but definitely not continuously streaming.  I may even
consider doing this on the B210/E310 at a lower rate (60e6?).

I can't remember if the X310 has enough buffer/DDR3/whatever to accept a
full burst that large from a low performance host that can't actually keep
up with real streaming.  My assumption is the the kernel can buffer an
incoming 2e6 sample receive burst without issue.

*Will this work on the X310 (or E310 or B210?)*  I'm sorta looking for a
simple yes/no, but would take detailed suggestions if you have them.

Sorry for the mostly dumb questions...  its not like i used to work at ER
or anything...

the future of humanity thanks you

-John
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Burst Transmit/Acquisition on X310 (or other USRP)

[John Malsbury via USRP-users]

Looks like there is suffecient buffering on usrp for timed transmit with a
slim (1 gig) interface.

Not so for rx though...



On Dec 8, 2017 1:05 PM, "John Malsbury" 
wrote:

> I have an urgent need to do a quick finite burst/acquisition app with an
> X310.  Basically, I'd like to perform a timed transmission of 2e6 complex
> samples to the radio, and do an aligned acquisition of 2e6 samples from the
> receiver at exactly the same sample clock cycle.  I need to do this from a
> fairly lightweight and low performance machine (slightly less than a
> typical laptop).Looking to do these at a 100 MS/s rate on X310 or
> ~60ish if B210/E310, but definitely not continuously streaming.  I may even
> consider doing this on the B210/E310 at a lower rate (60e6?).
>
> I can't remember if the X310 has enough buffer/DDR3/whatever to accept a
> full burst that large from a low performance host that can't actually keep
> up with real streaming.  My assumption is the the kernel can buffer an
> incoming 2e6 sample receive burst without issue.
>
> *Will this work on the X310 (or E310 or B210?)*  I'm sorta looking for a
> simple yes/no, but would take detailed suggestions if you have them.
>
> Sorry for the mostly dumb questions...  its not like i used to work at ER
> or anything...
>
> the future of humanity thanks you
>
> -John
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com