A card can be a simpler control than a menu. Put a story card on a box, place a model beside an exhibit, or tap an album sleeve on a player: the object tells the user what to expect. For a design or education team, the hard part is usually what happens after the reader detects the tag.
Should the content restart while the card stays in place? Should removing it pause playback? What happens when someone presents an unknown card? On our bench we brought up a PN532 reader module with a Raspberry Pi Pico running MicroPython to get a real card-reading baseline for those questions. It is a reader test, not a finished media player.
Decide what one tap means
In a Storybox project on Reddit, a reader asks whether removing a figure pauses its story. The builder explains that it keeps playing; the figure has to be removed and scanned again to pause. Both behaviors are possible, but the user needs to know which one the device implements.
A different NFC jukebox project uses magnets to align a tagged case with the reader. That solves a physical problem as well as a software one: people need to know where to place the object.
For a first prototype, choose one rule you can explain in a sentence, for example "placing a new card starts its content; keeping it there does not restart it." Then test that rule with the actual card and the proposed case material.
Separate the controller link from the card link
The PN532 talks to the controller over a wired host interface. Separately, its antenna talks to the nearby card. A working serial cable does not show that the intended tag can be read through the final front panel.
We used the PN532's high-speed UART interface, called HSU in its documentation, on UART(1) at 115200 baud with GP8 transmitting and GP9 receiving. Configure the controller from the actual pins and code, not from a connector label that says something else.
On this module, MTX and MRX describe the host paths: GP8/TX connects to MTX and GP9/RX to MRX, and the module crosses transmit and receive internally. Check that convention before copying the wiring to a differently labeled breakout.
The PN532's interface-selection bits choose HSU (00), SPI (01) or I2C (10), and the board setting has to match the driver. Selecting one does not make software written for another interface work. We did not have a matching schematic for this board revision, so get one before changing its supply or selector wiring.
Use a known test tag
We presented a blue key-fob-style tag to the antenna. Its shape does not identify its radio protocol or memory layout. Use a tag with a known part or protocol description, and keep it with the test record.
Our test targeted MIFARE Classic over ISO/IEC 14443A. It does not demonstrate universal NFC compatibility. In particular, do not carry a claim of ISO/IEC 15693 support into a product requirement: the PN532 does not support it. Check the NXP PN532 documentation against the exact tag family you plan to ship.
Reading an identifier is enough to select a story in a demonstration, but it is not an authorization system. Keep a content-selection prototype separate from decisions about secure access or payment.
Bring up the reader before adding playback
Our program requested the reader's firmware version, configured the PN532's secure access module (SAM) and then polled for a card. If you reproduce it, check that the module name you import matches the file that is actually in the driver package you install; ours was named differently from what some example code expected.
This gives a useful debugging boundary. If the firmware query fails, look at the host connection and interface selection. If the reader responds but no tag appears, look at the tag, antenna position and radio compatibility before changing any media-player code.
The log shows several "No card detected" cycles followed by the four-byte UID 86 3e 29 02, successful authentication of block 4, a read of its contents and a successful write response. The test program writes sixteen 0x01 bytes to that block, so run the full sequence only on a disposable card whose contents you intend to change. A content-selection demo can start with identifier reading alone.
The log also reports entry into low-power mode. It has no current measurement and no recorded wake-up cycle, so check the wake sequence separately before it becomes the basis for battery-life or instant-wake promises.
Turn repeated reads into one deliberate action
The polling loop can see the same tag many times. Starting playback on every read would restart a story over and over, even though the person placed the card once. Add a small amount of state: remember the last accepted tag, recognize its continued presence, and decide what absence or a different tag should do.
For a tap-to-start rule, a useful test sequence is:
- place card A and leave it in place;
- remove it, then place it again;
- replace it with card B;
- present an unknown card;
- make a quick pass that only briefly enters the reading area.
Record the observed action for each case instead of judging the interaction from one successful scan.
A brief light or sound can acknowledge an accepted card. Keep that acknowledgment separate from "content started": a recognized tag may still point to a missing file or an unavailable service. The separation tells the user whether to reposition the card or wait.
When moving into a case, test tag orientation, panel thickness and nearby hardware together. The read area should be obvious from the outside. A marking, recess or shaped landing area may help more than chasing the headline reading distance.
Use the test to choose the next build
The next prototype should answer whether people can reliably choose content with the physical tokens you intend to use. It needs a defined placement area, a mapping from tags to actions, clear feedback and a repeatable rule for removal and re-presentation. Audio quality, file management and power behavior are separate integration tasks after that.
There is also a component-lifecycle decision before a custom board: NXP currently lists the PN532 as not recommended for new designs. The existing module is fine for this bench investigation, but a new product should review its reader chip and supported tag families before freezing the electronics.