Cannot get Reader mode to work

[Peterthegreat]

I can't use my ChameleonMini to read any type of cards, but emulation and other functions works.
For the emulation, I have to hold the reader at a specific distance, and even then, from the reader's perspective the emulated card is detected for a few milliseconds but it disconnects, so a full read is not finished. Most of the time it reads only a few blocks, but sometimes it manages to do a full read.

The board was soldered by me, but it passed all the tests (except the test-version one)
# ChameleonMini-master/Software/test_commands.py

..................................................F

FAIL: testVersion (__main__.TestCommands)

More info:
http://i.imgur.com/rFg0QdG.png

[Peterthegreat]

Update: Emulation works fine. It was a problem with my reader
I have seen issue #51. I am trying ISO14443A and Mifare Ultralight cards (also the dump_mfu gives a timeout)

[feifeilanniao]

My reader had the same problem before.but now it return the uid of my card .so ,i think you can try more cards,it seem that it can only work with nxp products.

[Peterthegreat]

@feifeilanniao how did you fix it? I am pretty sure I am using nxp cards. Some of them are encrypted, but the reader should see the uid anyway.

[feifeilanniao]

Do you have the oscilloscope? You can use the oscilloscope to find the problem.

[Peterthegreat]

@feifeilanniao Yes, I do have an oscilloscope. What should I measure?

[feifeilanniao]

@Peterthegreat
Oh,i had make a mistake.Maybe you use a wrong command.If you want to get the uid of you card,you should CONFIG the chameleonmini as ISO14443A_READER,then,you should use the GETUID command,instead of GETUID?.
more info:

[Peterthegreat]

I got a timeout response. I did a reflash (the self tests passed again ) and tried the windows GUI and the results are the same. Looks like a hardware problem to me.

[feifeilanniao]

try to use a oscilloscope.and make sure your chamemini can out put 13.5MHZ wave after you send the command GETUID

[feifeilanniao]

and i can get the wave in yellow in the picture from the x3,and the wave in purple from pin

[Peterthegreat]

Here is the output on X3 when reading UID. I will test the 'demod reader' now.

[feifeilanniao]

it seem that your borad can out put 13.5MHZ wave after you send a command GETUID,maybe be it is just a problem of your card.

[Peterthegreat]

Both measurements here .. It's ok that they are both the same frequency?

[Peterthegreat]

I will post the output from 2 different readers when they try to get the UID. I have multiple cards.
Anyway, at least one mifare ultralight card should be seen by the ChameleonMini

[feifeilanniao]

Ok,and you can try to set the messure time at ms level,then you can see how the card modulate the signal.

[geo-rg]

Hi @Peterthegreat
so you want to communicate with a MiFare Ultralight card. Is it credit-card-shaped? There could be problems with small tags.

Also note that for the reader also the DEMOD signal is used, not the DEMOD-READER (we know, it is a bit confusing ;) ).

[Peterthegreat]

