I am currently trying to use the LimeSDR as an RFID reader. A quick summary of the relevant parts of RFID:
The reader tries to talk to an RFID tag by sending out a continuous wave (constant amplitude sine wave, around 915 MHz for my application), and then modulating its amplitude. The tag is powered by the reader’s transmitted waves, and talks back to the reader by changing how it reflects the continuous wave (backscattering).
In part of the protocol, the reader begins by sending a QUERY command. The tag then responds with an RN16 (a random 16 bit number). Upon receiving a valid RN16, the reader then needs to send another command to the tag within 500 us of the tag sending the last bit of its RN16.
So essentially, the tricky bit here in terms of latency is that the LimeSDR reader needs to see the RN16 at its RX port, get it through to the computer, process it, send the response to the TX, and the response needs to arrive at the tag, all within 500 us. I’m defining ‘latency’ here to mean the time between the last bit of the RN16 being sent from the tag, and the first bit of the reader’s response to the RN16 reaching the tag. Currently, the latency I’m achieving (measured using the RX on the LimeSDR) is around 2.5ms.
I’m using this RFID library on GNU Radio. I know that the issue is not with GNU Radio or this library, because others have successfully used this library in GNU Radio with Ettus devices.
The next layers of the software stack are gr-osmosdr, then SoapySDR, then finally the SoapyLMS7 API for the lime drivers. I’ve checked in both gr-osmosdr and SoapySDR, and to the best of my knowledge there are no buffers in either layer which could be causing the latency, so I feel like they are not the issue.
Within the SoapyLMS7 API, I have already forced the performanceLatency parameter (e.g. here) to be zero, which did improve things considerably, but only to the extent described above (note that even though it says there that the parameter should be 1 to minimise latency, this is in fact correct, and is contradictory with other parts of the LimeSuite code; I opened a github issue about this here ).
I found this thread which seems like it talks about some relevant stuff. The particular comment I linked to especially I think could be of interest, although I admit that a lot of the discussion in the thread goes a bit over my head. In the Lime streaming source there is this line which seems to be setting a streaming buffer size. The previous line defines ‘packetsToBatch’, which is related to ‘txbatchSize’ (or ‘rxBatchSize’), which is the parameter which is set by the latency parameter discussed above, and it’s already as small as it can go. The only other parameter that then controls the bufferSize is the FPGA_DataPacket size, which is defined here. I’m kind of scared to mess with this, as the buffer sizes here are defined in numbers rather than as constants, which could suggest that they’re not meant to be changed. Fiddling around with how packets are sent to the FPGA sounds like a good way to brick the board (without knowing what I’m doing at least).
Does anyone have any suggestions of what I can do to bring the latency down any more? I’ve tried a few different USB3 cables with no effect. I also installed a new USB3.1-PCIe card in my computer to see if that was the culprit, but no effect there either.
A couple of interesting things to note:
My current sample rate is 1 MS/s for the DAC, and 2MS/s for the ADC. If I try and increase these by a factor of 2 the latency does not change. If I increase these by a factor of 4 however, the application quickly seg faults. This could suggest that somewhere a buffer is being written to an invalid address (i.e. filling up more quickly than it is being emptied), or something is trying to grab samples out of an empty buffer (i.e. emptying more quickly than it is filling up)?
I have made a few other changes to the SoapyLMS7 source code in order to fix some of the other issues I have been having. These were: disabling the digital DC corrector in both TX and RX; and forcing the baseband frequency to be zero in all cases. I doubt these are relevant but have mentioned them just in case.
I realise that in this thread a while back I seemed to have solved the issue. However, for some reason I can no longer replicate those results, and I have no idea why.