So at the end of my post above I do mention that I managed to get that at one point. However, some time in the intervening weeks since then, I have lost the ability to replicate those results, even though I went back to (what I believe is) that exact same configuration.
Thanks for the link though, I had looked at your issue before when researching this issue but got distracted by other problems I was having with the Lime and had forgotten I had seen it. I had actually just independently found out (again) about the config.bufferLength parameter and had come back to this thread to post about it when I saw your post.
The next thing I will try with my Lime is to reduce that buffer length and see if that improves things. I’m confident that gnuradio buffers are not the issue as it’s possible to get an RFID reader working with gnuradio, many people have done this with the Ettus hardware. Unfortunately (from the perspective of my project) I’m now away from my Lime for the next few weeks so I won’t have a chance to try it out for a while.
With regards to your particular problem, I have two suggestions on what might reduce the latency:
-
Try putting the following line here:
config.performanceLatency = 0.0
The comment there which says that 1 is lowest latency is backwards, I’m fairly certain. I opened a github issue about it (my post at the start of this thread has a link to it).
-
Make sure you are running gnuradio in a way which forces your computer to prioritise running gnuradio and not get distracted by other tasks in the background. The way you can do this is to use realtime execution. Use the following command:
sudo GR_SCHEDULER=STS nice -n -20 python ./reader.py
replacing ‘reader.py’ with the name of the python code for your gnuradio flowgraph. I have to admit I haven’t really looked into how this command works, it was recommended with the RFID gnuradio library that I am using.