Hello,
We are a lab group trying to use LimeSDR USB with a chip we just taped out. We need to send ASK to it at 4MHz data-rate with 5% modulation depth in Manchester econding and receive OOK from the chip at 20MHz data rate with NRZ (Chip sends at -15dbm with about 40dB path loss). The applications all seem very simple but we have spent the past 3 months trying to work with our limesdr USB to do so. The lack of documentation and application notes has made this very difficult. We are making this post as a last ditch effort before just hooking up our own LNA, packet detectors etc.
We use GNU Radio Companion 3.7.11.1 downloaded from the pothos windows package
Here is a link to our zip file:
To start, we have run through all the suggested setup tests and calibration on the quick start wiki. For ASK, we use the following block diagram in GNUradio. What happens, is that no matter what complex number we type into the vector source, or read in from a file source, when we look at the output on a scope (we use a 100 GS/s scope) it either assigns the value to a 1 or 0 on the output, so OOK not ASK.
Example: Input Vector [15,20,30] Output on scope [1,1,0] (Yes it’s inverted on the scope)
We also have the issue of transmitted 1’s being longer in length than a transmitted 0.
Question 1: What are we doing wrong? How are we supposed to setup for a transmission of ASK.
Next on to OOK. We have tried many tips and tricks with OOK but are facing the limit of when we try to store data at a rate of 20MHz, we see extreme jitter on the edges and there doesn’t seem to be any way to perform clock and data recovery because the osmoscom source is already outputting these errors in baseband. There is the clock and data recovery block, but that is after the errors are in baseband so it is not a true clock and data recovery block. We also see errors if we send more than 2 1’s or 0’s in a row due to dc drift. The DC filter block does not seem to help this at all and actually seems to make the dc drift even worse. We need to collect data for at least 1 hour straight and the drift would be up to 10,000% error by then.
Question 2: Can this radio actually receive signals as high as 20MHz? Based on the limitation for decimation etc. it seems to have error rates of about 10^-2, which is unacceptable in our application.
If you can help with either case to make this board useful please let us know. We were concerned maybe it was a hardware error or bad board so we bought a second. Same errors persist.
Please Advise,
Poon Lab