Hi Michael,

Thank you for your quick response! I wanted the payload to be QPSK modulated. I 
put a QT Range blocks in for the gain settings on the ofdm_tx and ofdm_rx 
flowgraphs. I still can’t seem to get any better than 20% BER though, but I 
think the advice about doing a PER calculator is pointing me in the right 
direction as a lost packet would definitely screw up the BER. So thank you very 
much for the advice!!

I did have another question though regarding the metadata that still has me 
confused. If the header data is taken out of the payload, why does it still 
show up when I put a time sink after the payload gettings decoded (after the 
constellation decoder/stream CR32 blocks)? It plots the decoded bits as well as 
the packet num, carrier_offset, etc. Did I put my time sink in the wrong place?

Thank you!
Sarah

From: Michael Dickens [mailto:michael.dick...@ettus.com]
Sent: Tuesday, March 6, 2018 5:24 PM
To: Sarah Tran <st...@oceanit.com>; usrp-users@lists.ettus.com
Subject: Re: [USRP-users] OFDM TX/RX BER Calculator

Hi Sarah - A few things to note on using the default GR OFDM using real SDR 
devices that could be relevant here:

* tx data amplification: This needs to be such that the data heading to UHD 
doesn't saturate on conversion. You can visually see this if you look at the 
raw Rx signal ... it will look mostly like OFDM in the center but then have 
significant side bands. With too little Tx data amplification, the signal will 
look very OFDM, but it might end up with the average signal peaks being not far 
enough above the noise floor. The Tx data amp value depends on which 
constellation you're using for the payload. An easy way to see all of this is 
to use a graphical slider to set this value & then watch the raw Rx signal.

* rx data amplification: You generally want this "high", but you can play with 
this value to see what works best. This value generally isn't as critical as 
the Tx data amp value.

* Since OFDM sends data in packets, you really care about the Packet Error Rate 
(PER). Lose 1 packet, and you've lost a bunch of bits. The OFDM Rx uses the tag 
"packet_num" to show successful packet receipt, and increments this value by 1 
for each packet detected but invalid (whether in the meta-data header or in the 
payload). So you should be able to create a PER block that just watches for 
skips in the Rx "packet_num" tag.

* The meta-data you mention is the header, which is indeed inserted into the 
OFDM signal. It is removed on Rx, so it should not be the cause of your issues.

* It sounds almost as if the OFDM Rx is losing sync after 20% of the data is 
received, for some reason. Usually Rx sync is lost because the USRP's Tx gain 
isn't high enough, and so the Rx signal's "SNR" isn't high enough to always 
meet the sync's criteria. Maybe try playing with the USRP Tx gain & see if that 
helps.

I';m sure there are other things relevant here, but these are the ones that 
come to mind. Hope this helps! - MLD

On Tue, Mar 6, 2018, at 3:53 PM, Sarah Tran via USRP-users wrote:

I am trying to use the ofdm_tx.grc and ofdm_rx.grc to transmit data from one 
N210 controlled by a host to another N210 controlled by a separate host. 
Eventually I want to build an 8x8 MIMO system using OFDMA. I want to verify 
that the correct data is being received so I sent all of the decoded payload 
data into a file sink. The file I sent has 10e6 random samples from 0-255 being 
stored into bytes. I received at least 5x that amount to ensure that I got all 
the data. I imported the received data and the known sent data into Matlab and 
performed the cross-correlation. The figure looks kind of okay as it showed 
multiple peaks (see figure below). However when I went to actually calculate 
the BER, I never got more than 20% of the correct bits. It was behaving 
strangely as 20% of the bits would be correct in a row, and then after that it 
would just be completely wrong. I know the ofdm_tx.grc graphs inserts metadata 
into the signal, and my theory is that the meta data is also being decoded and 
it won’t match exactly what was sent in the file because of the extra 
information. My understanding might be completely off, so if anyone can clarify 
it would be greatly appreciated! I just want to be able to have a way that 
calculates the BER between what is transmitted and what is received. Thank you 
for your time!!

_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Reply via email to