Sorry for the late response, here are the tags I am trying to read (photos from my phone's NFC reader).
@feifeilanniao what do you mean? Increasing the timeout?
@geo-rg Hi, I am trying to read any card at the moment. 2 of them are small (Mifare 1K), the rest are credit-card-shaped. I will measure DEMOD signal and post the results.

thank you again for helping me out

[Peterthegreat]

Photos of "DEMOD" signal wen running getuid:

[feifeilanniao]

From the photos of "DEMOD" signal,i think that there is no problem with your board hardware.The problem may be come from the firmware or your cards.

[Peterthegreat]

@feifeilanniao Well, as you can see from the uploaded photos, I had the flash memory rewritten 2 times (successfully), and the self-tests results was ok each time. The cards are Mifare 1K, ISO 14443 A and Mifare Ultralight.

Reading UIDs from other reader

I can try a full chip erase and rewrite the boot-loader and flash if you think is worth a shot.

[geo-rg]

Well, actually, your DEMOD signal does not look very good. The big pulses are the readers REQA. The small ones are the cards answer. Since the reader does not recognize the answer, it directly starts the transmission of the next REQA. It looks like the pictures are taken with cards, which antennas have a shape that does not good couple with the Chameleons antenna.

On the software-side you could play with the threshold=... command to maybe recognize the cards answers.

[h3xx0x90]

I had some of the same problems, first issue was I had not turned the card on, look for a switch on the left side it is "off" by default. The second issue was the default timeout if 1000ms and it was not reading the id fast enough to before the timeout. I reset it to 5000ms and it was able to get the "101:OK WITH TEXT" and my UID.

[geo-rg]

@Peterthegreat Could you solve your problem?

[Peterthegreat]

@geo-rg You were right, the threshold solves a part of my issue. I will post some results this weekend, but there are still some major problems.

[Peterthegreat]

First, let me share how I got the reader mode to work (partially, as I am unable to read Mifare Ultralight yet) -This doesn't require an oscilloscope- . Open a serial com and set the following:

1. LEDRED=FIELD_DETECTED
2. SETTING=8
3. CONFIG=ISO14443A_READER
4. TIMEOUT=0 (or a high number)
5. GETUID

Now put 2 Mifare 1K cards below the ChameleonMini ( or make a sandwich with some NFC cards e.g. card 2 comes on top of the ChameleonMini ), as shown in this picture (the cards must not have any space between them). I suppose this will reflect some of the electromagnetic field.

Then, approach a 3rd card on the top of the ChameleonMini, again, very close to it. If the threshold level is close to the correct one, the red LED should blink. Regardless if the led blinks or not, you should now change the threshold level (490 was the one that worked for me) and try GETUID again.

Using this adjustable tool, I found the threshold value so I would have the maximum reading distance for my card. I am not sure why, but if I put the card too close to the reader, I can't get a reading. So it only works at a certain distance from the reader. Is this normal? I find it inconvenient

Note that different card shapes / card manufacturers require different threshold levels.
Of course, you can skip all of these steps and try directly a threshold level that works for you.

Because the the threshold level is brought back to default value after a power off, one solution is to hard-code the threshold level by recompiling the source code. A nicer approach would be to have the threshold level stored somewhere in EEPROM.
I will post the signal seen on my oscilloscope soon. Also, I will try to read Ultralight again.

Now, regarding my other problems with the chameleon...

1. ChameleonMini stops working after a random period of time -> no power-up LED, not detected on USB (happened when changing settings or just by powering on via USB ). Seems software related since a re-flash brings it back to life.
2. Emulation works at specific distance, and gives errors ~30% of the time. Also, the NFC reader from my bus can see the ChameleonMini but it ignores it ( looks like Mifare Classic emulation not working with some readers (Galaxy S3) #83 ).

Note that the threshold level setting is related to reader only.
I don't think they are related with the current issue, so I will start a new one.

[zenroth1752]

Excellent description of the problem. Well done for the perfect demo.

[geo-rg]

Hi @Peterthegreat,
thanks for your detailed explanation. First of all, I want to stress that the reader mode does not support anticollision and thus won't work if you try to obtain multiple UIDs or try to communicate with multiple cards.

But as I can see from your photos, you also tried reading one single card with an appropriate distance. Just to tell you how it works for the Chameleons I have here: I can put an arbitrary card directly on it and obtain its UID without adjusting the threshold. Even different card shapes are ok. There are very few cards that don't work good (In fact I only know of one). If you use the most recent firmwares and since most people seem to not have this problem, I would also take into account a hardware malfunction.

Regarding the Chameleon stopping after a random period of time: This also seems - supposing you are using a recent firmware - strongly like a hardware malfunction. If it were a software malfunction, the power LED would be still lighting. There is only a slight chance that a software error would turn off the power LED.

Regarding the emulation problems: Did I understand correctly, that even when it works, it has a 30 % error rate? Which reader are you using? We are aware that emulation does not work perfectly in every distance and relative position, which was a hardware design tradeoff. But we seldom had an error rate of 30%.

[Peterthegreat]

Regarding the emulation problem... I thought that "MFClassic_patch" was already built, so I was trying the same .hex file as in the master branch. Emulation works fine now (using the patch)

Will post more info soon

[Peterthegreat]

@geo-rg Thanks for the autocalibrate feature! It works great. I am now waiting for "readerthreshold stored in EEPROM" from @robots to be merged to the master branch.