[USRP-users] multiple N200 devices

Dan Sego bubbadoradar at gmail.com
Mon Dec 1 21:53:56 EST 2014


Thank you Marcus.

I bow to your wisdom on the registry change. However there is no such entity
Program Files <x86>/UHD/share/uhd/FastSendDatagramThreshold.reg

In the latest UHD installation (taken from
http://files.ettus.com/manual/page_transport.html#transport_udp_windows).

Searching the complete C: directory produced no hits.

I did find it at
http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/86c32704e864e42651a7d1529436acbbe7eeb96e
dated April 2012, and downloaded it.

I have Windows 8 (unfortunately). The UHD support page only extends to
Windows 7. Issue?

Looking at the advanced properties of the network adapter (receive 512,
transmit 128) will the registry edit be reflected in these values?

Good evening. Dan

On Sun, Nov 30, 2014 at 1:18 PM, Marcus D. Leech <mleech at ripnet.com> wrote:

>  On 11/30/2014 04:13 PM, Dan Sego wrote:
>
>  Again thank you. To avoid confusion, the error I'm referring to as this
> one (from the first message)
>
>  "Error: RuntimeError: fifo cntl timed out looking for acks"
>
>  which appeared during or after the "Creating UDP step". This did not
> occur using a ThinkPad and single N200 unit and without a registry change
> (though the UHD Warning on packet size was received...The MTU (1472) is
> larger than the FastSendDataGramThreshold (1024)! This will negatively
> affect.....). I still receive that warning before the error above occurs.
>
>  I continue to launch the program until success occurs. At that point....
>
>  Using to_pp_string I print "addr" which returns the correct addresses
> (addr0 to .10.3 and addr1 to .10.2). I appears that I am doing that
> correctly.
>
>  After "Clock Source Set"  usrp returns
>
>  Using Device: Multi USRP
>    Device: USRP2 / N-Series Device
>    Mboard 0: N200r4
>    Mboard1: N200r4
>    Rx Channel: 0
>       RX DSP: 0
>       RX Board: A
>       RX Subdev: WBXv3 RX+GDB
>     Rx Channel: 1
>       RX DSP: 0
>       RX Board: A
>       RX Subdev: WBXv3 RX+GDB
>     Tx Channel: 0
>       TX DSP: 0
>       TX Board: A
>       TX Subdev: WBXv3 RX+GDB
>    Tx Channel: 1
>       TX DSP: 0
>       TX Board: A
>       TX Subdev: WBXv3 RX+GDB
>
>  I'm reluctant to muck about with the registry as a non-windows
> specialist.
>
>  vr Dan
>
> Could you please copy your replies to the usrp-users mailng list, as
> others can benefit from the discussion, and other Ettus folks can also
>   contribute to a possible solution.
>
> I strongly suggest that you modify the FastDataGramSendThreshold, as
> described in the online manual for Windows.  Without this, things are
>   happening on the slow path, which may be contributing to your problem.
>
> Also, if you ping the two devices, does that yield reliable results?
>
>
>
>
>
> On Sun, Nov 30, 2014 at 11:54 AM, Marcus D. Leech <mleech at ripnet.com>
> wrote:
>
>>  On 11/30/2014 02:21 PM, Dan Sego wrote:
>>
>>  The error is occurring at the creation of the creation of the usrp
>> device
>>
>> uhd::device_addr_t dev_addr;
>>
>> dev_addr["addr0"] = "192.168.10.3";
>>
>> dev_addr["addr1"] = "192.168.10.2";
>>
>> uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(dev_addr);
>>
>> I was aware of the max rate (though I had hoped to finesse it to a higher
>> rate - 2x - because I'm sampling in bursts at a duty factor of 20% instead
>> of continuous streaming - duty of 100%).
>>
>> If NIC is "network interface card" I have a brand new Lenovo I7
>> Ideapad with the Realtek PCIe GBE family controller.
>>
>> Registry changes - no.
>>
>>
>>  Dan
>>
>>
>>  See:
>>
>> http://files.ettus.com/manual/page_transport.html#transport_udp_windows
>>
>> and
>>
>> http://files.ettus.com/manual/page_usrp2.html#usrp2_mimocable_shared
>>
>>
>>
>>
>> On Sun, Nov 30, 2014 at 11:09 AM, Marcus D. Leech <mleech at ripnet.com>
>> wrote:
>>
>>>  On 11/30/2014 02:01 PM, Dan Sego wrote:
>>>
>>>  correct. Requested sample rate is 12.5E+06 in bursts of 10k samples..
>>>
>>>  The error occurs, at the earliest, after the UDP transport is opened
>>> for the first unit (-- Creating WSA UPD transport for 192.168.10.3:XXXXX,
>>> which occurs 4 times), sometimes after the UDP transport for the second
>>> device (-- Creating WSA UPD transport for 192.168.10.2:XXXXX, which
>>> also occurs 4 times). The "sequence" of the error in the flow is not the
>>> same.
>>>
>>>  If the execution gets past the "--Detecting internal GPSDO......No
>>> GPSDO found" message then it runs to completion.
>>>
>>>  I have print statements to echo the setup at each point with the last
>>> one after the creation of the rx_streamer, to localize problems
>>>
>>>  vr Dan
>>>
>>>  How are you addressing the devices in your code?
>>>
>>> 2 x 12.5e6 SPS is the absolute maximum you can channel over a single
>>> 1GiGe connection.  See if there's a relationship to sample-rate in the
>>>   emergence of the problem.  What kind of NIC are you using?  Have you
>>> applied the registry changes that are recommended for enabling
>>>   "fast path" processing on Windows?
>>>
>>>
>>>
>>>
>>> On Sun, Nov 30, 2014 at 10:47 AM, Marcus D. Leech <mleech at ripnet.com>
>>> wrote:
>>>
>>>>  On 11/30/2014 01:45 PM, Dan Sego wrote:
>>>>
>>>> Sorry. No the devices are on MIMO cable
>>>>
>>>>  OK, so you're using shared-ethernet mode (that is, there's a single
>>>> cable between your host and the "master" USRP)
>>>>
>>>>
>>>> What sample rate are you trying to use?
>>>>
>>>>
>>>>
>>>>
>>>> On Sun, Nov 30, 2014 at 10:40 AM, Marcus D. Leech <mleech at ripnet.com>
>>>> wrote:
>>>>
>>>>>  On 11/30/2014 01:34 PM, Dan Sego wrote:
>>>>>
>>>>>  Thank you once again. The address change was successful. Might you
>>>>> be able to offer any suggestion on the runtime error? With a single N200
>>>>> operating the likelihood of experiencing the error was 4:10 tries to
>>>>> execute the C++ code. With the two channel code it has degraded to < 1:10
>>>>> tries.
>>>>>
>>>>>  cheers! Dan
>>>>>
>>>>>  Did you power-cycle the device after changing the IP address?
>>>>>
>>>>> These devices are on a switch, no doubt?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Nov 28, 2014 at 7:25 PM, Marcus D. Leech via USRP-users <
>>>>> usrp-users at lists.ettus.com> wrote:
>>>>>
>>>>>>   On 11/28/2014 10:18 PM, Dan Sego via USRP-users wrote:
>>>>>>
>>>>>>   Good evening the List.
>>>>>>
>>>>>>  I have two N200 devices connected by MIMO cable. Running
>>>>>> und_find_devices returns:
>>>>>>
>>>>>>  Win32; Microsoft Visual C++ version 10.0; Boost_105400;
>>>>>> UHD_003.008.000-release
>>>>>> --------------------------------------------------
>>>>>> -- UHD Device 0
>>>>>> --------------------------------------------------
>>>>>> Device Address:
>>>>>>     type: usrp2
>>>>>>     addr: 192.168.10.2
>>>>>>     name:
>>>>>>     serial: F4B96A
>>>>>>
>>>>>> --------------------------------------------------
>>>>>> -- UHD Device 1
>>>>>> --------------------------------------------------
>>>>>> Device Address:
>>>>>>     type: usrp2
>>>>>>     addr: 192.168.10.2
>>>>>>     name:
>>>>>>     serial: F4B96A
>>>>>>
>>>>>>  Should the addresses be the same? I've looked at several code
>>>>>> examples where addr:198.162.10.2 is used for device 0 and 198.162.10.3 for
>>>>>> device 1.
>>>>>>
>>>>>>  Running the sampling routine (derived from rx_multi_usrp.cpp) with
>>>>>> the same address produces the following output
>>>>>>
>>>>>>  in32; Microsoft Visual C++ version 10.0; Boost_105400;
>>>>>> UHD_003.008.000-release
>>>>>>
>>>>>> -- Opening a USRP2/N-Series device...
>>>>>> -- Current recv frame size: 1472 bytes
>>>>>> -- Current send frame size: 1472 bytes
>>>>>> -- Creating WSA UDP transport for 192.168.10.2:49156
>>>>>> -- Creating WSA UDP transport for 192.168.10.2:49158
>>>>>> -- Creating WSA UDP transport for 192.168.10.2:49157
>>>>>> -- Creating WSA UDP transport for 192.168.10.2:49159
>>>>>> -- Creating WSA UDP transport for 192.168.10.2:49156
>>>>>> -- Creating WSA UDP transport for 192.168.10.2:49158
>>>>>> -- Creating WSA UDP transport for 192.168.10.2:49157
>>>>>> -- Creating WSA UDP transport for 192.168.10.2:49159
>>>>>>  Error: RuntimeError: fifo cntl timed out looking for acks
>>>>>>
>>>>>>  Not shown on the command line output is the following
>>>>>> UHD Warning:
>>>>>>
>>>>>>
>>>>>>  I am able to read successively using a single device (and single
>>>>>> channel s/w) but approximately 50% of the times I launch a collect I
>>>>>> receive the same error
>>>>>>
>>>>>>  Any suggestions would be helpful. Cheers. Dan Sego
>>>>>>
>>>>>>
>>>>>>
>>>>>>  _______________________________________________
>>>>>> USRP-users mailing listUSRP-users at lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>
>>>>>>  The devices leave the factory with a 192.168.10.2  IP address.   You
>>>>>> have to reprogram that address if you want something different:
>>>>>>
>>>>>> http://files.ettus.com/manual/page_usrp2.html#usrp2_network
>>>>>>
>>>>>> The requirement for distinct devices to have distinct IP addresses is
>>>>>> fundamental to IP networking.
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> USRP-users mailing list
>>>>>> USRP-users at lists.ettus.com
>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>   --
>>>>> Marcus Leech
>>>>> Principal Investigator
>>>>> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Marcus Leech
>>>> Principal Investigator
>>>> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>>>>
>>>>
>>>
>>>
>>> --
>>> Marcus Leech
>>> Principal Investigator
>>> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>>>
>>>
>>
>>
>> --
>> Marcus Leech
>> Principal Investigator
>> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141201/1cbc7438/attachment-0002.html>


More information about the USRP-users mailing list