bastibl
commented
1 year ago The DC offset looks OK, otherwise the "Amplitude" in the upper plot would be permanently high and trigger frame detection all the time. Since you're using 10MHz, I guess there is also no issue with over- or underruns. I'd just try over the air. You didn't mention an attenuator in your setup. At least for the Ettus devices you need one to avoid frying your RX port. Not sure about the specs for the Lime. Also recheck your gain. The Lime uses absolute and not normalized ([0; 1.0]) gains, no? So you should probably try values >1?
pdflynn
Hi bastibl,
I've been trying to get gr-ieee802-11 working with two LimeSDR Minis with the intent of using it to transmit arbitrary packets over the air. I'm using GNU Radio 3.9 and I've been reading through a lot of the other issues that others had that essentially came down to a large DC spike from the direct conversion architecture of some SDRs (e.g. LimeSDR, HackRF One).
My setup is as follows: On my laptop, a LimeSDR Mini is connected and running the vanilla wifi_tx.grc. The gain of the LimeSDR is set to 0 dB (I played around with many gain values and this seemed to work the best) and the "tx_gain" set to 0.75. The only change I've made other than using a LimeSDR sink is that I changed the frequency to 912 MHz in the ISM band (as that's what band I have antennas for). The TX port of the LimeSDR is connected to an SMA cable that is about 9 inches long.
On another PC, I have another LimeSDR mini with the other end of the SMA cable connected to the RX port. As I read a bunch of other issues that were having DC spike issues, I tried two things here: First, I used the filter taps you reference in issue #83 . With this setup, and some generous gain tuning (I landed on 2.0 dB for the LimeSDR receiver), I am able to receive packets through the wire if they are very short (4-5 characters), using very generous 1/2 rate FEC in either BPSK or QPSK configuration. I've also achieved the same thing using the gr-correctiq library, so here's my current receiver flowgraph:
As you can see here from this console screenshot, I sometimes receive frames, but the "instantaneous fer" (which I am guessing stands for frame error rate) is extremely high, like 99% or higher.
If it helps, here's a few screenshots of the QT GUI from the Wifi RX flowgraph. The symbols definitely look wrong, and I'm not sure how to correct any further beyond what I've done.
My end goal is using this over the air, so I need more than just this through-cable test to work (I previously tried the same tuning process over the air and could not get any frames to decode properly).
Thanks