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<https://aka.ms/o0ukef> ________________________________ From: USRP-users <usrp-users-boun...@lists.ettus.com> on behalf of usrp-users-requ...@lists.ettus.com <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 <rj...@bu.edu> To: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com> Subject: [USRP-users] UHD Errors Message-ID: <CALNG9q=etzn6hd0vgqh1+tw2cux-xemfa0yrs_y3munlgxi...@mail.gmail.com> 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]: <block gr uhd usrp sink (1)>]: 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: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171204/e0f944a1/attachment-0001.html> ------------------------------ Message: 2 Date: Mon, 04 Dec 2017 16:20:24 -0500 From: "Marcus D. Leech" <mle...@ripnet.com> 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) release of UHD? Also, what are the specs on your computer? > > 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]: <block gr uhd usrp sink (1)>]: > 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 > > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171204/eeda2b6d/attachment-0001.html> ------------------------------ Message: 3 Date: Mon, 4 Dec 2017 19:24:29 -0200 From: Andr? Gomes <andre.go...@dcc.ufmg.br> To: "Marcus D. Leech" <mle...@ripnet.com> Cc: usrp-users@lists.ettus.com, Racyus Delano Garcia Pac?fico <racyusdela...@gmail.com> Subject: Re: [USRP-users] Error during synthesis Message-ID: <CAETBXyZmisGYQ7x+S-b4W5um1cpMMxfZBxLCVthnw_jKiXS=x...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi Marcus, You are right! When I ran without sudo, I had a problem with file permissions. Sudo was a lazy working around and it ended up being a bad one. ? That's said, everything works fine now. Thanks for you help! Regards, *Andr? Gomes* Email: andre.go...@dcc.ufmg.br Homepage: http://homepages.dcc.ufmg.br/~andre.gomes/ Mobile: +55 31 994859285 <+55%2031%2099485-9285> On 4 December 2017 at 14:32, Marcus D. Leech via USRP-users < usrp-users@lists.ettus.com> wrote: > There's absolutely no reason to run "make" as root. When you run sudo, > your PATH variable, by default is not inherited by the root shell that is > created. > > > On 12/04/2017 10:26 AM, Andr? Gomes via USRP-users wrote: > > I'm facing a problem during synthesis for USRP B210. The problem is shown > below. It occurs when I try to run *sudo* *make B210 b200.v* under > directory /opt/uhd/fpga-src/usrp3/top/b200. > > */bin/sh: 1: xtclsh: not found* > ISE Version: > make -f Makefile.b200.inc bin NAME=B210 DEVICE=XC6SLX150 > EXTRA_DEFS="TARGET_B210=1 " > make[1]: Entering directory '/opt/uhd/fpga-src/usrp3/top/b200' > /bin/sh: 1: xtclsh: not found > /bin/sh: 1: xtclsh: not found > build-B210//b200.xise > xtclsh /opt/uhd/fpga-src/usrp3/top/tcl/ise_helper.tcl "" > /bin/sh: 1: xtclsh: not found > ../Makefile.common:51: recipe for target 'build-B210//b200.xise' failed > make[1]: *** [build-B210//b200.xise] Error 127 > make[1]: Leaving directory '/opt/uhd/fpga-src/usrp3/top/b200' > Makefile:77: recipe for target 'B210' failed > make: *** [B210] Error 2 > > I installed the Xilinx tools. I can find *xtclsh* on > */opt/Xilinx/14.7/ISE_DS/ISE/bin/lin/xtclsh*. Moreover, *xtclsh* is also > set up in my environment. See figure below. > > [image: Inline images 1] > > Have anyone faced any related problem? > > Regards, > > > > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171204/d1f98da7/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 31729 bytes Desc: not available URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171204/d1f98da7/attachment-0001.png> ------------------------------ Message: 4 Date: Mon, 4 Dec 2017 16:30:51 -0500 From: Richard Mcallister <rj...@bu.edu> To: "Marcus D. Leech" <mle...@ripnet.com> Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com> Subject: Re: [USRP-users] UHD Errors Message-ID: <CALNG9qm4Sg1FunTbQE6C4B9cEHKxpcpd8uTSd-khc==ia74...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi Marcus, Thanks for the quick reply. I can try upgrading to a new version-but it was with the latest version of UHD that I had my previous problems, where near instant underruns would trigger late samples and freeze the program. The computer has like 64gb memory, NVIDIA 1080, 16-core Intel CPU, I think its i7 or i9 (not sure the exact model and buts its speed is >3GHz). I'm pretty sure its not the computer-the CPU should definitely be able to handle this. Are there other specs I should double-check? I'll try upgrading after class. -Rich On Mon, Dec 4, 2017 at 4:20 PM, Marcus D. Leech via USRP-users < usrp-users@lists.ettus.com> wrote: > 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) release of UHD? > > Also, what are the specs on your computer? > > > > 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]: <block gr uhd usrp sink (1)>]: 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 > > > _______________________________________________ > USRP-users mailing > listUSRP-users@lists.ettus.comhttp://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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171204/b482ab60/attachment-0001.html> ------------------------------ Message: 5 Date: Mon, 4 Dec 2017 21:43:55 +0000 From: Mark Koenig <mark.koe...@iubelttechnologies.com> To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com> Subject: [USRP-users] Decrease in SNR seen with X310 Message-ID: <d873db5b-18ac-42ad-9fb0-eebc2c75c...@contoso.com> Content-Type: text/plain; charset="utf-8" I have been collecting signals in a lab environment using an N210 with a CBX card without any perceived issues. When running the uhd_fft script I am seeing an SNR of 20-30 dB, which is enough for me to do the post processing of the collected signals. When I upgraded to the X310 with UBX40 cards I noticed a much higher noise floor and a decrease in SNR ~10dB. This decrease in SNR makes it unable for me to post process the signals. I am operating in Rx mode only. Does anyone have any thoughts as to what might be going on? Thank you Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171204/d06ded6a/attachment-0001.html> ------------------------------ Message: 6 Date: Mon, 04 Dec 2017 16:55:43 -0500 From: "Marcus D. Leech" <mle...@ripnet.com> To: usrp-users@lists.ettus.com Subject: Re: [USRP-users] Decrease in SNR seen with X310 Message-ID: <5a25c45f.8070...@ripnet.com> Content-Type: text/plain; charset="windows-1252"; Format="flowed" On 12/04/2017 04:43 PM, Mark Koenig via USRP-users wrote: > > I have been collecting signals in a lab environment using an N210 with > a CBX card without any perceived issues. When running the uhd_fft > script I am seeing an SNR of 20-30 dB, which is enough for me to do > the post processing of the collected signals. > > When I upgraded to the X310 with UBX40 cards I noticed a much higher > noise floor and a decrease in SNR ~10dB. This decrease in SNR makes > it unable for me to post process the signals. > > I am operating in Rx mode only. > > Does anyone have any thoughts as to what might be going on? > > Thank you > > Mark > > > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com Could you try adjusting gain downwards/upwards by a few dB and see if that makes a difference in SNR? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171204/4a0c2df3/attachment-0001.html> ------------------------------ Message: 7 Date: Mon, 4 Dec 2017 17:57:44 -0500 (EST) From: ROBIN TORTORA <ti...@comcast.net> To: Mark Koenig <mark.koe...@iubelttechnologies.com>, Mark Koenig via USRP-users <usrp-users@lists.ettus.com> Subject: Re: [USRP-users] Decrease in SNR seen with X310 Message-ID: <49604772.43482.1512428267...@connect.xfinity.com> Content-Type: text/plain; charset="utf-8" The LO feed through on the UBX is wicked high... Offset tuning helps alot... > On December 4, 2017 at 4:43 PM Mark Koenig via USRP-users > <usrp-users@lists.ettus.com> wrote: > > > I have been collecting signals in a lab environment using an N210 with a > CBX card without any perceived issues. When running the uhd_fft script I am > seeing an SNR of 20-30 dB, which is enough for me to do the post processing > of the collected signals. > > > > When I upgraded to the X310 with UBX40 cards I noticed a much higher > noise floor and a decrease in SNR ~10dB. This decrease in SNR makes it > unable for me to post process the signals. > > > > I am operating in Rx mode only. > > > > Does anyone have any thoughts as to what might be going on? > > > > Thank you > > > > Mark > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171204/148fa83f/attachment-0001.html> ------------------------------ Message: 8 Date: Mon, 4 Dec 2017 23:01:22 +0000 From: Mark Koenig <mark.koe...@iubelttechnologies.com> To: ROBIN TORTORA <ti...@comcast.net>, Mark Koenig via USRP-users <usrp-users@lists.ettus.com> Subject: Re: [USRP-users] Decrease in SNR seen with X310 Message-ID: <bn4pr12mb0804dda9f7643b1e22d2eb128c...@bn4pr12mb0804.namprd12.prod.outlook.com> Content-Type: text/plain; charset="us-ascii" Thanks for the quick response! Can you provide more details to your statement? Thanks Mark Get Outlook for iOS<https://aka.ms/o0ukef> ________________________________ From: ROBIN TORTORA <ti...@comcast.net> Sent: Monday, December 4, 2017 5:57:44 PM To: Mark Koenig; Mark Koenig via USRP-users Subject: Re: [USRP-users] Decrease in SNR seen with X310 The LO feed through on the UBX is wicked high... Offset tuning helps alot... On December 4, 2017 at 4:43 PM Mark Koenig via USRP-users <usrp-users@lists.ettus.com> wrote: I have been collecting signals in a lab environment using an N210 with a CBX card without any perceived issues. When running the uhd_fft script I am seeing an SNR of 20-30 dB, which is enough for me to do the post processing of the collected signals. When I upgraded to the X310 with UBX40 cards I noticed a much higher noise floor and a decrease in SNR ~10dB. This decrease in SNR makes it unable for me to post process the signals. I am operating in Rx mode only. Does anyone have any thoughts as to what might be going on? Thank you Mark _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171204/78639984/attachment-0001.html> ------------------------------ Message: 9 Date: Mon, 4 Dec 2017 19:18:12 -0500 From: Richard Mcallister <rj...@bu.edu> To: "Marcus D. Leech" <mle...@ripnet.com> Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com> Subject: Re: [USRP-users] UHD Errors Message-ID: <calng9qkuaxr5dyticpbvqdb5fljqakfl-jhgjj_qpoverfu...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi, I upgraded to 3.10.2, it always runs but there are underruns immediately after executing. If i leave it, it freezes and crashes in minute. More system info: Intel i7-6900K, 16 cores @ 3.2Ghz, max Ghz 4.0. 62.8Gb ram. -Rich On Mon, Dec 4, 2017 at 4:20 PM, Marcus D. Leech via USRP-users < usrp-users@lists.ettus.com> wrote: > 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) release of UHD? > > Also, what are the specs on your computer? > > > > 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]: <block gr uhd usrp sink (1)>]: 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 > > > _______________________________________________ > USRP-users mailing > listUSRP-users@lists.ettus.comhttp://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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171204/4a71fc45/attachment-0001.html> ------------------------------ Message: 10 Date: Mon, 04 Dec 2017 20:28:46 -0500 From: "Marcus D. Leech" <mle...@ripnet.com> To: Richard Mcallister <rj...@bu.edu> Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com> Subject: Re: [USRP-users] UHD Errors Message-ID: <5a25f64e.7060...@ripnet.com> Content-Type: text/plain; charset="utf-8"; Format="flowed" On 12/04/2017 07:18 PM, Richard Mcallister wrote: > Hi, > > I upgraded to 3.10.2, it always runs but there are underruns > immediately after executing. If i leave it, it freezes and crashes in > minute. > > More system info: Intel i7-6900K, 16 cores @ 3.2Ghz, max Ghz 4.0. > 62.8Gb ram. > > -Rich > Perhaps, at this point, you could share your flow-graph? > On Mon, Dec 4, 2017 at 4:20 PM, Marcus D. Leech via USRP-users > <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote: > > 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) release of UHD? > > Also, what are the specs on your computer? > > >> >> 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]: <block gr uhd usrp sink (1)>]: >> 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 >> >> >> _______________________________________________ >> USRP-users mailing list >> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com> >> http://lists.ettus.com/mailman/listinfo/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 <mailto:USRP-users@lists.ettus.com> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171204/dd0333c8/attachment-0001.html> ------------------------------ Message: 11 Date: Mon, 4 Dec 2017 17:57:54 -0800 From: Neel Pandeya <neel.pand...@ettus.com> To: usrp-users <usrp-users@lists.ettus.com> Subject: [USRP-users] Reminder -- USRP/GNU Radio and RFNoC Workshops in the Los Angeles Area Message-ID: <cacaxmv-mwaj7gsbmdsgqgaj8rfcfbgrw0b3v_dkq0v10pcu...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" ====================================================================== Ettus Research will be running a series of free, hands-on, technical workshops in the Los Angeles area next week. USRP, UHD, GNU Radio Workshop Tuesday December 12, from 09:00 to 17:00 El Segundo, California, USA RFNoC Workshop Wednesday December 13, from 09:00 to 16:00 El Segundo, California, USA USRP, UHD, GNU Radio Workshop Thursday December 14, from 09:00 to 17:00 Santa Ana, California, USA RFNoC Workshop Friday December 15, from 09:00 to 16:00 Santa Ana, California, USA ====================================================================== Descriptions of the Workshops: Title: Introduction to the USRP, UHD, and GNU Radio (Open-Source Toolchain) Abstract: This workshop will provide a thorough and practical introduction to the USRP hardware and the open-source software toolchain (UHD and GNU Radio). We will examine the hardware and architecture of the entire USRP family of software-defined radios. We will discuss topics such as how to get started using a new USRP device, how to install and configure the open-source software toolchain, programming the USRP using the UHD API from C++, using GNU Radio with the USRP and creating and running flowgraphs, using GNU Radio from both GRC and Python, and various debugging techniques. Several exercises will be performed, such as implementing an FM transmitter and receiver. Various demonstrations of wireless systems will be shown. A discussion of the embedded E310 radio and using embedded SDR will be included. Several other open-source tools will be discussed, such as GQRX, Fosphor, Inspectrum, and several Out-of-Tree (OOT) modules. A discussion of cellular applications, including OpenBTS and LTE stacks, as well as GPS/GNSS applications will be presented. Several other miscellaneous topics such as 10 Gigabit Ethernet networking, host system performance tuning, X300/X310 device recovery, and some best practices will be discussed. Attendees should come away with a solid foundation and practical understanding of how to configure, program, and use the USRP to implement a wide range range of wireless systems. Title: FPGA Programming on the USRP with the RFNoC Framework Abstract: Ettus Research's RFNoC (RF Network-on-Chip) software framework is designed to decrease the development time for experienced FPGA engineers seeking to integrate IP into the USRP FPGA signal processing chain. RFNoC is the framework for USRP devices that use Xilinx 7-series FPGAs (E310, E312, X300, X310). RFNoC is built around a packetized network infrastructure in the FPGA that handles the transport of control and sample data between the host CPU and the radio. Users target their custom algorithms to the FPGA in the form of Computation Engines (CE), which are processing blocks that attach to this network. CEs act as independent nodes on the network that can receive and transmit data to any other node (e.g., another CE, the radio block, or the host CPU). Users can create modular, FPGA-accelerated SDR applications by chaining CEs into a flow graph. RFNoC is supported in UHD and GNU Radio. In this workshop, we will present an interactive hands-on tutorial on RFNoC, including a discussion on its design and capabilities, demonstrations of several existing examples, and a walk-through on implementing a user-defined CE and integrating the CE into GNU Radio. ====================================================================== Addresses of the two workshop locations: AWR Corporation / National Instruments 1960 E Grand Avenue, Suite 430 El Segundo, California, 90245 http://www.awrcorp.com/company/contact-us/locations WinSoft 1932 E Deere Avenue, Suite 110 Santa Ana, California, 92705 http://www.winsoft.com/ http://www.ni.com/training/locations/ ====================================================================== Details and Logistics: * The workshops are free, technical, and hands-on. * The content of the two sessions of the USRP, UHD, GNU Radio Workshop and the RFNoC Workshop will be the same between El Segundo and Santa Ana. * Each day, coffee and donuts/bagels will be provided at 08:30, as well as lunch around 12:00, and an afternoon snack. * In both workshops, laptop computers and USRP radios will be provided for use. Attendees do not need to bring or prepare anything. * Space is limited and will be allocated on a first-come, first-serve basis. * Registration is required in advance. To register, please email "supp...@ettus.com". * Be sure to specify your (1) full name, (2) email address, (3) telephone number, (4) company/organization, and (5) which workshop(s) you will attend. * Your registration information will not be shared with any external third-parties whatsoever. * You are not considered to be registered until you have received a confirmation email. * For the USRP/GNU Radio Workshop, attendees should have some previous experience with Linux and using the Linux command line, and basic familiarity with a programming language such as C, C++, or Python, and basic fundamental concepts in DSP and RF. For the RFNoC Workshop, attendees should also have some basic familiarity with Verilog. Extensive or deep experience with these topics is not necessary. * Please email "supp...@ettus.com" if you have any questions. * We look forward to seeing you there! ====================================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171204/f9c96a7f/attachment-0001.html> ------------------------------ Subject: Digest Footer _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com ------------------------------ End of USRP-users Digest, Vol 88, Issue 5 *****************************************
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
