We’re rewarding the question askers & reputations are being recalculated! Read more.

Hot answers tagged

8

Call serial.end() to stop receiving. Then call serial.begin(...) again when you want to start listening again.


6

Sorry, but I must disagree with your 'NXP datasheet is incomprehensible'. From the FIRST PAGE of the MFRC522 datasheet: 'Remark: The MFRC522 supports all variants of the MIFARE Mini, MIFARE 1K, MIFARE 4K, MIFARE Ultralight, MIFARE DESFire EV1 and MIFARE Plus RF identification protocols' Here it says the MFRC522 covers just a part of ISO/IEC 14443. The ...


5

You're reading (and doing your sums) backwards. You have 1024 bytes of data space. That data space is split into 16 sectors, so 1024 / 16 = 64 bytes per sector. Each sector has 16 bytes reserved for keys etc, so each sector has 64 - 16 = 48 bytes of user data space. 48 bytes of user data space per sector multiplied by 16 sectors is 768 bytes. ...


4

According to the link you provided, we can see that the RFID-RC522 uses SPI to communicate with Arduino. On Arduino UNO, the SPI pins are located as follows: pin 11: MOSI, pin 12: MISO, pin 13: SCK On the Arduino YUN, this is different though; as stated there (bold highlight is mine): SPI: on the ICSP header. These pins support SPI communication using ...


4

As I read your post an idea came to me that must be obvious in its simplicity. Since a chess board has pieces already on it we can simply use hall-effect sensors (dirt cheap) under each square and each piece has a magnet at its base. Since pieces on a chess board move from one square to another and the initial position of all pieces is known/constant, the ...


4

You should try adding this, at the end of readBlock(): // Halt PICC mfrc522.PICC_HaltA(); // Stop encryption on PCD mfrc522.PCD_StopCrypto1();


4

It is just so obvious that you should connect them that they did not bother to write it down. The reader needs power. That is taken as read. Without power it can do nothing. Why would they bother to waste time telling you to connect the things that you have to connect regardless? The only things that they tell you to connect are things that are specific to ...


4

For convenience, here is a comment: You wrote, “I've tried the code above but it didn't work”. That is inadequate to convey what happened and what you wanted to happen. Please edit your question to include a clear statement of symptoms and desired results. Now on to an answer. From “I'm only using 2 readers to find the correct and make it work”, I ...


4

You are using SPI comm. The code is fine too. Usually this "communication failure" happens due to wrong pin connections. Say for eg. If MOSI and MISO are interchanged. Check all connections, ground and VCC connections once more. I have also seen that soldering the pins of MFRC522, instead of simply connecting by wire has solved this issue most of the time. ...


3

From your code: void isr() { Serial.println(F("Interrupt")); mfrc522.PCD_WriteRegister(MFRC522::ComIrqReg, 0x80); //Clear interrupts } Do not do serial prints inside an ISR! They will eventually hang it. What you need to do is have a volatile variable (eg. a bool), set that in the ISR, and then check that in loop. If it changes, display it. Eg. ...


3

Looking at the datasheet for the MFR522, it is not clear that it even supports multidrop SPI. It does not mention anything about the state of the SPI output pins when the chip is not selected. It also mentions that the chip uses the slave select line to detect what communication mode to use upon startup, but does not mention anything about how the chip will ...


3

You got me ;) Since a UID is a fixed size you don't need to think in "lines", only in bytes. The most efficient way of storing the UIDs is as pure bytes. I am not familiar with that specific card and reader combination, but I will assume as an example an 8 byte UID (though this all holds true for any other length you care to choose). You treat your file ...


3

Chances are the offset headers won't allow the shield to directly plug into a breadboard. As @Majenko noted, shields have a header that is offset by 0.16" from the other headers. Since a breadboard is a strict 0.1" grid that header won't fit into the holes.


3

Why not have your class just extend the MFRC522 class? #include <MFRC522.h> class UltimateRFID : public MFRC522 { private: MIFARE_Key key; public: UltimateRFID(uint8_t ss, uint8_t rst) : MFRC522(ss, rst) {} // your other methods void initialize(); }; void UltimateRFID::initialize() { //digitalWrite(49, ...


3

