On 05/31/2018 01:53 PM, Steve Gough wrote:
Thanks for the tip. Tried that as well, and I get the below. Device
address in the GRC parameter is set as : "addr=192.168.10.2
addr=192.168.10.5" (as attached)
File "/home/colosseum/Downloads/for_steve_gough2.py", line 37, in
__init__
channels=range(5),
File
"/home/colosseum/src/gr-prefix/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
line 122, in constructor_interceptor
return old_constructor(*args)
File
"/home/colosseum/src/gr-prefix/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
line 2686, in make
return _uhd_swig.usrp_source_make(*args)
NotImplementedError: Wrong number or type of arguments for overloaded
function 'usrp_source_make'.
Possible C/C++ prototypes are:
gr::uhd::usrp_source::make(::uhd::device_addr_t const
&,::uhd::io_type_t const &,size_t)
gr::uhd::usrp_source::make(::uhd::device_addr_t const
&,::uhd::stream_args_t const &,bool const)
I am not sure what else to try to get the two devices to sample-align.
Well, according your first instinct, and this doc here:
https://files.ettus.com/manual/page_multiple.html
The syntax should be:
"addr0=192.168.10.5,addr1=192.168.10.2"
BUT, there was this special mode for N210/USRP2 called "shared ethernet
mode", and I think it keys on the two devices being on the same
subhet, and connected by the MIMO cable.
Perhaps someone in R&D can confirm this, and that perhaps there is some
internal confusion in UHD when the two addresses are on the same
subnet, but not actually a "MIMO-cable pair".
In the meantime, if you have more than one 1GiGe interface, you can
re-address one of them, and put it on its own subnet.
On Thu, May 31, 2018 at 1:36 PM, Marcus D. Leech <mle...@ripnet.com
<mailto:mle...@ripnet.com>> wrote:
On 05/31/2018 01:24 PM, Steve Gough wrote:
Oh, I meant I edited the python from the GRC which you had sent
to print the number of motherboards using UHD's get_num_mboards
(https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#ae4efbbc6480fba44939b34c78d44d7e9
<https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#ae4efbbc6480fba44939b34c78d44d7e9>),
and it returned 1. I expected 2.
The GRC and a screenshot of the same is attached.
Simply running this flowgraph gives me the error :
File "/home/colosseum/Downloads/for_steve_gough2.py", line 43,
in __init__
self.uhd_usrp_source_0.set_clock_source('external', 1)
File
"/home/colosseum/src/gr-prefix/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
line 3706, in set_clock_source
return _uhd_swig.usrp_source_sptr_set_clock_source(self,
source, mboard)
RuntimeError: LookupError: IndexError: multi_usrp::mb_root(1) -
vector::_M_range_check: __n (which is 1) >= this->size() (which is 1)
Is there any particular cause of this error ?
This should Just Work(tm).
I'd forgotten that I'd written you a flow-graph to test
things..... sigh.
You still have a "," between the addresses. Use a space. The
"," separates parameters for a single mboard.
On Thu, May 31, 2018 at 1:02 PM, Marcus D. Leech
<mle...@ripnet.com <mailto:mle...@ripnet.com>> wrote:
On 05/31/2018 12:50 PM, Steve Gough wrote:
Thanks. That temporarily fixes the addressing issue.
However, I am now seeing the following error. Could you
please tell me why this might be happening?
File "/home/colosseum/Downloads/for_steve_gough.py", line
47, in __init__
self.uhd_usrp_source_0.set_clock_source('external', 1)
File
"/home/colosseum/src/gr-prefix/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
line 3706, in set_clock_source
return _uhd_swig.usrp_source_sptr_set_clock_source(self,
source, mboard)
RuntimeError: LookupError: IndexError:
multi_usrp::mb_root(1) - vector::_M_range_check: __n (which
is 1) >= this->size() (which is 1)
It looks like with the "addr=192.168.10.5 addr=192.168.10.2"
device args, it thinks there is only 1 motherboard.
A check on self.uhd_usrp_source_0.get_num_mboards() replies
"1" . Shouldn't it actually be 2 ?
Thanks!
I can't recall at this point, but is this a GnuRadio (GRC,
even) flow-graph?
If so, there's a "number of Mboards" parameter -- it doesn't
get computed automatically.
On Wed, May 30, 2018 at 5:39 PM, Marcus D. Leech
<mle...@ripnet.com <mailto:mle...@ripnet.com>> wrote:
On 05/30/2018 04:45 PM, Steve Gough wrote:
Same error still, unfortunately even after setting the
gateway and subnet on the N210 via usrp_burn_mb_eeprom
and power-cycling.
Ah!
Try this in your device args:
"addr=192.168.10.5 addr=192.168.10.2"
For the N210:
| | Mboard: N210r4
| | hardware: 2577
| | mac-addr: a0:36:fa:25:3e:96
| | ip-addr: 192.168.10.5
| | subnet: 255.255.255.0
| | gateway: 192.168.10.1
| | gpsdo: none
| | serial: E9R1EQ6UP
| | FW Version: 12.4
| | FPGA Version: 11.1
| |
| | Time sources: none, external, _external_, mimo
| | Clock sources: internal, external, mimo
| | Sensors: mimo_locked, ref_locked
For the X310:
Mboard: X310
| | revision: 8
| | revision_compat: 7
| | product: 30818
| | mac-addr0: 00:80:2f:25:c1:ec
| | mac-addr1: 00:80:2f:25:c1:ed
| | gateway: 192.168.10.1
| | ip-addr0: 192.168.10.2
| | subnet0: 255.255.255.0
| | ip-addr1: 192.168.20.2
| | subnet1: 255.255.255.0
| | ip-addr2: 192.168.30.2
| | subnet2: 255.255.255.0
| | ip-addr3: 192.168.40.2
| | subnet3: 255.255.255.0
| | serial: 30E781A
| | FW Version: 5.0
| | FPGA Version: 33.0
| | RFNoC capable: Yes
| |
| | Time sources: internal, external, gpsdo
| | Clock sources: internal, external, gpsdo
| | Sensors: ref_locked
-----------------------------------------------------------------
colosseum@colosseum-ThinkPad-T430:~/wireless/lp_door/doppler/usrp_sync$
python ~/Downloads/for_steve_gough.py
WARNING: Config file
'/home/colosseum/.gnuradio/config.conf' failed to parse:
std::exception
Skipping it
WARNING: Config file
'/home/colosseum/.gnuradio/config.conf' failed to parse:
std::exception
Skipping it
WARNING: Config file
'/home/colosseum/.gnuradio/config.conf' failed to parse:
std::exception
Skipping it
linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_003.011.000.git-78-gf70dd85d
UHD Error:
Device discovery error: ValueError: Could not
resolve device hint "addr=192.168.10.2" to a single device.
UHD Error:
Device discovery error: ValueError: Could not
resolve device hint "addr=192.168.10.5" to a single device.
Traceback (most recent call last):
File "/home/colosseum/Downloads/for_steve_gough.py",
line 95, in <module>
main()
File "/home/colosseum/Downloads/for_steve_gough.py",
line 84, in main
tb = top_block_cls()
File "/home/colosseum/Downloads/for_steve_gough.py",
line 36, in __init__
channels=range(5),
File
"/home/colosseum/src/gr-prefix/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
line 122, in constructor_interceptor
return old_constructor(*args)
File
"/home/colosseum/src/gr-prefix/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
line 2686, in make
return _uhd_swig.usrp_source_make(*args)
RuntimeError: LookupError: KeyError: No devices found
for ----->
Device Address:
addr0: 192.168.10.2
addr1: 192.168.10.5
---------------------------------------------------------------------------------------------------------------------------
Is there any other reason why this might be happening ?
Thanks!
Steve
On Wed, May 30, 2018 at 2:05 PM, Marcus D. Leech
<mle...@ripnet.com <mailto:mle...@ripnet.com>> wrote:
On 05/30/2018 02:00 PM, Steve Gough wrote:
Thanks for the reply, Ian and Marcus.
I see. Could you please tell me what should be the
values I must set on the host and N210 for the
gateway and subnet ?
Thanks!
Gateway addy should all be (assuming 192.168.10.x)
subnet:
192.168.10.1
Subnet mask should be:
255.255.255.0
On Wed, May 30, 2018 at 12:36 PM, Ian Buckley via
USRP-users <usrp-users@lists.ettus.com
<mailto:usrp-users@lists.ettus.com>> wrote:
Those N210 settings are broken also…bad subnet
and gateway
> On May 30, 2018, at 9:26 AM, Marcus D. Leech
via USRP-users <usrp-users@lists.ettus.com
<mailto:usrp-users@lists.ettus.com>> wrote:
>
> On 05/30/2018 12:22 PM, Steve Gough via
USRP-users wrote:
>> Hi Neel and USRP mailing list,
>>
>> The uhd_usrp_probe returns as follows:
>>
>> For the N210 with WBX:
>> Mboard: N210r4
>> | | hardware: 2577
>> | | product: 30194
>> | | mac-addr: a0:36:fa:25:3a:6b
>> | | ip-addr: 192.168.10.4
>> | | subnet: 255.255.255.255
>> | | gateway: 255.255.255.255
>>
>> For the X310 with 2 TwinRXs:
>> Mboard: X310
>> | | revision: 8
>> | | revision_compat: 7
>> | | product: 30818
>> | | mac-addr0: 00:80:2f:25:c1:ec
>> | | mac-addr1: 00:80:2f:25:c1:ed
>> | | gateway: 192.168.10.1
>> | | ip-addr0: 192.168.10.2
>> | | subnet0: 255.255.255.0
>> | | ip-addr1: 192.168.20.2
>> | | subnet1: 255.255.255.0
>> | | ip-addr2: 192.168.30.2
>> | | subnet2: 255.255.255.0
>> | | ip-addr3: 192.168.40.2
>> | | subnet3: 255.255.255.0
>>
>> So, yes, it looks like the N210 and the
X310 devices have different MAC addresses.
>>
--------------------------------------------------------------------------------------------------
>>
>>
>> The IPv4 settings on the host are :
>> Address : 192.168.10.1
>> Netmask : 24
>> Gateway : 192.168.10.255
>>
>>
> The gateway address you have set on your
host is the subnet-broadcast address. Not
sure if this makes a difference in this case,
since you're never going
> "off net" and will not require the gateway.
But maybe it's confusing your IP stack a bit?
>
>
>
> _______________________________________________
> 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>
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
