Polling stops randomly on sending and processing buffer
kelvien opened this issue · 6 comments
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:
- 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> - 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
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:
- What version of Node are you using?
- What version of
node-serialportare you using? - Are you just running the example code, or is it part of a large application? If it Is within an application, are you using anything like electron?
- Roughly how quickly does the problem typically show up (within 10 scans, after a few minutes, etc)?
A few notes:
- The buffer being sent is a valid frame for scanning a tag. One place the library needs some work though is with error handling/retrying, especially with UART (HSU) support. Two particular notes in the PN532 User Guide
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.
- The received buffer (
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 with00 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:
- I am using Node v.4.0.0 in my Raspberry Pi 3
- node-serialport is in version 2.0.6
- My code to test this is just the example code.
- This can happen after the first scan up to the fifth scan. I haven't seen it poll NFC tags beyond that.
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
#9 (comment)
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.