ReadUidMultiReader is not working

[giddel]

I've tried the Ino with minimal changes (other pins). As long as 2 readers are physically plugged, nothing works. But if one reader is removed physically from the breadboard, the other works fine. It does not matter, which reader is plugged. Both are working fine with this Ino if they are the only reader. All tags get regognized. Nothing goes if both readers are wired. I've checked the wiring more than once. I have no more idea. Any hints?

[lmmeng]

@giddel: it is working for me quite well on more Arduino boards (Uno, Leonardo, Nano). Please post your changes (actually the full setup will be better). Please post the readers' versions also (read them after mfrc522[reader].PCD_Init(ssPins[reader], RST_PIN); // Init each MFRC522 card with a command like byte readReg = mfrc522[reader].PCD_ReadRegister(mfrc522[reader].VersionReg); and print them)

LE The library version will be also interesting.

[Rotzbua]

@giddel I suggest wrong pins for both SS

[giddel]

The pins are: ...

define RST_PIN 10

define SS_1_PIN 9

define SS_2_PIN 8

... on my Arduino Nano.

@lmmeng: which "library" do you mean? I use the lib here from this project.

I will rebuild the complete layout on the board and come back then.

[lmmeng]

I was meaning the library's version, but as long the sketch is compiling, I suppose is OK. From the software point of view, it looks OK for me, but as @Rotzbua says, it looks like a SS problem. Please check the connections to don't have a short-circuit between the two SS.

[giddel]

So. I'v rebuild the complete layout on my breadboard - without any changes of the pin layout against the example sketch here.
And I gave the two readers a separate power supply of 3,3V.

But: nothing changed. The one reader works, the other reader works, both together don't work.

I'm using the latest library version from the repo here: 1.1.8 The output of "VersionReg" is "0" for each reader.

[lmmeng]

Hello @giddel, You say you have the layout on the breadboard. How long are the connecting wires? Have you connected the grounds of the Arduino and MFRC522s together? The version you are reading is also strange. Till now I've seen 0x11, 0x91, 0x92. Are you reading the version with only one reader connected, or with both of them? Do you have any pull-ups/pull-downs on the wires? Something on MISO signal? As a side note, I'm using without issues one Arduino (different types of) with two readers, all supplied from the USB port of my laptop.

[Rotzbua]

0 means there is a connection problem. Try not connect the reset pins or connect them with the hardware reset pin of the arduino.

[dgriggs]

I'm having a similar issue as giddel. When I call the versions of 2 connected RFID readers, I get 146 (in hex: 0x92) for the zeroth reader, and 0 for other. When I hook up 6 readers, I get 146 again for the zeroth and 0s for all the rest. When I hook up 10 readers I get 0s on all of them. Occasionally one of them will read chip UIDs, but sporadically. Hooking one up alone works every time.

@lmmeng please describe the setup you used to comm with 2 boards. Does SPI not travel well across 1-2 ft of typical 18 gauge single-core wire? I'll have my oscilloscope tomorrow to check for signal issues. I'm daisy chaining everything except Slave Selects (which are all in separate Arduino Uno I/O pins 3-9 and 17-19). Yet somehow I'm not connecting to most of my boards.

@Rotzbua I tried leaving reset pins unconnected and also connecting to hardware reset, both resulted in all 0s for VersionReg's

[dgriggs]

Hmm just tried 6 readers again and got 146 for the first 4, 0s for the last 2. Not sure what's changing between these trials? I'll check for loose breadboard connections again... continuity test showed all wires successfully daisy chained, but maybe the readers are sensitive?

I tested all 10 readers one at a time with the example code DumpInfo. All cards read out 0x92 version 2.0 and successfully read the same chip with correct data output.

[Rotzbua]

May try: https://github.com/julienrat/rfid/commit/2e350323a82ab5a84f02db71137ff6f2399b64b7

[lmmeng]

Hello @dgriggs, I've used the combination "one controller - two readers" in more combination (with arduino & ESP8266); all worked as expected. I've done the first tests using a hand wired (holes) PCB; a picture before adding the second reader is at http://forum.rocrail.net/viewtopic.php?f=45&t=9965&start=105#p99580 . I've placed the second reader (a new male connector) on free side (right side in the picture) of the board. No special precaution by "routing" - some signals are carried from one connector to the other, some are in parallel. One reader is connected directly (female connector on the MFRC522 board) and one with ~20 cm cable (no idea how thick). Maybe you can test with some slower SPI clock. Because all SPI transactions are "resetting" the communication to the SPI_CLOCK_DIV4, I'll try to change the define for this (in the spi.h file) to a slower one.