The time between 2 interrupt triggers is only 8us. Also digitalRead() is a quite big function, that needs some time to execute (I don't know how much). That way it is to short for the Serial print command to execute in the leftover time. Make the following change and you will see, that it works. void loop(){ noInterrupts(); Serial.print("Program running ...


3

The code formats UUID as a string of 4 hex bytes (each bytes a pair of hex digits) separated by colons. String ID = "" Blank the string for (byte i = 0; i < 4; i ++){ Iterate over the four bytes of the UUID ID += Add the following to the string "ID" (rfid.uid.uidByte[i] < 0x10 ? "0" : "") + If the hex number to be displayed is less than 0x10, ...


2

According to the docs, SoftwareSerial doesn't support .end(), so Gerben's answer won't work here, I think. It's hacky, but you could exploit the fact that only one SoftwareSerial can receive data at a time, and create a second one, activating it with SoftwareSerial.listen(). Then .listen() again on your original SoftwareSerial, when you want to resume ...


2

Whether or not the serial data becomes available really does not matter. If you flush the port before every read rather than consuming the data, let 'er rip. If you are using interrupts, toggle interrupts on the serial pin.


2

As far as I can understand, you expect to receive byte data from the RFID reader, you would like to store this data into a single variable, and eventually print its content, or manipulate it in some way. You could do this maintaining a byte array (or uint8_t array). Let's suppose, for example, to receive a unique ID of length 4 from the RFID reader. In this ...


2

I don't think it is particularly practical, unless you make your own RFID scanner. The off-the-shelf ones generally only respond once when a particular card is in range, so you can't even detect if the card is left next the reader, or not. Also, as the range is usually quite limited (a few cm) I don't see how it could tell the difference between you being ...


2

Connect everyone to the MOSI / MISO / SCK and ground, then define every SDA all the way around. and set respectively high low depending on where you want to write. How ever im not sure if you need to set high or low if you want to read. But since you got multiple you can play around with that your self. Feel free to add to this question with the result for ...


2

Use the EEPROM. This allows data to remain intact and unchanged even when power is disconnected. As you say you're new to programming, and because I wrote a similar program just last week as an experiment for something bigger, I'll talk you through some of it. However, I'm not going to give you the whole code to copy-and-paste, I'm only going to give you ...


2

Based on some experimenting, I believe the 1st key is skipped for one of two reasons: If you follow the code flow, in loop(), PICC_IsNewCardPresent() and PICC_ReadCardSerial() called. If a "new" card/tag is present, then try_key() is called which calls PICC_IsNewCardPresent() [and PICC_ReadCardSerial()] again. Since the card/tag is not "new", ...


2

Divide 1024 bytes into 16 sectors - 1024 bytes / 16 sectors = 64 bytes per sector The first 16 bytes of each sector are used for 'management' and thus reserved. This leaves - 64 - 16 = 48 bytes (per sector) for general storage


2

I am joining this conversation VERY late, however maybe my answer can help someone who is just now looking into this. I was able to get SEVEN RC522 readers working on one Arduino! My solution was very similar to your idea, except instead of the SS pin, I used the MISO pin. If you look into how the pins work, all of them are outputs going from the master (...


2

No. Looking at the datasheet, card emulation is not a feature provided by the RC522. Another popular chip, the PN532, does seem to indicate support for that feature, however, looking at the most popular library for this chip from Adafruit, it does not implement this feature. Another library from Seeed, does seem to implement it, but it looks rather limited ...


2

First, your code isn't structured properly. It should be: success = nfc.readPassiveTargetID(PN532_MIFARE_ISO14443A, uid, &uidLength); if (success) Serial.println("Present"); else Serial.println("Card Gone"); From what I could find in the library, the reason you aren't getting either the 'Card Gone' or 'Present' message when there is no card is ...


2

Let's dissect your program a moment and see why it's not doing what you want: while (Serial.available() > 0) { So while there are characters available to read in the serial buffer rfid = Serial.read(); read one character into the rfid variable. String cardnum(rfid); Convert that character into a string. cardnum.replace("", ""); Replace ...


2

This is what I use, although admittedly not in your application. I run it from a 12V wall adaptor and adjust the output voltage to suit my requirements. The input should ideally be at least a couple of volts above the output(depends on current and temperature at 25degC and 20mA it's > 1.6V and 1.5A at the same temp it's > 2.7V). Another alternative if you ...


2

From what I can tell it's absolutely possible but will take some considerable development time and around $30-$70 of hardware per NFC terminal. Please note I would strongly not recommend this as a first project as it has a lot of individual components that all have to work together flawlessly and each is different. Properly done this will be complex software ...


Only top voted, non community-wiki answers of a minimum length are eligible