Send USRP-users mailing list submissions to
[email protected]
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
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. advice about architcture (iftah giladi)
2. Re: advice about architcture (Marcus M?ller)
3. Re: RX timeout after longer inactivity (Ales Povalac)
----------------------------------------------------------------------
Message: 1
Date: Mon, 14 Apr 2014 14:03:39 +0300
From: "iftah giladi" <[email protected]>
To: <[email protected]>
Subject: [USRP-users] advice about architcture
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Greetings to all,
I would really like to hear your opinion on my suggested
architecture(attached)
The principles that lead me to this are:
1. Want to use the MIMO cable to sync 2 userp to work as one 2 ch
receiver.
2. Want the all the USRP to start sample at approximately the same time
up to a 100ms delay, less is better.
3. Sample at 25Mhz, in 32 bit per sample so have to use different 1G link
to the computer, one on the M/B and the other on a NIC PCIe card( I guess 2
max for computer ).
4. Working with the N200( total 4 ), XCRV @ 2.4G IEEE 802.11
5. No time issue regarding collection all of the files to later
processing.
So do you think I have it right in my mind?
Am I missing something?
Is it even possible to have these usrp working together with the mimo cable
but receiving the get stream commend from one computer and transferring the
data to another computer?
Any advice on that issue would be very appreciated.
Thanks in advance,
Iftah
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140414/570a5e9a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: arch prop.jpg
Type: image/jpeg
Size: 44432 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140414/570a5e9a/attachment-0001.jpg>
------------------------------
Message: 2
Date: Mon, 14 Apr 2014 14:35:04 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] advice about architcture
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Greetings to you,
just a few quick comments:
> 1. Want to use the MIMO cable to sync 2 userp to work as one 2
> ch receiver.
Well, that works.
>
> 2. Want the all the USRP to start sample at approximately the
> same time up to a 100ms delay, less is better.
When working in synchronized mode (w/ a MIMO cable), you can be
sample-synchronous.
>
> 3. Sample at 25Mhz, in 32 bit per sample so have to use
> different 1G link to the computer, one on the M/B and the other on
> a NIC PCIe card( I guess 2 max for computer ).
A few things with this:
1. to my knowledge, there is no USRP with 32 bit sampling depth. N2x0
have 14bit ADCs.
2. 25MSp/s complex means that you have to get 5e7 values/s through a
1e9 bit/s. That implies an absolute maximum value of 20bit/value, not
even considering overhead.
3. You can usually have as many NICs as you have PCIe slots, and these
can themselves have multiple ports, so there is no need for multiple
PCs, unless one can not provide the processing power or storage bandwidth.
> 4. Working with the N200( total 4 ), XCRV @ 2.4G IEEE 802.11
Take a look at the B210 USRPs. They are inherently dual channel and
relatively inexpensive.
> 5. No time issue regarding collection all of the files to later
> processing.
This is an reoccurring topic. Storing away multiple fully utilized
Gigabit Ethernet streams of data is *not* trivial in a general purpose
computer. You'll need some potent storage setup because you need a
high guaranteed storage bandwidth (not only a nice average write speed).
> So do you think I have it right in my mind?
You don't really explain why you need four USRPs, you only mention a
dual-USRP receiver; I assume you want to do IEEE802.11 transmissions.
This will work with the proposed setup, though you might really go the
B210 route.
> Am I missing something?
>
> Is it even possible to have these usrp working together with the
> mimo cable but receiving the get stream commend from one computer
> and transferring the data to another computer?
No, but that's not how you would do it:
USRP A and USRP B are connected via MIMO cable, so they share one
clock source; they can also share a PPS to synchronize their absolute
time.
Computer A and B are connected to USRP A and B, respectively. Computer
A issues a streaming command with a timestamp, Computer B does the
exact same. Both USRPs start streaming simultaneously.
Greetings,
Marcus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTS9X4AAoJEBQ6EdjyzlHthoMH/jZsprgtznXIPkAXy/IMUL/M
5kLAQg7TQE3rI1D97X4WFJtLllmUcPboLxM2uLFTelqwEhsfRsLzF7x7t2wbPaF/
LdvuWElfwD1srb0zrqyEkLtQ7nDeoXvEO6X32SlMjCNFD6d9VSR6cftONohuS5se
T23845w4X/oUNzHu0LRMqmrvupssNpUcVEsMLCmgQacLGPuQKdV4rQR3qgAov1if
pJPNPwg9VEt8IExaoIBPq/IHIc8OCQY70gcdsXc5EJx61oPVf3+hGRKc6FriGiTf
rUdhsNtxo/jtTnNfcjELTUp8ceRhILnRNIrQ7zGd7WPei70NS5XGGaLH2UbEzrQ=
=RbEZ
-----END PGP SIGNATURE-----
------------------------------
Message: 3
Date: Mon, 14 Apr 2014 17:13:01 +0200
From: Ales Povalac <[email protected]>
To: Michael West <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] RX timeout after longer inactivity
Message-ID:
<CADyMgmzJQn0J=WGB5tqTUBK6V2hfq=yvaadjsmqem78qbjk...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi Michael,
have you already tested the issue on Windows? Can you confirm this as
a bug in UHD?
Regards,
Ales
2014-03-20 23:36 GMT+01:00 Michael West <[email protected]>:
> Ales,
>
> My apologies for the delayed response. I have not yet been able to
> reproduce the issue, but I have only tested on Linux systems so far. I will
> try a Windows system and get back to you.
>
> --Michael
>
>
> On Mon, Mar 17, 2014 at 9:13 AM, Ales Povalac <[email protected]> wrote:
>>
>> Hi Michael,
>>
>> any news regarding the issue? Were you able to reproduce it?
>>
>> Thanks,
>> Ales
>>
>>
>>
>> 2014-03-10 7:13 GMT+01:00 Ales Povalac <[email protected]>:
>>
>>> Hi Michael,
>>>
>>> system is Windows 7 64-bit, tested on several computers. Last
>>> experiment was with N210 and WBX, same issue was also on N200 and
>>> TVRX2. Gigabit adapters are from Intel (PCIe) and Realtek (PCI).
>>>
>>> Regards,
>>> Ales
>>>
>>>
>>> 2014-03-07 1:21 GMT+01:00 Michael West <[email protected]>:
>>> > Ales,
>>> >
>>> > Can you provide me with some information about your set up (i.e. OS,
>>> > type of
>>> > device, type of daughterboards, etc...)?
>>> >
>>> > Thanks,
>>> >
>>> > Michael E. West
>>> > Senior Software Design Engineer
>>> > Ettus Research
>>> > www.ettus.com
>>> >
>>> >
>>> > On Wed, Mar 5, 2014 at 3:58 PM, Michael West <[email protected]>
>>> > wrote:
>>> >>
>>> >> Ales,
>>> >>
>>> >> Thanks for letting us know. We will try to reproduce the issue and
>>> >> file a
>>> >> bug if appropriate. I will let you know if we find a workaround or
>>> >> fix.
>>> >>
>>> >> Best regards,
>>> >> Michael E. West
>>> >> Senior Software Design Engineer
>>> >> Ettus Research
>>> >> www.ettus.com
>>> >>
>>> >>
>>> >> On Wed, Mar 5, 2014 at 6:10 AM, Ales Povalac <[email protected]> wrote:
>>> >>>
>>> >>> Dear all,
>>> >>>
>>> >>> we have a problem with UHD RX code. If there is a delay between
>>> >>> get_rx_stream() and issue_stream_cmd() longer than ca. 64 seconds,
>>> >>> the
>>> >>> recv() call always fails with ERROR_CODE_TIMEOUT.
>>> >>>
>>> >>> Issue can be reproduced in rx_samples_to_file example by adding a
>>> >>> delay of >64 seconds before stream command, diff at
>>> >>> http://pastebin.com/MFDNVyYy . Threshold is near 64 seconds - 60 sec
>>> >>> always works, 70 sec always fails with "Timeout while streaming".
>>> >>>
>>> >>> I am on maint branch of UHD, tested also on 003.005.001 with the same
>>> >>> result. Any ideas how to fix this issue?
>>> >>>
>>> >>> Thanks,
>>> >>> Ales
>>> >>>
>>> >>> _______________________________________________
>>> >>> USRP-users mailing list
>>> >>> [email protected]
>>> >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>> >>
>>> >>
>>> >
>>
>>
>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 44, Issue 14
******************************************
