Closed kelvien closed 8 years ago
Hmm, I'm not sure offhand. I've yet to get my hands on a RPi3, but haven't had any issues with a RPi2 or BBB. I have few questions:
node-serialport
are you using?A few notes:
page 34
Timeout error in case of HSU The PN532 detects a timeout error if the complete frame is not received within a time interval corresponding to four times the duration of a 256-bytes length frame with the current baud rate used. The timeout detection starts after the reception of the LCS byte.
page 40
The PN532 has to respond to the incoming command frame within 15 ms (T Max Response Time: delay between the command frame and the ACK frame). In the case the host controller does not detect an ACK frame within these 15 ms, the host controller should resend the same command frame.
It could be the PN532 is not ready to receive a new frame and needs to have a frame resent after a delay. It's odd that as I've not ran into this myself and have maybe BBB-based devices deployed.
00 fe e2
) is not a valid full buffer, but could have been a partial frame that came in later. Could you provide the full buffer being processed ({some buffer}
in your issue). There could have been some "noise" at the front of your buffer that needs cleaned up. While working on I2C support I've added some logic to clean the front of the buffer until a valid preamble and start codes are found (basically the buffer starts with 00 00 ff
). This might help in this situation as well for UART if this is in fact what is happening.Hi, thanks for the quick response. Here is the answers for your questions:
Here is the complete debugging log that was missing in my first post:
debug: [frame-emitter] Data received <Buffer fe e2>
debug: [frame-emitter] Processing buffer <Buffer 00 fe e2>
debug: [frame-emitter] Data received <Buffer 6c 80 04 08 8e f1 08 73 12 1a fe>
debug: [frame-emitter] Processing buffer <Buffer 00 fe e2 6c 80 04 08 8e f1 08 73 12 1a fe>
As when it stops in Sending buffer ebug: [pn532] Sending buffer: <Buffer 00 00 ff 04 fc d4 4a 01 00 e1 00>
:
I agree with you that there might be a timing issue that is happening. I'm not sure how to go about this
Thank you
I think you might be right about the timing issues in the UART. I just saw this post https://frillip.com/raspberry-pi-3-uart-baud-rate-workaround/ Basically UART doesn't work properly in RPi 3 due to the new embedded Bluetooth which explains why this library does not work properly in RPi 3. I will try the workaround to make UART function properly in RPi 3 and will let you know if it works.
Interesting, that does sound related. Let me know how it goes. I hope to get my hands on a RPi 3 soon.
On Mon, Apr 11, 2016, 12:46 PM kelvien notifications@github.com wrote:
I think you might be right about the timing issues in the UART. I just saw this post https://frillip.com/raspberry-pi-3-uart-baud-rate-workaround/ http://url Basically UART doesn't work properly in RPi 3 due to the new embedded Bluetooth which explains why this library does not work properly in RPi 3. I will try the workaround to make UART function properly in RPi 3 and will let you know if it works.
— You are receiving this because you commented.
Reply to this email directly or view it on GitHub https://github.com/techniq/node-pn532/issues/9#issuecomment-208443609
Good news! It is working perfectly fine after configuring the /boot/config.txt file to accommodate RPi 3 changes in handling UART. I'm not sure what the side effect is changing the core frequency to 250MHz.
@kelvien great to hear. Care to submit a PR to add a note to the README to explain the workaround for other RPi 3 owners?
Also, I just got my RPi 3 in yesterday, but haven't even taken it out of the box yet.
Hello, I'm trying to use this library to continually poll my NFC tags and show it to user the UID of the NFC tags that are currently placed in the reader. I use your example code here:
rfid.on('ready', function() { console.log('Listening for a tag scan...'); rfid.on('tag', function(tag) { console.log('tag:', tag.uid); }); });
My NFC reader is able to scan tags for a couple of times, and it will stop after a number of scan (The number is changing) And in the debug mode, it stops on these cases:
info: [pn532] Scanning tag... debug: [pn532] Sending buffer: <Buffer 00 00 ff 04 fc d4 4a 01 00 e1 00>
debug: [frame-emitter] Data received <Buffer 00 fe e2> debug: [frame-emitter] Processing buffer <Buffer 00 fe e2> debug: [frame-emitter] Data received <Buffer {some buffer}> debug: [frame-emitter] Processing buffer <Buffer {some buffer}>
Do you know what actually is happening here?
I'm using Raspberry Pi 3, Adafruit PN532 Breakout board v1.6