discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Received data rate for wifi_rx in gnuradio


From: Bastian Bloessl
Subject: Re: [Discuss-gnuradio] Received data rate for wifi_rx in gnuradio
Date: Fri, 31 May 2019 09:56:44 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0

Hi,

the data rate of the PHY (derived from the encoding) is not similar to
link-level data rate. You would not reach the PHY data rate even if
frames would be sent back-to-back (overhead from preamble and signal
field). That being said, I'm not sure about your configuration. I don't
think there is a 5Mbps MCS.

I'm also not sure what you are trying to benchmark. Maximum TX rate,
receiver performance, or both at once. Regarding the transmitter, it is
not optimized for speed. It uses the upstream OFDM blocks, which, AFAIK,
introduce overhead from memory management.

There are several issues on the topic, e.g.:
https://github.com/bastibl/gr-ieee802-11/issues/162
https://github.com/bastibl/gr-ieee802-11/issues/146#issuecomment-447776917
https://github.com/bastibl/gr-ieee802-11/pull/32

And there is a paper:

G. Arcos, R. Ferreri, M. Richart, P. Ezzatti, and E. Grampín,
“Accelerating an IEEE 802.11 a/g/p Transceiver in GNU Radio,” in 9th
Latin America Networking Conference (LANC’16), Valparaíso, Chile: ACM,
Oct. 2016, pp. 13–19. DOI: 10.1145/2998373.2998443.

If you need high TX rates, there are easy improvements, as mentioned in
the paper and pull request.

Best,
Bastian

On 5/30/19 6:26 PM, Torell, Kent L wrote:
> Well, you could look at the raw data you've captured/processed from the Lime, 
> and process a few milliseconds of that.  Plot the amplitude, and you will see 
> the bursts of the wifi transmitter.  You can isolate a burst and determine 
> the spectral bandwidth to bound the modulation rate, then do some simple 
> demodulation to get a better measure of the modulation type (bpsk has only 2 
> phases) and rate.  Wireshark will tell you the user data rate, after the 
> transport packets are re-assembled after stripping off the header and control 
> bits of the physical layer signal.
> Kent
> 
> -----Original Message-----
> From: SG <address@hidden> 
> Sent: Wednesday, May 29, 2019 10:10 PM
> To: Torell, Kent L <address@hidden>; address@hidden
> Subject: Re: [Discuss-gnuradio] Received data rate for wifi_rx in gnuradio
> 
> Thanks for your reply.
> 
> So in the considered system, transmitter is continuously broadcasting data at 
> the rate 5Mbps using ieee802.11 protocol (BPSK modulation is used). The WiFi 
> receiver is receiving continuously using LimeSDR Mini and I am trying to 
> capture data rate after the decode and demodulation of received signal. It is 
> receiving the broadcasted data at a significantly lower rate (based on 
> wireshark capture statistics) for which I am unable to identify the reason. 
> So I was wondering if looking at wireshark file is an accurate way to 
> approach this data-rate calculation problem or something more appropriate 
> exists.
> 
> Thanks
> 
> SG
> 
> On 29/05/19 9:35 PM, Torell, Kent L wrote:
>> Wi-fi is short burst messages.   So the modulation data rate is high, but 
>> the effective user data rate is low.  'Data rate' is very context dependent.
>>
>> -----Original Message-----
>> From: Discuss-gnuradio 
>> <address@hidden> On Behalf Of 
>> SG
>> Sent: Wednesday, May 29, 2019 1:26 AM
>> To: address@hidden
>> Subject: [Discuss-gnuradio] Received data rate for wifi_rx in gnuradio
>>
>> Hi,
>>
>> I have been wondering and trying to figure out a way to calculate data rate 
>> of the wifi_rx.  One way that I thought was to check the captured statistics 
>> of the wireshark (.pcap) file generated by wifi_rx. However, these are far 
>> lower than the transmitter rate which is set to 5Mbps and the receiver is 
>> based on the gr-ieee802.11.
>>
>> Could anyone point me in the right direction for calculating data-rate in 
>> gnuradio.
>>
>> Thanks
>>
>> SG

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]