Closed andrewpono closed 1 year ago
Hi Andrew
Thank you! It is an error in my description, I will correct it!
Below you can find a record of NFC-V tag what I used to test and develop this tool.
The specification indicates that there are two subcarriers, and the use of one or two can be selected by the VDC using the first bit in the protocol header. In my tests I was only able to see one of them, that's why only that scheme is supported in this tool.
You can capture the responses using an AirSpy receiver, with RTLSDR it is difficult due to the low sampling rate and bandwidth limit.
[NFC-V_ICODE_SLIX_record-20211023110711-b.zip] (https://github.com/josevcm/nfc-laboratory/files/13173212/NFC-V_ICODE_SLIX_record-20211023110711-b.zip)
Indeed it's the reader's job to call which modulation is to be used. In my case the reader specifies 2FSK. Attached is the capture of the transmission in question. Unfortunately it is done with the RTL-SDR, but you can still see the 2FSK part, the ASK gets decoded just fine. I have no access to the AirSpy, but I have an RSP1 that supports up to 8M sample rate. I use it for decoding the FSK, but if I load those URH IQ wave capture files into an nfc-lab, it does not demodulate either ASK or FSK. It appears you accept mono wav files that can't hold IQ data. NFC-V_ICODE_SLIX_2FSK.zip
The application supports loading IQ files as long as the wav format is correct, please send me a recording of Rsp1 to test it
Thanks!
Here's a couple of examples. RSP1 IQ looks different from the RTL-SDR for some reason. I did not look too deep into this yet, but both native SDRUno and URH produce similar wavs. When imported into nfc-lab both look upside down, when viewed in URH they are opposite polarity. Thanks for looking into this, really appreciated! RSP1-13_56MHz-6_78MSps-6_78MHz.zip
Hi Andrew
The files you have sent do not contain a valid I/Q signal, below you have the screenshot. You can see them with Audacity. Maybe it's a setting of the SW you use, have you tried SDRSharp? (https://airspy.com/download/)
A valid IQ capture must contain 2 channels with sinusoids displaced 90º over which the signal appears modulated, similar to the following example.
If you get a similar recording with 6Mbps or 10MBps you could see the responses from the tag (but it will be decoded if uses only one subcarrier).
Regards
My understanding is the sine over which the signal is modulated in your image is the beat between actual reader carrier frequency and the particular SDR frequency synthesizer (including the software setting error). In my experiments I take great care to tune the SDR to the exact carrier frequency to eliminate the beat. I can't eliminate it completely, but with DC correction I get a fairly straight base line. It simplifies further processing on my side. Due to this approach you can see some amplitude steps on my signal - it's the DC correction artifact. On the image below you can see the slow sine I can get by tuning close to the carrier prior to the DC correction. Edit: I've added a capture with no frequency tuning or DC correction applied. This one got decoded in the nfc-lab (one side only of course). So it appears you rely on that beat to demodulate the IQ properly. Sorry it did not occur to me earlier. Thanks for the hint! RSP1-13_56MHz-6_78MSps-6_78MHz_3.zip
Imagine a pure carrier signal without modulation, when demodulated by SDR using I/Q, what would you see in the recording of the I and Q channels?
Due real signal value is R=sqrt(I I + Q Q), and the carrier signal is present, you should get two pure sine waves 90º out of phase, as they appear here:
When a modulation is introduced, it appears over the I/Q waves.
To obtain its real value, the I/Q channels must be transformed to their 1 channel real component with R=sqrt(II + QQ), and with that the sine waves disappear and reveal the original baseband signal, like this:
Thanks!
Your last capture is perfect, but my SW does not recognize the response because it uses 2 FSK.
Well, if you ever feel like adding the 2FSK, you have the perfect test signal :) Thanks for the wonderful tool again!
In the Nfc-V section of the (very detailed!) doc, it says: "Card responses are encoded using manchester OOK with 848 subcarrier as of NFC-A." ISO15693-2 section 8 specifies one or 2 subcarrier FSK modulation. I've seen 2FSK indeed used in the SLIX series RFID tag chips. I can't find any mention of 848 encoding in the ISO15693. In my case only reader-to-card messages were decoded by nfc-lab, the responses were not. Otherwise really impressive tool, big thanks!