So the stage I’m at currently is that I can get the LimeSDR to transmit the query, and the tag successfully responds with the RN16. After that however, there is a long delay (~7ms) before the LimeSDR attempts to reply with an ACK, and so the tag stops listening (at the 40 kHz BLF we’re using the reader needs to start responding within 500 us), so the communication stops there. See the figure below.
I’ve been using the same Gen 2 UFH RFID library that you were trying originally, but I never seemed to get the TX popping issues that you mentioned above. I also used the same code that you originally posted (with some slight modifications to put back in the other file sink blocks and change the file locations slightly).
I don’t seem to get nearly as much output on my screen as you do; this is all I get when I run the script:
linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_003.010.002.000-3-g122bfae1
gr-osmosdr v0.1.4-98-gc653754d (0.1.5git) gnuradio 3.7.11.1
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace airspy soapy redpitaya
[INFO] Make connection: 'LimeSDR-USB [USB 3.0] 9062000C41E13'
[INFO] Reference clock 30.720 MHz
[INFO] Device name: LimeSDR-USB
[INFO] Reference: 30.72 MHz
[INFO] Init LMS7002M(0)
[INFO] Ver=7, Rev=1, Mask=1
[INFO] LMS7002M calibration values caching Disable
gr-osmosdr v0.1.4-98-gc653754d (0.1.5git) gnuradio 3.7.11.1
built-in sink types: uhd hackrf bladerf soapy redpitaya file
'Q' to quit
[INFO] L
q
--------------------------
| Number of queries/queryreps sent : 8
| Current Inventory round : 9
--------------------------
| Correctly decoded EPC : 0
| Number of unique tags : 0
--------------------------
Is there some kind of logging parameter that I need to enable somewhere to get the more verbose output? The output pauses at ‘[INFO] L’ until either I press q or it tries 1000 attempts (as defined in global_vars.h), which takes about 20 minutes.
With regards to the latency issue, I suspect it’s to do with the USB transfer packet size - see the post I just made here for more specific details.
I also seem to get a weird unwanted sawtooth waveform in the RX, the frequency of which is affected by the sampling rate; it this something you’ve experienced? More detailed post is here ; the picture shown above is taken in the first 50ms or so of the signal where the sawtooth hasn’t started up yet.
Thanks,
DasSidG