Thanks for the responses. When I use the USRPs the UHD sink is placed after the OFDM Cyclic Prefixer, right after the Mutliply Const (50m). I haven't changed any settings because I remember reading in a few previous emails that the most common question people ask is "Did you change anything?"
Sadly, the delay wasn't the case, at least for the loopback mode. I reduced the amplitude of the signal by an additional 0.02, so the multiply constant is at 0.03 as opposed to 0.05. It brought the clipping well within +1, -1. Before the signal clipped past -1 but never rose above +1. No effect but I am not ruling out that it wouldn't help. The video is interesting enough that I am going to continue watching after the first half, maybe I can figure out more from there. Jon On Wed, Mar 19, 2014 at 7:50 AM, Martin Braun <[email protected]>wrote: > On 03/19/2014 12:25 AM, Jonathan Fox wrote: > > So I have the stock python scripts (tx_ofdm and rx_ofdm) located in the > > gr-digital examples and put USRP sources and sinks in the appropriate > > spots. I left sampling alone (100K for TX, 3.2M for RX) and had the > > TX/RX frequency at 500 MHz. The USRPs used are N210s with WBX > > daughterboards. I tested the USRP used for TX out by outputting a signal > > to another and looking at it on the GNU Radio spectrum analyzer. Also, > > this is through SMA cables and a 30 dB attenuator, no over the air > > transmission. I placed file sinks after each block in the process; each > > file is a binary file. After multiple runs I felt like something wasn't > > working after looking at the binary files. > > Maybe you're probably screwing up your tx signal by clipping, although I > can't say for sure from your flow graphs (where exactly do you put the > UHD sink?) See > > http://video.fosdem.org/2014/AW1125/Sunday/Tutorial_OFDM_Packet_Transceivers.webm > , > starting around ~27 mins for an explanation, or search the mailing list > archive. > > Martin > > > > > When I execute, only the file sinks placed after the Schmidl & Cox OFDM > > Synchronizer freq_offset and detect have data in them, at least their > > files have some size to them, implying something has been written. The > > file sinks after FFT (or the header/payload demux) have no data, 0 KB. > > > > When I discovered that the receive didn't work, I took the grc file > > another user made back in October with both TX mod and RX demod in the > > same flowgraph to see if that would work (files attached). Again same > > issue, all the binary files after the FFT have no data so something is > > getting screwed up in my demod. > > > > Has any user on this list run into this issue before or can offer some > > insight to why the receiver is failing? > > > > Thank you, > > > > Jon > > > > Attached is the python script, grc file, and screen shot of the TXRX > > combo in GRC. > > > > > > _______________________________________________ > > Discuss-gnuradio mailing list > > [email protected] > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
