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. Re: X310/UBX-160 Tx output power (Rob Kossler)
2. Problem B210 mac OS (Leonardo Sampaio Cardoso)
3. Re: Fwd: Help In installing Yate BTS with B200 (Marcus M?ller)
4. Re: Fwd: Help In installing Yate BTS with B200 (Marcus M?ller)
5. Re: Problem B210 mac OS (Michael Dickens)
6. Re: Can the USRP B210 do passive scanning of WIFI? (Marcus M?ller)
7. Re: Twin RX Bandwidth Requirements (Marcus M?ller)
8. Re: Problem B210 mac OS (Leonardo Sampaio Cardoso)
9. Re: Problem B210 mac OS (Michael Dickens)
10. Re: Twin RX Bandwidth Requirements (Marcus M?ller)
11. Re: Twin RX Bandwidth Requirements (Marcus D. Leech)
12. YateBTS+USRP B200 (ayush gupta)
13. Re: Twin RX Bandwidth Requirements (Marcus M?ller)
14. Re: YateBTS+USRP B200 (Marcus M?ller)
15. Re: YateBTS+USRP B200 (Marcus M?ller)
16. Re: RFNOC x310 image 2 bytes too large (Sam Carey)
17. Re: YateBTS+USRP B200 (Marcus M?ller)
18. Block Diagram Publish (Richard Bell)
19. Re: RFNOC x310 image 2 bytes too large (Long, Jeffrey P.)
20. Re: Block Diagram Publish (Ian Buckley)
21. Re: TX/RX Fixed Signal Phase Synchronization (Sam Carey)
22. Selling my E110 (Joe Y. Mambu)
23. Re: Selling my E110 (Joe Y. Mambu)
24. Re: TX/RX Fixed Signal Phase Synchronization (Marcus M?ller)
25. Re: Issue with DmaFIFO uhd::lookup_error' (Walter Maguire)
26. Re: Issue with DmaFIFO uhd::lookup_error' (Walter Maguire)
27. B210 Initialization issue (Joan Olmos)
28. Re: B210 Initialization issue (Marcus D. Leech)
29. Re: B210 Initialization issue (Simon Brown)
30. Re: Problem B210 mac OS (Leonardo Sampaio Cardoso)
31. Re: Problem B210 mac OS (Michael Dickens)
32. FFT block's mag^2 output in RFNoC (Jason Matusiak)
33. error in rfnoc_fosphor.grc (Long, Jeffrey P.)
34. Re: error in rfnoc_fosphor.grc (Sylvain Munaut)
35. Re: FFT block's mag^2 output in RFNoC (Sylvain Munaut)
36. Re: error in rfnoc_fosphor.grc (Long, Jeffrey P.)
37. Re: error in rfnoc_fosphor.grc (Sylvain Munaut)
----------------------------------------------------------------------
Message: 1
Date: Mon, 3 Oct 2016 12:10:32 -0400
From: Rob Kossler <rkoss...@nd.edu>
To: Matt Ettus <m...@ettus.com>
Cc: Marcus M?ller <marcus.muel...@ettus.com>,
"usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] X310/UBX-160 Tx output power
Message-ID:
<cab__htqnnggxjbnjadarswtwvzs4653rt2hjn_dh--hfeny...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks for the quick responses Friday. Today, I am seeing power levels in
line with the published performance data. To my knowledge, nothing changed
in my setup between Friday and today, but now I am seeing reasonable power
levels with all signal types (single tone, chirp, etc).
Rob
On Fri, Sep 30, 2016 at 6:18 PM, Matt Ettus <m...@ettus.com> wrote:
>
> Measurements are taken in X310. Try with a single tone.
>
> Matt
>
> On Fri, Sep 30, 2016 at 3:14 PM, Rob Kossler via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> ok. With 1 MHz chirp and spectrum analyzer in zero-span with 8 MHz RBW,
>> I see a bit more power - about 1 dB more than previously reported. Still
>> less than expecting though.
>>
>> I can test with single tone, two tone, or noise. I'm wondering how Ettus
>> tested to create the performance data. Was this in a USRP or stand-alone?
>> If the latter, is there any data when testing in an X310?
>>
>> Rob
>>
>> On Fri, Sep 30, 2016 at 6:09 PM, Marcus M?ller via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi Rob, and also: Dear future mailing list reader!
>>>
>>> I typically go through the following checklist:
>>>
>>> * measurement device input impedance set to 50 Ohm
>>> * bandwidth of SA filter >> signal bw
>>> * first test typically constant single-tone, small sweep step ->
>>> verify filter shape visible
>>> * two tone test next
>>> * pseudo-white bw next
>>>
>>> Best regards,
>>>
>>> Marcus
>>>
>>> On 09/30/2016 02:56 PM, Rob Kossler via USRP-users wrote:
>>>
>>> I will change my sample rate to something small so that the chirp is
>>> over a very narrow band and then turn off the spectrum analyzer sweeping as
>>> you suggest. But, I'm pretty confident because I was measuring the power
>>> using a marker function which integrates all power within a specified
>>> band. With the very fast chirp compared to the very slow spectrum analyzer
>>> sweep, the measurement should be ok.
>>>
>>> Rob
>>>
>>> On Fri, Sep 30, 2016 at 5:53 PM, Matt Ettus <m...@ettus.com> wrote:
>>>
>>>>
>>>> Yes, but if your signal is sweeping, then you can't just read the
>>>> output power level, as the power is spread over a wider frequency range.
>>>> Turn off the sweep and look at the power if you haven't already done that.
>>>>
>>>> Matt
>>>>
>>>> On Fri, Sep 30, 2016 at 2:51 PM, Rob Kossler <rkoss...@nd.edu> wrote:
>>>>
>>>>> Spectrum analyzer (Agilent EXA). They are reasonably good power
>>>>> meters - their spec for overall amplitude accuracy is +/- 0.3 dB.
>>>>>
>>>>>
>>>>> On Fri, Sep 30, 2016 at 5:48 PM, Matt Ettus <m...@ettus.com> wrote:
>>>>>
>>>>>>
>>>>>> You should be getting much more power out. But are you sure you are
>>>>>> measuring correctly? Are you looking at a power meter or a spectrum
>>>>>> analyzer?
>>>>>>
>>>>>>
>>>>>> On Fri, Sep 30, 2016 at 2:47 PM, Rob Kossler <rkoss...@nd.edu> wrote:
>>>>>>
>>>>>>> 31.5
>>>>>>>
>>>>>>> On Fri, Sep 30, 2016 at 5:44 PM, Matt Ettus <m...@ettus.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> What did you set tx gain to?
>>>>>>>>
>>>>>>>> On Fri, Sep 30, 2016 at 2:31 PM, Rob Kossler via USRP-users <
>>>>>>>> usrp-users@lists.ettus.com> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>> I am trying to see how much output power I can get from my
>>>>>>>>> X310/UBX-160. Measuring on a spectrum analyzer (Agilent EXA), I am
>>>>>>>>> getting
>>>>>>>>> much lower levels than I expected after reviewing the UBX performance
>>>>>>>>> data
>>>>>>>>> on the Ettus website. In particular, I am only presently concerned
>>>>>>>>> with
>>>>>>>>> two center frequencies: 2440 & 5800 MHz.
>>>>>>>>>
>>>>>>>>> From the UBX performance data (page 263), I expect in the ballpark
>>>>>>>>> of 20 dBm @ 2440 MHz and 9 dBm @ 5800 MHz. In my measurements, I am
>>>>>>>>> seeing
>>>>>>>>> 8.4 dBm @ 2440 MHz and 1 dBm @ 5800 MHz. Thus, @ 2440 MHz, it is
>>>>>>>>> 11-12 dB
>>>>>>>>> lower than expected. Similarly, @ 5800 MHz, it is 8 dB lower than
>>>>>>>>> expected.
>>>>>>>>>
>>>>>>>>> My signal is a linear FM chirp with constant amplitude at 0.9 full
>>>>>>>>> scale so that could account for 1 dB of loss. I'm wondering if it is
>>>>>>>>> perhaps not possible to achieve the UBX output powers shown in the
>>>>>>>>> document
>>>>>>>>> when the UBX is installed in an X310. Was the performance data
>>>>>>>>> measured
>>>>>>>>> with the UBX in an X310 or stand-alone?
>>>>>>>>>
>>>>>>>>> Rob
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> USRP-users mailing list
>>>>>>>>> USRP-users@lists.ettus.com
>>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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/20161003/5b0f9b65/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 3 Oct 2016 18:26:04 +0200
From: Leonardo Sampaio Cardoso <leonardo.sampaio-card...@inria.fr>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Problem B210 mac OS
Message-ID: <c2925d33-2900-4615-916b-344445302...@inria.fr>
Content-Type: text/plain; charset=utf-8
Hello everyone,
I?m trying to make a transmission with a USRP B210 and GNU Radio. The first
time I try, everything goes fine, the firmware gets flashed and the
transmission starts normally.
>From the second time on, however, I get a problem like this one:
File "/Users/lcardoso/Devel/GRC-leo/top_block.py", line 315, in <module>
main()
File "/Users/lcardoso/Devel/GRC-leo/top_block.py", line 303, in main
tb = top_block_cls()
File "/Users/lcardoso/Devel/GRC-leo/top_block.py", line 85, in __init__
channels=range(1),
File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/uhd/__init__.py",
line 122, in constructor_interceptor
return old_constructor(*args)
File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/uhd/uhd_swig.py",
line 3010, in make
return _uhd_swig.usrp_sink_make(*args)
RuntimeError: RuntimeError: fifo ctrl timed out getting a send buffer
>>> Done (return code 1)
To make it work again, I have to physically disconnect the USB port, reconnect
and retry.
Has anyone who is a Mac user seen this problem before? It looks like a FIFO
thing, but I?m out of ideas on how to deal with it?
I?m on El Captain, most up-to-date version, with a recently built UHD and GNU
Radio.
Thanks,
Leonardo Cardoso
------------------------------
Message: 3
Date: Mon, 3 Oct 2016 09:27:16 -0700
From: Marcus M?ller <marcus.muel...@ettus.com>
To: ayush gupta <guptaayus...@gmail.com>, usrp-users
<usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Fwd: Help In installing Yate BTS with B200
Message-ID: <01e9a238-d523-f3be-8c83-be1907897...@ettus.com>
Content-Type: text/plain; charset="utf-8"
Hi Ayush,
Sadly, I'm not experienced with YateBTS myself; but:
Have you investigated the paths mentioned in the lines starting with
"failed.."?
Best regards,
Marcus
On 10/01/2016 02:11 PM, ayush gupta wrote:
> and yes i have compiled yate and yatebts after uhd 3.10 was installed
> and properly working
>
>
> On Sun, Oct 2, 2016 at 2:38 AM, ayush gupta <guptaayus...@gmail.com
> <mailto:guptaayus...@gmail.com>> wrote:
>
> hello marcus
>
> thanx for replying
>
> i have installed older (feb 2015) versions for yate and yatebts on
> ubuntu 16.04
> by following instructions on this
>
> page(http://randomkeystrokes.com/2016/07/01/installing-yatebts-on-a-clean-ubuntu-install-16-04-lts/
>
> <http://randomkeystrokes.com/2016/07/01/installing-yatebts-on-a-clean-ubuntu-install-16-04-lts/>)
>
>
> and for tweaking it for using uhd transceiver
> i did neccessary changes in ybts.conf path=./transceiver-uhd
> according to this post
> http://forum.yate.ro/index.php?topic=429.0
> <http://forum.yate.ro/index.php?topic=429.0>
>
> uhd_find_devices
> uhd_usrp_probe
> are runing perfect
>
> my yate installation seemed to be ok
> but now when i run
> i get this
>
> sudo yate
> [sudo] password for ryker:
> Yate (4723) is starting Sun Oct 2 02:37:04 2016
> Loaded module Javascript
> Loaded module OpenSSL - based on OpenSSL 1.0.2g 1 Mar 2016
> Loaded module iSAC floating point - based on WebRTC iSAC library
> version 4.3.0 (SPL version 1.2.0)
> Loaded module Call Forker
> Loaded module ZLib - using zlib library version 1.2.8
> Loaded module Call Generator
> Loaded module SIP Channel
> Loaded module WaveFile
> Loaded module MsgSniffer
> Loaded module ExtModule
> Loaded module YSOCKS
> Loaded module YJingle
> Loaded module CdrCombine
> Loaded module GVoice
> Loaded module YSTUN
> Loaded module iLBC - based on WebRTC iLBC library version 1.1.1
> Loaded module Analyzer
> Loaded module DumbChannel
> Loaded module YIAX
> Loaded module RegexRoute
> Loaded module GSM - based on libgsm-1.0.10
> Loaded module File Transfer
> Loaded module Conference
> Loaded module ToneDetector
> Loaded module CdrBuild
> Loaded module MOH
> Loaded module MUX
> Loaded module iLBC - based on iLBC reference library
> Loaded module CdrFile
> Loaded module PBX
> Loaded module FileInfo
> Loaded module YRTP
> Loaded module ToneGen
> Loaded module RManager
> Loaded module Call Parking
> Loaded module Analog Channel
> Loaded module Monitoring
> Loaded module Clustering
> Loaded module Queues Notify
> Loaded module Analog Detector
> Loaded module MGCP-GW
> Loaded module Cpu
> Loaded module MRCP
> Loaded module Heartbeat
> Loaded module GSM Transceiver
> Loaded module Queues
> Loaded module Registration from file
> Loaded module Cisco SM
> Loaded module Users Management
> Loaded module Accounts from file
> Loaded module SigTransport
> Loaded module MGCP-CA
> Loaded module DbWave
> Loaded module Subscriptions
> Loaded module SNMP Agent
> Loaded module Register for database
> Loaded module Radius client
> Loaded module CallCounters
> Loaded module SIP Features
> Loaded module Presence
> Loaded module YBTS
> Loaded module Event Logs
> Loaded module Signalling Channel
> Loaded module PBX for database
> Loaded module CCongestion
> Loaded module Late Router
> Loaded module Cache
> Loaded module BladeRF using libusb 1.0.20.11004
> desc='http://libusb.info'
> Loaded module DummyRadio
> Initializing plugins
> Initializing module DummyRadio
> Initializing module BladeRF
> Initializing module Event Logs
> Initializing module Subscriptions
> Initializing module DbWave
> Initializing module MGCP Call Agent
> Initializing module SigTransport
> Initializing module Cisco SM
> Initializing module Cpu
> Initializing module Analog Detector
> Initializing module CdrFile
> Initializing module MUX
> Initializing module YSOCKS
> Initializing module ZLib
> Initializing module OpenSSL
> Initializing module Javascript
> Initializing module iSAC
> Initializing module Call Forker
> Initializing module Call Generator
> Initializing module SIP Channel
> Initializing module WaveFile
> Initializing module MsgSniffer
> Initializing module ExtModule
> 2016-10-02_02:37:05.126039 <sip:WARN> Listener(UDP,'general')
> unable to bind on :5060 - trying a random port. 98 'Address
> already in use'
> Initializing module YJingle
> Initializing module CdrCombine
> Initializing module GVoice
> Initializing module YSTUN
> Initializing module iLBC webrtc
> Initializing module Analyzer
> Initializing module DumbChannel
> DumbChannel initialized
> Initializing module YIAX
> 2016-10-02_02:37:05.154285 <iaxengine:WARN> Failed to bind socket
> on ':4569' - trying a random port. 98: 'Address already in use'
> [0x19d1aa0]
> Initializing module RegexRoute
> Initializing module File Transfer
> Initializing module Conference
> Initializing module ToneDetector
> Initializing module CdrBuild
> Initializing module MOH
> Initializing module PBX
> Initializing module FileInfo
> Initializing module YRTP
> Initializing module ToneGen
> Initializing module RManager
> 2016-10-02_02:37:05.273914 <RManager:GOON> Failed to bind to
> 127.0.0.1:5038 <http://127.0.0.1:5038> : Address already in use
> Initializing module Call Parking
> Initializing module Analog Channel
> Initializing module Monitoring
> Initializing module Queues Notify
> Initializing module MGCP Gateway
> Initializing module MrcpSpeech
> Initializing module GSM Transceiver
> Initializing module Queues for database
> Initializing module Register from file
> Initializing module Users Management
> Initializing module Accounts from file
> Initializing module SNMP Agent
> Initializing module Register for database
> Initializing module Radius client
> Initializing module SIP Features
> Initializing module Presence
> Initializing module YBTS
> Initializing module Signalling Channel
> Initializing module PBX for database
> Initializing module CCongestion
> Initializing module Late Router
> Initializing module Cache
> Initialization complete
> Failed to change directory to '/server/bts': 2 No such file or
> directory
> Failed to execute '/server/bts/mbts': 2 No such file or directory
> Yate engine is initialized and starting up
> Failed to change directory to '/server/bts': 2 No such file or
> directory
> Failed to execute '/server/bts/mbts': 2 No such file or directory
> Failed to change directory to '/server/bts': 2 No such file or
> directory
> Failed to execute '/server/bts/mbts': 2 No such file or directory
> Failed to change directory to '/server/bts': 2 No such file or
> directory
> Failed to execute '/server/bts/mbts': 2 No such file or directory
> Failed to change directory to '/server/bts': 2 No such file or
> directory
> Failed to execute '/server/bts/mbts': 2 No such file or directory
> Failed to change directory to '/server/bts': 2 No such file or
> directory
> Failed to execute '/server/bts/mbts': 2 No such file or directory
> Failed to change directory to '/server/bts': 2 No such file or
> directory
> Failed to execute '/server/bts/mbts': 2 No such file or directory
> Failed to change directory to '/server/bts': 2 No such file or
> directory
> Failed to execute '/server/bts/mbts': 2 No such file or directory
> Failed to change directory to '/server/bts': 2 No such file or
> directory
> Failed to execute '/server/bts/mbts': 2 No such file or directory
> Failed to change directory to '/server/bts': 2 No such file or
> directory
> Failed to execute '/server/bts/mbts': 2 No such file or directory
> 2016-10-02_02:37:59.002256 <ybts:GOON> Restart index reached
> maximum value 10. Exiting ...
> Yate engine is shutting down with code 125
> Unloading module Cache
> Unloading module Late Router
> Unloading module CCongestion
> Unloading module PBX for database
> Unloading module Signalling Channel
> Unloading module YBTS
> Unloaded module Presence
> Unloading module SIP Features
> Unloading module CallCounters
> Unloaded module Radius client
> Unloading module Register for database
> 2016-10-02_02:38:00.279215 <GOON> Unloading 'ysnmpagent' removed 0
> out of 1 plugins
> Unloaded module Users Management
> Unload module Registration from file
> Unloading module Queues
> 2016-10-02_02:38:00.279641 <GOON> Unloading 'gsmtrx' removed 0 out
> of 1 plugins
> Unloading module Heartbeat
> Unloading module MRCP
> 2016-10-02_02:38:00.279844 <GOON> Unloading 'mgcpgw' removed 0 out
> of 1 plugins
> Unloading module Queues Notify
> Unloaded module Monitoring
> 2016-10-02_02:38:00.280024 <GOON> Unloading 'analog' removed 0 out
> of 1 plugins
> Unloading module Call Parking
> Unloading module RManager
> Unloading module ToneGen
> Unloading module YRTP
> Unloading module FileInfo
> Unloading module PBX
> Unloading module iLBC with 0 codecs still in use
> Unloading module MOH
> Unloading module CdrBuild
> 2016-10-02_02:38:00.282637 <GOON> Unloading 'tonedetect' removed 0
> out of 1 plugins
> Unloading module Conference
> Unloading module GSM with 0 codecs still in use
> Unloading module YIAX
> Unloading module DumbChannel
> Unloading module Analyzer
> Unloading module iLBC webrtc with 0 codecs still in use
> Unloading module YSTUN
> Unloading module GVoice
> Unloading module CdrCombine
> 2016-10-02_02:38:00.283642 <GOON> Unloading 'yjinglechan' removed
> 0 out of 1 plugins
> Unloading module ExtModule
> 2016-10-02_02:38:00.283832 <GOON> Unloading 'ysipchan' removed 0
> out of 1 plugins
> Unloading module Call Generator, clearing 0 calls
> Unloading module Call Forker
> Unloading module iSAC with 0 codecs still in use
> 2016-10-02_02:38:00.284116 <GOON> Unloading 'javascript' removed 0
> out of 1 plugins
> Unloading module OpenSSL
> Unloading module ZLib
> 2016-10-02_02:38:00.284478 <GOON> Unloading 'ysockschan' removed 0
> out of 1 plugins
> Unloading module File Transfer
> Unloading module MUX
> Unloading module CdrFile
> Unloading module Clustering
> Unloading module Analog Detector
> Unloading module Cpu
> Unloading module Cisco SM
> Unloading module SigTransport
> Unloading module MGCP-GW
> Unloading module MGCP-CA
> Unloading module ToneDetector
> Unloading module SIP Channel
> 2016-10-02_02:38:00.285246 <GOON> Unloading 'mgcpca' removed 4 out
> of 1 plugins
> Unloading module Subscriptions
> Unloading module Event Logs
> Unloading module BladeRF
> Unloading module DummyRadio
> 2016-10-02_02:38:00.285646 <GOON> Exiting with 0 locked mutexes
> and 6 plugins loaded!
> Yate (4723) is stopping Sun Oct 2 02:38:00 2016
> Unloaded module SNMP Agent
> Unloading module GSM Transceiver
> Unloading module Analog Channel
> Unloading module YJingle
> Unloading module YSOCKS
> Unloading module Javascript
>
>
> please help :(
>
>
> On Sat, Oct 1, 2016 at 9:17 PM, Marcus M?ller
> <marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com>> wrote:
>
> Hello Ayush,
> Have you re-compiled/linked yatebts after updating UHD?
>
> Best regards,
> Marcus
>
> Am 1. Oktober 2016 01:10:42 GMT-07:00, schrieb ayush gupta via
> USRP-users <usrp-users@lists.ettus.com
> <mailto:usrp-users@lists.ettus.com>>:
>
> Hello everyone
>
> I want to use yatebts with USRP B200
> Upto now I have successfully installed
> YateBTS and USRP B200 UHD driver with correct FPGA image
> but since recent update I am unable change "transceiver
> Path value" to ./transceiver-uhd
>
> As new configuration file doesn't have that option now
> (ybts.conf)
> Can anyone help me how can I make USRP B200 work with
> yateBTS?!?
> I am using Ubuntu 16.04 lts
>
> Thanks In advance
> Ayush Gupta
>
>
>
> ------------------------------------------------------------------------
>
> 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>
>
> -- Sent from my Android device with K-9 Mail. Please excuse my
> brevity.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161003/1cdba1d6/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 3 Oct 2016 09:32:43 -0700
From: Marcus M?ller <marcus.muel...@ettus.com>
To: ayush gupta <guptaayus...@gmail.com>, usrp-users
<usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Fwd: Help In installing Yate BTS with B200
Message-ID: <29f60a2e-9c7e-a4aa-f1ef-d2ac0d0da...@ettus.com>
Content-Type: text/plain; charset="utf-8"
That is a general Unix usage thing; just change the permissions or
ownerships on the file the program needs to access to something that
allows the program to do so:
https://www.linux.com/learn/understanding-linux-file-permissions
Best regards,
Marcus
On 10/03/2016 09:30 AM, ayush gupta wrote:
> yes marcus i investigated them they exist but i think the script
> running dosent have the correct directory address
> i wanted to investigate/change the address so that it can work but
> cant find the right file to do so
>
> On Mon, Oct 3, 2016 at 9:57 PM, Marcus M?ller
> <marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com>> wrote:
>
> Hi Ayush,
>
> Sadly, I'm not experienced with YateBTS myself; but:
> Have you investigated the paths mentioned in the lines starting
> with "failed.."?
>
> Best regards,
>
> Marcus
>
>
> On 10/01/2016 02:11 PM, ayush gupta wrote:
>> and yes i have compiled yate and yatebts after uhd 3.10 was
>> installed and properly working
>>
>>
>> On Sun, Oct 2, 2016 at 2:38 AM, ayush gupta
>> <guptaayus...@gmail.com <mailto:guptaayus...@gmail.com>> wrote:
>>
>> hello marcus
>>
>> thanx for replying
>>
>> i have installed older (feb 2015) versions for yate and
>> yatebts on ubuntu 16.04
>> by following instructions on this
>>
>> page(http://randomkeystrokes.com/2016/07/01/installing-yatebts-on-a-clean-ubuntu-install-16-04-lts/
>>
>> <http://randomkeystrokes.com/2016/07/01/installing-yatebts-on-a-clean-ubuntu-install-16-04-lts/>)
>>
>>
>> and for tweaking it for using uhd transceiver
>> i did neccessary changes in ybts.conf path=./transceiver-uhd
>> according to this post
>> http://forum.yate.ro/index.php?topic=429.0
>> <http://forum.yate.ro/index.php?topic=429.0>
>>
>> uhd_find_devices
>> uhd_usrp_probe
>> are runing perfect
>>
>> my yate installation seemed to be ok
>> but now when i run
>> i get this
>>
>> sudo yate
>> [sudo] password for ryker:
>> Yate (4723) is starting Sun Oct 2 02:37:04 2016
>> Loaded module Javascript
>> Loaded module OpenSSL - based on OpenSSL 1.0.2g 1 Mar 2016
>> Loaded module iSAC floating point - based on WebRTC iSAC
>> library version 4.3.0 (SPL version 1.2.0)
>> Loaded module Call Forker
>> Loaded module ZLib - using zlib library version 1.2.8
>> Loaded module Call Generator
>> Loaded module SIP Channel
>> Loaded module WaveFile
>> Loaded module MsgSniffer
>> Loaded module ExtModule
>> Loaded module YSOCKS
>> Loaded module YJingle
>> Loaded module CdrCombine
>> Loaded module GVoice
>> Loaded module YSTUN
>> Loaded module iLBC - based on WebRTC iLBC library version 1.1.1
>> Loaded module Analyzer
>> Loaded module DumbChannel
>> Loaded module YIAX
>> Loaded module RegexRoute
>> Loaded module GSM - based on libgsm-1.0.10
>> Loaded module File Transfer
>> Loaded module Conference
>> Loaded module ToneDetector
>> Loaded module CdrBuild
>> Loaded module MOH
>> Loaded module MUX
>> Loaded module iLBC - based on iLBC reference library
>> Loaded module CdrFile
>> Loaded module PBX
>> Loaded module FileInfo
>> Loaded module YRTP
>> Loaded module ToneGen
>> Loaded module RManager
>> Loaded module Call Parking
>> Loaded module Analog Channel
>> Loaded module Monitoring
>> Loaded module Clustering
>> Loaded module Queues Notify
>> Loaded module Analog Detector
>> Loaded module MGCP-GW
>> Loaded module Cpu
>> Loaded module MRCP
>> Loaded module Heartbeat
>> Loaded module GSM Transceiver
>> Loaded module Queues
>> Loaded module Registration from file
>> Loaded module Cisco SM
>> Loaded module Users Management
>> Loaded module Accounts from file
>> Loaded module SigTransport
>> Loaded module MGCP-CA
>> Loaded module DbWave
>> Loaded module Subscriptions
>> Loaded module SNMP Agent
>> Loaded module Register for database
>> Loaded module Radius client
>> Loaded module CallCounters
>> Loaded module SIP Features
>> Loaded module Presence
>> Loaded module YBTS
>> Loaded module Event Logs
>> Loaded module Signalling Channel
>> Loaded module PBX for database
>> Loaded module CCongestion
>> Loaded module Late Router
>> Loaded module Cache
>> Loaded module BladeRF using libusb 1.0.20.11004
>> desc='http://libusb.info'
>> Loaded module DummyRadio
>> Initializing plugins
>> Initializing module DummyRadio
>> Initializing module BladeRF
>> Initializing module Event Logs
>> Initializing module Subscriptions
>> Initializing module DbWave
>> Initializing module MGCP Call Agent
>> Initializing module SigTransport
>> Initializing module Cisco SM
>> Initializing module Cpu
>> Initializing module Analog Detector
>> Initializing module CdrFile
>> Initializing module MUX
>> Initializing module YSOCKS
>> Initializing module ZLib
>> Initializing module OpenSSL
>> Initializing module Javascript
>> Initializing module iSAC
>> Initializing module Call Forker
>> Initializing module Call Generator
>> Initializing module SIP Channel
>> Initializing module WaveFile
>> Initializing module MsgSniffer
>> Initializing module ExtModule
>> 2016-10-02_02:37:05.126039 <sip:WARN> Listener(UDP,'general')
>> unable to bind on :5060 - trying a random port. 98 'Address
>> already in use'
>> Initializing module YJingle
>> Initializing module CdrCombine
>> Initializing module GVoice
>> Initializing module YSTUN
>> Initializing module iLBC webrtc
>> Initializing module Analyzer
>> Initializing module DumbChannel
>> DumbChannel initialized
>> Initializing module YIAX
>> 2016-10-02_02:37:05.154285 <iaxengine:WARN> Failed to bind
>> socket on ':4569' - trying a random port. 98: 'Address
>> already in use' [0x19d1aa0]
>> Initializing module RegexRoute
>> Initializing module File Transfer
>> Initializing module Conference
>> Initializing module ToneDetector
>> Initializing module CdrBuild
>> Initializing module MOH
>> Initializing module PBX
>> Initializing module FileInfo
>> Initializing module YRTP
>> Initializing module ToneGen
>> Initializing module RManager
>> 2016-10-02_02:37:05.273914 <RManager:GOON> Failed to bind to
>> 127.0.0.1:5038 <http://127.0.0.1:5038> : Address already in use
>> Initializing module Call Parking
>> Initializing module Analog Channel
>> Initializing module Monitoring
>> Initializing module Queues Notify
>> Initializing module MGCP Gateway
>> Initializing module MrcpSpeech
>> Initializing module GSM Transceiver
>> Initializing module Queues for database
>> Initializing module Register from file
>> Initializing module Users Management
>> Initializing module Accounts from file
>> Initializing module SNMP Agent
>> Initializing module Register for database
>> Initializing module Radius client
>> Initializing module SIP Features
>> Initializing module Presence
>> Initializing module YBTS
>> Initializing module Signalling Channel
>> Initializing module PBX for database
>> Initializing module CCongestion
>> Initializing module Late Router
>> Initializing module Cache
>> Initialization complete
>> Failed to change directory to '/server/bts': 2 No such file
>> or directory
>> Failed to execute '/server/bts/mbts': 2 No such file or directory
>> Yate engine is initialized and starting up
>> Failed to change directory to '/server/bts': 2 No such file
>> or directory
>> Failed to execute '/server/bts/mbts': 2 No such file or directory
>> Failed to change directory to '/server/bts': 2 No such file
>> or directory
>> Failed to execute '/server/bts/mbts': 2 No such file or directory
>> Failed to change directory to '/server/bts': 2 No such file
>> or directory
>> Failed to execute '/server/bts/mbts': 2 No such file or directory
>> Failed to change directory to '/server/bts': 2 No such file
>> or directory
>> Failed to execute '/server/bts/mbts': 2 No such file or directory
>> Failed to change directory to '/server/bts': 2 No such file
>> or directory
>> Failed to execute '/server/bts/mbts': 2 No such file or directory
>> Failed to change directory to '/server/bts': 2 No such file
>> or directory
>> Failed to execute '/server/bts/mbts': 2 No such file or directory
>> Failed to change directory to '/server/bts': 2 No such file
>> or directory
>> Failed to execute '/server/bts/mbts': 2 No such file or directory
>> Failed to change directory to '/server/bts': 2 No such file
>> or directory
>> Failed to execute '/server/bts/mbts': 2 No such file or directory
>> Failed to change directory to '/server/bts': 2 No such file
>> or directory
>> Failed to execute '/server/bts/mbts': 2 No such file or directory
>> 2016-10-02_02:37:59.002256 <ybts:GOON> Restart index reached
>> maximum value 10. Exiting ...
>> Yate engine is shutting down with code 125
>> Unloading module Cache
>> Unloading module Late Router
>> Unloading module CCongestion
>> Unloading module PBX for database
>> Unloading module Signalling Channel
>> Unloading module YBTS
>> Unloaded module Presence
>> Unloading module SIP Features
>> Unloading module CallCounters
>> Unloaded module Radius client
>> Unloading module Register for database
>> 2016-10-02_02:38:00.279215 <GOON> Unloading 'ysnmpagent'
>> removed 0 out of 1 plugins
>> Unloaded module Users Management
>> Unload module Registration from file
>> Unloading module Queues
>> 2016-10-02_02:38:00.279641 <GOON> Unloading 'gsmtrx' removed
>> 0 out of 1 plugins
>> Unloading module Heartbeat
>> Unloading module MRCP
>> 2016-10-02_02:38:00.279844 <GOON> Unloading 'mgcpgw' removed
>> 0 out of 1 plugins
>> Unloading module Queues Notify
>> Unloaded module Monitoring
>> 2016-10-02_02:38:00.280024 <GOON> Unloading 'analog' removed
>> 0 out of 1 plugins
>> Unloading module Call Parking
>> Unloading module RManager
>> Unloading module ToneGen
>> Unloading module YRTP
>> Unloading module FileInfo
>> Unloading module PBX
>> Unloading module iLBC with 0 codecs still in use
>> Unloading module MOH
>> Unloading module CdrBuild
>> 2016-10-02_02:38:00.282637 <GOON> Unloading 'tonedetect'
>> removed 0 out of 1 plugins
>> Unloading module Conference
>> Unloading module GSM with 0 codecs still in use
>> Unloading module YIAX
>> Unloading module DumbChannel
>> Unloading module Analyzer
>> Unloading module iLBC webrtc with 0 codecs still in use
>> Unloading module YSTUN
>> Unloading module GVoice
>> Unloading module CdrCombine
>> 2016-10-02_02:38:00.283642 <GOON> Unloading 'yjinglechan'
>> removed 0 out of 1 plugins
>> Unloading module ExtModule
>> 2016-10-02_02:38:00.283832 <GOON> Unloading 'ysipchan'
>> removed 0 out of 1 plugins
>> Unloading module Call Generator, clearing 0 calls
>> Unloading module Call Forker
>> Unloading module iSAC with 0 codecs still in use
>> 2016-10-02_02:38:00.284116 <GOON> Unloading 'javascript'
>> removed 0 out of 1 plugins
>> Unloading module OpenSSL
>> Unloading module ZLib
>> 2016-10-02_02:38:00.284478 <GOON> Unloading 'ysockschan'
>> removed 0 out of 1 plugins
>> Unloading module File Transfer
>> Unloading module MUX
>> Unloading module CdrFile
>> Unloading module Clustering
>> Unloading module Analog Detector
>> Unloading module Cpu
>> Unloading module Cisco SM
>> Unloading module SigTransport
>> Unloading module MGCP-GW
>> Unloading module MGCP-CA
>> Unloading module ToneDetector
>> Unloading module SIP Channel
>> 2016-10-02_02:38:00.285246 <GOON> Unloading 'mgcpca' removed
>> 4 out of 1 plugins
>> Unloading module Subscriptions
>> Unloading module Event Logs
>> Unloading module BladeRF
>> Unloading module DummyRadio
>> 2016-10-02_02:38:00.285646 <GOON> Exiting with 0 locked
>> mutexes and 6 plugins loaded!
>> Yate (4723) is stopping Sun Oct 2 02:38:00 2016
>> Unloaded module SNMP Agent
>> Unloading module GSM Transceiver
>> Unloading module Analog Channel
>> Unloading module YJingle
>> Unloading module YSOCKS
>> Unloading module Javascript
>>
>>
>> please help :(
>>
>>
>> On Sat, Oct 1, 2016 at 9:17 PM, Marcus M?ller
>> <marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com>>
>> wrote:
>>
>> Hello Ayush,
>> Have you re-compiled/linked yatebts after updating UHD?
>>
>> Best regards,
>> Marcus
>>
>> Am 1. Oktober 2016 01:10:42 GMT-07:00, schrieb ayush
>> gupta via USRP-users <usrp-users@lists.ettus.com
>> <mailto:usrp-users@lists.ettus.com>>:
>>
>> Hello everyone
>>
>> I want to use yatebts with USRP B200
>> Upto now I have successfully installed
>> YateBTS and USRP B200 UHD driver with correct FPGA
>> image but since recent update I am unable change
>> "transceiver
>> Path value" to ./transceiver-uhd
>>
>> As new configuration file doesn't have that option
>> now (ybts.conf)
>> Can anyone help me how can I make USRP B200 work with
>> yateBTS?!?
>> I am using Ubuntu 16.04 lts
>>
>> Thanks In advance
>> Ayush Gupta
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> 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>
>>
>> -- Sent from my Android device with K-9 Mail. Please
>> excuse my brevity.
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161003/c06681b1/attachment-0001.html>
------------------------------
Message: 5
Date: Mon, 03 Oct 2016 12:37:22 -0400
From: Michael Dickens <michael.dick...@ettus.com>
To: Leonardo Sampaio Cardoso <leonardo.sampaio-card...@inria.fr>,
usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Problem B210 mac OS
Message-ID:
<1475512642.47501.744439817.21067...@webmail.messagingengine.com>
Content-Type: text/plain; charset="utf-8"
HI Leonardo - I don't see this issue with my B210, but I've almost never
had issues with it. Did you install UHD via MacPorts or some other
means? Is it a release or some other version? You can the basic info by
executing "uhd_config_info" in a shell. Do you get the same error if you
execute "uhd_fft" multiple times in a row? - MLD
On Mon, Oct 3, 2016, at 12:26 PM, Leonardo Sampaio Cardoso via
USRP-users wrote:
> I?m trying to make a transmission with a USRP B210 and GNU Radio. The
> first time I try, everything goes fine, the firmware gets flashed and the
> transmission starts normally.
>
> From the second time on, however, I get a problem like this one:
>
> File "/Users/lcardoso/Devel/GRC-leo/top_block.py", line 315, in <module>
> main()
> File "/Users/lcardoso/Devel/GRC-leo/top_block.py", line 303, in main
> tb = top_block_cls()
> File "/Users/lcardoso/Devel/GRC-leo/top_block.py", line 85, in __init__
> channels=range(1),
> File
>
> "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/uhd/__init__.py",
> line 122, in constructor_interceptor
> return old_constructor(*args)
> File
>
> "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/uhd/uhd_swig.py",
> line 3010, in make
> return _uhd_swig.usrp_sink_make(*args)
> RuntimeError: RuntimeError: fifo ctrl timed out getting a send buffer
>
> >>> Done (return code 1)
>
> To make it work again, I have to physically disconnect the USB port,
> reconnect and retry.
>
> Has anyone who is a Mac user seen this problem before? It looks like a
> FIFO thing, but I?m out of ideas on how to deal with it?
>
> I?m on El Captain, most up-to-date version, with a recently built UHD and
> GNU Radio.
------------------------------
Message: 6
Date: Mon, 3 Oct 2016 09:58:11 -0700
From: Marcus M?ller <marcus.muel...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Can the USRP B210 do passive scanning of
WIFI?
Message-ID: <8c070552-9118-e703-8720-57e81a857...@ettus.com>
Content-Type: text/plain; charset="windows-1252"
Hi John,
the B210 is "just" SDR frontend ? it will give you the "raw" baseband
spectrum as mathematically to what's on the air at the configured center
frequency.
Having a maximum analog Bandwidth of 56 MHz, yes, you can observe a
single channel. Jumping through a lot of Wifi channels is not going to
be overly fast, the B210 practically being the USRP that has the slowest
tuning/settle time.
In any case, the conversion from "complex baseband samples at a very
high rate" to "OFDM Frames" to "WiFi Packets" to "WiFi payload and
administrative data" is a software job, and not a capability of the USRP.
Think about it this way: Your question was basically "can I use this
sound card to do speech recognition-based room surveillance" to which
the answer is "yes, assuming you're very good with audio signal
processing, speech recognition and signal classification; the soundcard
is just going to give you audio samples".
Best regards,
Marcus
On 10/03/2016 01:30 AM, John DeLeong via USRP-users wrote:
> Hi,
>
> Can the USRP B210
> a) do passive scanning of Wifi APs and Clients; and
> b) do passive collection of Wifi packets off the air?
>
>
>
> _______________________________________________
> 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/20161003/a418ed55/attachment-0001.html>
------------------------------
Message: 7
Date: Mon, 3 Oct 2016 10:07:14 -0700
From: Marcus M?ller <marcus.muel...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Twin RX Bandwidth Requirements
Message-ID: <05f1c534-08a4-2e6f-d2a5-b7cbde364...@ettus.com>
Content-Type: text/plain; charset="windows-1252"
Hi Kevin,
go for 10GbE for high throughput. PCIe is most recommendable for LabVIEW
usage. Also, 10GE connectivity is far more flexible ? you can use
anything that does 10GBase with SFP+ connectors ? for example,
mouser.com has a small selection of cheap Amphenol FCI 10GBE cables in
stock, and you can use any 10GBase-SR, -LR,... fiber optics SFP+
transceiver (and: if you're on a budget: these can often be had as
surplus equipment!) for longer distances.
320MS/s need 320 MS/s * 32b/S = 10.24 GB/s > 10GB/s == 10GE wire speed.
But:
with UHD 3.10.0.0 dual-10GE support was added, but I've never tried it
myself so far, but what I found out (thanks, Nate!) was:
If you specify a device address string, you'd use
"addr=192.168.30.2,second_addr=192.168.40.2" (assuming these were your
device's addresses)and then you'd be able to use two 10GE connections in
parallel.
Best regards,
Marcus
On 10/03/2016 08:10 AM, Rigney, Kevin E via USRP-users wrote:
>
> Hello,
>
>
>
> What is the best data-link (PCI-E, 10GbE) to use with an X3X0 running
> two Twin RX receivers at full rate? That setup would be two
> daughterboards streaming a total of 4 channels of 80MS/s
> floating-point complex data back to a computer. The pages for both the
> 10GbE card and PCI-E card say they support 200MS/S in full-duplex
> mode. Can they run at 320MS/s in one direction?
>
>
>
> Thanks,
>
>
>
> Kevin Rigney
>
>
>
>
>
> _______________________________________________
> 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/20161003/923f093b/attachment-0001.html>
------------------------------
Message: 8
Date: Mon, 3 Oct 2016 19:18:12 +0200
From: Leonardo Sampaio Cardoso <leonardo.sampaio-card...@inria.fr>
To: Michael Dickens <michael.dick...@ettus.com>
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Problem B210 mac OS
Message-ID: <ed1b2b19-b20e-42d9-95e5-bd28ce966...@inria.fr>
Content-Type: text/plain; charset=utf-8
Thanks Michael,
Until now I've never had issues with it, but recently I had to reinstall my
system and now hell broke loose!
Yes, I?ve installed everything through macports. My reinstall is of last week.
If I?m not mistaken it is the release (stable) version.
This is what ?uhd_config_info? tells me:
Mac OS; Clang version 7.3.0 (clang-703.0.31); Boost_105900;
UHD_003.010.000.000-MacPorts-Release
And, ?uhd_fft" gives me exactly the same problem.
Cheers,
Leo
> On 03 Oct 2016, at 18:37, Michael Dickens <michael.dick...@ettus.com> wrote:
>
> HI Leonardo - I don't see this issue with my B210, but I've almost never
> had issues with it. Did you install UHD via MacPorts or some other
> means? Is it a release or some other version? You can the basic info by
> executing "uhd_config_info" in a shell. Do you get the same error if you
> execute "uhd_fft" multiple times in a row? - MLD
>
> On Mon, Oct 3, 2016, at 12:26 PM, Leonardo Sampaio Cardoso via
> USRP-users wrote:
>> I?m trying to make a transmission with a USRP B210 and GNU Radio. The
>> first time I try, everything goes fine, the firmware gets flashed and the
>> transmission starts normally.
>>
>> From the second time on, however, I get a problem like this one:
>>
>> File "/Users/lcardoso/Devel/GRC-leo/top_block.py", line 315, in <module>
>> main()
>> File "/Users/lcardoso/Devel/GRC-leo/top_block.py", line 303, in main
>> tb = top_block_cls()
>> File "/Users/lcardoso/Devel/GRC-leo/top_block.py", line 85, in __init__
>> channels=range(1),
>> File
>>
>> "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/uhd/__init__.py",
>> line 122, in constructor_interceptor
>> return old_constructor(*args)
>> File
>>
>> "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/uhd/uhd_swig.py",
>> line 3010, in make
>> return _uhd_swig.usrp_sink_make(*args)
>> RuntimeError: RuntimeError: fifo ctrl timed out getting a send buffer
>>
>>>>> Done (return code 1)
>>
>> To make it work again, I have to physically disconnect the USB port,
>> reconnect and retry.
>>
>> Has anyone who is a Mac user seen this problem before? It looks like a
>> FIFO thing, but I?m out of ideas on how to deal with it?
>>
>> I?m on El Captain, most up-to-date version, with a recently built UHD and
>> GNU Radio.
------------------------------
Message: 9
Date: Mon, 03 Oct 2016 13:27:09 -0400
From: Michael Dickens <michael.dick...@ettus.com>
To: Leonardo Sampaio Cardoso <leonardo.sampaio-card...@inria.fr>
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Problem B210 mac OS
Message-ID:
<1475515629.58024.744495361.291f7...@webmail.messagingengine.com>
Content-Type: text/plain; charset="utf-8"
Hi Leonardo - OK; good data points.
Can you try the "uhd-devel" port & see if it fixes anything? It's
generally a drop-in replacement for "uhd". You can do this via:
{{{
sudo port -f deact uhd
sudo port install uhd-devel
}}}
You'll want to re-link your project before trying again (probably don't
need to, but it's a good idea).
Ditto for trying "uhd_fft" multiple times again. Thanks! - MLD
On Mon, Oct 3, 2016, at 01:18 PM, Leonardo Sampaio Cardoso wrote:
> Until now I've never had issues with it, but recently I had to reinstall
> my system and now hell broke loose!
>
> Yes, I?ve installed everything through macports. My reinstall is of last
> week. If I?m not mistaken it is the release (stable) version.
>
> This is what ?uhd_config_info? tells me:
>
> Mac OS; Clang version 7.3.0 (clang-703.0.31); Boost_105900;
> UHD_003.010.000.000-MacPorts-Release
>
> And, ?uhd_fft" gives me exactly the same problem.
------------------------------
Message: 10
Date: Mon, 3 Oct 2016 11:00:48 -0700
From: Marcus M?ller <marcus.muel...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Twin RX Bandwidth Requirements
Message-ID: <d184287f-3e16-9018-6553-bc05c26cc...@ettus.com>
Content-Type: text/plain; charset="windows-1252"
Ah, I was just pointed to something (thanks for that) the fact that the
ADCs always run at 200MS/s, and currently, we have no rational
resampler, only a DDC chain with a normal decimation, i.e. you can't
have 4x 80MS/s, but 4x 100MS/s works!
Best regards,
Marcus
On 10/03/2016 10:07 AM, Marcus M?ller wrote:
>
> Hi Kevin,
>
> go for 10GbE for high throughput. PCIe is most recommendable for
> LabVIEW usage. Also, 10GE connectivity is far more flexible ? you can
> use anything that does 10GBase with SFP+ connectors ? for example,
> mouser.com has a small selection of cheap Amphenol FCI 10GBE cables in
> stock, and you can use any 10GBase-SR, -LR,... fiber optics SFP+
> transceiver (and: if you're on a budget: these can often be had as
> surplus equipment!) for longer distances.
>
> 320MS/s need 320 MS/s * 32b/S = 10.24 GB/s > 10GB/s == 10GE wire
> speed. But:
>
> with UHD 3.10.0.0 dual-10GE support was added, but I've never tried it
> myself so far, but what I found out (thanks, Nate!) was:
>
> If you specify a device address string, you'd use
> "addr=192.168.30.2,second_addr=192.168.40.2" (assuming these were your
> device's addresses)and then you'd be able to use two 10GE connections
> in parallel.
>
> Best regards,
>
> Marcus
>
>
> On 10/03/2016 08:10 AM, Rigney, Kevin E via USRP-users wrote:
>>
>> Hello,
>>
>>
>>
>> What is the best data-link (PCI-E, 10GbE) to use with an X3X0 running
>> two Twin RX receivers at full rate? That setup would be two
>> daughterboards streaming a total of 4 channels of 80MS/s
>> floating-point complex data back to a computer. The pages for both
>> the 10GbE card and PCI-E card say they support 200MS/S in full-duplex
>> mode. Can they run at 320MS/s in one direction?
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Kevin Rigney
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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/20161003/1c3d47fc/attachment-0001.html>
------------------------------
Message: 11
Date: Mon, 03 Oct 2016 14:09:54 -0400
From: "Marcus D. Leech" <mle...@ripnet.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Twin RX Bandwidth Requirements
Message-ID: <57f29ef2.1030...@ripnet.com>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 10/03/2016 02:00 PM, Marcus M?ller via USRP-users wrote:
>
> Ah, I was just pointed to something (thanks for that) the fact that
> the ADCs always run at 200MS/s, and currently, we have no rational
> resampler, only a DDC chain with a normal decimation, i.e. you can't
> have 4x 80MS/s, but 4x 100MS/s works!
>
> Best regards,
> Marcus
>
I'd rather like to meet the computer that can handle 400Msps of this
stuff, and "do useful things" for various values of "useful".
In fact, the not-for-profit that I'm in the middle of creating would
love a handful :)
>
> On 10/03/2016 10:07 AM, Marcus M?ller wrote:
>>
>> Hi Kevin,
>>
>> go for 10GbE for high throughput. PCIe is most recommendable for
>> LabVIEW usage. Also, 10GE connectivity is far more flexible ? you can
>> use anything that does 10GBase with SFP+ connectors ? for example,
>> mouser.com has a small selection of cheap Amphenol FCI 10GBE cables
>> in stock, and you can use any 10GBase-SR, -LR,... fiber optics SFP+
>> transceiver (and: if you're on a budget: these can often be had as
>> surplus equipment!) for longer distances.
>>
>> 320MS/s need 320 MS/s * 32b/S = 10.24 GB/s > 10GB/s == 10GE wire
>> speed. But:
>>
>> with UHD 3.10.0.0 dual-10GE support was added, but I've never tried
>> it myself so far, but what I found out (thanks, Nate!) was:
>>
>> If you specify a device address string, you'd use
>> "addr=192.168.30.2,second_addr=192.168.40.2" (assuming these were
>> your device's addresses)and then you'd be able to use two 10GE
>> connections in parallel.
>>
>> Best regards,
>>
>> Marcus
>>
>>
>> On 10/03/2016 08:10 AM, Rigney, Kevin E via USRP-users wrote:
>>>
>>> Hello,
>>>
>>> What is the best data-link (PCI-E, 10GbE) to use with an X3X0
>>> running two Twin RX receivers at full rate? That setup would be two
>>> daughterboards streaming a total of 4 channels of 80MS/s
>>> floating-point complex data back to a computer. The pages for both
>>> the 10GbE card and PCI-E card say they support 200MS/S in
>>> full-duplex mode. Can they run at 320MS/s in one direction?
>>>
>>> Thanks,
>>>
>>> Kevin Rigney
>>>
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161003/637c452d/attachment-0001.html>
------------------------------
Message: 12
Date: Mon, 3 Oct 2016 23:49:59 +0530
From: ayush gupta <guptaayus...@gmail.com>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] YateBTS+USRP B200
Message-ID:
<cagf-_vmbruwrlogundqvc45dno2hbuvba3yavvluklh5+z_...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello All,
Have anyone here used USRP B200 with yateBTS??!
If yes please share the
Version information of yate and Yatebts working with usrpb200
Also the os and uhd version.
Thanks
Ayush Gupta
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161003/214971a6/attachment-0001.html>
------------------------------
Message: 13
Date: Mon, 3 Oct 2016 11:22:02 -0700
From: Marcus M?ller <marcus.muel...@ettus.com>
To: usrp-users@lists.ettus.com
Cc: Wan Liu <wan....@ni.com>
Subject: Re: [USRP-users] Twin RX Bandwidth Requirements
Message-ID: <db7c147d-687b-b0e2-6605-ab20bcfaf...@ettus.com>
Content-Type: text/plain; charset="windows-1252"
Heh, that's pretty through, though I've seen people do 2x200MS/s at
least running a FFT display, and I think there was some demo that
actually used quad-channel full-rate TwinRX; hopefully Wan can chime in
on what machine that was. "Useful" actually is pretty hard to define ;),
a FFT display might or might not fulfil that requirement.
But, yes. You'll need something with quite a few cores, something whose
PCIe architecture is optimized for high-throughput network data, you'll
need the CPU cores to run pretty fast, and even then, there'll be a lot
of hand-tweaking involved until you get the most out of it. However, I
think what we tell most customers is that you first verify
operationality, then you use a much lower sampling rate to prototype,
then you figure out the bottlenecks, and then you solve these and scale up.
So, the problem is that you've already identified that bottleneck. I'll
set up a new dev machine pretty soon (hopefully), and I plan to report
back on that, and the issues/solutions involved.
Cheers,
Marcus
On 10/03/2016 11:09 AM, Marcus D. Leech via USRP-users wrote:
> On 10/03/2016 02:00 PM, Marcus M?ller via USRP-users wrote:
>>
>> Ah, I was just pointed to something (thanks for that) the fact that
>> the ADCs always run at 200MS/s, and currently, we have no rational
>> resampler, only a DDC chain with a normal decimation, i.e. you can't
>> have 4x 80MS/s, but 4x 100MS/s works!
>>
>> Best regards,
>> Marcus
>>
> I'd rather like to meet the computer that can handle 400Msps of this
> stuff, and "do useful things" for various values of "useful".
>
> In fact, the not-for-profit that I'm in the middle of creating would
> love a handful :)
>
>
>>
>> On 10/03/2016 10:07 AM, Marcus M?ller wrote:
>>>
>>> Hi Kevin,
>>>
>>> go for 10GbE for high throughput. PCIe is most recommendable for
>>> LabVIEW usage. Also, 10GE connectivity is far more flexible ? you
>>> can use anything that does 10GBase with SFP+ connectors ? for
>>> example, mouser.com has a small selection of cheap Amphenol FCI
>>> 10GBE cables in stock, and you can use any 10GBase-SR, -LR,... fiber
>>> optics SFP+ transceiver (and: if you're on a budget: these can often
>>> be had as surplus equipment!) for longer distances.
>>>
>>> 320MS/s need 320 MS/s * 32b/S = 10.24 GB/s > 10GB/s == 10GE wire
>>> speed. But:
>>>
>>> with UHD 3.10.0.0 dual-10GE support was added, but I've never tried
>>> it myself so far, but what I found out (thanks, Nate!) was:
>>>
>>> If you specify a device address string, you'd use
>>> "addr=192.168.30.2,second_addr=192.168.40.2" (assuming these were
>>> your device's addresses)and then you'd be able to use two 10GE
>>> connections in parallel.
>>>
>>> Best regards,
>>>
>>> Marcus
>>>
>>>
>>> On 10/03/2016 08:10 AM, Rigney, Kevin E via USRP-users wrote:
>>>>
>>>> Hello,
>>>>
>>>>
>>>>
>>>> What is the best data-link (PCI-E, 10GbE) to use with an X3X0
>>>> running two Twin RX receivers at full rate? That setup would be two
>>>> daughterboards streaming a total of 4 channels of 80MS/s
>>>> floating-point complex data back to a computer. The pages for both
>>>> the 10GbE card and PCI-E card say they support 200MS/S in
>>>> full-duplex mode. Can they run at 320MS/s in one direction?
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>>
>>>>
>>>> Kevin Rigney
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> USRP-users@lists.ettus.com
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> 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/20161003/41151132/attachment-0001.html>
------------------------------
Message: 14
Date: Mon, 3 Oct 2016 11:22:37 -0700
From: Marcus M?ller <marcus.muel...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] YateBTS+USRP B200
Message-ID: <4b3764a5-7316-8317-847b-7b8f08b54...@ettus.com>
Content-Type: text/plain; charset="windows-1252"
Does that mean you've solved your permission problems?
Best regards,
Marcus
On 10/03/2016 11:19 AM, ayush gupta via USRP-users wrote:
>
> Hello All,
>
> Have anyone here used USRP B200 with yateBTS??!
> If yes please share the
> Version information of yate and Yatebts working with usrpb200
> Also the os and uhd version.
>
> Thanks
> Ayush Gupta
>
>
>
> _______________________________________________
> 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/20161003/5f9a6647/attachment-0001.html>
------------------------------
Message: 15
Date: Mon, 3 Oct 2016 11:43:07 -0700
From: Marcus M?ller <marcus.muel...@ettus.com>
To: ayush gupta <guptaayus...@gmail.com>, usrp-users
<usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] YateBTS+USRP B200
Message-ID: <47588dd6-5aac-ddca-b969-35dfda121...@ettus.com>
Content-Type: text/plain; charset="utf-8"
Yes, these are valid concerns, but as long as your installation can't
access necessary files, there's nothing that using different versions
can fix. You'll need to fix your file permissions, in any case. It's not
hard, it's just standard linux administration!
Best regards,
Marcus
On 10/03/2016 11:41 AM, ayush gupta wrote:
>
> I found out that yate and Yatebts must be of correct version to work
> together
> And uhd version used is most probably
> 3.10 but let's see if someone have made it work
>
>
> On Oct 3, 2016 11:53 PM, "Marcus M?ller via USRP-users"
> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote:
>
> Does that mean you've solved your permission problems?
>
> Best regards,
>
> Marcus
>
>
> On 10/03/2016 11:19 AM, ayush gupta via USRP-users wrote:
>>
>> Hello All,
>>
>> Have anyone here used USRP B200 with yateBTS??!
>> If yes please share the
>> Version information of yate and Yatebts working with usrpb200
>> Also the os and uhd version.
>>
>> Thanks
>> Ayush Gupta
>>
>>
>>
>> _______________________________________________
>> 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/20161003/f9e0ac72/attachment-0001.html>
------------------------------
Message: 16
Date: Mon, 3 Oct 2016 14:45:38 -0400
From: Sam Carey <s...@samcarey.com>
To: "Long, Jeffrey P." <jpl...@mitre.org>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] RFNOC x310 image 2 bytes too large
Message-ID:
<cap85vd8cqnbtbkmzmzpjcp0nj0nrk75bxl2v+5+dqsgeeyv...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Sure. It's "Red Hat Enterprise Linux 6 64-bit" running Vivado 2015.4.1.
It's the ECE Linux server at Georgia Tech, so there may be some strange
system configurations that I'm not aware of.
In the past, it worked fine with Vivado 2015.2 on the same server. This
problem only started when rfnoc-devel switched over to 2015.4. No idea why.
-Sam
On Mon, Oct 3, 2016 at 10:04 AM, Long, Jeffrey P. <jpl...@mitre.org> wrote:
> Sam-
>
> Thanks for the reply. That sounds like an easy fix.
> Just out of curiosity can you tell me what OS, vivado version, etc. you
> are using.
>
> Thanks
> Jeff
>
> -----Original Message-----
> From: Sam Carey [mailto:s...@samcarey.com]
> Sent: Sunday, October 02, 2016 8:15 PM
> To: Long, Jeffrey P.; usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] RFNOC x310 image 2 bytes too large
>
> Hey Jeff,
>
> I?ve had the same problem for a while. My workaround was to simply edit
> the image loader so that it is ok with the larger file size.
> Just do a search for the smaller byte number in the uhd/host source code,
> change it to the larger byte number, and rebuild/reinstall uhd.
> Apparently, the byte count is not a strict requirement for image loading.
>
> -Sam
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161003/4083d9cd/attachment-0001.html>
------------------------------
Message: 17
Date: Mon, 3 Oct 2016 11:59:14 -0700
From: Marcus M?ller <marcus.muel...@ettus.com>
To: ayush gupta <guptaayus...@gmail.com>, usrp-users
<usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] YateBTS+USRP B200
Message-ID: <28ac758d-37b4-9f07-4134-2b6ccb3a6...@ettus.com>
Content-Type: text/plain; charset="utf-8"
Dear Ayush,
as said, I'm not a YateBTS expert. Please try to keep the list in CC:;
that way, you might get expert info. Again, this simply looks like a
setup problem, so I think that the right way to go here is to
investigate and look for more Yate-specific forums. What seems to be
going wrong has not much to do with USRP usage :)
Best regards,
Marcus
On 10/03/2016 11:55 AM, ayush gupta wrote:
> ryker@ryker-007:~$ sudo yate -vvv
> Yate (2936) is starting Tue Oct 4 00:21:41 2016
> Loaded module Javascript
> Loaded module OpenSSL - based on OpenSSL 1.0.2g 1 Mar 2016
> Loaded module iSAC floating point - based on WebRTC iSAC library
> version 4.3.0 (SPL version 1.2.0)
> Loaded module Call Forker
> Loaded module ZLib - using zlib library version 1.2.8
> Loaded module Call Generator
> Loaded module SIP Channel
> Loaded module WaveFile
> Loaded module MsgSniffer
> Loaded module ExtModule
> Loaded module YSOCKS
> Loaded module YJingle
> Loaded module CdrCombine
> Loaded module GVoice
> Loaded module YSTUN
> Loaded module iLBC - based on WebRTC iLBC library version 1.1.1
> Loaded module Analyzer
> Loaded module DumbChannel
> Loaded module YIAX
> Loaded module RegexRoute
> Loaded module GSM - based on libgsm-1.0.10
> Loaded module File Transfer
> Loaded module Conference
> Loaded module ToneDetector
> Loaded module CdrBuild
> Loaded module MOH
> Loaded module MUX
> Loaded module iLBC - based on iLBC reference library
> Loaded module CdrFile
> Loaded module PBX
> Loaded module FileInfo
> Loaded module YRTP
> Loaded module ToneGen
> Loaded module RManager
> Loaded module Call Parking
> Loaded module Analog Channel
> Loaded module Monitoring
> Loaded module Clustering
> Loaded module Queues Notify
> Loaded module Analog Detector
> Loaded module MGCP-GW
> Loaded module Cpu
> Loaded module MRCP
> Loaded module Heartbeat
> Loaded module GSM Transceiver
> Loaded module Queues
> Loaded module Registration from file
> Loaded module Cisco SM
> Loaded module Users Management
> Loaded module Accounts from file
> Loaded module SigTransport
> Loaded module MGCP-CA
> Loaded module DbWave
> Loaded module Subscriptions
> Loaded module SNMP Agent
> Loaded module Register for database
> Loaded module Radius client
> Loaded module CallCounters
> Loaded module SIP Features
> Loaded module Presence
> Loaded module YBTS
> Loaded module Event Logs
> Loaded module Signalling Channel
> Loaded module PBX for database
> Loaded module CCongestion
> Loaded module Late Router
> Loaded module Cache
> Loaded module BladeRF using libusb 1.0.20.11004 desc='http://libusb.info'
> Loaded module DummyRadio
> Initializing plugins
> Initializing module DummyRadio
> 2016-10-04_00:21:41.986635 <NOTE> Failed to open config file
> '/usr/local/etc/yate/dummyradio.conf', using defaults (2: No such file
> or directory)
> Initializing module BladeRF
> 2016-10-04_00:21:41.986720 <NOTE> Failed to open config file
> '/usr/local/etc/yate/ybladerf.conf', using defaults (2: No such file
> or directory)
> Initializing module Event Logs
> Initializing module Subscriptions
> Initializing module DbWave
> Initializing module MGCP Call Agent
> Initializing module SigTransport
> Initializing module Cisco SM
> Initializing module Cpu
> 2016-10-04_00:21:41.989365 <cpuload:NOTE> Updating CPU core number
> from 1 to 4
> Initializing module Analog Detector
> 2016-10-04_00:21:41.989645 <clustering:NOTE> Node name is empty,
> clustering disabled.
> Initializing module CdrFile
> Initializing module MUX
> Initializing module YSOCKS
> Initializing module ZLib
> Initializing module OpenSSL
> Initializing module Javascript
> Initializing module iSAC
> Initializing module Call Forker
> Initializing module Call Generator
> Initializing module SIP Channel
> Initializing module WaveFile
> Initializing module MsgSniffer
> Initializing module ExtModule
> 2016-10-04_00:21:42.305063 <sip:WARN> Listener(UDP,'general') unable
> to bind on :5060 - trying a random port. 98 'Address already in use'
> Loading external module 'gsm_auth.sh' ''
> Initializing module YJingle
> 2016-10-04_00:21:42.306778 <jingle:NOTE> Module initialized:
> localip=MISSING jingle_version=1 singletone=true pending_timeout=10000
> anonymous_caller=unk_caller codecs=mulaw,alaw
> Initializing module CdrCombine
> Initializing module GVoice
> Initializing module YSTUN
> Initializing module iLBC webrtc
> Initializing module Analyzer
> Initializing module DumbChannel
> DumbChannel initialized
> Initializing module YIAX
> 2016-10-04_00:21:42.307493 <iaxengine:WARN> Failed to bind socket on
> ':4569' - trying a random port. 98: 'Address already in use' [0xe14ff0]
> Initializing module RegexRoute
> Initializing module File Transfer
> Initializing module Conference
> Initializing module ToneDetector
> Initializing module CdrBuild
> Initializing module MOH
> Initializing module PBX
> Initializing module FileInfo
> Initializing module YRTP
> Initializing module ToneGen
> Initializing module RManager
> 2016-10-04_00:21:42.380203 <RManager:GOON> Failed to bind to
> 127.0.0.1:5038 <http://127.0.0.1:5038> : Address already in use
> Initializing module Call Parking
> Initializing module Analog Channel
> Initializing module Monitoring
> Initializing module Queues Notify
> Initializing module MGCP Gateway
> Initializing module MrcpSpeech
> Initializing module GSM Transceiver
> Initializing module Queues for database
> Initializing module Register from file
> Initializing module Users Management
> Initializing module Accounts from file
> Initializing module SNMP Agent
> Initializing module Register for database
> Initializing module Radius client
> 2016-10-04_00:21:42.393614 <yradius:NOTE> Local address not set or
> invalid. Radius functions disabled
> Initializing module SIP Features
> Initializing module Presence
> Initializing module YBTS
> Initializing module Signalling Channel
> 2016-10-04_00:21:42.411646 <sig:NOTE> Section 'tcapuser_test'.
> Unknown/missing type '(null)'
> Initializing module PBX for database
> Initializing module CCongestion
> Initializing module Late Router
> Initializing module Cache
> Initialization complete
> 2016-10-04_00:21:42.412192 <ybts:NOTE> State changed Idle -> Starting
> restart counter 1/10
> 2016-10-04_00:21:42.412849 <ybts:NOTE> State changed Starting ->
> WaitHandshake
> 2016-10-04_00:21:42.413048 <javascript:WARN> Trying to load script
> 'nib' dynamically, but it was already loaded from configuration file
> 2016-10-04_00:21:42.413064 <ybts:WARN> Failed to load script='nib',
> error='Failed to load script from file 'nib.js'
> '
> *Yate engine is initialized and starting up
> Failed to change directory to '/server/bts': 2 No such file or directory
> Failed to execute '/server/bts/mbts': 2 No such file or directory
> 2016-10-04_00:21:42.991767 <cpuload:NOTE> Updating CPU core number
> from 1 to 4
> 2016-10-04_00:21:45.972648 <ybts:NOTE> Peer pid 2968 vanished
> 2016-10-04_00:21:46.977625 <ybts:NOTE> 'shutdown' command failed
> 2016-10-04_00:21:46.998149 <ybts:NOTE> State changed WaitHandshake -> Idle
> 2016-10-04_00:21:47.976700 <ybts:NOTE> State changed Idle -> Starting
> restart counter 2/10
> 2016-10-04_00:21:47.978271 <ybts:NOTE> State changed Starting ->
> WaitHandshake*
> Failed to change directory to '/server/bts': 2 No such file or directory
> Failed to execute '/server/bts/mbts': 2 No such file or directory
> 2016-10-04_00:21:50.987179 <ybts:NOTE> Peer pid 2974 vanished
> 2016-10-04_00:21:51.985437 <ybts:NOTE> 'shutdown' command failed
> 2016-10-04_00:21:52.005977 <ybts:NOTE> State changed WaitHandshake -> Idle
> 2016-10-04_00:21:52.990875 <ybts:NOTE> State changed Idle -> Starting
> restart counter 3/10
> 2016-10-04_00:21:52.992524 <ybts:NOTE> State changed Starting ->
> WaitHandshake
> Failed to change directory to '/server/bts': 2 No such file or directory
> Failed to execute '/server/bts/mbts': 2 No such file or directory
> 2016-10-04_00:21:55.992802 <ybts:NOTE> Peer pid 2979 vanished
> 2016-10-04_00:21:56.992888 <ybts:NOTE> 'shutdown' command failed
> 2016-10-04_00:21:57.013396 <ybts:NOTE> State changed WaitHandshake -> Idle
> 2016-10-04_00:21:57.993425 <ybts:NOTE> State changed Idle -> Starting
> restart counter 4/10
> 2016-10-04_00:21:57.994975 <ybts:NOTE> State changed Starting ->
> WaitHandshake
> Failed to change directory to '/server/bts': 2 No such file or directory
> Failed to execute '/server/bts/mbts': 2 No such file or directory
> 2016-10-04_00:22:00.996239 <ybts:NOTE> Peer pid 2984 vanished
> 2016-10-04_00:22:01.995965 <ybts:NOTE> 'shutdown' command failed
> 2016-10-04_00:22:02.016462 <ybts:NOTE> State changed WaitHandshake -> Idle
> 2016-10-04_00:22:02.996294 <ybts:NOTE> State changed Idle -> Starting
> restart counter 5/10
> 2016-10-04_00:22:02.997976 <ybts:NOTE> State changed Starting ->
> WaitHandshake
> Failed to change directory to '/server/bts': 2 No such file or directory
> Failed to execute '/server/bts/mbts': 2 No such file or directory
> 2016-10-04_00:22:05.999015 <ybts:NOTE> Peer pid 2989 vanished
> 2016-10-04_00:22:06.997831 <ybts:NOTE> 'shutdown' command failed
> 2016-10-04_00:22:07.018315 <ybts:NOTE> State changed WaitHandshake -> Idle
> 2016-10-04_00:22:08.000981 <ybts:NOTE> State changed Idle -> Starting
> restart counter 6/10
> 2016-10-04_00:22:08.002523 <ybts:NOTE> State changed Starting ->
> WaitHandshake
> Failed to change directory to '/server/bts': 2 No such file or directory
> Failed to execute '/server/bts/mbts': 2 No such file or directory
> 2016-10-04_00:22:10.999467 <ybts:NOTE> Peer pid 2994 vanished
> 2016-10-04_00:22:12.002005 <ybts:NOTE> 'shutdown' command failed
> 2016-10-04_00:22:12.022525 <ybts:NOTE> State changed WaitHandshake -> Idle
> 2016-10-04_00:22:13.000922 <ybts:NOTE> State changed Idle -> Starting
> restart counter 7/10
> 2016-10-04_00:22:13.002556 <ybts:NOTE> State changed Starting ->
> WaitHandshake
> Failed to change directory to '/server/bts': 2 No such file or directory
> Failed to execute '/server/bts/mbts': 2 No such file or directory
> 2016-10-04_00:22:16.001988 <ybts:NOTE> Peer pid 2999 vanished
> 2016-10-04_00:22:17.002712 <ybts:NOTE> 'shutdown' command failed
> 2016-10-04_00:22:17.023253 <ybts:NOTE> State changed WaitHandshake -> Idle
> 2016-10-04_00:22:18.001956 <ybts:NOTE> State changed Idle -> Starting
> restart counter 8/10
> 2016-10-04_00:22:18.003556 <ybts:NOTE> State changed Starting ->
> WaitHandshake
> Failed to change directory to '/server/bts': 2 No such file or directory
> Failed to execute '/server/bts/mbts': 2 No such file or directory
> 2016-10-04_00:22:21.000545 <ybts:NOTE> Peer pid 3004 vanished
> 2016-10-04_00:22:22.000631 <ybts:NOTE> 'shutdown' command failed
> 2016-10-04_00:22:22.021162 <ybts:NOTE> State changed WaitHandshake -> Idle
> 2016-10-04_00:22:23.001754 <ybts:NOTE> State changed Idle -> Starting
> restart counter 9/10
> 2016-10-04_00:22:23.003152 <ybts:NOTE> State changed Starting ->
> WaitHandshake
> Failed to change directory to '/server/bts': 2 No such file or directory
> Failed to execute '/server/bts/mbts': 2 No such file or directory
> 2016-10-04_00:22:25.999941 <ybts:NOTE> Peer pid 3009 vanished
> 2016-10-04_00:22:27.000152 <ybts:NOTE> 'shutdown' command failed
> 2016-10-04_00:22:27.020672 <ybts:NOTE> State changed WaitHandshake -> Idle
> 2016-10-04_00:22:28.004377 <ybts:NOTE> State changed Idle -> Starting
> restart counter 10/10
> 2016-10-04_00:22:28.005847 <ybts:NOTE> State changed Starting ->
> WaitHandshake
> Failed to change directory to '/server/bts': 2 No such file or directory
> Failed to execute '/server/bts/mbts': 2 No such file or directory
> 2016-10-04_00:22:31.001697 <ybts:NOTE> Peer pid 3014 vanished
> 2016-10-04_00:22:32.002507 <ybts:NOTE> 'shutdown' command failed
> 2016-10-04_00:22:32.023007 <ybts:NOTE> State changed WaitHandshake -> Idle
> 2016-10-04_00:22:33.001563 <ybts:GOON> Restart index reached maximum
> value 10. Exiting ...
> Yate engine is shutting down with code 125
> 2016-10-04_00:22:34.245030 <NOTE> Soft cancelling 4 running threads
> 2016-10-04_00:22:34.260408 <MILD> Hard cancelling 1 remaining threads
> 2016-10-04_00:22:34.260465 <WARN> ThreadPrivate 'ExtMod Receiver'
> terminating pthread 0xe07028 [0xe07010]
> 2016-10-04_00:22:34.260788 <WARN> Process 2945 has not exited on
> closing stdin - we'll kill it
> 2016-10-04_00:22:34.261007 <WARN> Process 2945 has still not exited yet?
> Unloading external module 'gsm_auth.sh' ''
> Unloading module Cache
> Unloading module Late Router
> Unloading module CCongestion
> Unloading module PBX for database
> Unloading module Signalling Channel
> Unloading module YBTS
> Unloaded module Presence
> Unloading module SIP Features
> Unloading module CallCounters
> Unloaded module Radius client
> Unloading module Register for database
> 2016-10-04_00:22:34.267788 <GOON> Unloading 'ysnmpagent' removed 0 out
> of 1 plugins
> Unloaded module Users Management
> Unload module Registration from file
> Unloading module Queues
> 2016-10-04_00:22:34.268156 <GOON> Unloading 'gsmtrx' removed 0 out of
> 1 plugins
> Unloading module Heartbeat
> Unloading module MRCP
> 2016-10-04_00:22:34.268295 <GOON> Unloading 'mgcpgw' removed 0 out of
> 1 plugins
> Unloading module Queues Notify
> Unloaded module Monitoring
> 2016-10-04_00:22:34.268429 <GOON> Unloading 'analog' removed 0 out of
> 1 plugins
> Unloading module Call Parking
> Unloading module RManager
> Unloading module ToneGen
> Unloading module YRTP
> Unloading module FileInfo
> Unloading module PBX
> Unloading module iLBC with 0 codecs still in use
> Unloading module MOH
> Unloading module CdrBuild
> 2016-10-04_00:22:34.270451 <GOON> Unloading 'tonedetect' removed 0 out
> of 1 plugins
> Unloading module Conference
> Unloading module GSM with 0 codecs still in use
> Unloading module YIAX
> Unloading module DumbChannel
> Unloading module Analyzer
> Unloading module iLBC webrtc with 0 codecs still in use
> Unloading module YSTUN
> Unloading module GVoice
> Unloading module CdrCombine
> 2016-10-04_00:22:34.271260 <GOON> Unloading 'yjinglechan' removed 0
> out of 1 plugins
> Unloading module ExtModule
> 2016-10-04_00:22:34.271454 <GOON> Unloading 'ysipchan' removed 0 out
> of 1 plugins
> Unloading module Call Generator, clearing 0 calls
> Unloading module Call Forker
> Unloading module iSAC with 0 codecs still in use
> 2016-10-04_00:22:34.271692 <GOON> Unloading 'javascript' removed 0 out
> of 1 plugins
> Unloading module OpenSSL
> Unloading module ZLib
> 2016-10-04_00:22:34.271952 <GOON> Unloading 'ysockschan' removed 0 out
> of 1 plugins
> Unloading module File Transfer
> Unloading module MUX
> Unloading module CdrFile
> Unloading module Clustering
> Unloading module Analog Detector
> Unloading module Cpu
> Unloading module Cisco SM
> Unloading module SigTransport
> Unloading module MGCP-GW
> Unloading module MGCP-CA
> Unloading module ToneDetector
> Unloading module SIP Channel
> 2016-10-04_00:22:34.272477 <GOON> Unloading 'mgcpca' removed 4 out of
> 1 plugins
> Unloading module Subscriptions
> Unloading module Event Logs
> Unloading module BladeRF
> Unloading module DummyRadio
> 2016-10-04_00:22:34.273082 <GOON> Exiting with 0 locked mutexes and 6
> plugins loaded!
> Yate (2936) is stopping Tue Oct 4 00:22:34 2016
> Unloaded module SNMP Agent
> Unloading module GSM Transceiver
> Unloading module Analog Channel
> Unloading module YJingle
> Unloading module YSOCKS
> Unloading module Javascript
>
>
> can you tell me whats going on in highlighted log part?
>
>
> On Tue, Oct 4, 2016 at 12:13 AM, Marcus M?ller
> <marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com>> wrote:
>
> Yes, these are valid concerns, but as long as your installation
> can't access necessary files, there's nothing that using different
> versions can fix. You'll need to fix your file permissions, in any
> case. It's not hard, it's just standard linux administration!
>
> Best regards,
>
> Marcus
>
>
> On 10/03/2016 11:41 AM, ayush gupta wrote:
>>
>> I found out that yate and Yatebts must be of correct version to
>> work together
>> And uhd version used is most probably
>> 3.10 but let's see if someone have made it work
>>
>>
>> On Oct 3, 2016 11:53 PM, "Marcus M?ller via USRP-users"
>> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>>
>> wrote:
>>
>> Does that mean you've solved your permission problems?
>>
>> Best regards,
>>
>> Marcus
>>
>>
>> On 10/03/2016 11:19 AM, ayush gupta via USRP-users wrote:
>>>
>>> Hello All,
>>>
>>> Have anyone here used USRP B200 with yateBTS??!
>>> If yes please share the
>>> Version information of yate and Yatebts working with usrpb200
>>> Also the os and uhd version.
>>>
>>> Thanks
>>> Ayush Gupta
>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20161003/15006bf0/attachment-0001.html>
------------------------------
Message: 18
Date: Mon, 3 Oct 2016 12:17:00 -0700
From: Richard Bell <richard.be...@gmail.com>
To: "usrp-users@lists.ettus.com" <USRP-users@lists.ettus.com>
Subject: [USRP-users] Block Diagram Publish
Message-ID:
<cammoi3t8qx02+datas1r1boxfu6m_veq03s9sazi+hu5wge...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
I'm in the midst of publishing a paper that uses the USRP N210 block
diagram attached. This was distributed on the mailing list by someone at
Ettus a long while back. I can't find the block diagram on the Ettus
website myself.
Is this diagram copyrighted or covered under a creative commons license, or
some other license? May I publish this block diagram freely?
Thanks,
Rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161003/704adc18/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: WBX-N210 Block Diagram.png
Type: image/png
Size: 64511 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161003/704adc18/attachment-0001.png>
------------------------------
Message: 19
Date: Mon, 3 Oct 2016 19:17:13 +0000
From: "Long, Jeffrey P." <jpl...@mitre.org>
To: Sam Carey <s...@samcarey.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] RFNOC x310 image 2 bytes too large
Message-ID:
<dm5pr09mb1372aabad12d1be56038652cd9...@dm5pr09mb1372.namprd09.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
OK weird. My problem happens only with my 16 LTS Ubuntu machine. 12LTS works
fine but I have not tried 14. I did the patch to 2015.4.2 but that did not seem
to help.
Oh well, thanks for the fix.
Jeff
From: Sam Carey [mailto:s...@samcarey.com]
Sent: Monday, October 03, 2016 2:46 PM
To: Long, Jeffrey P.
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] RFNOC x310 image 2 bytes too large
Sure. It's "Red Hat Enterprise Linux 6 64-bit" running Vivado 2015.4.1.
It's the ECE Linux server at Georgia Tech, so there may be some strange system
configurations that I'm not aware of.
In the past, it worked fine with Vivado 2015.2 on the same server. This problem
only started when rfnoc-devel switched over to 2015.4. No idea why.
-Sam
On Mon, Oct 3, 2016 at 10:04 AM, Long, Jeffrey P.
<jpl...@mitre.org<mailto:jpl...@mitre.org>> wrote:
Sam-
Thanks for the reply. That sounds like an easy fix.
Just out of curiosity can you tell me what OS, vivado version, etc. you are
using.
Thanks
Jeff
-----Original Message-----
From: Sam Carey [mailto:s...@samcarey.com<mailto:s...@samcarey.com>]
Sent: Sunday, October 02, 2016 8:15 PM
To: Long, Jeffrey P.;
usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] RFNOC x310 image 2 bytes too large
Hey Jeff,
I?ve had the same problem for a while. My workaround was to simply edit the
image loader so that it is ok with the larger file size.
Just do a search for the smaller byte number in the uhd/host source code,
change it to the larger byte number, and rebuild/reinstall uhd.
Apparently, the byte count is not a strict requirement for image loading.
-Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161003/2d51a61a/attachment-0001.html>
------------------------------
Message: 20
Date: Mon, 3 Oct 2016 12:32:54 -0700
From: Ian Buckley <i...@ionconcepts.com>
To: Richard Bell <richard.be...@gmail.com>
Cc: "usrp-users@lists.ettus.com" <USRP-users@lists.ettus.com>
Subject: Re: [USRP-users] Block Diagram Publish
Message-ID:
<CAM_0ocFToyvhn00YGJjrGWoUXbPa+Evd082GZxPHd=x_su7...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
If I recall correct Rich, that diagram was part of an NI white-paper,
probably done by an NI apps guy rather than coming from the core Ettus
team. It may well have been me that posted it here, can't recall exactly.
I picked it up from here: http://www.ni.com/white-paper/14311/en/
I'd be utterly surprised if anyone cared if you use it verbatim assuming
you are discussing a project that utilizes the USRP, there's nothing there
that is not public domain.
-Ian
On Mon, Oct 3, 2016 at 12:17 PM, Richard Bell via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hello,
>
> I'm in the midst of publishing a paper that uses the USRP N210 block
> diagram attached. This was distributed on the mailing list by someone at
> Ettus a long while back. I can't find the block diagram on the Ettus
> website myself.
>
> Is this diagram copyrighted or covered under a creative commons license,
> or some other license? May I publish this block diagram freely?
>
> 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/20161003/bad8176a/attachment-0001.html>
------------------------------
Message: 21
Date: Mon, 3 Oct 2016 16:45:01 -0400
From: Sam Carey <s...@samcarey.com>
To: usrp-users@lists.ettus.com, marcus.muel...@ettus.com
Subject: Re: [USRP-users] TX/RX Fixed Signal Phase Synchronization
Message-ID:
<cap85vd-xgvhjcnf+j31gbw6hsccmdizts7a0u3q-k75aaa4...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hey Marcus,
Thanks for the reply!
And yes, I'm using 40dB of attenuation for the loopback :)
I'm actually not interested in a modem. I'm interested in
stepped-frequency, phase coherent radar.
I need to scan a series of frequencies between 500MHz and 5GHz. For each
frequency, I need to transmit a tone, simultaneously receive it, and
measure the phase offset.
This offset contains information about range, so it must be absolutely
consistent.
I realize I can make the hardware TX/RX phase offset consistent with timed
commands. The question is: how do I actually measure the offset at a given
frequency?
My GRC method was to to connect a SigSource block to a USRP:Sink and port 2
of a Conjugate Multiply block and a USRP:Source block to port 1. The result
should be a consistent phase offset. But this ignores the various buffers
between the hardware and software.
I suggested this design to Derek Kozel (who is currently away) and he said:
> "There is no meaning to comparing the output of signal source to the
> output of the USRP Source block. The GNU Radio scheduler, your operating
> system's various buffers, group delays in the radio, and many other effects
> will contribute to that producing a random offset every time you run even
> though the radios themselves may be perfectly synchronized."
So my question is, (specifically) how do I measure it, if not with GRC
blocks?
Also, I would really like some help with the under/overruns. I consistently
get them even with simpler flowgraphs and low sample rates.
For example, the flowgraph described above, with a SigSource, UHD: Source,
UHD: Sink, and Multiply Conjugate block will not run, even at 0.390625MS/s
which I think is the minimum samp_rate. It just floods the output with
"U"s. If I replace the multiply block with a null sink, I just get a burst
of "U"s at the begining and then they stop and the flowgraph continues.
Specs:
Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI
Express Gigabit Ethernet Controller (rev 06)
Memory: 16GB
CPU: 8 x "Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz"
So it seems my computer has plenty of power, so I don't know why I'm
getting so many over/underruns.
Sorry for sending two questions in one email.
Thanks for your help!
Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161003/93ff9ec6/attachment-0001.html>
------------------------------
Message: 22
Date: Tue, 4 Oct 2016 07:14:32 +0800
From: "Joe Y. Mambu" <jfk2...@aut.ac.nz>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Selling my E110
Message-ID:
<cap+d5oq41esrvxxye-l1mmxa+gbtgancgqkg2adnf6cfafq...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear all,
I'm selling my E110 for half the price. Bought from Ettus last year for
academic purpose
Please email jyy...@gmail.com if interested
On Oct 4, 2016 12:02 AM, <usrp-users-requ...@lists.ettus.com> wrote:
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. Re: RFNOC x310 image 2 bytes too large (Sam Carey)
2. Can the USRP B210 do passive scanning of WIFI? (John DeLeong)
3. Re: Can the USRP B210 do passive scanning of WIFI?
(Dave NotTelling)
4. Re: RFNOC x310 image 2 bytes too large (Long, Jeffrey P.)
5. Twin RX Bandwidth Requirements (Rigney, Kevin E)
----------------------------------------------------------------------
Message: 1
Date: Sun, 2 Oct 2016 20:14:32 -0400
From: Sam Carey <s...@samcarey.com>
To: jpl...@mitre.org, usrp-users@lists.ettus.com
Subject: Re: [USRP-users] RFNOC x310 image 2 bytes too large
Message-ID: <ec8a9c02-67ae-481f-be73-cea9fae3e...@samcarey.com>
Content-Type: text/plain; charset=utf-8
Hey Jeff,
I?ve had the same problem for a while. My workaround was to simply edit the
image loader so that it is ok with the larger file size.
Just do a search for the smaller byte number in the uhd/host source code,
change it to the larger byte number, and rebuild/reinstall uhd.
Apparently, the byte count is not a strict requirement for image loading.
-Sam
------------------------------
Message: 2
Date: Mon, 3 Oct 2016 16:30:00 +0800
From: John DeLeong <spirita...@gmail.com>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Can the USRP B210 do passive scanning of WIFI?
Message-ID:
<cac6kioze6kasfb8p-r8eugxyd_wlixpcb0-_35dfhorij2x...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
Can the USRP B210
a) do passive scanning of Wifi APs and Clients; and
b) do passive collection of Wifi packets off the air?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.
ettus.com/attachments/20161003/b3825c42/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 3 Oct 2016 08:44:21 -0400
From: Dave NotTelling <dmp250...@gmail.com>
To: John DeLeong <spirita...@gmail.com>
Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Can the USRP B210 do passive scanning of
WIFI?
Message-ID:
<cak6gvuoqpzgx0te9g-ya01ppz4dlp_oqpovrhyv7+kr02j0...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
John,
Check out https://github.com/bastibl/gr-ieee802-11
V/R,
-Dave
On Mon, Oct 3, 2016 at 4:30 AM, John DeLeong via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi,
>
> Can the USRP B210
> a) do passive scanning of Wifi APs and Clients; and
> b) do passive collection of Wifi packets off the air?
>
>
> _______________________________________________
> 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/20161003/b870419a/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 3 Oct 2016 14:04:23 +0000
From: "Long, Jeffrey P." <jpl...@mitre.org>
To: Sam Carey <s...@samcarey.com>, "usrp-users@lists.ettus.com"
<usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] RFNOC x310 image 2 bytes too large
Message-ID:
<DM5PR09MB13726CBAF03A940AE86B56F2D9C20@DM5PR09MB1372.
namprd09.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Sam-
Thanks for the reply. That sounds like an easy fix.
Just out of curiosity can you tell me what OS, vivado version, etc. you are
using.
Thanks
Jeff
-----Original Message-----
From: Sam Carey [mailto:s...@samcarey.com]
Sent: Sunday, October 02, 2016 8:15 PM
To: Long, Jeffrey P.; usrp-users@lists.ettus.com
Subject: Re: [USRP-users] RFNOC x310 image 2 bytes too large
Hey Jeff,
I?ve had the same problem for a while. My workaround was to simply edit the
image loader so that it is ok with the larger file size.
Just do a search for the smaller byte number in the uhd/host source code,
change it to the larger byte number, and rebuild/reinstall uhd.
Apparently, the byte count is not a strict requirement for image loading.
-Sam
------------------------------
Message: 5
Date: Mon, 3 Oct 2016 15:10:08 +0000
From: "Rigney, Kevin E" <kevin.e.rig...@lmco.com>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] Twin RX Bandwidth Requirements
Message-ID:
<48338491bd523a4f971c76bebd1aab5513f3c...@hvxdsp41.us.lmco.com>
Content-Type: text/plain; charset="us-ascii"
Hello,
What is the best data-link (PCI-E, 10GbE) to use with an X3X0 running two
Twin RX receivers at full rate? That setup would be two daughterboards
streaming a total of 4 channels of 80MS/s floating-point complex data back
to a computer. The pages for both the 10GbE card and PCI-E card say they
support 200MS/S in full-duplex mode. Can they run at 320MS/s in one
direction?
Thanks,
Kevin Rigney
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.
ettus.com/attachments/20161003/4527f3b3/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 74, Issue 3
*****************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161004/1bc5acdb/attachment-0001.html>
------------------------------
Message: 23
Date: Tue, 4 Oct 2016 07:21:49 +0800
From: "Joe Y. Mambu" <jfk2...@aut.ac.nz>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Selling my E110
Message-ID:
<CAP+d5OT_G7dcA1FnJjTC+=F0pMA0Qj=1tbzks5dfr2seg_f...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Or you can also email jfk2...@aut.ac.nz
On Oct 4, 2016 7:14 AM, "Joe Y. Mambu" <jfk2...@aut.ac.nz> wrote:
> Dear all,
> I'm selling my E110 for half the price. Bought from Ettus last year for
> academic purpose
> Please email jyy...@gmail.com if interested
> On Oct 4, 2016 12:02 AM, <usrp-users-requ...@lists.ettus.com> wrote:
>
> 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. Re: RFNOC x310 image 2 bytes too large (Sam Carey)
> 2. Can the USRP B210 do passive scanning of WIFI? (John DeLeong)
> 3. Re: Can the USRP B210 do passive scanning of WIFI?
> (Dave NotTelling)
> 4. Re: RFNOC x310 image 2 bytes too large (Long, Jeffrey P.)
> 5. Twin RX Bandwidth Requirements (Rigney, Kevin E)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 2 Oct 2016 20:14:32 -0400
> From: Sam Carey <s...@samcarey.com>
> To: jpl...@mitre.org, usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] RFNOC x310 image 2 bytes too large
> Message-ID: <ec8a9c02-67ae-481f-be73-cea9fae3e...@samcarey.com>
> Content-Type: text/plain; charset=utf-8
>
> Hey Jeff,
>
> I?ve had the same problem for a while. My workaround was to simply edit
> the image loader so that it is ok with the larger file size.
> Just do a search for the smaller byte number in the uhd/host source code,
> change it to the larger byte number, and rebuild/reinstall uhd.
> Apparently, the byte count is not a strict requirement for image loading.
>
> -Sam
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 3 Oct 2016 16:30:00 +0800
> From: John DeLeong <spirita...@gmail.com>
> To: usrp-users@lists.ettus.com
> Subject: [USRP-users] Can the USRP B210 do passive scanning of WIFI?
> Message-ID:
> <cac6kioze6kasfb8p-r8eugxyd_wlixpcb0-_35dfhorij2x...@mail.gm
> ail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi,
>
> Can the USRP B210
> a) do passive scanning of Wifi APs and Clients; and
> b) do passive collection of Wifi packets off the air?
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.
> com/attachments/20161003/b3825c42/attachment-0001.html>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 3 Oct 2016 08:44:21 -0400
> From: Dave NotTelling <dmp250...@gmail.com>
> To: John DeLeong <spirita...@gmail.com>
> Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
> Subject: Re: [USRP-users] Can the USRP B210 do passive scanning of
> WIFI?
> Message-ID:
> <CAK6GVuOQPzGx0Te9g-ya01ppZ4dLp_oqpoVRHYv7+Kr02J0JPw@mail.
> gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> John,
>
> Check out https://github.com/bastibl/gr-ieee802-11
>
> V/R,
>
> -Dave
>
> On Mon, Oct 3, 2016 at 4:30 AM, John DeLeong via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> > Hi,
> >
> > Can the USRP B210
> > a) do passive scanning of Wifi APs and Clients; and
> > b) do passive collection of Wifi packets off the air?
> >
> >
> > _______________________________________________
> > 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/20161003/b870419a/attachment-0001.html>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 3 Oct 2016 14:04:23 +0000
> From: "Long, Jeffrey P." <jpl...@mitre.org>
> To: Sam Carey <s...@samcarey.com>, "usrp-users@lists.ettus.com"
> <usrp-users@lists.ettus.com>
> Subject: Re: [USRP-users] RFNOC x310 image 2 bytes too large
> Message-ID:
> <DM5PR09MB13726CBAF03A940AE86B56F2D9C20@DM5PR09MB1372.namprd
> 09.prod.outlook.com>
>
> Content-Type: text/plain; charset="utf-8"
>
> Sam-
>
> Thanks for the reply. That sounds like an easy fix.
> Just out of curiosity can you tell me what OS, vivado version, etc. you
> are using.
>
> Thanks
> Jeff
>
> -----Original Message-----
> From: Sam Carey [mailto:s...@samcarey.com]
> Sent: Sunday, October 02, 2016 8:15 PM
> To: Long, Jeffrey P.; usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] RFNOC x310 image 2 bytes too large
>
> Hey Jeff,
>
> I?ve had the same problem for a while. My workaround was to simply edit
> the image loader so that it is ok with the larger file size.
> Just do a search for the smaller byte number in the uhd/host source code,
> change it to the larger byte number, and rebuild/reinstall uhd.
> Apparently, the byte count is not a strict requirement for image loading.
>
> -Sam
>
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 3 Oct 2016 15:10:08 +0000
> From: "Rigney, Kevin E" <kevin.e.rig...@lmco.com>
> To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
> Subject: [USRP-users] Twin RX Bandwidth Requirements
> Message-ID:
> <48338491bd523a4f971c76bebd1aab5513f3c...@hvxdsp41.us.lmco.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Hello,
>
> What is the best data-link (PCI-E, 10GbE) to use with an X3X0 running two
> Twin RX receivers at full rate? That setup would be two daughterboards
> streaming a total of 4 channels of 80MS/s floating-point complex data back
> to a computer. The pages for both the 10GbE card and PCI-E card say they
> support 200MS/S in full-duplex mode. Can they run at 320MS/s in one
> direction?
>
> Thanks,
>
> Kevin Rigney
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.
> com/attachments/20161003/4527f3b3/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 74, Issue 3
> *****************************************
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161004/063eb456/attachment-0001.html>
------------------------------
Message: 24
Date: Mon, 3 Oct 2016 17:21:25 -0700
From: Marcus M?ller <marcus.muel...@ettus.com>
To: Sam Carey <s...@samcarey.com>, usrp-users@lists.ettus.com
Subject: Re: [USRP-users] TX/RX Fixed Signal Phase Synchronization
Message-ID: <2f774dd7-9148-974f-f125-7689063d7...@ettus.com>
Content-Type: text/plain; charset="utf-8"
Hi Sam,
the whole point in having the timestamps in the RX metadata as well as
the ability set the transmit time in the TX metadata is to have an
adjustable TX/RX delay == phase! By letting the hardware define the
exact time when to TX and RX the first sample, the flexible buffering
effects are eliminated ? and you can then, based on (sample
number)/(sampling rate)*(recv start time - transmit start time)
calculate the time offset, no matter how much buffering there is.
Of course, you'd still have to calculate the absolute phase difference
for a single given target based on observation (there's cables and
antennas involved here, anyway, so this is necessary in any case), but
with that single target, for any fixed frequency and any fixed timestamp
delta, your phase delay should be calibrated :)
Now, the underruns at low sampling rates aren't a good thing, but then
again, I don't know exactly what you're doing to generate the TX signal
? and if you just multiply the RX with the TX signal, GNU Radio will
force the GNU Radio signal source to halt as soon as its output buffer
is full, which will happen pretty quickly if you don't set the RX start
time to something sufficiently before the TX start time. Since there
can't be any signal generated, the USRP can't get that signal, and
hence, it'll generate Underrun notifications.
Best regards,
Marcus
On 10/03/2016 01:45 PM, Sam Carey wrote:
> Hey Marcus,
>
> Thanks for the reply!
> And yes, I'm using 40dB of attenuation for the loopback :)
>
> I'm actually not interested in a modem. I'm interested in
> stepped-frequency, phase coherent radar.
> I need to scan a series of frequencies between 500MHz and 5GHz. For
> each frequency, I need to transmit a tone, simultaneously receive it,
> and measure the phase offset.
> This offset contains information about range, so it must be absolutely
> consistent.
>
> I realize I can make the hardware TX/RX phase offset consistent with
> timed commands. The question is: how do I actually measure the offset
> at a given frequency?
> My GRC method was to to connect a SigSource block to a USRP:Sink and
> port 2 of a Conjugate Multiply block and a USRP:Source block to port
> 1. The result should be a consistent phase offset. But this ignores
> the various buffers between the hardware and software.
> I suggested this design to Derek Kozel (who is currently away) and he
> said:
>
> "There is no meaning to comparing the output of signal source to
> the output of the USRP Source block. The GNU Radio scheduler, your
> operating system's various buffers, group delays in the radio, and
> many other effects will contribute to that producing a random
> offset every time you run even though the radios themselves may be
> perfectly synchronized."
>
> So my question is, (specifically) how do I measure it, if not with GRC
> blocks?
>
> Also, I would really like some help with the under/overruns. I
> consistently get them even with simpler flowgraphs and low sample rates.
> For example, the flowgraph described above, with a SigSource, UHD:
> Source, UHD: Sink, and Multiply Conjugate block will not run, even
> at 0.390625MS/s which I think is the minimum samp_rate. It just floods
> the output with "U"s. If I replace the multiply block with a null
> sink, I just get a burst of "U"s at the begining and then they stop
> and the flowgraph continues.
>
> Specs:
> Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411
> PCI Express Gigabit Ethernet Controller (rev 06)
> Memory: 16GB
> CPU: 8 x "Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz"
>
> So it seems my computer has plenty of power, so I don't know why I'm
> getting so many over/underruns.
>
> Sorry for sending two questions in one email.
>
> Thanks for your help!
> Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161003/8bc2e3a0/attachment-0001.html>
------------------------------
Message: 25
Date: Tue, 4 Oct 2016 11:35:08 +1100
From: Walter Maguire <wmagu...@iinet.net.au>
To: Jonathon Pendlum <jonathon.pend...@ettus.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Issue with DmaFIFO uhd::lookup_error'
Message-ID: <85e57d94-e9a3-ea6d-bc01-74d1e52a9...@iinet.net.au>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hi Jonathan,
I would be grateful if you would elaborate more on how this might be
done. I can understand how a MIG would work on the X300. What confuses
me regarding the E310 is that the Zynq PS has access to the DDR3.
Therefore is the access to the DDR shared with the PS system or does the
E310 have an additional separate DDR3 memory?
Regarding the ip in the E300/ip directory I don seem able to open it
with Vivado. I have tried to add the contents of the build-ip directory
as a repository without success. Other than Xilinx's documentation are
there any other Ettus documents which cover this.
Regards,
Walter
On 1/10/2016 5:40 AM, Jonathon Pendlum wrote:
> Hi Walter,
>
> The DMA FIFO RFNoC block is not a normal rfnoc block. It is meant to
> interface with DRAM via a Xilinx MIG instance. You can look at
> x300_core.v to see how it should be used. On the E310, we have a mig
> instance in the e300/ip you can use.
>
>
>
> Jonathon
>
> On Tue, Sep 27, 2016 at 11:38 PM, Walter Maguire via USRP-users
> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote:
>
> Hi all
>
> I am using this commit c41b8330f7d700feeae4819e7f7241fe3fd2bc7b on
> the rfnoc-devel branch.
>
> This should be the top of the commits.
>
> If I build the standard FPGA set with this commit all is fine.
> However, if I modify file rfnoc_ce_auto_inst_e310.v to have only 3
> CEs as shown below and rebuild the uhd_usrp_probe command fails
> as shown below.
>
> root@ettus-e3xx-sg1:~# uhd_usrp_probe --init-only
> linux; GNU C++ version 4.9.2; Boost_105700;
> UHD_004.000.000.rfnoc-devel-641-g8773fb2c
>
> -- Loading FPGA image: /usr/share/uhd/images/usrp_e310_fpga.bit...
> done
> -- Initializing core control (global registers)...
> -- Performing register loopback test... pass
> -- Initializing AD9361 using hard SPI core...OK
> -- [RFNOC] ------- Block Setup -----------
> -- [E300] Setting up dest map for host ep 0 to be stream 0
> -- Setting up NoC-Shell Control for port #0 (SID: 00:00>02:10)...O
> -- Port 16: Found NoC-Block with ID 12AD100000000000.
> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/radio_e3xx.xml
> -- [E300] Setting up dest map for host ep 1 to be stream 1
> -- Setting up NoC-Shell Control for port #1 (SID: 00:01>02:11)...OK
> -- [RFNoC Factory] block_ctrl_base::make()
> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/radio_e3xx.xml
> -- [RFNoC Factory] Using controller key 'E3XXRadio' and block name
> 'Radio'
> -- block_ctrl_base()
> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/radio_e3xx.xml
> -- Found valid blockdef
> -- NOC ID: 0x12AD100000000000 Block ID: 0/Radio_0
> -- [0/Radio_0] block_ctrl_base::clear()
> -- [0/Radio_0] node_ctrl_base::clear()
> -- [0/Radio_0] block_ctrl_base::_clear()
> -- [0/Radio_0] block_ctrl_base::_clear()
> -- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/in/0:
> type = 'sc16' pkt_size = '0' vlen = '0'
> -- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/in/1:
> type = 'sc16' pkt_size = '0' vlen = '0'
> -- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/out/0:
> type = 'sc16' pkt_size = '0' vlen = '0'
> -- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/out/1:
> type = 'sc16' pkt_size = '0' vlen = '0'
> -- [RFNoC Radio] Performing register loopback test... pass
> -- [RFNoC Radio] Performing register loopback test... pass
> -- [0/Radio_0] radio_ctrl_impl::_update_spp(): Requested spp: 364
> -- [0/Radio_0] radio_ctrl_impl::_update_spp(): Setting spp to: 364
> -- [0/Radio_0] e3xx_radio_ctrl_impl::ctor()
> -- Setting time source to internal
> -- [0/Radio_0] e3xx_radio_ctrl_impl::_update_gpio_state()
> -- [0/Radio_0] Creating internal GPIOs...
> -- [0/Radio_0] Setting tick rate...
> -- [RFNOC] ------- Block Setup -----------
> -- [E300] Setting up dest map for host ep 2 to be stream 2
> -- Setting up NoC-Shell Control for port #0 (SID: 00:02>02:20)...OK
> -- Port 32: Found NoC-Block with ID F1F0000000000000.
> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/fifo.xml
> -- [RFNoC Factory] block_ctrl_base::make()
> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/fifo.xml
> -- [RFNoC Factory] Using controller key 'Block' and block name 'FIFO'
> -- block_ctrl_base()
> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/fifo.xml
> -- Found valid blockdef
> -- NOC ID: 0xF1F0000000000000 Block ID: 0/FIFO_0
> -- [0/FIFO_0] block_ctrl_base::clear()
> -- [0/FIFO_0] node_ctrl_base::clear()
> -- [0/FIFO_0] block_ctrl_base::_clear()
> -- [0/FIFO_0] Adding port definition at xbar/FIFO_0/ports/in/0:
> type = '' pkt_size = '0' vlen = '0'
> -- [0/FIFO_0] Adding port definition at xbar/FIFO_0/ports/out/0:
> type = '' pkt_size = '0' vlen = '0'
> -- [RFNOC] ------- Block Setup -----------
> -- [E300] Setting up dest map for host ep 3 to be stream 3
> -- Setting up NoC-Shell Control for port #0 (SID: 00:03>02:30)...OK
> -- Port 48: Found NoC-Block with ID F1F0D00000000000.
> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/dma_fifo.xml
> -- [E300] Setting up dest map for host ep 4 to be stream 4
> -- Setting up NoC-Shell Control for port #1 (SID: 00:04>02:31)...OK
> -- [RFNoC Factory] block_ctrl_base::make()
> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/dma_fifo.xml
> -- [RFNoC Factory] Using controller key 'DmaFIFO' and block name
> 'DmaFIFO'
> -- block_ctrl_base()
> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/dma_fifo.xml
> -- Found valid blockdef
> -- NOC ID: 0xF1F0D00000000000 Block ID: 0/DmaFIFO_0
> -- [0/DmaFIFO_0] block_ctrl_base::clear()
> -- [0/DmaFIFO_0] node_ctrl_base::clear()
> -- [0/DmaFIFO_0] block_ctrl_base::_clear()
> -- [0/DmaFIFO_0] block_ctrl_base::_clear()
> terminate called after throwing an instance of 'uhd::lookup_error'
> what(): LookupError: Path not found in tree: /mboards/0/tx_dsps/0
> Aborted
>
> The changes to the rfnoc_ce_auto_inst_e310.v file are as follows
>
> localparam NUM_CE = 2; // Must be no more than 14 (2 ports
> taken by radio core & PS-PL DMA).
>
> wire [NUM_CE*64-1:0] ce_flat_o_tdata, ce_flat_i_tdata;
> wire [63:0] ce_o_tdata[0:NUM_CE-1], ce_i_tdata[0:NUM_CE-1];
> wire [NUM_CE-1:0] ce_o_tlast, ce_o_tvalid, ce_o_tready,
> ce_i_tlast, ce_i_tvalid, ce_i_tready;
> wire [63:0] ce_debug[0:NUM_CE-1];
>
> // Flattern CE tdata arrays
> genvar k;
> generate
> for (k = 0; k < NUM_CE; k = k + 1) begin
> assign ce_o_tdata[k] = ce_flat_o_tdata[k*64+63:k*64];
> assign ce_flat_i_tdata[k*64+63:k*64] = ce_i_tdata[k];
> end
> endgenerate
>
> wire ce_clk = radio_clk;
> wire ce_rst = radio_rst;
>
> noc_block_axi_fifo_loopback inst_noc_block_axi_fifo_loopback (
> .bus_clk(bus_clk), .bus_rst(bus_rst),
> .ce_clk(ce_clk), .ce_rst(ce_rst),
> .i_tdata(ce_o_tdata[0]), .i_tlast(ce_o_tlast[0]),
> .i_tvalid(ce_o_tvalid[0]), .i_tready(ce_o_tready[0]),
> .o_tdata(ce_i_tdata[0]), .o_tlast(ce_i_tlast[0]),
> .o_tvalid(ce_i_tvalid[0]), .o_tready(ce_i_tready[0]),
> .debug(ce_debug[0]));
>
>
> noc_block_axi_dma_fifo inst_noc_block_axi_dma_fifo (
> .bus_clk(bus_clk), .bus_rst(bus_rst),
> .ce_clk(ce_clk), .ce_rst(ce_rst),
> .i_tdata(ce_o_tdata[1]), .i_tlast(ce_o_tlast[1]),
> .i_tvalid(ce_o_tvalid[1]), .i_tready(ce_o_tready[1]),
> .o_tdata(ce_i_tdata[1]), .o_tlast(ce_i_tlast[1]),
> .o_tvalid(ce_i_tvalid[1]), .o_tready(ce_i_tready[1]),
> .debug(ce_debug[1]));
>
>
> I would be grateful for any feedback on this issue.
>
> Regards
>
>
> Walter
>
>
>
> _______________________________________________
> 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/20161004/2910fb94/attachment-0001.html>
------------------------------
Message: 26
Date: Tue, 4 Oct 2016 11:57:39 +1100
From: Walter Maguire <wmagu...@iinet.net.au>
To: Jonathon Pendlum <jonathon.pend...@ettus.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Issue with DmaFIFO uhd::lookup_error'
Message-ID: <5aebe7be-067c-7100-e04b-5017e2984...@iinet.net.au>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hi Jonathan,
I see from the E310 schematics that the E310 has a two DDR3 areas, one
connected to the PS (1GByte) and one connected to the FPGA PL (512
MByte). I assume the MIG works with the later? How is data captured in
the 512MByte area viewed by a Linux running on the PS? Would this be
the correct application use ie
1. Samples in -> DMA_FIFO->MIG->DDR3(512) // High speed capture
2. Samples Out DDR3(512)->(PL additional ip, ie FIFO, DMA Engine etc)
->PS->DDR3(1GByte) // Low speed analysis
Are stages 1 and 2 contained in the RFNoC Block once the MIG is added?
Regards
Walter
On 1/10/2016 5:40 AM, Jonathon Pendlum wrote:
> Hi Walter,
>
> The DMA FIFO RFNoC block is not a normal rfnoc block. It is meant to
> interface with DRAM via a Xilinx MIG instance. You can look at
> x300_core.v to see how it should be used. On the E310, we have a mig
> instance in the e300/ip you can use.
>
>
>
> Jonathon
>
> On Tue, Sep 27, 2016 at 11:38 PM, Walter Maguire via USRP-users
> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote:
>
> Hi all
>
> I am using this commit c41b8330f7d700feeae4819e7f7241fe3fd2bc7b on
> the rfnoc-devel branch.
>
> This should be the top of the commits.
>
> If I build the standard FPGA set with this commit all is fine.
> However, if I modify file rfnoc_ce_auto_inst_e310.v to have only 3
> CEs as shown below and rebuild the uhd_usrp_probe command fails
> as shown below.
>
> root@ettus-e3xx-sg1:~# uhd_usrp_probe --init-only
> linux; GNU C++ version 4.9.2; Boost_105700;
> UHD_004.000.000.rfnoc-devel-641-g8773fb2c
>
> -- Loading FPGA image: /usr/share/uhd/images/usrp_e310_fpga.bit...
> done
> -- Initializing core control (global registers)...
> -- Performing register loopback test... pass
> -- Initializing AD9361 using hard SPI core...OK
> -- [RFNOC] ------- Block Setup -----------
> -- [E300] Setting up dest map for host ep 0 to be stream 0
> -- Setting up NoC-Shell Control for port #0 (SID: 00:00>02:10)...O
> -- Port 16: Found NoC-Block with ID 12AD100000000000.
> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/radio_e3xx.xml
> -- [E300] Setting up dest map for host ep 1 to be stream 1
> -- Setting up NoC-Shell Control for port #1 (SID: 00:01>02:11)...OK
> -- [RFNoC Factory] block_ctrl_base::make()
> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/radio_e3xx.xml
> -- [RFNoC Factory] Using controller key 'E3XXRadio' and block name
> 'Radio'
> -- block_ctrl_base()
> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/radio_e3xx.xml
> -- Found valid blockdef
> -- NOC ID: 0x12AD100000000000 Block ID: 0/Radio_0
> -- [0/Radio_0] block_ctrl_base::clear()
> -- [0/Radio_0] node_ctrl_base::clear()
> -- [0/Radio_0] block_ctrl_base::_clear()
> -- [0/Radio_0] block_ctrl_base::_clear()
> -- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/in/0:
> type = 'sc16' pkt_size = '0' vlen = '0'
> -- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/in/1:
> type = 'sc16' pkt_size = '0' vlen = '0'
> -- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/out/0:
> type = 'sc16' pkt_size = '0' vlen = '0'
> -- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/out/1:
> type = 'sc16' pkt_size = '0' vlen = '0'
> -- [RFNoC Radio] Performing register loopback test... pass
> -- [RFNoC Radio] Performing register loopback test... pass
> -- [0/Radio_0] radio_ctrl_impl::_update_spp(): Requested spp: 364
> -- [0/Radio_0] radio_ctrl_impl::_update_spp(): Setting spp to: 364
> -- [0/Radio_0] e3xx_radio_ctrl_impl::ctor()
> -- Setting time source to internal
> -- [0/Radio_0] e3xx_radio_ctrl_impl::_update_gpio_state()
> -- [0/Radio_0] Creating internal GPIOs...
> -- [0/Radio_0] Setting tick rate...
> -- [RFNOC] ------- Block Setup -----------
> -- [E300] Setting up dest map for host ep 2 to be stream 2
> -- Setting up NoC-Shell Control for port #0 (SID: 00:02>02:20)...OK
> -- Port 32: Found NoC-Block with ID F1F0000000000000.
> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/fifo.xml
> -- [RFNoC Factory] block_ctrl_base::make()
> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/fifo.xml
> -- [RFNoC Factory] Using controller key 'Block' and block name 'FIFO'
> -- block_ctrl_base()
> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/fifo.xml
> -- Found valid blockdef
> -- NOC ID: 0xF1F0000000000000 Block ID: 0/FIFO_0
> -- [0/FIFO_0] block_ctrl_base::clear()
> -- [0/FIFO_0] node_ctrl_base::clear()
> -- [0/FIFO_0] block_ctrl_base::_clear()
> -- [0/FIFO_0] Adding port definition at xbar/FIFO_0/ports/in/0:
> type = '' pkt_size = '0' vlen = '0'
> -- [0/FIFO_0] Adding port definition at xbar/FIFO_0/ports/out/0:
> type = '' pkt_size = '0' vlen = '0'
> -- [RFNOC] ------- Block Setup -----------
> -- [E300] Setting up dest map for host ep 3 to be stream 3
> -- Setting up NoC-Shell Control for port #0 (SID: 00:03>02:30)...OK
> -- Port 48: Found NoC-Block with ID F1F0D00000000000.
> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/dma_fifo.xml
> -- [E300] Setting up dest map for host ep 4 to be stream 4
> -- Setting up NoC-Shell Control for port #1 (SID: 00:04>02:31)...OK
> -- [RFNoC Factory] block_ctrl_base::make()
> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/dma_fifo.xml
> -- [RFNoC Factory] Using controller key 'DmaFIFO' and block name
> 'DmaFIFO'
> -- block_ctrl_base()
> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/dma_fifo.xml
> -- Found valid blockdef
> -- NOC ID: 0xF1F0D00000000000 Block ID: 0/DmaFIFO_0
> -- [0/DmaFIFO_0] block_ctrl_base::clear()
> -- [0/DmaFIFO_0] node_ctrl_base::clear()
> -- [0/DmaFIFO_0] block_ctrl_base::_clear()
> -- [0/DmaFIFO_0] block_ctrl_base::_clear()
> terminate called after throwing an instance of 'uhd::lookup_error'
> what(): LookupError: Path not found in tree: /mboards/0/tx_dsps/0
> Aborted
>
> The changes to the rfnoc_ce_auto_inst_e310.v file are as follows
>
> localparam NUM_CE = 2; // Must be no more than 14 (2 ports
> taken by radio core & PS-PL DMA).
>
> wire [NUM_CE*64-1:0] ce_flat_o_tdata, ce_flat_i_tdata;
> wire [63:0] ce_o_tdata[0:NUM_CE-1], ce_i_tdata[0:NUM_CE-1];
> wire [NUM_CE-1:0] ce_o_tlast, ce_o_tvalid, ce_o_tready,
> ce_i_tlast, ce_i_tvalid, ce_i_tready;
> wire [63:0] ce_debug[0:NUM_CE-1];
>
> // Flattern CE tdata arrays
> genvar k;
> generate
> for (k = 0; k < NUM_CE; k = k + 1) begin
> assign ce_o_tdata[k] = ce_flat_o_tdata[k*64+63:k*64];
> assign ce_flat_i_tdata[k*64+63:k*64] = ce_i_tdata[k];
> end
> endgenerate
>
> wire ce_clk = radio_clk;
> wire ce_rst = radio_rst;
>
> noc_block_axi_fifo_loopback inst_noc_block_axi_fifo_loopback (
> .bus_clk(bus_clk), .bus_rst(bus_rst),
> .ce_clk(ce_clk), .ce_rst(ce_rst),
> .i_tdata(ce_o_tdata[0]), .i_tlast(ce_o_tlast[0]),
> .i_tvalid(ce_o_tvalid[0]), .i_tready(ce_o_tready[0]),
> .o_tdata(ce_i_tdata[0]), .o_tlast(ce_i_tlast[0]),
> .o_tvalid(ce_i_tvalid[0]), .o_tready(ce_i_tready[0]),
> .debug(ce_debug[0]));
>
>
> noc_block_axi_dma_fifo inst_noc_block_axi_dma_fifo (
> .bus_clk(bus_clk), .bus_rst(bus_rst),
> .ce_clk(ce_clk), .ce_rst(ce_rst),
> .i_tdata(ce_o_tdata[1]), .i_tlast(ce_o_tlast[1]),
> .i_tvalid(ce_o_tvalid[1]), .i_tready(ce_o_tready[1]),
> .o_tdata(ce_i_tdata[1]), .o_tlast(ce_i_tlast[1]),
> .o_tvalid(ce_i_tvalid[1]), .o_tready(ce_i_tready[1]),
> .debug(ce_debug[1]));
>
>
> I would be grateful for any feedback on this issue.
>
> Regards
>
>
> Walter
>
>
>
> _______________________________________________
> 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/20161004/5ab022f2/attachment-0001.html>
------------------------------
Message: 27
Date: Tue, 4 Oct 2016 13:22:52 +0200
From: Joan Olmos <ol...@tsc.upc.edu>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] B210 Initialization issue
Message-ID: <617e1427-8773-2bc7-01f5-65fb93a70...@tsc.upc.edu>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
I'm having problems during the initialization phase of the B210.
My issue is identical to what was previously reported in:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-October/016196.html
I cannot load the firmware and running "uhd_find_devices" reports:
linux; GNU C++ version 6.1.1 20160802; Boost_106100; UHD_003.009.005-0-unknown
-- Loading firmware image: /usr/local/share/uhd/images/usrp_b200_fw.hex...
UHD Error:
Device discovery error: EnvironmentError: IOError: Could not load firmware:
EnvironmentError: IOError: ihex_reader::read(): record hander returned
failure code
No UHD Devices Found
The firmware is in the right path and there are no permissions problems.
This is the output of dmesg after fresh reboot:
[ 4.539243] usb 4-1: new SuperSpeed USB device number 2 using xhci_hcd
[ 4.556928] usb 4-1: unable to get BOS descriptor
[ 4.558428] usb 4-1*: config 1 has an invalid descriptor of length 1, skipping
remainder of
the config*
[ 4.558498] usb 4-1*: config 1 has 1 interface, different from the descriptor's
value: 5*
[ 4.558568] usb 4-1*: config 1 interface 0 altsetting 1 has 0 endpoint
descriptors,
different from the interface descriptor's value: 9*
[ 4.558638] usb 4-1*: config 1 interface 0 has no altsetting 0*
[ 4.562428] usb 4-1: New USB device found, idVendor=2500, idProduct=0020
[ 4.562491] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 4.562554] usb 4-1: Product: USRP B200
[ 4.562614] usb 4-1: Manufacturer: Ettus Research LLC
[ 4.562675] usb 4-1: SerialNumber: 3?3us R
Should I RMA the board as was advised in that previously mentioned thread?
Thanks.
Joan Olmos
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161004/4ef10afb/attachment-0001.html>
------------------------------
Message: 28
Date: Tue, 04 Oct 2016 08:18:07 -0400
From: "Marcus D. Leech" <mle...@ripnet.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] B210 Initialization issue
Message-ID: <57f39dff.5090...@ripnet.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 10/04/2016 07:22 AM, Joan Olmos via USRP-users wrote:
> I'm having problems during the initialization phase of the B210.
>
> My issue is identical to what was previously reported in:
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-October/016196.html
>
> I cannot load the firmware and running "uhd_find_devices" reports:
>
> linux; GNU C++ version 6.1.1 20160802; Boost_106100; UHD_003.009.005-0-unknown
>
> -- Loading firmware image: /usr/local/share/uhd/images/usrp_b200_fw.hex...
> UHD Error:
> Device discovery error: EnvironmentError: IOError: Could not load
> firmware:
> EnvironmentError: IOError: ihex_reader::read(): record hander returned
> failure code
> No UHD Devices Found
>
> The firmware is in the right path and there are no permissions problems.
>
>
> This is the output of dmesg after fresh reboot:
>
> [ 4.539243]usb 4-1: new SuperSpeed USB device number 2 using xhci_hcd
> [ 4.556928]usb 4-1: unable to get BOS descriptor
> [ 4.558428]usb 4-1*: config 1 has an invalid descriptor of length 1,
> skipping remainder of the config*
> [ 4.558498]usb 4-1*: config 1 has 1 interface, different from the
> descriptor's value: 5*
> [ 4.558568]usb 4-1*: config 1 interface 0 altsetting 1 has 0 endpoint
> descriptors, different from the interface descriptor's value: 9*
> [ 4.558638]usb 4-1*: config 1 interface 0 has no altsetting 0*
> [ 4.562428]usb 4-1: New USB device found, idVendor=2500, idProduct=0020
> [ 4.562491]usb 4-1: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> [ 4.562554]usb 4-1: Product: USRP B200
> [ 4.562614]usb 4-1: Manufacturer: Ettus Research LLC
> [ 4.562675]usb 4-1: SerialNumber: 3?3us R
> Should I RMA the board as was advised in that previously mentioned thread?
> Thanks.
>
> Joan Olmos
>
>
The serial number is wonky, and there seems to be other USB-related
errors related to the card. I'd RMA it.
Send a note to supp...@ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161004/1e498723/attachment-0001.html>
------------------------------
Message: 29
Date: Tue, 4 Oct 2016 13:23:00 +0100
From: "Simon Brown" <si...@sdr-radio.com>
To: <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] B210 Initialization issue
Message-ID: <00c801d21e3a$0c26ede0$2474c9a0$@sdr-radio.com>
Content-Type: text/plain; charset="utf-8"
Check the USB3 cable first though ? don?t use extension cables either.
Simon Brown, GK4ELI
http://sdr-radio.com
From: USRP-users [mailto:usrp-users-boun...@lists.ettus.com] On Behalf Of
Marcus D. Leech via USRP-users
Sent: 04 October 2016 13:18
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] B210 Initialization issue
On 10/04/2016 07:22 AM, Joan Olmos via USRP-users wrote:
I'm having problems during the initialization phase of the B210.
My issue is identical to what was previously reported in:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-October/016196.html
I cannot load the firmware and running "uhd_find_devices" reports:
linux; GNU C++ version 6.1.1 20160802; Boost_106100; UHD_003.009.005-0-unknown
-- Loading firmware image: /usr/local/share/uhd/images/usrp_b200_fw.hex...
UHD Error:
Device discovery error: EnvironmentError: IOError: Could not load firmware:
EnvironmentError: IOError: ihex_reader::read(): record hander returned
failure code
No UHD Devices Found
The firmware is in the right path and there are no permissions problems.
This is the output of dmesg after fresh reboot:
[ 4.539243] usb 4-1: new SuperSpeed USB device number 2 using xhci_hcd
[ 4.556928] usb 4-1: unable to get BOS descriptor
[ 4.558428] usb 4-1: config 1 has an invalid descriptor of length 1,
skipping remainder of the config
[ 4.558498] usb 4-1: config 1 has 1 interface, different from the
descriptor's value: 5
[ 4.558568] usb 4-1: config 1 interface 0 altsetting 1 has 0 endpoint
descriptors, different from the interface descriptor's value: 9
[ 4.558638] usb 4-1: config 1 interface 0 has no altsetting 0
[ 4.562428] usb 4-1: New USB device found, idVendor=2500, idProduct=0020
[ 4.562491] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 4.562554] usb 4-1: Product: USRP B200
[ 4.562614] usb 4-1: Manufacturer: Ettus Research LLC
[ 4.562675] usb 4-1: SerialNumber: 3?3us R
Should I RMA the board as was advised in that previously mentioned thread?
Thanks.
Joan Olmos
The serial number is wonky, and there seems to be other USB-related errors
related to the card. I'd RMA it.
Send a note to supp...@ettus.com <mailto:supp...@ettus.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161004/01db4c7f/attachment-0001.html>
------------------------------
Message: 30
Date: Tue, 4 Oct 2016 15:07:36 +0200
From: Leonardo Sampaio Cardoso <leonardo.sampaio-card...@inria.fr>
To: Michael Dickens <michael.dick...@ettus.com>
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Problem B210 mac OS
Message-ID: <6ec59182-e807-4b31-97ee-404d97e65...@inria.fr>
Content-Type: text/plain; charset=utf-8
Hi Michael,
Installed uhd-devel and launched uhd_fft. Another problem arises:
RuntimeError:
GR-UHD detected ABI compatibility mismatch with UHD library.
GR-UHD was build against ABI: 3.10.0,
but UHD library reports ABI: 3.11.0
Suggestion: install an ABI compatible version of UHD,
or rebuild GR-UHD component against this ABI version.
At the same time I?ve been conducting tests on Sierra on another Mac (same
macports gnuradio and UHD install). The I try uhd_fft i get:
libc++abi.dylib: terminating with uncaught exception of type uhd::io_error:
EnvironmentError: IOError: usb rx6 transfer status: LIBUSB_TRANSFER_ERROR
Abort trap: 6
I dont know whats ABI, but I suppose its related to the issue. :)
Any clues?
Cheers,
Leo
> On 03 Oct 2016, at 19:27, Michael Dickens <michael.dick...@ettus.com> wrote:
>
> Hi Leonardo - OK; good data points.
>
> Can you try the "uhd-devel" port & see if it fixes anything? It's
> generally a drop-in replacement for "uhd". You can do this via:
> {{{
> sudo port -f deact uhd
> sudo port install uhd-devel
> }}}
>
> You'll want to re-link your project before trying again (probably don't
> need to, but it's a good idea).
>
> Ditto for trying "uhd_fft" multiple times again. Thanks! - MLD
>
> On Mon, Oct 3, 2016, at 01:18 PM, Leonardo Sampaio Cardoso wrote:
>> Until now I've never had issues with it, but recently I had to reinstall
>> my system and now hell broke loose!
>>
>> Yes, I?ve installed everything through macports. My reinstall is of last
>> week. If I?m not mistaken it is the release (stable) version.
>>
>> This is what ?uhd_config_info? tells me:
>>
>> Mac OS; Clang version 7.3.0 (clang-703.0.31); Boost_105900;
>> UHD_003.010.000.000-MacPorts-Release
>>
>> And, ?uhd_fft" gives me exactly the same problem.
------------------------------
Message: 31
Date: Tue, 04 Oct 2016 09:26:48 -0400
From: Michael Dickens <michael.dick...@ettus.com>
To: Leonardo Sampaio Cardoso <leonardo.sampaio-card...@inria.fr>
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Problem B210 mac OS
Message-ID:
<1475587608.1189545.745421201.17dc8...@webmail.messagingengine.com>
Content-Type: text/plain; charset="utf-8"
Hi Leonardo - Hmm ... OK; well, uhd-devel is not quite a drop-in
replacement for uhd I guess. Maybe it is with minor version changes
(e.g., 3.10.0 to 3.10.1)? Those clever UHD programmers at work, trying
to keep the ABIs honest ...
Anyway, you'll need to rebuild gnuradio to make use of the "new"
uhd-devel install. To make this easier, you can keep the release
versions as they are, and move to the devel versions for the latest
code:
{{{
sudo port -f deactivate gnuradio
sudo port install gnuradio-devel
}}}
After that, assuming it succeeds, do your testing & see if "uhd_fft"
works now (as well as your code).
You can go back to the release versions via:
{{{
sudo port -f deactivate gnuradio-devel uhd-devel
sudo port activate gnuradio uhd
}}}
Cheers! - MLD
On Tue, Oct 4, 2016, at 09:07 AM, Leonardo Sampaio Cardoso wrote:
> Installed uhd-devel and launched uhd_fft. Another problem arises:
>
> RuntimeError:
> GR-UHD detected ABI compatibility mismatch with UHD library.
> GR-UHD was build against ABI: 3.10.0,
> but UHD library reports ABI: 3.11.0
> Suggestion: install an ABI compatible version of UHD,
> or rebuild GR-UHD component against this ABI version.
>
> At the same time I?ve been conducting tests on Sierra on another Mac
> (same macports gnuradio and UHD install). The I try uhd_fft i get:
>
> libc++abi.dylib: terminating with uncaught exception of type
> uhd::io_error: EnvironmentError: IOError: usb rx6 transfer status:
> LIBUSB_TRANSFER_ERROR
> Abort trap: 6
>
> I dont know whats ABI, but I suppose its related to the issue. :)
>
> Any clues?
------------------------------
Message: 32
Date: Tue, 4 Oct 2016 09:36:03 -0400
From: Jason Matusiak <ja...@gardettoengineering.com>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] FFT block's mag^2 output in RFNoC
Message-ID:
<5f71b8b1-9cdf-5a19-395b-781450df8...@gardettoengineering.com>
Content-Type: text/plain; charset=utf-8; format=flowed
I have sort of a dumb question. I was attempting to convert a flowgraph
to use some RFNoC blocks and needed to use the FFT block. I chose the
output to be the magnitude^2 option. Where I am confused is why it
outputs a complex value still. I expected that once I changed the
output type that it would become a float like the GR block.
My one thought is that RFNoC can only handle types "complex" so it needs
to stay with that output. If so, what is the recommended way of using
the magnitude^2 out of the FFT block?
------------------------------
Message: 33
Date: Tue, 4 Oct 2016 13:44:48 +0000
From: "Long, Jeffrey P." <jpl...@mitre.org>
To: "USRP-users@lists.ettus.com" <USRP-users@lists.ettus.com>
Subject: [USRP-users] error in rfnoc_fosphor.grc
Message-ID:
<dm5pr09mb13726426cd9f03541c214ef6d9...@dm5pr09mb1372.namprd09.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Not sure if this is a gnuradio error or a RFNOC error but I will start here and
please redirect me if I have the wrong forum.
When I opened rfnoc_fosphor.grc example the flowgraph indicated the following
error and would not give me the green arrow to run:
I am working with the latest master branch of gr-ettus. Does this assume a
particular version of gnuradio and or uhd? I have the latest master branch of
gnuradio and the lastest rfnoc-devel branch of uhd.
Thanks
Jeff
Error 0:
Connection (
Block - uhd_rfnoc_streamer_ddc_0 - RFNoC: DDC(uhd_rfnoc_streamer_ddc)
Source - out(0)
Block - uhd_rfnoc_streamer_window_0 - RFNoC: Window(uhd_rfnoc_streamer_window)
Sink - in(0)
):
Source IO size "8" does not match sink IO size "8192".
Error 1:
Connection (
Block - uhd_rfnoc_streamer_radio_0 - RFNoC: Radio(uhd_rfnoc_streamer_radio)
Source - out(0)
Block - uhd_rfnoc_streamer_ddc_0 - RFNoC: DDC(uhd_rfnoc_streamer_ddc)
Sink - in(0)
):
Source IO size "8192" does not match sink IO size "8".
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161004/685cb965/attachment-0001.html>
------------------------------
Message: 34
Date: Tue, 4 Oct 2016 16:44:45 +0200
From: Sylvain Munaut <246...@gmail.com>
To: "Long, Jeffrey P." <jpl...@mitre.org>
Cc: "USRP-users@lists.ettus.com" <USRP-users@lists.ettus.com>
Subject: Re: [USRP-users] error in rfnoc_fosphor.grc
Message-ID:
<CAHL+j0-COfc_AF_orvth1yMeDvMysqOcKcBRCCbPGqqXD=q...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi,
> When I opened rfnoc_fosphor.grc example the flowgraph indicated the
> following error and would not give me the green arrow to run:
>
> I am working with the latest master branch of gr-ettus. Does this assume a
> particular version of gnuradio and or uhd? I have the latest master branch
> of gnuradio and the lastest rfnoc-devel branch of uhd.
Yeah those are "normal" ... GRC doesn't deal very well with packet
size and the DCC block don't have a "packet size" attribute.
With F5/F6 you can force GRC to generate / run flowgraphs with errors
and they'll work fine.
Cheers,
Sylvain
------------------------------
Message: 35
Date: Tue, 4 Oct 2016 16:46:29 +0200
From: Sylvain Munaut <246...@gmail.com>
To: Jason Matusiak <ja...@gardettoengineering.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] FFT block's mag^2 output in RFNoC
Message-ID:
<cahl+j09+ergxpkscewbaut1yogvuw82pnjvkoz5h4_+2mve...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi,
> My one thought is that RFNoC can only handle types "complex" so it needs to
> stay with that output.
Yes, I think that's correct.
> If so, what is the recommended way of using the
> magnitude^2 out of the FFT block?
Using complex to float you can ignore the 'imaginary' part of the output.
Cheers,
Sylvain
------------------------------
Message: 36
Date: Tue, 4 Oct 2016 15:01:14 +0000
From: "Long, Jeffrey P." <jpl...@mitre.org>
To: Sylvain Munaut <246...@gmail.com>
Cc: "USRP-users@lists.ettus.com" <USRP-users@lists.ettus.com>
Subject: Re: [USRP-users] error in rfnoc_fosphor.grc
Message-ID:
<dm5pr09mb1372a9f5446123d4f1fea503d9...@dm5pr09mb1372.namprd09.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Sylvain-
Ok that does not seem to be an option for me, it is all grayed out.
Nevertheless I just ran the .py from the command line and I get the following
output at the end of all the rfnoc verbage:
.
.
.
-- [NocScript] Executing SR_WRITE()
-- [0/fosphor_0] sr_write(WF_DECIM, 000000FE) ==>
INFO: Setting args on 0/FIFO_0 (gr_vlen=1024,spp=1024)
DEBUG: output item size: 1024
Traceback (most recent call last):
File "./rfnoc_fosphor.py", line 335, in <module>
main()
File "./rfnoc_fosphor.py", line 323, in main
tb = top_block_cls()
File "./rfnoc_fosphor.py", line 162, in __init__
"FIFO", 1, -1,
File "/usr/local/lib/python2.7/dist-packages/ettus/ettus_swig.py", line 3380,
in make
return _ettus_swig.rfnoc_generic_make(dev, tx_stream_args, rx_stream_args,
block_name, block_select, device_select)
RuntimeError: Cannot find a block for ID: FIFO_1
When I usrp probe my image I do have a fifo but maybe not enough?? I used
make.py to build this. Can you recommend a build string for make.py that should
build what I need?
Thanks
Jeff
| | /
| | | RFNoC blocks on this device:
| | |
| | | * DmaFIFO_0
| | | * Radio_0
| | | * Radio_1
| | | * fosphor_0
| | | * FFT_0
| | | * DDC_0
| | | * Window_0
| | | * FIFO_0
-----Original Message-----
From: Sylvain Munaut [mailto:246...@gmail.com]
Sent: Tuesday, October 04, 2016 10:45 AM
To: Long, Jeffrey P.
Cc: USRP-users@lists.ettus.com
Subject: Re: [USRP-users] error in rfnoc_fosphor.grc
Hi,
> When I opened rfnoc_fosphor.grc example the flowgraph indicated the
> following error and would not give me the green arrow to run:
>
> I am working with the latest master branch of gr-ettus. Does this assume a
> particular version of gnuradio and or uhd? I have the latest master branch
> of gnuradio and the lastest rfnoc-devel branch of uhd.
Yeah those are "normal" ... GRC doesn't deal very well with packet
size and the DCC block don't have a "packet size" attribute.
With F5/F6 you can force GRC to generate / run flowgraphs with errors
and they'll work fine.
Cheers,
Sylvain
------------------------------
Message: 37
Date: Tue, 4 Oct 2016 17:04:26 +0200
From: Sylvain Munaut <246...@gmail.com>
To: "Long, Jeffrey P." <jpl...@mitre.org>
Cc: "USRP-users@lists.ettus.com" <USRP-users@lists.ettus.com>
Subject: Re: [USRP-users] error in rfnoc_fosphor.grc
Message-ID:
<cahl+j08q2xdu3faggwri5vrp_0hrckqink3a7e49lqtodzq...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi,
> Ok that does not seem to be an option for me, it is all grayed out.
> Nevertheless I just ran the .py from the command line and I get the following
> output at the end of all the rfnoc verbage:
Yeah, they're grayed out, but F5 / F6 should still work. They bypass the icons.
> RuntimeError: Cannot find a block for ID: FIFO_1
The new flow graph needs two loopback FIFOs. Your FPGA image only has one.
Cheers,
Sylvain
------------------------------
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 74, Issue 4
*****************************************
