[USRP-users] How to calculate packets live from USRPN200 hardware

Marcus Müller marcus.mueller at ettus.com
Tue Mar 29 11:48:49 EDT 2016

Hi Mariam,

On 29.03.2016 17:28, Mariam Musavi wrote:
> Hi Marcus!
> I agree the things you mentioned in your recent email, but i am still
> not agreeing with "There is nothing that one can do to predict/measure
> throughput "in general", all depends on your system design".
It really does.
> Since i am working more on Network layer, If we see USRP hardware has
> front panel LEDs, describing functionalities few of them i am
> mentioning such as LED A: transmitting and LED C: receiving, when we
> talk about ettus Network series USRP N200, we normally talk about
> packets and system configuration isn't it (sorry that, i am more
> indulge into working on to network layer in IP stack).
No, we shouldn't be talking about packets when communicating with the
N200, and I've been constantly trying to explain that: the USRP sends
some kind of signal. The fact that it does doesn't mean there's /data/
(as in "payload data", such as video) flowing. The fact that this signal
comes to the USRP in the shape of sample UDP packets doesn't mean
anything in relation to your video data.
> The device which transmit data to another device
A USRP *does not* transmit data to another device. It is capable of
synthesizing an RF signal. The fact that you can transmit data with that
happens as soon as you analyse/generate a digital signal that
*represents* data.**
> (assuming in my case each USRP is equipped with system design which i
> made in GRC flowgraph with the following  parameters:
No. The USRP is not equipped with what you've designed in GRC: What one
designs in GRC is a GNU Radio flowgraph, which is software, which runs
on your PC, *not* on the USRP. So the USRP is really just the frontend
that gets the samples.
> acket size: 2720 bits, Transmission rate: 1Mbps, Modulation: GMSK),
Where do you specifiy that packet size? That is your application! You've
not told us what application you use. How do you set that 1Mbps rate?
I'm confused. Please hurry up with that system overview diagram!
> My question is how can i measure each node's parameters such as
> packets (sent/receive) independently in GRC, without using any network
> analyzer software?
Not at all. The fact that UHD underneath takes the samples you generate
in GNU Radio, converts them to a format that the USRP understands and
transports them to the USRP via ethernet, USB, PCIexpress … is
completely out of scope of GNU Radio. In fact, the purpose of UHD is to
hide the fact that the connection between your software and the USRP is
not actually a continous stream of samples!
Again, the UHD packets have absolutely no relationship to the data
packets you are referring to.

Best regards,

> On Tue, Mar 29, 2016 at 8:07 PM, Mariam Musavi <mariam.musvi at gmail.com
> <mailto:mariam.musvi at gmail.com>> wrote:
>     Hi Marcus!
>     LED A: transmitting
>     LED C: receiving
>     On Tue, Mar 29, 2016 at 7:14 PM, Marcus Müller
>     <marcus.mueller at ettus.com <mailto:marcus.mueller at ettus.com>> wrote:
>         Mariam,
>         as mentioned, "throughput" is a very high-level concept.
>         At the physical layer, where we're currently discussing, you
>         can only *select* a given bandwidth/modulation/coding
>         combination and hence *set* the throughput.
>         This selection of methods and parameters depends alone on how
>         you want your system to behave, and how you model your channel.
>         As said multiple times now, you're the one defining bit rate,
>         and your channel and the methods used will lead to an error
>         rate. There's nothing that one can do to predict/measure
>         throughput "in general"; all depends on your system design.
>         Best regards,
>         marcus
>         On 29.03.2016 15:17, Mariam Musavi wrote:
>>         Hi Marcus!
>>         I am really sorry that i couldn't elucidate my problem
>>         clearly to the USRP community, i agree with the point that
>>         USRP only knows the language of waveform. My problem is i
>>         simulate a noise to provide to USRP node. Since i feed that
>>         simulated noise to USRP, it will response to that noise
>>         resulting (lower SNR), providing less throughput. i basically
>>         want to measure the throughput of each node while sending
>>         (video data) waveform in the presence of simulated noise. Is
>>         there any block in GRC/USRP which can measure the throughput
>>         in hop-to-hop manner of each node from USRP source to USRP
>>         destination?  
>>         Let me know Marcus if the problem is still unclear!
>>         Thanks.
>>         On Tue, Mar 29, 2016 at 6:01 PM, Marcus Müller
>>         <marcus.mueller at ettus.com <mailto:marcus.mueller at ettus.com>>
>>         wrote:
>>             Mariam,
>>             the point still is that the USRP really doesn't know (and
>>             care) what your samples mean. To the USRP, these are just
>>             relative voltage values.
>>             The fact that it's data is up to your software's
>>             interpretation of these values; you can't transmit "bits"
>>             over the air, but you can transmit a waveform that can be
>>             interpreted as such.
>>             So, a USRP can't forward "data"; it just receives RF
>>             signal, makes a digital signal out of it, gives that to a
>>             PC, which might then do something with that, eg. take the
>>             same digital numbers and give it to a USRP to make a TX
>>             signal out of it.
>>             I'm having a bit of a hard time understanding in what
>>             kind of "deadlock" you are. That is probably because I
>>             don't understand you correctly; could you explain your
>>             problem?
>>             Best regards,
>>             Marcus
>>             On 29.03.2016 14:40, Mariam Musavi wrote:
>>>             video data packets.
>>>             On Tue, Mar 29, 2016 at 4:17 PM, Marcus Müller
>>>             <marcus.mueller at ettus.com
>>>             <mailto:marcus.mueller at ettus.com>> wrote:
>>>                 Hi Mariam,
>>>                 what packets are you referring to?
>>>                 Best regards,
>>>                 Marcus
>>>                 On 29.03.2016 12:06, Mariam Musavi wrote:
>>>>                 Greetings!
>>>>                 All users,
>>>>                 I am working on USRP Network series N200, and i am
>>>>                 stuck up in the deadlock to calculate packets
>>>>                 sent/received during transmission from USRP node.
>>>>                 There are two cases:
>>>>                 1. Calculate packets offline (end-to-end): if i
>>>>                 want to calculate end-to-end packet delivery, i
>>>>                 used third-party Network Analyzer software.
>>>>                 2. Calculate packets online: (hop-to-hop) but since
>>>>                 i want to calculate real-time packets sent/received
>>>>                 from USRP source node to USRP destination node.
>>>>                 For instance, the network scenario is described as
>>>>                 setting up three USRPs that are connected to a
>>>>                 computer through ethernet switch. USRP source node
>>>>                 forwards data packets (or video) to second USRP
>>>>                 (i.e., relay node) and finally the second USRP
>>>>                  forwards the data packets to USRP destination
>>>>                 node. For transmission of packets i use a video file.
>>>>                 Looking forward for help. Thanks.
>>         -- 
>>         Syed Mariam 
>>         Graduate Research Assistant
>>         Sunway University (Malaysia) & Lancaster University
>>         (UK) joint program.
>     -- 
>     Syed Mariam 
>     Graduate Research Assistant
>     Sunway University (Malaysia) & Lancaster University
>     (UK) joint program.
> -- 
> Syed Mariam 
> Graduate Research Assistant
> Sunway University (Malaysia) & Lancaster University
> (UK) joint program.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160329/1425e3fe/attachment-0002.html>

More information about the USRP-users mailing list