I have someone capture SPI data from a Texas Instruments ISO 15693 Tag. The data should look like this: E0 07 C0 9C 55 6B 67 9E, but with the Saleae, I get this hex value: 0x03/0x1F, 0x33/0x1F, 0xAF/0x1F, 0xD7/0x00, 0x00/0x10, 0x00/0x34, 0x00/0x03, 0x00/0x0C, 0x00/0xFF, 0x00/0xFF, 0x00/0x89, 0x00/0x90, 0x00/0x03, 0x00/0xC1, 0x00/0x54, 0xFF/0x12, 0x00/0x9B, 0xAF/0x10, 0x71/0x00, 0x00/0x04, 0x36/0x1F, 0xBF/0x00, 0x00/0x81, 0x3A/0x6F, 0x33/0x4F, 0x34/0x4F. From what I see in the ISO 15693 datasheet, it is Manchester encoded, but I’m unable to see the decoded data when I use the Manchester Analyzer. Can anyone help me out and make me understand how I can decode the data to match the sequence (E0 07 C0 9C 55 6B 67 9E)? Here is the .sal file. Tag.sal (46.2 KB)
It looks like typical clocked SPI data. I don’t see any data channels in your recording that hints at being Manchester encoded however, which is likely why our Manchester analyzer is not playing well with your recorded data.
Thank you for help i realy apreciate … I did try multiple comibabtion spi also, to make it match the E0 07 C0 9C 55 6B 67 9E but with the Asyc i use able to see the EO and C0 but i get framing error all the time i have no idea how to solve that… Mancester.sal (5.4 KB) Aysc.sal (13.9 KB)
What are you connected to and capturing? Is it an IC that can talk to an RFID tag, or the RF itself? The Manchester data is on the RF side, but if it is a reader/writer IC with MCU interface (like SPI or I2C) you need to read the data sheet for the serial protocol definition of the IC. So, exactly what IC and pins you are probing?
Thank you for your answer, so i have a tag reader that is send the data to a cc1101 receiver i connected my self to the cc1101 MISO/MOSI/CLK and CS and when i put the tag ISO 15693 I see it on the logic that is captured but in stead of getting the hex value ( E0 07 C0 9C 55 6B 67 9E ) I get ( 0x33/0x1F, 0xAF/0x1F, 0xD7/0x00, 0x00/0x10, 0x00/0x34, 0x00/0x03, 0x00/0x0C, 0x00/0xFF, 0x00/0xFF, 0x00/0x89, 0x00/0x90, 0x00/0x03, 0x00/0xC1, 0x00/0x54, 0xFF/0x12, 0x00/0x9B, 0xAF/0x10, 0x71/0x00, 0x00/0x04, 0x36/0x1F, 0xBF/0x00, 0x00/0x81, 0x3A/0x6F, 0x33/0x4F, 0x34/0x4F )
… which talks about a CC1101 decoder that is also available in the “Extensions” tab of the Logic 2 GUI. With that High-Level Analyzer, you can dig into the SPI messages to the CC1101 chip.
My guess is that the high-level information you are looking for, such as:
… is buried deeper in the lower-level SPI data stream.
Thus, you’ll need to dig into the CC1101 chip and specifically the datasheet to learn more about what information actually is being passed in between MCU and the IC.
[Edit] I am curious how ISO 15693 which is at 13.56 MHz is being interfaced with a CC1101, which runs at higher frequencies (315/433/868/915 MHz)? This could also be part of your problem – they may have some clever use of the hardware, but then do some software-level decoding of the bitstream, such that the hexadecimal values you’re looking for are not present in the low-level SPI traffic.
I did try that HLA is great, i also have a python parsser that will show me the data and when i pass the sal file i get :
Fifo Dump (read + write):
<op - write> : 01
<op - write> : 00
<op - read> : 00
<op - read> : 13
<op - read> : 1030030c3d36ffffffff8990ced7991803c154 This is how the tag is lloking like after the parsser, i did try evrythink and i really think that in fact the data is exncryted … that why i can not see it…
Are you sure you have the right chip (CC1101) and protocol (ISO 15693) identified?
(see above about 13.56 MHz for RFID vs. [315 - 915] MHz for CC101 IC)
Confirm: exactly what RFID reader are you using? Does it decode the tag properly at the module level?
(i.e., do you get the expected chip ID from the reader, but just not finding it in the SPI data? Did you try reading the RFID tag on a cell phone w/ NFC or ISO 15693 app?)
If you are 100% sure of IC being used, then try capturing all the SPI data from first power-up of IC
(review how chip registers are initialized for frequency settings, decoding, etc. vs. the datasheet)
Confirm if chip configuration is using a special mode (such as asynchronous serial transfer), where the data stream is actually on GPIOx pin?
Confirm the clock speed of CC1101 crystal (XOSC) input
(is it in spec range of [26 - 27] MHz? Note: might need an oscilloscope as this frequency is above Saleae’s analog bandwidth of 1 - 5 MHz)
It is really confusing to be using a chipset (CC1101) designed for a different operating frequency range than the targeted RF protocol. Just for reference, the Flipper Zero tool uses a completely different chipset for NFC/RFID HF (ST25R3916) vs. sub-1 GHz/UHF (CC1101). Also, even for RFID in the UHF band, I am not sure if CC1101 would be the right chipset choice?
So, it may help to re-check the basics: exactly what chips and RF protocols are being used, and what is actually working
Are you certain you have correctly identified the chip (CC1101) and protocol (ISO 15693)?
Yes, I used my phone to read the tag, and it indeed confirms that it’s ISO 15693. The tag’s UID is E0 07 C0 9C 55 6B 67 9E.
I have two hardware components: the sender and the receiver. The sender comprises a tag reader and a CC1101 module. When I place the ISO 15693 tag onto the tag reader, the data is transmitted to the receiver via the CC1101. The receiver also utilizes a CC1101 to receive and send data. To troubleshoot, I connected a Saleae device to the receiver’s CC1101 MISO/MOSI/CLK and CS pins. Upon placing the ISO 15693 tag, I observed some data being captured. However, the captured data isn’t clear and doesn’t match the expected UID, E0 07 C0 9C 55 6B 67 9E.
Furthermore, I conducted a comprehensive SPI capture during power-up (the .sal file is attached). The data is primarily on the MISO channel. When I capture the data asynchronously and adjust the baud rate to 76800, I can discern E0 and C0, but the remainder of the data results in a framing error. and i have no idea how to solve that… the file Asyc when i put the baudrate 76800 i see the E0 and the C0 but not the entire UID tag Code Start.sal (111.5 KB) AsycTag.sal (6.6 KB)
[Asyc76800 EO and C0 Picture](https://imgur.com/a/DmgaLas)
Looking at your data, it appears that there are a few ‘glitches’ on the SPI data channels (I saw a few 4 ns pulses that mess up decoding). It might help to either:
Improve the signal connection to target
(confirm good ground connection and any probes/clips are connected well), OR
enable the software glitch filter on your capture to eliminate short noise pulses
(e.g., something like 10 ns for each SPI channel: MISO, MOSI, Enable, and Clock)
Note: unfortunately, cannot add a glitch filter after a capture is recorded … so vote on the linked feature request if you’d like it to be implemented. Meanwhile, you’ll need to re-capture the data with a new setting, and confirm that the data is being decoded properly and glitches are removed.
Meanwhile, can you explain how AsyncTag.sal file was connected and captured vs. the Start.sal file? E.g., was Channel 2 still connected to the same pin (MISO), or did you move to monitor a different pin on the CC1101 (or to another part of the circuit)? Likewise, where was Channel 0 connected? Still on MOSI?
Note: the CC1101 does provide additional I/O: GDO0, GDO1, and GDO2 pins that may be worth monitoring as well. I believe GDO1 is on the same pin as SO (MISO), but the other two are on new/separate pins.
Thank you for your advices, i will fallow them and try to sniff the data with the Glich filer, and for the : Meanwhile, can you explain how AsyncTag.sal file was connected and captured vs. the Start.sal file? E.g., was Channel 2 still connected to the same pin (MISO), or did you move to monitor a different pin on the CC1101 (or to another part of the circuit)? Likewise, where was Channel 0 connected? Still on MOSI
The file Start.sl and Asyctag.sl has been captured in the same why, with pin connected miso/mosi/clk and cs…
Note: the CC1101 does provide additional I/O: GDO0, GDO1, and GDO2 pins that may be worth monitoring as well. I believe GDO1 is on the same pin as SO (MISO), but the other two are on new/separate pins.
I didn’t know that this my be intresting to check, thank you very much i will keep update
(Forgot to say hi)