rfid: [Collection] Bad boards

I have one of these https://core-electronics.com.au/piicodev-rfid-module.html . It reports version 0xB2 but seems to work fine. I haven’t seen much mention of 0xB2 elsewhere online.

I have a bunch of boards with the HW-126 marking and sparser layout of smaller components as shown in @globalcitizen’s post above. They report Firmware Version: 0xB2 (unknown). Weirdly, they work absolutely fine with the white credit card tags they came with (at a distance of about 2.5-3cm), but will absolutely not read the blue fobs with which they were also supplied…?

I just bought one to do some early testing, it’s also 0xB2, it reads and dumps data without an issue, but it simply wont let me write to the card and tag that came with it, both MiFare 1K’s, I’d assume they’re counterfit or straight up defective. I’ve got a pack of 10 EM4035 cards coming, which i’m hoping will work.

We work with these devices in our company. We have used thousands of these readers and we are getting them from many different sellers. I have encountered many problematic readers but most of them work in some ways. However, I have noticed a correlation between reading performance and the amount of power radiated from the antenna. Some cards have a poor matching, so higher amounts of power needed to read them. So the reader needs to have good matching on the antenna impedance using capacitors. You can’t tell this by inspecting visually but it is visible on an oscilloscope screen. Here is an example of three Chinese RFID boards with different rates of success. You can tell which one works better by measuring how much energy is being radiated to the environment. You can measure this using a wire loop connected to an oscilloscope. I have used 4 turns for the measurement wire. I hope you find this useful.

I have a very similar board to the Board B posted by @ma-ze. The markings on the board itself are nearly identical, but the chip on mine is marked:

RC522 19 35 TXD5440 NXP

In software, the device identifies itself as using firmware 0x92. However, the data buffer left behind by the self-test command does not match the NXP datasheet or this library’s header:

00000000: 00 be 88 7a 99 ae e1 ae 42 28 ba dc eb bc 63 0b  ...z....B(....c.
00000010: b7 ff c6 bf 10 e3 2f 9c db 5d ed 3d 3c a4 6e 72  ....../..].=<.nr
00000020: e3 f7 e8 b9 6a ac c9 58 d2 90 e5 ac 42 82 b2 2e  ....j..X....B...
00000030: 78 cd ce 10 4d e8 fb 99 2d 62 65 7b 82 c7 57 29  x...M...-be{..W)

Unfortunately I’m not able to get close-up photos of the chip markings. I also haven’t had a chance to do any functional testing as far as reading and writing tags. I’m hoping to spend some time on that today, and I’ll update with my findings.

[UPDATE 1] During my tests today, I discovered a very peculiar interaction between the self-test functionality and the RcvOff bit of the CommandReg register. In my original test code, I sought to preserve the value of RcvOff and only modify the lower nybble containing the command to start the test. (I.e., I set CommandReg to be (CommandReg & 0xF0) | MFRC522::PCD_CalcCRC.) Since the chip’s soft-reset sequence initializes CommandReg as 0x20, the byte being written back was 0x23. In this configuration, I receive the incorrect result I described above. However, if I do not preserve RcvOff and instead simply write 0x03 to CommandReg, the self-test result matches the datasheet listing for this firmware version.

This seems very unintuitive to me. The test is described several times in the datasheet as a “digital self test,” and so I would expect a bit controlling the “analog part of the receiver” to have no effect on the results. In addition, the steps listed for starting the test do not mention clearing the RcvOff bit; the soft reset at the beginning of the sequence turns this bit on, and unless it is turned off the test will fail. Has anyone else observed this behavior and/or understand what causes the invalid result data?