[USRP-users] Long time for USRP N210 to respond -- is this v3.10, firewall problem, or something else?

Marcus Müller marcus.mueller at ettus.com
Tue Mar 22 17:34:42 EDT 2016


Hi Susan,

glad to hear you've got a solution to the delay problem.

My suspicion is that your Redhat is somehow configured to re-configure
the interface automatically.
The usual "suspect" for that is network-manager interfering with manual
configuration e.g. via ifconfig.

How do you manually set your PC's IP address?

Best regards,
Marcus

PS: How did you reply? I see you've replied to the digest, and that
worked, so I'm a bit confused.

On 22.03.2016 21:51, Mendel, Susan Marie via USRP-users wrote:
> I tried posting a reply on this a couple days ago, but I'm not seeing it. 
>
> It seems the problem was in my DNS settings on the Redhat. On Ubuntu I can set things up so I can switch cables to connect to my USRP or to my network. I tried to set it up the same way on Redhat. Once I put only the local address 192.168.10.1 for connecting to the USRP, the delay was gone. Only problem is now when I want to switch cables I have to change my network settings also. 
>
> I was also finally able to disable the firewall, although I don't think that was causing problems. 
>
> I am still having a problem, though, which is that when I try to do a loop back using txrx_loopback_to_file, it sends a little data then stops, and although it creates a file of the right length, the data in it appears to be garbage. Using the same command on the Ubuntu machine, same USRP, I don't have this problem. In both cases I'm connecting directly to the USRP. I'm thinking it might still have something to do with my network settings and the fact that I'm using full duplex, because just transmitting or just receiving data to/from the USRP seems to work fine now with the Redhat machine, no late or dropped packets or anything.
>
> Susan
> ________________________________________
> From: USRP-users <usrp-users-bounces at lists.ettus.com> on behalf of usrp-users-request at lists.ettus.com <usrp-users-request at lists.ettus.com>
> Sent: Monday, March 21, 2016 10:00 AM
> To: usrp-users at lists.ettus.com
> Subject: USRP-users Digest, Vol 67, Issue 21
>
> Send USRP-users mailing list submissions to
>         usrp-users at 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-request at lists.ettus.com
>
> You can reach the person managing the list at
>         usrp-users-owner at 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. Re: Long time for USRP N210 to respond -- is this v3.10,
>       firewall problem, or something else? (Mendel, Susan Marie)
>    2. E310 GPS lock issue (Tyler)
>    3. Re: Long time for USRP N210 to respond -- is this v3.10,
>       firewall problem, or something else? (Marcus M?ller)
>    4. Re: Long time for USRP N210 to respond -- is this v3.10,
>       firewall problem, or something else? (Marcus D. Leech)
>    5. Re: Long time for USRP N210 to respond -- is this v3.10,
>       firewall problem, or something else? (Marcus M?ller)
>    6. Re: RFNoc Signal Output (Jonathon Pendlum)
>    7. Re: Modelsim execute error for option -64 (Jonathon Pendlum)
>    8. Re: GRC Radio Block Receives no Data (Jonathon Pendlum)
>    9. Re: Vivado Version for fpga RFNoC Branch (Jonathon Pendlum)
>   10. Re: Modelsim execute error for option -64 (Swanson, Craig)
>   11. Re: Modelsim execute error for option -64 (Jonathon Pendlum)
>   12. Re: GRC Radio Block Receives no Data (Zhihong Luo)
>   13. Re: Long time for USRP N210 to respond -- is this v3.10,
>       firewall problem, or something else? (Mendel, Susan Marie)
>   14. IIP2 of E310 (john liu)
>   15. Re: IIP2 of E310 (Marcus D. Leech)
>   16. Re: IIP2 of E310 (john liu)
>   17. Re: RFNoc Signal Output (Eugene Chai)
>   18. E310 - Maximal rate for rx_samples_to_file example (????)
>   19. Re: E310 - Maximal rate for rx_samples_to_file example
>       (Claudio Cicconetti)
>   20. Re: Modelsim execute error for option -64 (Swanson, Craig)
>   21. Re: E310 - Maximal rate for rx_samples_to_file example
>       (James Humphries)
>   22. Demuxer Error : Bad Frames (My Solution So Far) (Kevin McGuire)
>   23. USRP B210 and E310 (Thomas Wagner)
>   24. posting did not go through (Thomas Wagner)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 20 Mar 2016 16:13:52 +0000
> From: "Mendel, Susan Marie" <smendel at lanl.gov>
> To: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
> Subject: Re: [USRP-users] Long time for USRP N210 to respond -- is
>         this v3.10, firewall problem, or something else?
> Message-ID: <1458490431884.8089 at lanl.gov>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Marcus,
>
> I get the same long delay with uhd_usrp_probe but not with uhd_find_devices.
>
> Can I expect things to work OK through the firewall as long as I'm specifying the IP address or is it likely to cause other problems down the road?
>
> I'm going to try to install a released version now but I suspect  I will have the same problem. I was seeing a similar delay on a Windows laptop when I was trying to send data using the Matlab USRP support package. I didn't have the laptop long enough to trouble shoot the problem, which I'm guessing is in my system configuration some where.
>
> Thanks,
> Susan
> ________________________________________
> From: USRP-users <usrp-users-bounces at lists.ettus.com> on behalf of usrp-users-request at lists.ettus.com <usrp-users-request at lists.ettus.com>
> Sent: Sunday, March 20, 2016 10:00 AM
> To: usrp-users at lists.ettus.com
> Subject: USRP-users Digest, Vol 67, Issue 20
>
> Send USRP-users mailing list submissions to
>         usrp-users at 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-request at lists.ettus.com
>
> You can reach the person managing the list at
>         usrp-users-owner at 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. RFNoc Signal Output (Eugene Chai)
>    2. Modelsim execute error for option -64 (Swanson, Craig)
>    3. Re: Long time for USRP N210 to respond -- is this v3.10,
>       firewall problem, or something else? (Marcus D. Leech)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 19 Mar 2016 17:48:46 +0000
> From: Eugene Chai <eugene at nec-labs.com>
> To: USRP-users <usrp-users at lists.ettus.com>
> Subject: [USRP-users] RFNoc Signal Output
> Message-ID: <8BBAC087-4F17-47D5-AF46-CED058E36479 at nec-labs.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi,
>
> I have an RFNoC block on an X310 with three input and one output port.  I used the addsub block as a starting point, and I?m working on the rfnoc-devel git branch.   The RFNoC block acts as a mux ? it  takes three continuous streams from the host PC, and selects one of them for the output.  However, during testing, the output signal seems to be discontinuous.  I?ve attached a plot of the output signal that I captured over the air with a second X310.  Does anybody know what could be wrong here?
>
> Thanks,
> Eugene
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: test_sig.pdf
> Type: application/pdf
> Size: 46295 bytes
> Desc: test_sig.pdf
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160319/dd84005d/attachment-0001.pdf>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 19 Mar 2016 18:09:14 +0000
> From: "Swanson, Craig" <Craig.Swanson at gtri.gatech.edu>
> To: Jonathon Pendlum <jonathon.pendlum at ettus.com>
> Cc: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
> Subject: [USRP-users] Modelsim execute error for option -64
> Message-ID: <1458410953798.64631 at gtri.gatech.edu>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Jonathon,
>
> I have not run a Modelsim simulation in about three months.  This week I decided to upgrade my uhd/fpga-src to the latest rev in git.
>
>
> I tried running the noc_block_qpsk testbench and I got the following error:
>
> Failed to open executable /opt/mentor/modelsim/modelsim_dlx/bin/../linuxpe/../linux_x86_64pe/vish in execute mode needed for the option -64.
> execv: No such file or directory
> ** Fatal: Unable to exec the GUI /opt/mentor/modelsim/modelsim_dlx/bin/../linuxpe/../linux_x86_64pe/vish.
>
> Do you have any ideas on where I can start looking for how to fix this error?
>
> Craig
>
>
>
> Craig F. Swanson
> Research Engineer II
> Information and Communications Laboratory
> Communications, Systems, and Spectrum Division
> Georgia Tech Research Institute
> Room 560
> 250 14th St NW
> Atlanta, GA 30318
> Cell: 770.298.9156
> http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160319/e9278bb6/attachment-0001.html>
>
> ------------------------------
>
> Message: 3
> Date: Sat, 19 Mar 2016 14:25:29 -0400
> From: "Marcus D. Leech" <mleech at ripnet.com>
> To: usrp-users at lists.ettus.com
> Subject: Re: [USRP-users] Long time for USRP N210 to respond -- is
>         this v3.10, firewall problem, or something else?
> Message-ID: <56ED9999.2080409 at ripnet.com>
> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>
> On 03/18/2016 10:01 PM, Mendel, Susan Marie via USRP-users wrote:
>>
>>
>> In installing UHD on a new laptop, I very stupidly installed version
>> 3.10 instead of the latest release. I didn't use git clone -- I tried
>> but that failed, I think due to my firewall, so I grabbed the zip.
>>
>> When I send a command to the USRP N210, there seems to be a 30 second
>> or so delay before I get any response. For instance the command
>> tx_waveforms prints out "current send frame size" and then it will be
>> a long time before I see anything else. Things seem to work fine once
>> it starts sending. Using the same command on a computer with v3.8.4
>> installed and the same USRP, there is no long delay.
>>
>>
>> I haven't disabled the firewall because I may need permission to do
>> that. Meanwhile I'm specifying the USRP address in the command. Is the
>> firewall likely causing the delay?
>>
>> Secondly, if I were to try building an earlier version instead, what
>> all do I need to remove first? The lib64/uhd directory?
>>
>>
>> Thanks for any help
>>
>>
> A delay isn't normal.
>
> What happens if you use uhd_usrp_probe:
>
> uhd_usrp_probe --args addr=192.168.10.2       (or whatever the IP
> address of your N210 is)
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160319/5aa43098/attachment-0001.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> ------------------------------
>
> End of USRP-users Digest, Vol 67, Issue 20
> ******************************************
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 18 Mar 2016 21:38:33 -0700
> From: Tyler <tkline at toyon.com>
> To: usrp-users at lists.ettus.com
> Subject: [USRP-users] E310 GPS lock issue
> Message-ID: <56ECD7C9.5090909 at toyon.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> I'm using an E310 running UHD 3.9.1, and when following the manual's
> instructions for "Device Time to GPS time", I'm getting an error at the
> first instruction:
>
>      while(! (usrp->get_mboard_sensor("gps_locked",0).to_bool()) ) {
> boost::this_thread::sleep(boost::posix_time::seconds(2));
>      }
>
>      LookupError: Path not found in tree: /mboards/0/sensors/gps_locked
>
> Also getting the following error:
>
>      UHD Error:
>          An error occured making GPSDd interface: RuntimeError: Failed
> to connect to gpsd: can't get host entry
>
> Any idea why this is happening?
>
> Thanks,
> Tyler
>
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sun, 20 Mar 2016 19:31:55 +0100
> From: Marcus M?ller <marcus.mueller at ettus.com>
> To: usrp-users at lists.ettus.com
> Subject: Re: [USRP-users] Long time for USRP N210 to respond -- is
>         this v3.10, firewall problem, or something else?
> Message-ID: <56EEEC9B.9040901 at ettus.com>
> Content-Type: text/plain; charset="windows-1252"
>
> Hi Susan,
>
> could you send the full output of uhd_usrp_probe? Is the delay /always/
> happening after the  "current send frame size" line?
>
> The difference between UHD 3.8.4 and a recent version is indeed strange;
> UHD hasn't changed communication semantics, which means it's probably
> not the firewall.
> In fact, I don't think much N210-network-related code has changed since
> 3.8.4.
>
> So, could you send both the output of uhd_usrp_probe with the
> daughterboard installed and without, just excluding that as an error
> source. Does the delay occur in both cases?
>
> Best regards,
> Marcus
>
> On 20.03.2016 17:13, Mendel, Susan Marie via USRP-users wrote:
>> Marcus,
>>
>> I get the same long delay with uhd_usrp_probe but not with uhd_find_devices.
>>
>> Can I expect things to work OK through the firewall as long as I'm specifying the IP address or is it likely to cause other problems down the road?
>>
>> I'm going to try to install a released version now but I suspect  I will have the same problem. I was seeing a similar delay on a Windows laptop when I was trying to send data using the Matlab USRP support package. I didn't have the laptop long enough to trouble shoot the problem, which I'm guessing is in my system configuration some where.
>>
>> Thanks,
>> Susan
>>
>> On 03/18/2016 10:01 PM, Mendel, Susan Marie via USRP-users wrote:
>>>
>>> In installing UHD on a new laptop, I very stupidly installed version
>>> 3.10 instead of the latest release. I didn't use git clone -- I tried
>>> but that failed, I think due to my firewall, so I grabbed the zip.
>>>
>>> When I send a command to the USRP N210, there seems to be a 30 second
>>> or so delay before I get any response. For instance the command
>>> tx_waveforms prints out "current send frame size" and then it will be
>>> a long time before I see anything else. Things seem to work fine once
>>> it starts sending. Using the same command on a computer with v3.8.4
>>> installed and the same USRP, there is no long delay.
>>>
>>>
>>> I haven't disabled the firewall because I may need permission to do
>>> that. Meanwhile I'm specifying the USRP address in the command. Is the
>>> firewall likely causing the delay?
>>>
>>> Secondly, if I were to try building an earlier version instead, what
>>> all do I need to remove first? The lib64/uhd directory?
>>>
>>>
>>> Thanks for any help
>>>
>>>
>> A delay isn't normal.
>>
>> What happens if you use uhd_usrp_probe:
>>
>> uhd_usrp_probe --args addr=192.168.10.2       (or whatever the IP
>> address of your N210 is)
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160320/d851e841/attachment-0001.html>
>
> ------------------------------
>
> Message: 4
> Date: Sun, 20 Mar 2016 14:34:50 -0400
> From: "Marcus D. Leech" <mleech at ripnet.com>
> To: usrp-users at lists.ettus.com
> Subject: Re: [USRP-users] Long time for USRP N210 to respond -- is
>         this v3.10, firewall problem, or something else?
> Message-ID: <56EEED4A.70107 at ripnet.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> On 03/20/2016 12:13 PM, Mendel, Susan Marie via USRP-users wrote:
>> Marcus,
>>
>> I get the same long delay with uhd_usrp_probe but not with uhd_find_devices.
>>
>> Can I expect things to work OK through the firewall as long as I'm specifying the IP address or is it likely to cause other problems down the road?
>>
>> I'm going to try to install a released version now but I suspect  I will have the same problem. I was seeing a similar delay on a Windows laptop when I was trying to send data using the Matlab USRP support package. I didn't have the laptop long enough to trouble shoot the problem, which I'm guessing is in my system configuration some where.
>>
>> Thanks,
>> Susan
> My guess is that you have a network setup issue.  Either with your
> firewall configuration, or DNS.
>
> Do you perhaps have more than one device that is visible to your
> computer that has the same address as the N210?
>
>
>> ________________________________________
>> From: USRP-users <usrp-users-bounces at lists.ettus.com> on behalf of usrp-users-request at lists.ettus.com <usrp-users-request at lists.ettus.com>
>> Sent: Sunday, March 20, 2016 10:00 AM
>> To: usrp-users at lists.ettus.com
>> Subject: USRP-users Digest, Vol 67, Issue 20
>>
>> Send USRP-users mailing list submissions to
>>          usrp-users at 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-request at lists.ettus.com
>>
>> You can reach the person managing the list at
>>          usrp-users-owner at 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. RFNoc Signal Output (Eugene Chai)
>>     2. Modelsim execute error for option -64 (Swanson, Craig)
>>     3. Re: Long time for USRP N210 to respond -- is this v3.10,
>>        firewall problem, or something else? (Marcus D. Leech)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Sat, 19 Mar 2016 17:48:46 +0000
>> From: Eugene Chai <eugene at nec-labs.com>
>> To: USRP-users <usrp-users at lists.ettus.com>
>> Subject: [USRP-users] RFNoc Signal Output
>> Message-ID: <8BBAC087-4F17-47D5-AF46-CED058E36479 at nec-labs.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hi,
>>
>> I have an RFNoC block on an X310 with three input and one output port.  I used the addsub block as a starting point, and I?m working on the rfnoc-devel git branch.   The RFNoC block acts as a mux ? it  takes three continuous streams from the host PC, and selects one of them for the output.  However, during testing, the output signal seems to be discontinuous.  I?ve attached a plot of the output signal that I captured over the air with a second X310.  Does anybody know what could be wrong here?
>>
>> Thanks,
>> Eugene
>>
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: test_sig.pdf
>> Type: application/pdf
>> Size: 46295 bytes
>> Desc: test_sig.pdf
>> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160319/dd84005d/attachment-0001.pdf>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Sat, 19 Mar 2016 18:09:14 +0000
>> From: "Swanson, Craig" <Craig.Swanson at gtri.gatech.edu>
>> To: Jonathon Pendlum <jonathon.pendlum at ettus.com>
>> Cc: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
>> Subject: [USRP-users] Modelsim execute error for option -64
>> Message-ID: <1458410953798.64631 at gtri.gatech.edu>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> Jonathon,
>>
>> I have not run a Modelsim simulation in about three months.  This week I decided to upgrade my uhd/fpga-src to the latest rev in git.
>>
>>
>> I tried running the noc_block_qpsk testbench and I got the following error:
>>
>> Failed to open executable /opt/mentor/modelsim/modelsim_dlx/bin/../linuxpe/../linux_x86_64pe/vish in execute mode needed for the option -64.
>> execv: No such file or directory
>> ** Fatal: Unable to exec the GUI /opt/mentor/modelsim/modelsim_dlx/bin/../linuxpe/../linux_x86_64pe/vish.
>>
>> Do you have any ideas on where I can start looking for how to fix this error?
>>
>> Craig
>>
>>
>>
>> Craig F. Swanson
>> Research Engineer II
>> Information and Communications Laboratory
>> Communications, Systems, and Spectrum Division
>> Georgia Tech Research Institute
>> Room 560
>> 250 14th St NW
>> Atlanta, GA 30318
>> Cell: 770.298.9156
>> http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160319/e9278bb6/attachment-0001.html>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Sat, 19 Mar 2016 14:25:29 -0400
>> From: "Marcus D. Leech" <mleech at ripnet.com>
>> To: usrp-users at lists.ettus.com
>> Subject: Re: [USRP-users] Long time for USRP N210 to respond -- is
>>          this v3.10, firewall problem, or something else?
>> Message-ID: <56ED9999.2080409 at ripnet.com>
>> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>>
>> On 03/18/2016 10:01 PM, Mendel, Susan Marie via USRP-users wrote:
>>>
>>> In installing UHD on a new laptop, I very stupidly installed version
>>> 3.10 instead of the latest release. I didn't use git clone -- I tried
>>> but that failed, I think due to my firewall, so I grabbed the zip.
>>>
>>> When I send a command to the USRP N210, there seems to be a 30 second
>>> or so delay before I get any response. For instance the command
>>> tx_waveforms prints out "current send frame size" and then it will be
>>> a long time before I see anything else. Things seem to work fine once
>>> it starts sending. Using the same command on a computer with v3.8.4
>>> installed and the same USRP, there is no long delay.
>>>
>>>
>>> I haven't disabled the firewall because I may need permission to do
>>> that. Meanwhile I'm specifying the USRP address in the command. Is the
>>> firewall likely causing the delay?
>>>
>>> Secondly, if I were to try building an earlier version instead, what
>>> all do I need to remove first? The lib64/uhd directory?
>>>
>>>
>>> Thanks for any help
>>>
>>>
>> A delay isn't normal.
>>
>> What happens if you use uhd_usrp_probe:
>>
>> uhd_usrp_probe --args addr=192.168.10.2       (or whatever the IP
>> address of your N210 is)
>>
>>
>>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160319/5aa43098/attachment-0001.html>
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users at lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>> ------------------------------
>>
>> End of USRP-users Digest, Vol 67, Issue 20
>> ******************************************
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users at lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> ------------------------------
>
> Message: 5
> Date: Sun, 20 Mar 2016 19:39:08 +0100
> From: Marcus M?ller <marcus.mueller at ettus.com>
> To: usrp-users at lists.ettus.com
> Subject: Re: [USRP-users] Long time for USRP N210 to respond -- is
>         this v3.10, firewall problem, or something else?
> Message-ID: <56EEEE4C.6030509 at ettus.com>
> Content-Type: text/plain; charset=windows-1252
>
> Or is it possible that you have multiple N210s in your network?
>
> Best regards,
> Marcus
>
> On 20.03.2016 19:34, Marcus D. Leech via USRP-users wrote:
>> On 03/20/2016 12:13 PM, Mendel, Susan Marie via USRP-users wrote:
>>> Marcus,
>>>
>>> I get the same long delay with uhd_usrp_probe but not with
>>> uhd_find_devices.
>>>
>>> Can I expect things to work OK through the firewall as long as I'm
>>> specifying the IP address or is it likely to cause other problems
>>> down the road?
>>>
>>> I'm going to try to install a released version now but I suspect  I
>>> will have the same problem. I was seeing a similar delay on a Windows
>>> laptop when I was trying to send data using the Matlab USRP support
>>> package. I didn't have the laptop long enough to trouble shoot the
>>> problem, which I'm guessing is in my system configuration some where.
>>>
>>> Thanks,
>>> Susan
>> My guess is that you have a network setup issue.  Either with your
>> firewall configuration, or DNS.
>>
>> Do you perhaps have more than one device that is visible to your
>> computer that has the same address as the N210?
>>
>>
>>> ________________________________________
>>> From: USRP-users <usrp-users-bounces at lists.ettus.com> on behalf of
>>> usrp-users-request at lists.ettus.com <usrp-users-request at lists.ettus.com>
>>> Sent: Sunday, March 20, 2016 10:00 AM
>>> To: usrp-users at lists.ettus.com
>>> Subject: USRP-users Digest, Vol 67, Issue 20
>>>
>>> Send USRP-users mailing list submissions to
>>>          usrp-users at 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-request at lists.ettus.com
>>>
>>> You can reach the person managing the list at
>>>          usrp-users-owner at 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. RFNoc Signal Output (Eugene Chai)
>>>     2. Modelsim execute error for option -64 (Swanson, Craig)
>>>     3. Re: Long time for USRP N210 to respond -- is this v3.10,
>>>        firewall problem, or something else? (Marcus D. Leech)
>>>
>>>
>>> ----------------------------------------------------------------------
>>>
>>> Message: 1
>>> Date: Sat, 19 Mar 2016 17:48:46 +0000
>>> From: Eugene Chai <eugene at nec-labs.com>
>>> To: USRP-users <usrp-users at lists.ettus.com>
>>> Subject: [USRP-users] RFNoc Signal Output
>>> Message-ID: <8BBAC087-4F17-47D5-AF46-CED058E36479 at nec-labs.com>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> Hi,
>>>
>>> I have an RFNoC block on an X310 with three input and one output
>>> port.  I used the addsub block as a starting point, and I?m working
>>> on the rfnoc-devel git branch.   The RFNoC block acts as a mux ? it
>>> takes three continuous streams from the host PC, and selects one of
>>> them for the output.  However, during testing, the output signal
>>> seems to be discontinuous.  I?ve attached a plot of the output signal
>>> that I captured over the air with a second X310.  Does anybody know
>>> what could be wrong here?
>>>
>>> Thanks,
>>> Eugene
>>>
>>> -------------- next part --------------
>>> A non-text attachment was scrubbed...
>>> Name: test_sig.pdf
>>> Type: application/pdf
>>> Size: 46295 bytes
>>> Desc: test_sig.pdf
>>> URL:
>>> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160319/dd84005d/attachment-0001.pdf>
>>>
>>> ------------------------------
>>>
>>> Message: 2
>>> Date: Sat, 19 Mar 2016 18:09:14 +0000
>>> From: "Swanson, Craig" <Craig.Swanson at gtri.gatech.edu>
>>> To: Jonathon Pendlum <jonathon.pendlum at ettus.com>
>>> Cc: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
>>> Subject: [USRP-users] Modelsim execute error for option -64
>>> Message-ID: <1458410953798.64631 at gtri.gatech.edu>
>>> Content-Type: text/plain; charset="iso-8859-1"
>>>
>>> Jonathon,
>>>
>>> I have not run a Modelsim simulation in about three months.  This
>>> week I decided to upgrade my uhd/fpga-src to the latest rev in git.
>>>
>>>
>>> I tried running the noc_block_qpsk testbench and I got the following
>>> error:
>>>
>>> Failed to open executable
>>> /opt/mentor/modelsim/modelsim_dlx/bin/../linuxpe/../linux_x86_64pe/vish
>>> in execute mode needed for the option -64.
>>> execv: No such file or directory
>>> ** Fatal: Unable to exec the GUI
>>> /opt/mentor/modelsim/modelsim_dlx/bin/../linuxpe/../linux_x86_64pe/vish.
>>>
>>> Do you have any ideas on where I can start looking for how to fix
>>> this error?
>>>
>>> Craig
>>>
>>>
>>>
>>> Craig F. Swanson
>>> Research Engineer II
>>> Information and Communications Laboratory
>>> Communications, Systems, and Spectrum Division
>>> Georgia Tech Research Institute
>>> Room 560
>>> 250 14th St NW
>>> Atlanta, GA 30318
>>> Cell: 770.298.9156
>>> http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>>>
>>>
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL:
>>> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160319/e9278bb6/attachment-0001.html>
>>>
>>> ------------------------------
>>>
>>> Message: 3
>>> Date: Sat, 19 Mar 2016 14:25:29 -0400
>>> From: "Marcus D. Leech" <mleech at ripnet.com>
>>> To: usrp-users at lists.ettus.com
>>> Subject: Re: [USRP-users] Long time for USRP N210 to respond -- is
>>>          this v3.10, firewall problem, or something else?
>>> Message-ID: <56ED9999.2080409 at ripnet.com>
>>> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>>>
>>> On 03/18/2016 10:01 PM, Mendel, Susan Marie via USRP-users wrote:
>>>>
>>>> In installing UHD on a new laptop, I very stupidly installed version
>>>> 3.10 instead of the latest release. I didn't use git clone -- I tried
>>>> but that failed, I think due to my firewall, so I grabbed the zip.
>>>>
>>>> When I send a command to the USRP N210, there seems to be a 30 second
>>>> or so delay before I get any response. For instance the command
>>>> tx_waveforms prints out "current send frame size" and then it will be
>>>> a long time before I see anything else. Things seem to work fine once
>>>> it starts sending. Using the same command on a computer with v3.8.4
>>>> installed and the same USRP, there is no long delay.
>>>>
>>>>
>>>> I haven't disabled the firewall because I may need permission to do
>>>> that. Meanwhile I'm specifying the USRP address in the command. Is the
>>>> firewall likely causing the delay?
>>>>
>>>> Secondly, if I were to try building an earlier version instead, what
>>>> all do I need to remove first? The lib64/uhd directory?
>>>>
>>>>
>>>> Thanks for any help
>>>>
>>>>
>>> A delay isn't normal.
>>>
>>> What happens if you use uhd_usrp_probe:
>>>
>>> uhd_usrp_probe --args addr=192.168.10.2       (or whatever the IP
>>> address of your N210 is)
>>>
>>>
>>>
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL:
>>> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160319/5aa43098/attachment-0001.html>
>>>
>>> ------------------------------
>>>
>>> Subject: Digest Footer
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users at lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>> ------------------------------
>>>
>>> End of USRP-users Digest, Vol 67, Issue 20
>>> ******************************************
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users at lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users at lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> ------------------------------
>
> Message: 6
> Date: Sun, 20 Mar 2016 12:30:37 -0700
> From: Jonathon Pendlum <jonathon.pendlum at ettus.com>
> To: Eugene Chai <eugene at nec-labs.com>
> Cc: USRP-users <usrp-users at lists.ettus.com>
> Subject: Re: [USRP-users] RFNoc Signal Output
> Message-ID:
>         <CAGdo0uRK7H652DMD57_KB1E-bQmXw8za2KHB7WY7f2t-osoUCg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Eugene,
>
> What rate are you running the radio at? It could be possible you are
> underflowing the radio core. With current rfnoc-devel you would not know
> since the underflow packets are not forwarded to the host.
>
>
>
> Jonathon
>
> On Sat, Mar 19, 2016 at 10:48 AM, Eugene Chai via USRP-users <
> usrp-users at lists.ettus.com> wrote:
>
>> Hi,
>>
>> I have an RFNoC block on an X310 with three input and one output port.  I
>> used the addsub block as a starting point, and I?m working on the
>> rfnoc-devel git branch.   The RFNoC block acts as a mux ? it  takes three
>> continuous streams from the host PC, and selects one of them for the
>> output.  However, during testing, the output signal seems to be
>> discontinuous.  I?ve attached a plot of the output signal that I captured
>> over the air with a second X310.  Does anybody know what could be wrong
>> here?
>>
>> Thanks,
>> Eugene
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users at 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/20160320/5e0ef1da/attachment-0001.html>
>
> ------------------------------
>
> Message: 7
> Date: Sun, 20 Mar 2016 12:33:22 -0700
> From: Jonathon Pendlum <jonathon.pendlum at ettus.com>
> To: "Swanson, Craig" <Craig.Swanson at gtri.gatech.edu>
> Cc: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
> Subject: Re: [USRP-users] Modelsim execute error for option -64
> Message-ID:
>         <CAGdo0uS31kwiN+E2-XvyJ-_VtdAjGshuMHELZVcTqbsbmwjpXg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Craig,
>
> This is an error with Vivado. Make a symbolic link
> /opt/mentor/modelsim/modelsim_dlx/bin/linux_x86_64pe pointing
> to /opt/mentor/modelsim/modelsim_dlx/bin/linuxpe.
>
>
>
> Jonathon
>
> On Sat, Mar 19, 2016 at 11:09 AM, Swanson, Craig <
> Craig.Swanson at gtri.gatech.edu> wrote:
>
>> Jonathon,
>>
>> I have not run a Modelsim simulation in about three months.  This week I
>> decided to upgrade my uhd/fpga-src to the latest rev in git.
>>
>>
>> I tried running the noc_block_qpsk testbench and I got the following error:
>> Failed to open executable
>> /opt/mentor/modelsim/modelsim_dlx/bin/../linuxpe/../linux_x86_64pe/vish in
>> execute mode needed for the option -64.
>> execv: No such file or directory
>> ** Fatal: Unable to exec the GUI
>> /opt/mentor/modelsim/modelsim_dlx/bin/../linuxpe/../linux_x86_64pe/vish.
>>
>> Do you have any ideas on where I can start looking for how to fix this
>> error?
>>
>> Craig
>>
>>
>>
>> *Craig F. Swanson*
>>
>> *Research Engineer II *
>> *Information and Communications Laboratory*
>> *Communications, Systems, and Spectrum Division*
>> *Georgia Tech Research Institute*
>>
>>
>> *Room 560 250 14th St NW *
>> *Atlanta, GA 30318*
>> *Cell: 770.298.9156 <770.298.9156>*
>> http://www.gtri.gatech.edu
>> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>>
>>
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160320/b02ca971/attachment-0001.html>
>
> ------------------------------
>
> Message: 8
> Date: Sun, 20 Mar 2016 12:37:24 -0700
> From: Jonathon Pendlum <jonathon.pendlum at ettus.com>
> To: Zhihong Luo <zhluo at umich.edu>
> Cc: Zhihong Luo via USRP-users <USRP-users at lists.ettus.com>,    Li-Xuan
>         Chuo <lxchuo at umich.edu>
> Subject: Re: [USRP-users] GRC Radio Block Receives no Data
> Message-ID:
>         <CAGdo0uScixT3uXgox9YJ85etccSZvmuOGsQeVvgi+_OvyRsnqg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Zhihong,
>
> Are you saying you can run at 5M without overflows? Also, try adding a FIFO
> block and see if that helps.
>
>
>
> Jonathon
>
> On Fri, Mar 18, 2016 at 3:31 PM, Zhihong Luo via USRP-users <
> usrp-users at lists.ettus.com> wrote:
>
>> Hi all,
>>
>> We found that it will run into overrun error after the first try: (The
>> first try after power cycle will not have overrun, but the received signal
>> is not right (file sink)).
>>
>> Doverrun on chan 0
>> Doverrun on chan 0
>> -- radio_ctrl::handle_overrun()
>> Ooverrun on chan 0
>>
>> The sample rate is still very slow (5M). Besides, it worked if we used
>> Radio on Tx.
>>
>> I just get into RFNoC, and I never encountered this problem using the
>> usrp-source. I am really confused about this, thanks in advance for any
>> help.
>>
>> Thanks,
>> Zhihong
>>
>> On Fri, Mar 18, 2016 at 5:17 PM, Zhihong Luo <zhluo at umich.edu> wrote:
>>
>>> Hi all,
>>>
>>> I am new to RFNoC and I tried to run a simple GRC using a RFNoC Radio and
>>> scope sink. But there seems to be no outputs.
>>>
>>> I assume Radio works exactly as USRP Source, so I am really confused. The
>>> GRC' output is attached (didn't output errors). What am I missing?
>>>
>>> Using Volk machine: sse4_2_64_orc
>>> -- [0/Radio_0] _resolve_port_def()
>>> -- [0/Radio_0]   item type: sc16
>>> -- [0/Radio_0]   vector length: 0
>>> -- [0/Radio_0]   packet size: 0
>>> -- [0/Radio_0] _resolve_port_def()
>>> -- [0/Radio_0]   item type: sc16
>>> -- [0/Radio_0]   vector length: 0
>>> -- [0/Radio_0]   packet size: 0
>>> DEBUG: output item size: 8
>>>
>>> DEBUG: check_topology()
>>> DEBUG: RFNoC blocks with streaming ports: 1
>>> DEBUG: start(): ninputs == 0 noutputs == 1
>>> DEBUG: creating rx streamer with: block_id=0/Radio_0
>>> -- [0/Radio_0] _resolve_port_def()
>>> -- [0/Radio_0]   item type: sc16
>>> -- [0/Radio_0]   vector length: 0
>>> -- [0/Radio_0]   packet size: 0
>>> -- [RX Streamer] creating rx stream recv_buff_size=33554432
>>> -- [RX Streamer] data_sid = 00:08>02:30 actual recv_buff_size = 33554432
>>> -- [0/Radio_0] radio_ctrl::set_destination()
>>> --   Setting sid to 2.48>0.8
>>> -- [RX Streamer] spp == 364
>>> -- [RX Streamer] Flow Control Window = 20515, Flow Control Handler Window
>>> = 641
>>> -- [0/Radio_0] radio_ctrl::configure_flow_control_out()20515
>>> -- [RX Terminator 0] rx_stream_terminator::set_rx_streamer() 1
>>> -- [0/Radio_0] radio_ctrl::set_rx_streamer() 1
>>> -- [Device3] updating RX streamer to RX Terminator 0
>>> --   New tick_rate == 2e+08  New samp_rate == 8e+06 New scaling ==
>>> 3.05187e-05
>>> -- [0/Radio_0] radio_ctrl::issue_stream_cmd()
>>> -- [0/Radio_0] radio_ctrl::issue_stream_cmd()
>>> -- [RX Terminator 0] rx_stream_terminator::~rx_stream_terminator()
>>> -- [RX Terminator 0] rx_stream_terminator::set_rx_streamer() 0
>>> -- [0/Radio_0] radio_ctrl::set_rx_streamer() 0
>>>
>>>
>>> Thanks,
>>> Zhihong
>>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users at 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/20160320/65288cca/attachment-0001.html>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: Screenshot from 2016-03-18 16:55:14.png
> Type: image/png
> Size: 28720 bytes
> Desc: not available
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160320/65288cca/attachment-0001.png>
>
> ------------------------------
>
> Message: 9
> Date: Sun, 20 Mar 2016 12:38:42 -0700
> From: Jonathon Pendlum <jonathon.pendlum at ettus.com>
> To: Zhihong Luo <zhluo at umich.edu>
> Cc: Zhihong Luo via USRP-users <USRP-users at lists.ettus.com>
> Subject: Re: [USRP-users] Vivado Version for fpga RFNoC Branch
> Message-ID:
>         <CAGdo0uQoU7VtfGncGyXYshSszPbvDQecA01oZcw2EAh7HV1RHQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Zhihong,
>
> Did you manage to resolve your issue? It looks like in another thread you
> were able to run a RFNoC flowgraph.
>
>
>
> Jonathon
>
> On Thu, Mar 17, 2016 at 5:05 PM, Zhihong Luo <zhluo at umich.edu> wrote:
>
>> Jonathon,
>>
>> Sorry, I accidentally sent out the previous mail. Yes, I copied it into
>> the location, and the "md5sum" result is right. But running the GRC gives
>> me the same errors.
>>
>> I wonder whether it is because I am using UHD_003.010.rfnoc version, so
>> that I have to use X300_RFNOC_HGS for it ?
>>
>> On Thu, Mar 17, 2016 at 3:20 PM, Jonathon Pendlum <
>> jonathon.pendlum at ettus.com> wrote:
>>
>>> Hi Zhihong,
>>>
>>> uhd_image_downloader will place the files in <install
>>> path>/share/uhd/images. Did you manually copy the bitstream to that new
>>> location? Also, run 'md5sum' on your bit file. It should calculate a md5 of
>>> 06c99581aeb247d25a6664b537d00127. If your's is different, then you do not
>>> have the correct bitstream.
>>>
>>>
>>>
>>> Jonathon
>>>
>>> On Wed, Mar 16, 2016 at 8:41 PM, Zhihong Luo <zhluo at umich.edu> wrote:
>>>
>>>> Hi Jonathon,
>>>>
>>>> I just used the uhd_image_loader:
>>>>
>>>> uhd_image_loader --fpga-path new_fpga3.16/usrp_x300_fpga_HGS.bit
>>>> --args="type=x300,addr=192.168.40.2"
>>>>
>>>> ( new_fpga3.16 is a file created containing the images from
>>>> uhd_image_downloader)
>>>>
>>>> Zhihong
>>>>
>>>> On Wed, Mar 16, 2016 at 11:35 PM, Jonathon Pendlum <
>>>> jonathon.pendlum at ettus.com> wrote:
>>>>
>>>>> You can install Vivado 2015.2 alongside of 2015.4.
>>>>>
>>>>> It looks like you didn't flash your X310 with the correct image. What
>>>>> command did you run to flash your X310?
>>>>>
>>>>>
>>>>>
>>>>> Jonathon
>>>>>
>>>>> On Wed, Mar 16, 2016 at 8:04 PM, Zhihong Luo <zhluo at umich.edu> wrote:
>>>>>
>>>>>> Hi Jonathon,
>>>>>>
>>>>>> Okay, so I'll have to switch to 2015.2 for now, can I install 2015.2
>>>>>> without deleting the 2015.4 version?
>>>>>>
>>>>>> I used uhd_images_downloader to get the image, and load the
>>>>>> usrp_x300_fpga_HGS.bit into the x300. After that I ran uhd_usrp_probe
>>>>>> --init-only, the output seems right.
>>>>>>
>>>>>> But when I used a simple GRC to test it, it ran into errors:
>>>>>>
>>>>>> linux; GNU C++ version 4.8.4; Boost_105400;
>>>>>> UHD_003.010.rfnoc-316-gb7546712h
>>>>>>
>>>>>> Using Volk machine: sse4_2_64_orc
>>>>>> -- X300 initialization sequence...
>>>>>> -- Determining maximum frame size... 8000 bytes.
>>>>>> -- Setup basic communication...
>>>>>> =========================================================
>>>>>> Warning:
>>>>>> Expected FPGA compatibility number 1000, but got 20:
>>>>>> ...
>>>>>> RuntimeError: EnvironmentError: IOError: Radio ctrl (A) no response
>>>>>> packet - AssertionError: bool(buff)
>>>>>>   in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
>>>>>>   at /home/zhluo/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:203
>>>>>> ...
>>>>>> RuntimeError: LookupError: IndexError: multi_usrp::mb_root(56238800) -
>>>>>> vector::_M_range_check
>>>>>>
>>>>>> I assume it is because the fpga from the downloader is too old? So I
>>>>>> have to make the usrp_x300_fpga_HGS.bit from source?
>>>>>>
>>>>>> Thanks,
>>>>>> Zhihong
>>>>>> ?
>>>>>>
>>>>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160320/e4fc2fc9/attachment-0001.html>
>
> ------------------------------
>
> Message: 10
> Date: Sun, 20 Mar 2016 19:41:37 +0000
> From: "Swanson, Craig" <Craig.Swanson at gtri.gatech.edu>
> To: Jonathon Pendlum <jonathon.pendlum at ettus.com>
> Cc: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
> Subject: Re: [USRP-users] Modelsim execute error for option -64
> Message-ID: <69C0C10F-105D-403E-90D9-C03A8289A0C8 at gtri.gatech.edu>
> Content-Type: text/plain; charset="us-ascii"
>
> Jonathon,
> Thanks. What commit would be best to use if I plan on using the IIR filter and 1-in-N testbench and rfnoc block?
> Craig
>
> Sent from my iPhone
>
> On Mar 20, 2016, at 3:34 PM, Jonathon Pendlum <jonathon.pendlum at ettus.com<mailto:jonathon.pendlum at ettus.com>> wrote:
>
> Hi Craig,
>
> This is an error with Vivado. Make a symbolic link /opt/mentor/modelsim/modelsim_dlx/bin/linux_x86_64pe pointing to /opt/mentor/modelsim/modelsim_dlx/bin/linuxpe.
>
>
>
> Jonathon
>
> On Sat, Mar 19, 2016 at 11:09 AM, Swanson, Craig <Craig.Swanson at gtri.gatech.edu<mailto:Craig.Swanson at gtri.gatech.edu>> wrote:
>
> Jonathon,
>
> I have not run a Modelsim simulation in about three months.  This week I decided to upgrade my uhd/fpga-src to the latest rev in git.
>
>
> I tried running the noc_block_qpsk testbench and I got the following error:
>
> Failed to open executable /opt/mentor/modelsim/modelsim_dlx/bin/../linuxpe/../linux_x86_64pe/vish in execute mode needed for the option -64.
> execv: No such file or directory
> ** Fatal: Unable to exec the GUI /opt/mentor/modelsim/modelsim_dlx/bin/../linuxpe/../linux_x86_64pe/vish.
>
> Do you have any ideas on where I can start looking for how to fix this error?
>
> Craig
>
>
>
> Craig F. Swanson
> Research Engineer II
> Information and Communications Laboratory
> Communications, Systems, and Spectrum Division
> Georgia Tech Research Institute
> Room 560
> 250 14th St NW
> Atlanta, GA 30318
> Cell: 770.298.9156<tel:770.298.9156>
> http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160320/94c423ed/attachment-0001.html>
>
> ------------------------------
>
> Message: 11
> Date: Sun, 20 Mar 2016 12:43:49 -0700
> From: Jonathon Pendlum <jonathon.pendlum at ettus.com>
> To: "Swanson, Craig" <Craig.Swanson at gtri.gatech.edu>
> Cc: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
> Subject: Re: [USRP-users] Modelsim execute error for option -64
> Message-ID:
>         <CAGdo0uS3CvN8FQxjMDkQmEwsHyjCciEuXUEBiNFauj2iXudzrg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> The current head commit is fine.
>
>
> Jonathon
>
> On Sun, Mar 20, 2016 at 12:41 PM, Swanson, Craig <
> Craig.Swanson at gtri.gatech.edu> wrote:
>
>> Jonathon,
>> Thanks. What commit would be best to use if I plan on using the IIR filter
>> and 1-in-N testbench and rfnoc block?
>> Craig
>>
>> Sent from my iPhone
>>
>> On Mar 20, 2016, at 3:34 PM, Jonathon Pendlum <jonathon.pendlum at ettus.com>
>> wrote:
>>
>> Hi Craig,
>>
>> This is an error with Vivado. Make a symbolic link
>> /opt/mentor/modelsim/modelsim_dlx/bin/linux_x86_64pe pointing
>> to /opt/mentor/modelsim/modelsim_dlx/bin/linuxpe.
>>
>>
>>
>> Jonathon
>>
>> On Sat, Mar 19, 2016 at 11:09 AM, Swanson, Craig <
>> Craig.Swanson at gtri.gatech.edu> wrote:
>>
>>> Jonathon,
>>>
>>> I have not run a Modelsim simulation in about three months.  This week I
>>> decided to upgrade my uhd/fpga-src to the latest rev in git.
>>>
>>>
>>> I tried running the noc_block_qpsk testbench and I got the following
>>> error:
>>> Failed to open executable
>>> /opt/mentor/modelsim/modelsim_dlx/bin/../linuxpe/../linux_x86_64pe/vish in
>>> execute mode needed for the option -64.
>>> execv: No such file or directory
>>> ** Fatal: Unable to exec the GUI
>>> /opt/mentor/modelsim/modelsim_dlx/bin/../linuxpe/../linux_x86_64pe/vish.
>>>
>>> Do you have any ideas on where I can start looking for how to fix this
>>> error?
>>>
>>> Craig
>>>
>>>
>>>
>>> *Craig F. Swanson*
>>>
>>> *Research Engineer II *
>>> *Information and Communications Laboratory*
>>> *Communications, Systems, and Spectrum Division*
>>> *Georgia Tech Research Institute*
>>>
>>>
>>> *Room 560 250 14th St NW *
>>> *Atlanta, GA 30318*
>>> *Cell: 770.298.9156 <770.298.9156>*
>>> http://www.gtri.gatech.edu
>>> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>>>
>>>
>>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160320/fa3be610/attachment-0001.html>
>
> ------------------------------
>
> Message: 12
> Date: Sun, 20 Mar 2016 15:55:15 -0400
> From: Zhihong Luo <zhluo at umich.edu>
> To: Jonathon Pendlum <jonathon.pendlum at ettus.com>
> Cc: Zhihong Luo via USRP-users <USRP-users at lists.ettus.com>,    Li-Xuan
>         Chuo <lxchuo at umich.edu>
> Subject: Re: [USRP-users] GRC Radio Block Receives no Data
> Message-ID:
>         <CAH4wXLpO=1+7hr6VnR94ORveggnx_XcONtpa0YThOrbMqpb6pQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Jonathon,
>
> No, it will also run into errors at 5M. And I tried adding a FIFO between
> radio and file sink, it didn't help.
>
> I ended up using rx-sample-to-file.cpp for receiving data, and it works
> with no errors. So the X300 is ok, and the problem I had should be on GRC.
>
> I knew GRC has some rules for connecting RFNoC blocks and gnuradio blocks.
> Does directly connecting a Radio with a file sink or scope sink violate any
> of those?
>
> Thanks,
> Zhihong
>
> 2016?3?20?????Jonathon Pendlum <jonathon.pendlum at ettus.com> ???
>
>> Hi Zhihong,
>>
>> Are you saying you can run at 5M without overflows? Also, try adding a
>> FIFO block and see if that helps.
>>
>>
>>
>> Jonathon
>>
>> On Fri, Mar 18, 2016 at 3:31 PM, Zhihong Luo via USRP-users <
>> usrp-users at lists.ettus.com
>> <javascript:_e(%7B%7D,'cvml','usrp-users at lists.ettus.com');>> wrote:
>>
>>> Hi all,
>>>
>>> We found that it will run into overrun error after the first try: (The
>>> first try after power cycle will not have overrun, but the received signal
>>> is not right (file sink)).
>>>
>>> Doverrun on chan 0
>>> Doverrun on chan 0
>>> -- radio_ctrl::handle_overrun()
>>> Ooverrun on chan 0
>>>
>>> The sample rate is still very slow (5M). Besides, it worked if we used
>>> Radio on Tx.
>>>
>>> I just get into RFNoC, and I never encountered this problem using the
>>> usrp-source. I am really confused about this, thanks in advance for any
>>> help.
>>>
>>> Thanks,
>>> Zhihong
>>>
>>> On Fri, Mar 18, 2016 at 5:17 PM, Zhihong Luo <zhluo at umich.edu
>>> <javascript:_e(%7B%7D,'cvml','zhluo at umich.edu');>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I am new to RFNoC and I tried to run a simple GRC using a RFNoC Radio
>>>> and scope sink. But there seems to be no outputs.
>>>>
>>>> I assume Radio works exactly as USRP Source, so I am really confused.
>>>> The GRC' output is attached (didn't output errors). What am I missing?
>>>>
>>>> Using Volk machine: sse4_2_64_orc
>>>> -- [0/Radio_0] _resolve_port_def()
>>>> -- [0/Radio_0]   item type: sc16
>>>> -- [0/Radio_0]   vector length: 0
>>>> -- [0/Radio_0]   packet size: 0
>>>> -- [0/Radio_0] _resolve_port_def()
>>>> -- [0/Radio_0]   item type: sc16
>>>> -- [0/Radio_0]   vector length: 0
>>>> -- [0/Radio_0]   packet size: 0
>>>> DEBUG: output item size: 8
>>>>
>>>> DEBUG: check_topology()
>>>> DEBUG: RFNoC blocks with streaming ports: 1
>>>> DEBUG: start(): ninputs == 0 noutputs == 1
>>>> DEBUG: creating rx streamer with: block_id=0/Radio_0
>>>> -- [0/Radio_0] _resolve_port_def()
>>>> -- [0/Radio_0]   item type: sc16
>>>> -- [0/Radio_0]   vector length: 0
>>>> -- [0/Radio_0]   packet size: 0
>>>> -- [RX Streamer] creating rx stream recv_buff_size=33554432
>>>> -- [RX Streamer] data_sid = 00:08>02:30 actual recv_buff_size = 33554432
>>>> -- [0/Radio_0] radio_ctrl::set_destination()
>>>> --   Setting sid to 2.48>0.8
>>>> -- [RX Streamer] spp == 364
>>>> -- [RX Streamer] Flow Control Window = 20515, Flow Control Handler
>>>> Window = 641
>>>> -- [0/Radio_0] radio_ctrl::configure_flow_control_out()20515
>>>> -- [RX Terminator 0] rx_stream_terminator::set_rx_streamer() 1
>>>> -- [0/Radio_0] radio_ctrl::set_rx_streamer() 1
>>>> -- [Device3] updating RX streamer to RX Terminator 0
>>>> --   New tick_rate == 2e+08  New samp_rate == 8e+06 New scaling ==
>>>> 3.05187e-05
>>>> -- [0/Radio_0] radio_ctrl::issue_stream_cmd()
>>>> -- [0/Radio_0] radio_ctrl::issue_stream_cmd()
>>>> -- [RX Terminator 0] rx_stream_terminator::~rx_stream_terminator()
>>>> -- [RX Terminator 0] rx_stream_terminator::set_rx_streamer() 0
>>>> -- [0/Radio_0] radio_ctrl::set_rx_streamer() 0
>>>>
>>>>
>>>> Thanks,
>>>> Zhihong
>>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users at lists.ettus.com
>>> <javascript:_e(%7B%7D,'cvml','USRP-users at 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/20160320/c918bc7d/attachment-0001.html>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: Screenshot from 2016-03-18 16:55:14.png
> Type: image/png
> Size: 28720 bytes
> Desc: not available
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160320/c918bc7d/attachment-0001.png>
>
> ------------------------------
>
> Message: 13
> Date: Sun, 20 Mar 2016 21:05:12 +0000
> From: "Mendel, Susan Marie" <smendel at lanl.gov>
> To: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
> Subject: Re: [USRP-users] Long time for USRP N210 to respond -- is
>         this v3.10, firewall problem, or something else?
> Message-ID: <1458507912272.52250 at lanl.gov>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I was connecting directly to the USRP, not through a network. The delay always happens after the "current send frame size" line. I uninstalled v3.10 and installed v3.8.5 and have the same issue.
>
> I may not be able to get back to it until Tues. but then I will send you the output from uhd_usrp_probe with the daughter board installed and with out it.
>
> Thanks again,
> Susan
>
> ________________________________________
> From: USRP-users <usrp-users-bounces at lists.ettus.com> on behalf of usrp-users-request at lists.ettus.com <usrp-users-request at lists.ettus.com>
> Sent: Sunday, March 20, 2016 10:00 AM
> To: usrp-users at lists.ettus.com
> Subject: USRP-users Digest, Vol 67, Issue 20
>
> Send USRP-users mailing list submissions to
>         usrp-users at 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-request at lists.ettus.com
>
> You can reach the person managing the list at
>         usrp-users-owner at 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. RFNoc Signal Output (Eugene Chai)
>    2. Modelsim execute error for option -64 (Swanson, Craig)
>    3. Re: Long time for USRP N210 to respond -- is this v3.10,
>       firewall problem, or something else? (Marcus D. Leech)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 19 Mar 2016 17:48:46 +0000
> From: Eugene Chai <eugene at nec-labs.com>
> To: USRP-users <usrp-users at lists.ettus.com>
> Subject: [USRP-users] RFNoc Signal Output
> Message-ID: <8BBAC087-4F17-47D5-AF46-CED058E36479 at nec-labs.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi,
>
> I have an RFNoC block on an X310 with three input and one output port.  I used the addsub block as a starting point, and I?m working on the rfnoc-devel git branch.   The RFNoC block acts as a mux ? it  takes three continuous streams from the host PC, and selects one of them for the output.  However, during testing, the output signal seems to be discontinuous.  I?ve attached a plot of the output signal that I captured over the air with a second X310.  Does anybody know what could be wrong here?
>
> Thanks,
> Eugene
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: test_sig.pdf
> Type: application/pdf
> Size: 46295 bytes
> Desc: test_sig.pdf
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160319/dd84005d/attachment-0001.pdf>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 19 Mar 2016 18:09:14 +0000
> From: "Swanson, Craig" <Craig.Swanson at gtri.gatech.edu>
> To: Jonathon Pendlum <jonathon.pendlum at ettus.com>
> Cc: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
> Subject: [USRP-users] Modelsim execute error for option -64
> Message-ID: <1458410953798.64631 at gtri.gatech.edu>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Jonathon,
>
> I have not run a Modelsim simulation in about three months.  This week I decided to upgrade my uhd/fpga-src to the latest rev in git.
>
>
> I tried running the noc_block_qpsk testbench and I got the following error:
>
> Failed to open executable /opt/mentor/modelsim/modelsim_dlx/bin/../linuxpe/../linux_x86_64pe/vish in execute mode needed for the option -64.
> execv: No such file or directory
> ** Fatal: Unable to exec the GUI /opt/mentor/modelsim/modelsim_dlx/bin/../linuxpe/../linux_x86_64pe/vish.
>
> Do you have any ideas on where I can start looking for how to fix this error?
>
> Craig
>
>
>
> Craig F. Swanson
> Research Engineer II
> Information and Communications Laboratory
> Communications, Systems, and Spectrum Division
> Georgia Tech Research Institute
> Room 560
> 250 14th St NW
> Atlanta, GA 30318
> Cell: 770.298.9156
> http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160319/e9278bb6/attachment-0001.html>
>
> ------------------------------
>
> Message: 3
> Date: Sat, 19 Mar 2016 14:25:29 -0400
> From: "Marcus D. Leech" <mleech at ripnet.com>
> To: usrp-users at lists.ettus.com
> Subject: Re: [USRP-users] Long time for USRP N210 to respond -- is
>         this v3.10, firewall problem, or something else?
> Message-ID: <56ED9999.2080409 at ripnet.com>
> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>
> On 03/18/2016 10:01 PM, Mendel, Susan Marie via USRP-users wrote:
>>
>>
>> In installing UHD on a new laptop, I very stupidly installed version
>> 3.10 instead of the latest release. I didn't use git clone -- I tried
>> but that failed, I think due to my firewall, so I grabbed the zip.
>>
>> When I send a command to the USRP N210, there seems to be a 30 second
>> or so delay before I get any response. For instance the command
>> tx_waveforms prints out "current send frame size" and then it will be
>> a long time before I see anything else. Things seem to work fine once
>> it starts sending. Using the same command on a computer with v3.8.4
>> installed and the same USRP, there is no long delay.
>>
>>
>> I haven't disabled the firewall because I may need permission to do
>> that. Meanwhile I'm specifying the USRP address in the command. Is the
>> firewall likely causing the delay?
>>
>> Secondly, if I were to try building an earlier version instead, what
>> all do I need to remove first? The lib64/uhd directory?
>>
>>
>> Thanks for any help
>>
>>
> A delay isn't normal.
>
> What happens if you use uhd_usrp_probe:
>
> uhd_usrp_probe --args addr=192.168.10.2       (or whatever the IP
> address of your N210 is)
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160319/5aa43098/attachment-0001.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> ------------------------------
>
> End of USRP-users Digest, Vol 67, Issue 20
> ******************************************
>
>
>
> ------------------------------
>
> Message: 14
> Date: Mon, 21 Mar 2016 10:13:50 +0800
> From: john liu <johncorad1988 at gmail.com>
> To: "USRP-users at lists.ettus.com" <usrp-users at lists.ettus.com>
> Subject: [USRP-users] IIP2 of E310
> Message-ID:
>         <CAF6NnTLvoFAJb5XVOrsc3+HBq11qc2khxe2jmy9XwB5HoM=Nvw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Dear all,
>          From the E310 datasheet,we can find the IIP3 of E310 is -20dBm,but
> we want to know the IIP2 of E310,can you tell us about it?
>
> thank you.
>
> Best regards
> John
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160321/6b0a1da8/attachment-0001.html>
>
> ------------------------------
>
> Message: 15
> Date: Sun, 20 Mar 2016 22:22:03 -0400
> From: "Marcus D. Leech" <mleech at ripnet.com>
> To: usrp-users at lists.ettus.com
> Subject: Re: [USRP-users] IIP2 of E310
> Message-ID: <56EF5ACB.4030504 at ripnet.com>
> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>
> On 03/20/2016 10:13 PM, john liu via USRP-users wrote:
>> Dear all,
>> From the E310 datasheet,we can find the IIP3 of E310 is -20dBm,but we
>> want to know the IIP2 of E310,can you tell us about it?
>>
>> thank you.
>>
>> Best regards
>> John
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users at lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> Like most of the analog parameters, this will be dominated by the AD9361
> RFFE chip, the datasheet of which, I've linked below.  Both
>    IIP3 and IIP2 data are shown in that datasheet.
>
> http://www.analog.com/media/en/technical-documentation/data-sheets/AD9361.pdf
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160320/efa34d9f/attachment-0001.html>
>
> ------------------------------
>
> Message: 16
> Date: Mon, 21 Mar 2016 11:02:18 +0800
> From: john liu <johncorad1988 at gmail.com>
> To: "USRP-users at lists.ettus.com" <usrp-users at lists.ettus.com>
> Subject: Re: [USRP-users] IIP2 of E310
> Message-ID:
>         <CAF6NnTKcquw58A6u=Rk1xLgwWAtcJcja1-8722kP_GMnXSgvvw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi ,Marcus,
>       Thank you so much.
> best regards
> John
>
>
> Like most of the analog parameters, this will be dominated by the AD9361
> RFFE chip, the datasheet of which, I've linked below.  Both
>   IIP3 and IIP2 data are shown in that datasheet.
>
> http://www.analog.com/media/en/technical-documentation/data-sheets/AD9361.pdf
>
> On Mon, Mar 21, 2016 at 10:13 AM, john liu <johncorad1988 at gmail.com> wrote:
>
>> Dear all,
>>          From the E310 datasheet,we can find the IIP3 of E310 is
>> -20dBm,but we want to know the IIP2 of E310,can you tell us about it?
>>
>> thank you.
>>
>> Best regards
>> John
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160321/38f6c3a3/attachment-0001.html>
>
> ------------------------------
>
> Message: 17
> Date: Mon, 21 Mar 2016 04:19:11 +0000
> From: Eugene Chai <eugene at nec-labs.com>
> To: Jonathon Pendlum <jonathon.pendlum at ettus.com>
> Cc: USRP-users <usrp-users at lists.ettus.com>
> Subject: Re: [USRP-users] RFNoc Signal Output
> Message-ID: <D680646C-94F6-44AA-B604-BFF9B319F795 at nec-labs.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Jonathon,
>
> I?m transmitting 3x streams at 15.36MHz each.  Is it possible to use timed transmissions with RFNoC?  Will RFNoC then report if any of the transmissions were late?  The output of the RFNoC block is a FIFO RFNoC block, which is in turn connected to a TX radio interface.
>
> Thanks,
> Eugene
>
>> On Mar 20, 2016, at 3:30 PM, Jonathon Pendlum <jonathon.pendlum at ettus.com> wrote:
>>
>> Hi Eugene,
>>
>> What rate are you running the radio at? It could be possible you are underflowing the radio core. With current rfnoc-devel you would not know since the underflow packets are not forwarded to the host.
>>
>>
>>
>> Jonathon
>>
>> On Sat, Mar 19, 2016 at 10:48 AM, Eugene Chai via USRP-users <usrp-users at lists.ettus.com> wrote:
>> Hi,
>>
>> I have an RFNoC block on an X310 with three input and one output port.  I used the addsub block as a starting point, and I?m working on the rfnoc-devel git branch.   The RFNoC block acts as a mux ? it  takes three continuous streams from the host PC, and selects one of them for the output.  However, during testing, the output signal seems to be discontinuous.  I?ve attached a plot of the output signal that I captured over the air with a second X310.  Does anybody know what could be wrong here?
>>
>> Thanks,
>> Eugene
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users at lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
> ------------------------------
>
> Message: 18
> Date: Mon, 21 Mar 2016 10:37:03 +0000
> From: ???? <royk at eng.gov.il>
> To: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
> Subject: [USRP-users] E310 - Maximal rate for rx_samples_to_file
>         example
> Message-ID:
>         <BDAC4F2DD20BA24991EBDC81B4052584825EE3C5 at Imail-Exch02.govmail.tehila.gov.il>
>
> Content-Type: text/plain; charset="windows-1255"
>
> Hi,
>
> What is the maximal sampling rate possible for sampling to a file without getting overflows (E310)?
>
> I ran the rx_samples_to_file example on the E310 with the default sampling rate (1MHz), and after about a minute I started getting overflows ("O"s).
>
> Additional info:
>
>
> 1.       The E310 image is "fido-rfnoc-test" (http://files.ettus.com/e3xx_images/alpha/fido-rfnoc-test/)
>
> 2.       The FPGA image is "uhd-images_003.010.rfnoc-282-gab4e9eaa" (http://files.ettus.com/binaries/images/)
>
> 3.       The "rx_samples_to_file" example was cross-compiled from "rfnoc-devel" branch (https://github.com/EttusResearch/uhd/tree/rfnoc-devel), following the instructions in http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_sdk.
>
> 4.       The micro SD card is UHS speed class 1 (10MB/s).
>
> Thanks,
> Roy
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160321/b3b37afe/attachment-0001.html>
>
> ------------------------------
>
> Message: 19
> Date: Mon, 21 Mar 2016 14:10:50 +0100
> From: Claudio Cicconetti <ccicconetti at mbigroup.it>
> To: usrp-users at lists.ettus.com
> Subject: Re: [USRP-users] E310 - Maximal rate for rx_samples_to_file
>         example
> Message-ID: <56EFF2DA.7060207 at mbigroup.it>
> Content-Type: text/plain; charset=UTF-8
>
> Dear Roy,
> Did you try the --null option? It will do everything except storing the
> samples, just in case you suspect the issue may have something to do
> with the actual writing part.
>
> Best regards,
> Claudio
>
> On 03/21/2016 11:37 AM, ???? via USRP-users wrote:
>> Hi,
>>
>> What is the maximal sampling rate possible for sampling to a file without getting overflows (E310)?
>>
>> I ran the rx_samples_to_file example on the E310 with the default sampling rate (1MHz), and after about a minute I started getting overflows ("O"s).
>>
>> Additional info:
>>
>>
>> 1.       The E310 image is "fido-rfnoc-test" (http://files.ettus.com/e3xx_images/alpha/fido-rfnoc-test/)
>>
>> 2.       The FPGA image is "uhd-images_003.010.rfnoc-282-gab4e9eaa" (http://files.ettus.com/binaries/images/)
>>
>> 3.       The "rx_samples_to_file" example was cross-compiled from "rfnoc-devel" branch (https://github.com/EttusResearch/uhd/tree/rfnoc-devel), following the instructions in http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_sdk.
>>
>> 4.       The micro SD card is UHS speed class 1 (10MB/s).
>>
>> Thanks,
>> Roy
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users at lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
>
> ------------------------------
>
> Message: 20
> Date: Mon, 21 Mar 2016 14:28:32 +0000
> From: "Swanson, Craig" <Craig.Swanson at gtri.gatech.edu>
> To: Jonathon Pendlum <jonathon.pendlum at ettus.com>
> Cc: "Noury, Matthew G." <Matt.Noury at gtri.gatech.edu>,
>         "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
> Subject: Re: [USRP-users] Modelsim execute error for option -64
> Message-ID: <1458570511995.18986 at gtri.gatech.edu>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Jonathon,
>
> With the help of my IT guy, I needed to enter the command
>
>
> craig at craig-VirtualBox:/opt/mentor/modelsim/modelsim_dlx$ ln -s linuxpe linux_x86_64pe
>
>
> Which fixed my problem.  Thanks.
>
>
> Craig
>
> ?
> Craig F. Swanson
> Research Engineer II
> Information and Communications Laboratory
> Communications, Systems, and Spectrum Division
> Georgia Tech Research Institute
> Room 560
> 250 14th St NW
> Atlanta, GA 30318
> Cell: 770.298.9156
> http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>
> ________________________________
> From: Jonathon Pendlum <jonathon.pendlum at ettus.com>
> Sent: Sunday, March 20, 2016 3:33 PM
> To: Swanson, Craig
> Cc: usrp-users at lists.ettus.com
> Subject: Re: Modelsim execute error for option -64
>
> Hi Craig,
>
> This is an error with Vivado. Make a symbolic link /opt/mentor/modelsim/modelsim_dlx/bin/linux_x86_64pe pointing to /opt/mentor/modelsim/modelsim_dlx/bin/linuxpe.
>
>
>
> Jonathon
>
> On Sat, Mar 19, 2016 at 11:09 AM, Swanson, Craig <Craig.Swanson at gtri.gatech.edu<mailto:Craig.Swanson at gtri.gatech.edu>> wrote:
>
> Jonathon,
>
> I have not run a Modelsim simulation in about three months.  This week I decided to upgrade my uhd/fpga-src to the latest rev in git.
>
>
> I tried running the noc_block_qpsk testbench and I got the following error:
>
> Failed to open executable /opt/mentor/modelsim/modelsim_dlx/bin/../linuxpe/../linux_x86_64pe/vish in execute mode needed for the option -64.
> execv: No such file or directory
> ** Fatal: Unable to exec the GUI /opt/mentor/modelsim/modelsim_dlx/bin/../linuxpe/../linux_x86_64pe/vish.
>
> Do you have any ideas on where I can start looking for how to fix this error?
>
> Craig
>
>
>
> Craig F. Swanson
> Research Engineer II
> Information and Communications Laboratory
> Communications, Systems, and Spectrum Division
> Georgia Tech Research Institute
> Room 560
> 250 14th St NW
> Atlanta, GA 30318
> Cell: 770.298.9156<tel:770.298.9156>
> http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160321/36ee1b33/attachment-0001.html>
>
> ------------------------------
>
> Message: 21
> Date: Mon, 21 Mar 2016 11:09:04 -0400
> From: James Humphries <james.humphries at ettus.com>
> To: Claudio Cicconetti <ccicconetti at mbigroup.it>
> Cc: "USRP-users at lists.ettus.com" <usrp-users at lists.ettus.com>
> Subject: Re: [USRP-users] E310 - Maximal rate for rx_samples_to_file
>         example
> Message-ID:
>         <CAEwGFhU=hq=BHzeYKgHsXRf=U9Q4LeHrnQzxxaisib_6rghCNQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Roy,
>
> In addition to Claudio's suggestion, keep in mind that a 1MHz sampling rate
> is already approaching the max write speed of the micro-sd card. It may not
> be able to sustain those write speeds for very long.
>
> At 1 MS/s,
>
> 1 MS/s * 4 bytes/float * 2 floats/sample = 8 MB/s.
>
> This doesn't consider that the OS is also loaded from the SD card and may
> be consuming some time reading/writing to the SD card as well.
>
> -Trip
>
> On Mon, Mar 21, 2016 at 9:10 AM, Claudio Cicconetti via USRP-users <
> usrp-users at lists.ettus.com> wrote:
>
>> Dear Roy,
>> Did you try the --null option? It will do everything except storing the
>> samples, just in case you suspect the issue may have something to do
>> with the actual writing part.
>>
>> Best regards,
>> Claudio
>>
>> On 03/21/2016 11:37 AM, ???? via USRP-users wrote:
>>> Hi,
>>>
>>> What is the maximal sampling rate possible for sampling to a file
>> without getting overflows (E310)?
>>> I ran the rx_samples_to_file example on the E310 with the default
>> sampling rate (1MHz), and after about a minute I started getting overflows
>> ("O"s).
>>> Additional info:
>>>
>>>
>>> 1.       The E310 image is "fido-rfnoc-test" (
>> http://files.ettus.com/e3xx_images/alpha/fido-rfnoc-test/)
>>> 2.       The FPGA image is "uhd-images_003.010.rfnoc-282-gab4e9eaa" (
>> http://files.ettus.com/binaries/images/)
>>> 3.       The "rx_samples_to_file" example was cross-compiled from
>> "rfnoc-devel" branch (
>> https://github.com/EttusResearch/uhd/tree/rfnoc-devel), following the
>> instructions in http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_sdk
>> .
>>> 4.       The micro SD card is UHS speed class 1 (10MB/s).
>>>
>>> Thanks,
>>> Roy
>>>
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users at lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users at 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/20160321/98c7e5c6/attachment-0001.html>
>
> ------------------------------
>
> Message: 22
> Date: Mon, 21 Mar 2016 10:23:36 -0500
> From: Kevin McGuire <kmcg3413 at gmail.com>
> To: USRP-users at lists.ettus.com
> Subject: [USRP-users] Demuxer Error : Bad Frames (My Solution So Far)
> Message-ID:
>         <CACVSexmsa+UE28+VOv=wG-PoFiym4LgMLSp7RPQt2nTRB_tHhQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I have been suffering from this from time to time. I normally just RX with
> USB 2.0 power. However, if I set it to use 8-bit complex or 12-bit complex
> I can usually have this error happen fairly quickly.
>
> I know that the documentation says that I should be using the DC external
> power but I ignored that for some time. Today, that issue really stopped me
> in my tracks while doing RX and TX, which caused me to remember, so* I
> connected the external power and the error seems to have gone away. *
>
> I have read old mail from this list about people having similar problem. I
> thought that I might throw this in for you guys to chew on and perhaps it
> could be the problem at times.
>
> *I can not confirm it without a doubt but I will surely report back if the
> error happens again using *external power. It does make sense that
> something could be drawing too much power and causing some timing issues or
> even preventing the proper voltages and current sourcing onto the USB bus,
> therefore, corrupting frames.
>
> Best,
> - Kevin McGuire.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160321/43e48245/attachment-0001.html>
>
> ------------------------------
>
> Message: 23
> Date: Sun, 20 Mar 2016 12:14:41 -0600
> From: Thomas Wagner <twagner at kurma.com>
> To: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
> Subject: [USRP-users] USRP B210 and E310
> Message-ID: <77FD93A5-71CE-4547-A622-64A1DDC3B1FB at kurma.com>
> Content-Type: text/plain;       charset=us-ascii
>
> I have both a B210 and an E310.  I am using GRC.   I don't understand how to set up the ports with USRP source and sync to use the devices in MIMO mode.   I get single channel (B210) to work using the default ports.   I would like to transmit on one port and receive on two ports both channels I/Q to do phase comparison for radar processing.   I have the latest stable GNUradio and UHD.
> Can anyone please help with this?
>
> Regards,
> Tom
>
> Tom Wagner
> twagner at kurma.com
> Tom.Wagner at tautechnologies.com
> 310-387-4929 cell
>
>
>
>
> ------------------------------
>
> Message: 24
> Date: Mon, 21 Mar 2016 09:25:11 -0600
> From: Thomas Wagner <twagner at kurma.com>
> To: usrp-users at lists.ettus.com
> Subject: [USRP-users] posting did not go through
> Message-ID: <56F01257.2060806 at kurma.com>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> I sent this message a few days ago.
>
> I have both a B210 and an E310.  I am using GRC.   I don't understand
> how to set up the ports with USRP source and sync to use the devices in
> MIMO mode.   I get single channel (B210) to work using the default
> ports.   I would like to transmit on one port and receive on two ports
> both channels I/Q to do phase comparison for radar processing.   I have
> the latest stable GNUradio and UHD.
> Can anyone please help with this?
>
> Regards,
> Tom
>
> Tom Wagner
> twagner at kurma.com <mailto:twagner at kurma.com>
> Tom.Wagner at tautechnologies.com <mailto:Tom.Wagner at tautechnologies.com>
> 310-387-4929 cell
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160321/0c030168/attachment-0001.html>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: twagner.vcf
> Type: text/x-vcard
> Size: 143 bytes
> Desc: not available
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160321/0c030168/attachment-0001.vcf>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> ------------------------------
>
> End of USRP-users Digest, Vol 67, Issue 21
> ******************************************
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com





More information about the USRP-users mailing list