I have been using a WiFi API for relying on following link for developing WiFi receiver:
This API was developed for USRP and I am trying to use it with LimeSDR Mini. I found that LimeSDR Mini can be detected at UHD device using SoapySDR and SoapyUHD. I installed all the dependencies and ran uhd_find_devices in terminal and could detect the device. However when I run the WiFi receiver relying on above mentioned link, I am getting an error of device not found. I am unable to figure out a reason behind the non-detection. If UHD API is detecting my LimeSDR Mini then why is this API not detecting it?
Does there exist some patching between SoapySDR and UHD to work with detecting the device or there is some other issue?
UHD ( USRP (Universal Software Radio Peripheral) hardware driver) is an open source project, but … there is a non technical reason why the uhd_find_devices command will always fail with all hardware not manufactured by Ettus Research. (click in to about 20 minutes 40 seconds on the video linked to here )
But when I run uhd_find_devices on terminal, it detects limesdr mini. However, when running an API built for UHD decives it doesn’t. So what could be the reason behind that?
So, the API for USRP is now detecting my LimeSDR Mini and running when I set the data format (cpu_format) for the stream to F32. However, the processing of these data samples is done using complex double (FC64) data type. This means that Lime is receiving stream of IQIQIQ… FC32 complex data while the buffer where it is stored is of double type storing the IQ pairs (I,Q) as each complex sample. So I am not sure if this mismatch is going to affect the sample values because I am receiving weird normalized auto-correlation values (greater than 1). If so, could you suggest or point me in the right direction?
