Hello,
Please what will it take to use the LimeSDR-mini as a TV whitespace or Super-WiFi(802.11af) radio?
My test frequency range is 460 - 694MHz.
Can I just configure the LimeSDR-mini to transmit and receive within this frequency range, using the soapysdr C API?
Or, do I need to program the FPGA with an IP core for 802.11af?
Please what will it take to use the LimeSDR-mini as a TVWS radio ?
Thanks.
I understand that implementing WiFi with support for even modest data rates takes a lot of processing power. There are some research implementations based on GNU Radio, that use a GPP only I think, but the throughput is pretty low. Wasn’t clear if this is for production use, but if so, using SDR to implement WiFi is likely a terrible idea.
No idea what system/waveform you would need to implement for TVWS and so it’s hard to say. I think ascertaining that would be the starting point.
Does this imply that the TVWS stack has to be implemented directly in the FPGA?
No, or maybe yes. It implies that I have zero idea what is in a TVWS stack 
What waveform/modulation does TVWS need to use? Presumably there is a standard? I don’t know…
The vast majority of LimeSDR applications are implemented entirely on the host and I can think of only two projects which use custom FPGA gateware: one where this performs FFT for an accelerated spectrogram and another where part of a DVB stack is implemented in FPGA.
One of the standards for TVWS is IEEE 802.11af (also called super WiFi). It is a variant of 802.11.
The modulation is OFDM.
What do you think will be the best approach for implementing IEEE 802.11? SDR or FPGA?
802.11af defines enhancements to the 802.11 WLAN physical layer (PHY) and medium access control (MAC) specifications to support operation in the TV white space (TVWS) spectrum in the VHF and UHF bands between 54 and 790 MHz.
I see. I just googled SDR and 802.11af and the first thing I found was this:
Which notes:
We note that SWiFi is limited by the hardware SDR delay, and does not run within the SDR FPGA. Therefore it cannot send ACK packets within the SIFS interval. It is however designed with the
goal to enable the analysis of Wi-Fi networks in ways not possible before.
That is true for most 802.11 WiFi, that there is no way over USB 3.0 to receive a full frame, fully demodulate it, confirm that it is free of errors and then send back an ACKnowledgement within the required SIFS (Short Interframe Space) time.
However for Super-WiFi(802.11af) they have bumped up the aSifsTime (120 µs for BCUs: 6 MHz/7 MHz and 90 µs for BCUs: 8 MHz) which might just nearly be enough to make the timing almost possible, but it would require an insane amount of processing power and even then the timing may not be good enough because meeting the other timing requirements would not be simple.
Ref: “23.4.4 PHY characteristics” - DOI: 10.1109/IEEESTD.2014.6744566 (behind a pay wall)
This research paper proves that it is possible ( although with some limitations). It also shows that the WiFi SDR out-performs some commercial wifi modems.
It is possible to implement with the limesdr-mini with some performance limitations. Best performance will be obtained if implemented on the FPGA.
I will give the SDR approach a try, at least, for a start.
Openwifi might be a good starting point
I don’t know how much effort it will take to implement it on the limesdr-mini.
Strongly suspect not possible. The Mini has a pretty small FPGA. May be possible with LimeSDR-USB or one of the PCIe boards, but these all use Altera FPGAs and they use Xilinx. Porting is likely to be non-trivial.
I first need to confirm if the mac80211 Linux kernel module supports the IEEE 802.11af standard before trying to extend the openwifi PHY layer implementation to support 802.11af. The mac80211 kernel module will run an OpenWRT board connected to the LimeSDR-Mini.
In general, the openwifi architecture looks like a good starting point. I guess I will have to trim down the PHY implementation on the FPGA to only support 802.11af (the essential parts) so it fits into the LimeSDR-Mini.
Hi Eshikafe,
I am very interested in the project you are working on. because for one year I am working on using TVWS in IoT applications. Why don’t you use any of the shelf IEEE802.11af transceiver modules for your application?
Thanks Yasser. I have tried searching.
Please kindly share the list of TVWS transceiver modules available commercially.
I couldn’t find any in the market. I wonder if you know any IEEE02.11af transceiver. I thought that maybe I missed something. Do you have any clue that why there is not any of the shelf radio module for this band?
The only one I can find is the GWS 5000, I would not expect it to be cheap.
The device requires GPS so that it can report it’s location, with EIRP(effective isotropically radiated power) and other information which changes from country to country when requesting spectrum. Then it needs continuous internet access to contact the correct TV White Space Database server which would be different for each country, using the correct protocol for that country to negotiate a slice of spectrum to use for a short period of time (Ofcom granting use for up to 2 hours in the UK - https://tvws-databases.ofcom.org.uk/ , FCC granting use for up to 48 hours in the US - White Space Database Administration | Federal Communications Commission and https://apps.fcc.gov/oet/translator/ ). I would have expected them all to have been using PAWS(Protocol to Access White-Space - RFC7545) databases, but every country can do it their own unique non-standard/individualistic way. I can see creating hardware as being the easy part, but getting it certified and complying with all the different legal requirements in each country would be very expensive. And then developing the software that can interact with many non-standard databases for access, I’d see as a total nightmare. Legally TX would need to be fully disabled until allocated spectrum, and then if you fail to renew your existing allocation, you would need to follow each countries individual policy requirements, which can and will change!
e.g. For Canada the “WSDB failure to access ISED database” procedure would be:
"Should the ISED database not be available, additional attempts to retrieve information from the ISED database shall be made at least once every 4 hours. If more than 12 hours has elapsed without the WSDBA being able to retrieve this information, the WSDBA shall contact ISED regarding the unsuccessful access to the ISED database.
Thereafter, a WSDB may continue to operate for 7 days, from the last successful access, unless otherwise indicated by ISED. After those 7 days, the WSDBA shall only operate in accordance with instructions provided by ISED. It is anticipated that the latter approach (i.e. contacting ISED for further instructions) would only occur in rare circumstances."
Looks very simple to implement. I will need to compare this with the 802.11af specification.