Cannot get this to work #6

christill · 2015-11-04T22:38:09Z

I'm using using the adafruit pn532 shield with an arduino UNO. I'm running node v0.12.7 from a Mac.

I'm running the example code to log the firmware data but the rfid.on('ready') never seems to run.

What am I doing wrong?

If I run the log I get this: (then it hangs)

debug: [frame-emitter] listening to data
debug: [hsu] Initializing serial port...
debug: [hsu] Serial port initialized.
info: [pn532] Configuring secure access module (SAM)...
debug: [pn532] Sending buffer: <Buffer 00 00 ff 05 fb d4 14 01 00 01 16 00>
debug: [hsu] Waking up PN532...
debug: [frame-emitter] Data received <Buffer 86 18 60 00 86 86>
debug: [frame-emitter] Processing buffer <Buffer 86 18 60 00 86 86>
debug: [frame-emitter] Data received <Buffer 00 60 1e 66 60 06 06 06 f8 9e 00 60 06 06 06 18 06 60 06 78 06 86 9e 00 18 06 e6>
debug: [frame-emitter] Processing buffer <Buffer 86 18 60 00 86 86 00 60 1e 66 60 06 06 06 f8 9e 00 60 06 06 06 18 06 60 06 78 06 86 9e 00 18 06 e6>
debug: [frame-emitter] Data received <Buffer 9e 00 06 06 60 06 06 06 f8 86 00 86 9e 00 f8 9e 00 fe 9e 00 7e>
debug: [frame-emitter] Processing buffer <Buffer 86 18 60 00 86 86 00 60 1e 66 60 06 06 06 f8 9e 00 60 06 06 06 18 06 60 06 78 06 86 9e 00 18 06 e6 9e 00 06 06 60 06 06 06 f8 86 00

techniq · 2015-11-05T00:43:11Z

Hmm, I've not seen this before.

Are you sure you have the PN532 in UART mode (jumper)?
Do you have an FTDI cable you could hook up your Mac directly to the PN532 (and bypass the Arduino)?
Could you explain your setup more (how the Arduino is setup between your Mac and PN532). Are you using firmata?

christill · 2015-11-05T09:35:35Z

Hi,

This is how it's wired in, Arduino uno r3, all pins are connected. I've had it working with the arduino library from adafruit running on it. But for my project I need to use it with Node. It's running firmata and connected via usb. OSX 10.9

Thanks

techniq · 2015-11-05T14:01:31Z

Ok, I think I know what the issue is.

I'm using Adafruit's breakout board as opposed to their shield but they are functionally the same. The PN532 chip can be communicated with using I2C, SPI, or UART. By default the board uses I2C on the shield (but UART on the breakout board), although this can be changed by closing the appropriate SEL0 and/or SEL1 pins for the desired mode. On my breakout board these are through holes and come with pins to solder and a jumper. On the shield it looks like there just surface mount pads.

While the I2C support has been started, it is currently not functioning/complete. Issue #2 has some discussion on finishing the support and @RaananW started to improve it but I haven't heard or progress recently.

To use UART you'll need to find out which pad (SEL0 or SEL1) to close. It appears the shield is different than the breakout board as leaving SEL0 and SEL1 "off" sets it in UART, SEL0 off and SEL1 sets SPI, and SEL0 on and SEL1 off sets it in UART (see the picture of the breakout board, there is a silkscreen inside the antenna portion to show the configurations)

The shield product page has 1 mention of UART mode (about how the 1.0 revision had the labels backwards and affected getting it into SPI or UART from the default I2C) but it should still support UART mode since it's reliant on the PN532 chip.

To resolve your issue, you have 2 options I see:

Figure out which SEL# to apply solder to so you can set it in UART mode
Try to improve the I2C code so the driver will work with it

