# Mancester decoding issue
**URL:** https://discuss.saleae.com/t/mancester-decoding-issue/2846
**Category:** Uncategorized
**Created:** [April 29, 2024, 4:11pm UTC](https://discuss.saleae.com/t/mancester-decoding-issue/2846 "2024-04-29T16:11:56Z")
**Posts on this page:** 12
**Page:** 1
### Author:  [@levmarvel85](https://discuss.saleae.com/u/levmarvel85)
#### Post date: [April 29, 2024, 4:11pm UTC](https://discuss.saleae.com/t/mancester-decoding-issue/2846/1 "2024-04-29T16:11:56Z")
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](https://discuss.saleae.com/uploads/short-url/fCBbiSBLPWUic24cagjSj02LKuF.sal) (46.2 KB)
Thank you.
---
### Author:  [@levmarvel85](https://discuss.saleae.com/u/levmarvel85)
#### Post date: [April 29, 2024, 4:12pm UTC](https://discuss.saleae.com/t/mancester-decoding-issue/2846/2 "2024-04-29T16:12:37Z")
Hello 🙂 (Forgot to say hi)
---
### Author:  [@timreyes](https://discuss.saleae.com/u/timreyes)
#### Post date: [May 1, 2024, 12:39am UTC](https://discuss.saleae.com/t/mancester-decoding-issue/2846/3 "2024-05-01T00:39:18Z")
Hi @levmarvel85! Perhaps we can take a look at one transaction at a time to see where the issue might be taking place.
The first transaction (0x03/0x1F) is decoded as follows in the image below.
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.
---
### Author:  [@levmarvel85](https://discuss.saleae.com/u/levmarvel85)
#### Post date: [May 1, 2024, 7:04am UTC](https://discuss.saleae.com/t/mancester-decoding-issue/2846/4 "2024-05-01T07:04:27Z")
Hi Tim,
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](https://discuss.saleae.com/uploads/short-url/rgaTwir2czjnIkay3yZ5sZn6UhQ.sal) (5.4 KB)
[Aysc.sal](https://discuss.saleae.com/uploads/short-url/6KY9lqPOdzir91whRwvuSbHXaWC.sal) (13.9 KB)
---
### Author:  [@BitBob](https://discuss.saleae.com/u/BitBob)
#### Post date: [May 1, 2024, 10:33am UTC](https://discuss.saleae.com/t/mancester-decoding-issue/2846/5 "2024-05-01T10:33:38Z")
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?
---
### Author:  [@levmarvel85](https://discuss.saleae.com/u/levmarvel85)
#### Post date: [May 1, 2024, 11:39am UTC](https://discuss.saleae.com/t/mancester-decoding-issue/2846/6 "2024-05-01T11:39:52Z")
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 )
---
### Author:  [@BitBob](https://discuss.saleae.com/u/BitBob)
#### Post date: [May 1, 2024, 2:22pm UTC](https://discuss.saleae.com/t/mancester-decoding-issue/2846/7 "2024-05-01T14:22:04Z")
Okay, you might want to check out:
> [@Decode cc1101 or cc1121 data](https://discuss.saleae.com/t/decode-cc1101-or-cc1121-data/2773):
>
> Hi i’m new here and i just got my saleae analyzer, and i give it a first try i solder some bodge wire to a cc1121 module on MISO/MOSI/CS/CLK and i got some RF data but i can not understand how to interpret that data since i only get the hex value and not the function of the hex value, so my question is, is there a cc1101 or cc1121 decoder witch parse all my hex value and give me the correct function ? like in this example : Address Name HEX Value 0x00 IOCFG3 0x02 0x01 SYNC3…
… which talks about a [CC1101 decoder](https://github.com/smdjeff/saleae-cc1101) 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:
> [@levmarvel85](#):
>
> hex value ( E0 07 C0 9C 55 6B 67 9E )
… is buried deeper in the lower-level SPI data stream.
Thus, you’ll need to dig into the [CC1101](https://www.ti.com/product/CC1101) chip and specifically the [datasheet](https://www.ti.com/lit/gpn/cc1101) to learn more about what information actually is being passed in between MCU and the IC.
[Edit] I am curious how [ISO 15693](https://en.wikipedia.org/wiki/ISO/IEC_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.
---
### Author:  [@levmarvel85](https://discuss.saleae.com/u/levmarvel85)
#### Post date: [May 2, 2024, 9:58am UTC](https://discuss.saleae.com/t/mancester-decoding-issue/2846/8 "2024-05-02T09:58:48Z")
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):
\ : 01
\ : 00
\ : 00
\ : 13
\ : 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…
---
### Author:  [@BitBob](https://discuss.saleae.com/u/BitBob)
#### Post date: [May 2, 2024, 1:09pm UTC](https://discuss.saleae.com/t/mancester-decoding-issue/2846/9 "2024-05-02T13:09:18Z")
I think some of the key things to confirm are:
1. **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)
2. 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?)
3. 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)
4. Confirm if chip configuration is using a special mode (such as asynchronous serial transfer), where the data stream is actually on GPIOx pin?
5. 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](https://support.saleae.com/datasheets-and-specifications/datasheets) 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](https://blog.flipper.net/rfid/) 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](https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/488847/cc1101-rfid-reader-writer)?
So, it may help to re-check the basics: exactly what chips and RF protocols are being used, and what is actually working 🙂
---
### Author:  [@levmarvel85](https://discuss.saleae.com/u/levmarvel85)
#### Post date: [May 2, 2024, 4:56pm UTC](https://discuss.saleae.com/t/mancester-decoding-issue/2846/10 "2024-05-02T16:56:49Z")
Thank you for explaining all of this to me
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](https://discuss.saleae.com/uploads/short-url/w3mR2go8mhOhlDGiMAd9ROJgraU.sal) (111.5 KB)
[AsycTag.sal](https://discuss.saleae.com/uploads/short-url/ssUwOO7jH8c67K8QkYRuY7gcS2l.sal) (6.6 KB)
```auto
[Asyc76800 EO and C0 Picture](https://imgur.com/a/DmgaLas)
```
---
### Author:  [@BitBob](https://discuss.saleae.com/u/BitBob)
#### Post date: [May 2, 2024, 8:38pm UTC](https://discuss.saleae.com/t/mancester-decoding-issue/2846/11 "2024-05-02T20:38:46Z")
FYI –
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](https://support.saleae.com/user-guide/using-logic/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](https://ideas.saleae.com/b/feature-requests/after-capture-adjustable-glitch-filter/) … 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.
---
### Author:  [@levmarvel85](https://discuss.saleae.com/u/levmarvel85)
#### Post date: [May 3, 2024, 11:58am UTC](https://discuss.saleae.com/t/mancester-decoding-issue/2846/12 "2024-05-03T11:58:25Z")
> [@BitBob](#):
>
> 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