I hope I could help a little.

[dgriggs]

@lmmeng no permission to view files at that forum. I tried making a login but for some reason the site will not accept my email address :/

This is all helping, thank you for the timely response!

@Rotzbua I believe a longer startup time is helping, but with all 10 it still fails (all 0's). I'll keep toying with it and see what I come up with.

[Rotzbua]

I agree with @lmmeng, the example works with arduino or esp8266 and two readers. Here a pic of esp:

10 readers is a lot. Maybe you need a additional power source for the readers. Or the amount of readers have a significant capacity, so it cause some timing delays of SPI. So as lmmeng wrote, lower SPI speed will be a solution.

[dgriggs]

Thanks! I figured the code wasn't meant for 10+ readers, no surprise there. I'm at a point where I'm at least getting non-zero VersionReg values from all 10 readers, but only the last one read 0x92, the others were one 0x82 and eight 0xEE's... not sure what to make of that. I'll try slowing down the SPI, although I'm not experienced in manipulating libraries (as you can see from my problems with yours hehe).

[dgriggs]

For now i'd like to at least get my Uno working with 2 of em... I have 0x92 from both readers, but one of them won't read my chips, only one.

[lmmeng]

Hi, sorry for (not being able to view) the picture. I'm always connected, never knew the pictures are hidden. But you lost nothing, is probably an example of how the things shouldn't be done. Back to your problem, I think the easiest way to slow down the SPI communication will be to change the file ../arduino/hardware/arduino/avr/libraries/SPI/SPI.h and replace the line

#define SPI_CLOCK_DIV4 0x00 /*the real value for SPI_CLOCK_DIV4*/

with something slower

#define SPI_CLOCK_DIV4 0x03 /*the value for the SPI_CLOCK_DIV128*/

[dgriggs]

Didn't seem to help, same results of one VersionReg being weird (0x82 instead of 0x92) with no card reading capability, and the other working just fine.

Plugging in a common RESET pin to pin2 of the Uno fixes the VersionReg weirdness, but still only one reader reads.

I should mention, all I want are the UIDs of 10 cards that could come near, match them to the correct 10 readers to unlock a puzzle. I may even be able to manually communicate with the readers perhaps? Instead of using SPI? Maybe I don't need this library at all if there's a simpler way to do what I want (since I don't need 95% of what the library does)?

Dunno if I have time to make that happen though, if not I'll just buy 10 Pro Micros or something to avoid the whole issue.

[lmmeng]

Sorry, except the @Rotzbua's idea to check the supply I don't have any other. And maybe the communication levels. The MFRC522 is 3.3 V supplied and theoretically a level converter (3.3V <-> 5V) on the SPI signals is also needed.

[wgh000]

Did you resolved this?

[Rotzbua]

@giddel Hi. Did you found a solution? Or a more detailed bug description? Otherwise I will close this issue.

[dgriggs]

I never found a solution with your library. The solution is to use multiplexers for each arduino pin: SCK, MOSI, MISO, then bring every card's SDA pin to GND so they are all selected. Then you initiate just one class object, and start it for each card in turn. That way you can have as many RFID readers in communication as you want, limited only by the multiplexers. Works great, but slows down a bit above 16 readers. I read somewhere that the slave select pins are somehow not actually functional, as if the manufacurer screwed up and they cannot reliably be used as normal serial slaves.

[giddel]

@Rotzbua Actually I'm not working on this theme - because it's summer ;-) I'll be back again in late autumn. If the other participants in this thread have no more to say, you can close it.

@dgriggs: I think I come back to you if I will continue the work.

[Rotzbua]

@giddel Ok, I think we have many suggestions how to solve this issue. The solution @dgriggs seems also good. I will close this until you may want to reopen this. Best.

[CRImier]

In my experience, it seems like the slave select pins are indeed kinda useless. I've solved this in my own way. My technical requirements concerning this problem were, at the time, different - 5 readers, separate RESET and CS pins, only one reader needed to scan for a tag at a time (RFID tag test jig). My solution to this problem was, in short, like this:

1) hold all readers in RESET all the time (all RESET pins low) 2) when you need to scan from a certain reader, bring its RESET high and do PCD_Init(), then read 3) once you need to switch to a new reader, put the old one into RESET first, then do the 2) step

If I needed to scan all of the readers simultaneously, I'd use something like 74HC125 to buffer the SCK line on CS signals and not let the SCK signal pass through to the reader until the reader is the one selected. MISO might need to be buffered, too.

[Thibaultbbb]

I've got 5 readers working by manually setting the Slave Select in the Setup method.