techniq / node-pn532

Native Node.js driver for the PN532 NFC chip
70 stars 31 forks source link

Polling stops randomly on sending and processing buffer #9

Closed kelvien closed 8 years ago

kelvien commented 8 years ago

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:

  1. When it is sending buffer. info: [pn532] Scanning tag... debug: [pn532] Sending buffer: <Buffer 00 00 ff 04 fc d4 4a 01 00 e1 00>
  2. When it is processing buffer: 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

techniq commented 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:

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.

kelvien commented 8 years ago

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

kelvien commented 8 years ago

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.

techniq commented 8 years ago

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

kelvien commented 8 years ago

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.

techniq commented 8 years ago

@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.