I don't have much time right now to look at the I2C stuff myself (I'm using UART in production with great success) but can try to assist when I can. You might also want to touch base with @RaananW (just comment on issue #2) to see if he had any progress and possibly collaborate with him.

christill · 2015-11-05T14:09:58Z

Thanks for your reply.

OK, so the shield did come as a kit and I soldered the pins on myself. Just to clarify, are you saying that if I were to remove the 2 SCL / SDA pins it will then work with UART?
The silkscreen message says: "For I2C leave SEL0 and SEL1 open, For SPI close SEL0 and SEL1.

Thanks

RaananW · 2015-11-05T14:47:27Z

Hi,
The project I was working on was sadly delayed until January, I'll have the time to improve the I2C support then. But I also think the simplest solution would be to use UART.

christill · 2015-11-05T21:06:52Z

@techniq. Ok I've tried soldering only pin, the other and both and everytime the app hangs without connecting to the board. Any ideas? do I need other software installed?

techniq · 2015-11-05T21:35:41Z

You do not need any other software for this library.

I did some searching and found this forum about using libnfc with the shield (vs the breakout board) and it mentions you need to close the SEL0 but not the SEL1 pins to set the board to UART mode.

There was a lot of comments following that said they were still having trouble using libnfc with the shield (and I'm pretty sure libnfc is UART only as well, or at least used to be when I looked at it a few while ago). I did see on the last page someone appears to have it working with the following notes:

I use a FTDI breakout 5v from Sparkfun.
The FTDI TX wire goes to the the SS pin on the shield
The FTDI RX wire goes to the MOSI pin on the shield
My shield is version 1.3 so I soldered SEL0.

They also linked to to this [article]http://www.jerome-bernard.com/blog/2013/04/15/how-to-connect-adafruit-nfc-shield-to-a-mac-via-libnfc/). From the article and notes above, it sounds like you might need to solder/jumper RX to MOSI and TX to SS on the shield to align the pins. This tip was in one of the comments of the article

I had only to solder rx to MOSI and tx to SS on the shield (and as my shield is v1.3, solder SEL0 instead of SEL1... et voila!)

techniq · 2015-11-06T02:34:50Z

@RaananW thanks. I just saw your comment.

If my workload calms down around the holidays, I might take a stab at it. UART is easier to develop/troubleshoot since I can use an FTDI cable directly to my machine. For I2C, I might look at using an Arduino with firmata .

@christill Let me know if you have any success with UART on the shield, or if you take a stab at getting I2C support added.

christill · 2015-11-06T19:53:48Z

Hi @techniq. I dont think I have enough experience with this to help out with I2c.

I'm still unable to get this work. I think all the bits are there, I'm just missing something. My only goal at this stage is to get the nfc shield to work with Node via USB on a mac.

Currently I have the SEL1 pin soldered over and the other not, both lights are on, (BUSY) is always on. I can't tell if the board is in UART mode or what I need to do to get it to change.

techniq · 2015-11-06T20:12:16Z

I think you're supposed to have the SEL0 pins soldered and the SEL1 not for UART.

Also, are you using the SS and MOSI pins (or have them soldered/jumpered to TX/RX respectively)?

The adafruit breakout board works for me (and has nice jumpers for setting the mode). Worst case, spend another $40 for one?

christill · 2015-11-06T20:20:25Z

Hi @techniq. OK I'll swap them around. I'm not using any of those other pins.

Ok I might have to if this doesn't work. I wanted the shield though because I want to hookup and LED and button once activated via NFC touch.

techniq · 2015-11-06T20:55:53Z

As I quoted earlier, it looks like you'll need to solder the RX pins to MOSI and TX to SS on the shield (or just jumper wire them), as well as soldering the SEL0

I had only to solder rx to MOSI and tx to SS on the shield (and as my shield is v1.3, solder SEL0 instead of SEL1... et voila!)

christill · 2015-11-06T22:00:17Z

Hey @techniq. After putting in some jumpers I managed to get it fire up. Now rfid.on('ready') does fire and I can see the firmware etc. However now it doesn't react to a tag. Is this another wiring issue do you think? Thanks for all your help so far.

christill · 2015-11-06T22:19:04Z

@techniq Almost there! If i use the polling example, it says listening for a tag... but doesnt react if i touch it. However, if I place the tag on it, then start the app it does read the tag. I've noticed that this is when the busy light is on. It goes after about 2 seconds. I'm thinking this has something to do with it?

techniq · 2015-11-06T22:50:30Z

Can you paste the code you're running?

On Fri, Nov 6, 2015, 5:19 PM Chris Till notifications@github.com wrote:

@techniq https://github.com/techniq Almost there! If i use the polling
example, it says listening for a tag... but doesnt react if i touch it.
However, if I place the tag on it, then start the app it does read the tag.
I've noticed that this is when the busy light is on. It goes after about 2
seconds. I'm thinking this has something to do with it?

—
Reply to this email directly or view it on GitHub
#6 (comment).

christill · 2015-11-06T22:52:09Z

Sure it's

var pn532 = require('pn532');
var SerialPort = require('serialport').SerialPort;

var serialPort = new SerialPort('/dev/tty.usbmodemfd121', { baudrate: 115200 });
var rfid = new pn532.PN532(serialPort);
 
rfid.on('ready', function() {
    console.log('Listening for a tag scan...');
    rfid.on('tag', function(tag) {
        console.log('UID:', tag.uid);
    });
});

techniq · 2015-11-07T00:53:25Z

Instead of polling, try a one time scan -

rfid.on('ready', function() { 
  rfid.scanTag().then(function(tag) {
    console.log('tag:', tag.uid);
  });
});

techniq · 2015-11-07T00:56:47Z

Doesn't appear email comments can use markdown.

christill · 2015-11-07T10:14:46Z

Hi @techniq. It's the same. If I leave the tag on the reader when running the app. It will read the tag perfectly fine. If i run the app first then touch a tag on the reader, nothing.

It's like it's shorting out or something. The 'busy' light only stays on for the first second and from what I've read it should be on all the time until it detects a tag?

christill · 2015-11-07T11:22:24Z

@techniq So it seems I've had RX -> SS and TX -> MOSI and that's how i've had it working as per above. If i swap them around like suggested I get nothing.

techniq · 2015-11-07T12:57:17Z

Can you paste the log output from a scan? I'm running out of ideas.

christill · 2015-11-07T13:04:32Z

debug: [frame-emitter] listening to data
debug: [hsu] Initializing serial port...
STATUS: Application running
debug: [hsu] Serial port initialized.
info: [pn532] Configuring secure access module (SAM)...
debug: [pn532] Sending buffer: <Buffer 00 00 ff 05 fb d4 14 01 00 01 16 00>
debug: [hsu] Waking up PN532...
debug: [frame-emitter] Data received <Buffer 00 00 ff 00 ff 00>
debug: [frame-emitter] Processing buffer <Buffer 00 00 ff 00 ff 00>
debug: [frame-emitter] Frame found in buffer
info: [frame-emitter] Frame <AckFrame {"type":"Buffer","data":[0,0,255,0,255,0]}>
debug: [pn532] Response received for sendCommand <AckFrame {"type":"Buffer","data":[0,0,255,0,255,0]}>
info: [pn532] Command Acknowledged <AckFrame {"type":"Buffer","data":[0,0,255,0,255,0]}>
debug: [frame-emitter] AckFrame found in buffer
debug: [frame-emitter] Data received <Buffer 00 00 ff 02 fe d5 15 16 00>
debug: [frame-emitter] Processing buffer <Buffer 00 00 ff 02 fe d5 15 16 00>
debug: [frame-emitter] Frame found in buffer
info: [frame-emitter] Frame <DataFrame {"data":{"command":21,"body":{"type":"Buffer","data":[22]}}}>
debug: [pn532] Response received for sendCommand <DataFrame {"data":{"command":21,"body":{"type":"Buffer","data":[22]}}}>
info: [pn532] Command Response <DataFrame {"data":{"command":21,"body":{"type":"Buffer","data":[22]}}}>
debug: [pn532] Removing listeners
debug: [frame-emitter] DataFrame found in buffer
STATUS: RFID is ready
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 00 ff 00 ff 00>
debug: [frame-emitter] Processing buffer <Buffer 00 00 ff 00 ff 00>
debug: [frame-emitter] Frame found in buffer
info: [frame-emitter] Frame <AckFrame {"type":"Buffer","data":[0,0,255,0,255,0]}>
debug: [pn532] Response received for sendCommand <AckFrame {"type":"Buffer","data":[0,0,255,0,255,0]}>
info: [pn532] Command Acknowledged <AckFrame {"type":"Buffer","data":[0,0,255,0,255,0]}>
debug: [frame-emitter] AckFrame found in buffer
debug: [frame-emitter] Data received <Buffer 86 18 60 00 86 86 00 60 1e 66 60 06 06>
debug: [frame-emitter] Processing buffer <Buffer 86 18 60 00 86 86 00 60 1e 66 60 06 06>
debug: [frame-emitter] Data received <Buffer 06 f8 9e 00 60 06 06 06 18 06 60 06 78 06 86 9e 00 18 06 e6 9e 00 06 06 60 06 06>
debug: [frame-emitter] Processing buffer <Buffer 86 18 60 00 86 86 00 60 1e 66 60 06 06 06 f8 9e 00 60 06 06 06 18 06 60 06 78 06 86 9e 00 18 06 e6 9e 00 06 06 60 06 06>
debug: [frame-emitter] Data received <Buffer 06 f8 86 00 86 9e 00 f8 9e 00 fe 9e 00 7e>
debug: [frame-emitter] Processing buffer <Buffer 86 18 60 00 86 86 00 60 1e 66 60 06 06 06 f8 9e 00 60 06 06 06 18 06 60 06 78 06 86 9e 00 18 06 e6 9e 00 06 06 60 06 06 06 f8 86 00 86 9e 00 f8 9e 00 ... >

I think it's definitely something to do with the busy light not staying on.

christill · 2015-11-11T19:05:19Z

Hey,

So I've tried a few options and according to some people on a forum, UART doesn't work with the Arduino. So I'm going to purchase the breakout board. Do you recommend an FTDI cable to buy? I just want to make sure I buy the correct stuff this time.

Thanks

techniq · 2015-11-12T02:01:15Z

I have an FTDI cable that has 3.3V data lines (and 5V VCC) (bought it originally when working with a Beaglebone Black as it doesn't want 5V on the data lines). I can't find the original order, but I'm pretty sure it's this cable (it looks like it).

Adafruit recommends using a 3.3V FTDI cable as well, and actually has a link to this cable from their page. You can also get an FTDI friend which is recommended by Adafruit

Everything in your log looks good until this point:

debug: [frame-emitter] Data received <Buffer 86 18 60 00 86 86 00 60 1e 66 60 06 06>
debug: [frame-emitter] Processing buffer <Buffer 86 18 60 00 86 86 00 60 1e 66 60 06 06>
debug: [frame-emitter] Data received <Buffer 06 f8 9e 00 60 06 06 06 18 06 60 06 78 06 86 9e 00 18 06 e6 9e 00 06 06 60 06 06>
debug: [frame-emitter] Processing buffer <Buffer 86 18 60 00 86 86 00 60 1e 66 60 06 06 06 f8 9e 00 60 06 06 06 18 06 60 06 78 06 86 9e 00 18 06 e6 9e 00 06 06 60 06 06>
debug: [frame-emitter] Data received <Buffer 06 f8 86 00 86 9e 00 f8 9e 00 fe 9e 00 7e>
debug: [frame-emitter] Processing buffer <Buffer 86 18 60 00 86 86 00 60 1e 66 60 06 06 06 f8 9e 00 60 06 06 06 18 06 60 06 78 06 86 9e 00 18 06 e6 9e 00 06 06 60 06 06 06 f8 86 00 86 9e 00 f8 9e 00 ... >

Regardless of frame type (Data, Ack, Nack, Error) always start with 00 00 ff ... so I'm not sure why/how the line is getting 86 18 60 ....

It seems like this might be solvable, but at this point, I don't have much more to try at this moment. If I get my hands on a shield version of the board I could hook up my logic analyzer and try to investigate it, but it's probably better time spent to work on getting the I2C support working.

christill · 2015-11-12T09:34:55Z

Ok, thanks for that, so do you think this is an issue with the library or the wiring on the board?

Thanks

techniq · 2015-11-12T19:25:05Z

I feel like it's the wiring (primarily because you have to jumper the MOSI/SS to RX/TX pins), but since you're getting the initial frames correctly (Configuring secure access module (SAM)) it seems like it should work.

What kind of card you are scanning btw?

techniq · 2015-11-12T19:26:24Z

I've tested with NTAG203 tags, and any NTAG or Mifare Ultralight tags should work, but it's a known problem that MiFare Classics are not supported (in README).

christill · 2015-11-12T19:29:29Z

Ok, I'm using the card that came with the shield. I'm not 100% which card it is. It is reading the ID from the card though when it's already placed on the reader when the app runs. It's more like the app only runs or is 'awake' for a split second then hangs.

techniq · 2015-11-12T20:01:11Z

Hmm, looks like it comes with a MiFare Classic from their description (which I believe my breakout did as well). Maybe pick up some NTAG203 tags.

You can subscribe to this issue to track support for MiFare Classic cards.

techniq · 2015-11-12T20:02:07Z

I would try the tags before buying the breakout board (if you haven't yet) as I know the classic cards definitely won't work.

christill · 2015-11-12T20:20:39Z

Ok I'l try the tags first. Like I said though I can read an ID from the tag. The issue seems to be that the board hangs after a second (the busy light goes off). Before it does that, it reads the Mifare tag. I will purchase some NTAG203 and try that first thought. Thanks

techniq · 2015-11-12T21:58:35Z

From what I recall the UID region is consistent on all the different NFC tags/cards, but the data region was much different (page size and could be encrypted).

I created this spreadsheet when I was trying to understand the structure. See the third tab/worksheet for all the different tag types.

christill · 2015-11-13T19:31:22Z

Ok thanks. Adafruit just came back with this:

SEL0 closed, SEL1 open. SDA is TX, SCL is RX

I have SEL0 closed and SEL1 open. Not sure where SDA/SCL is

techniq · 2015-11-14T01:29:54Z

I just tested on my breakout board with my Mifare classic card and was able to run the examples/card_scan.js example without an issue (just getting the UID, not reading the card data.

I also just published 0.1.0 which drops needing 6to5/babel for ES6 support (and bluebird for Promises) and allows src/pn532.js to work directly with Node 4.0+. Might give that a try, although I think the issue is more hardware at this point (not as confident the different tags will fix your issues. Figuring the breakout board might be needed).

christill · 2015-11-14T11:41:57Z

HI @techniq. Thanks. I've update the library and it's working like before but with node 4. Makes it a bit easier.

I'm trying to figure out how to wire it based on what Adafruit have come back and said:

"SEL0 closed, SEL1 open. SDA is TX, SCL is RX"

I think that might be it then.

christill · 2015-11-14T11:49:06Z

This what I got so far and is reading the tag for first split second the app runs.

christill · 2015-11-16T09:30:53Z

This is what adafruit have come back with.

Nobody uses Serial mode on the PN532 shield, so I don't know for sure if this will work. But give it a try. Remove the jumper wires you have soldered, and try setting up software serial on pins A4 and A5. Those are also digital pins 18 and 19.

CODE: SELECT ALL | TOGGLE FULL SIZE
#include <SoftwareSerial.h>
SoftwareSerial pn532SS = SoftwareSerial(18, 19);

Is it possible to do this within your library @techniq?

techniq · 2015-11-16T14:19:28Z

That isn't something this library can do, it will need to be done on the Arduino itself (firmata).

christill · 2015-12-01T19:07:45Z

Hello @techniq. I just thought I'd let you know that I purchased the breakout board and an FTDI cable. Works like a dream first time :). Thanks for all your help.

techniq · 2015-12-01T19:33:37Z

Awesome 👍. I still plan to add I2C and experiment with using an Arduino / Firmata (for both UART and I2C). I'm glad you got it working.

christill closed this as completed Dec 1, 2015

techniq mentioned this issue Aug 29, 2018

readNdefData() is returned "UnDefine" #17

Closed

Cannot get this to work #6

Cannot get this to work #6

Comments

christill commented Nov 4, 2015

techniq commented Nov 5, 2015

christill commented Nov 5, 2015

techniq commented Nov 5, 2015

christill commented Nov 5, 2015

RaananW commented Nov 5, 2015

christill commented Nov 5, 2015

techniq commented Nov 5, 2015

techniq commented Nov 6, 2015

christill commented Nov 6, 2015

techniq commented Nov 6, 2015

christill commented Nov 6, 2015

techniq commented Nov 6, 2015

christill commented Nov 6, 2015

christill commented Nov 6, 2015

techniq commented Nov 6, 2015

christill commented Nov 6, 2015

techniq commented Nov 7, 2015

techniq commented Nov 7, 2015

christill commented Nov 7, 2015

christill commented Nov 7, 2015

techniq commented Nov 7, 2015

christill commented Nov 7, 2015

christill commented Nov 11, 2015

techniq commented Nov 12, 2015

christill commented Nov 12, 2015

techniq commented Nov 12, 2015

techniq commented Nov 12, 2015

christill commented Nov 12, 2015

techniq commented Nov 12, 2015

techniq commented Nov 12, 2015

christill commented Nov 12, 2015

techniq commented Nov 12, 2015

christill commented Nov 13, 2015

techniq commented Nov 14, 2015

christill commented Nov 14, 2015

christill commented Nov 14, 2015

christill commented Nov 16, 2015

techniq commented Nov 16, 2015

christill commented Dec 1, 2015

techniq commented Dec 1, 2015