I would like to propose an improvement to the RFID section of Bruce: adding a clear module selection in the RFID configuration menu between the standard PN532 and PN532Killer, while expanding the functionality available when the standard PN532 is selected.
Bruce already provides an impressive set of RFID features, including tag reading, cloning, NDEF writing, data writing/erasing, saving/loading tag data, and tag emulation. My proposal is mainly about making the hardware configuration more explicit and making the standard PN532 path as capable and reliable as the hardware itself allows.
Proposed configuration
In:
RFID → Config → RFID Module
add/select:
PN532
PN532Killer
The selected module should determine which implementation and capabilities Bruce uses.
For example:
PN532
Standard PN532 functionality
NFC/NDEF operations supported by the PN532
Reading supported tags
Writing supported NDEF/data formats
Saving/loading compatible tag data
Standard PN532 target/emulation functionality where supported by the hardware and protocol
PN532Killer
Existing PN532Killer-specific functionality
Existing advanced features that require the Killer hardware/firmware
Existing emulation/sniffing capabilities where supported
The important part is that selecting PN532 should not require PN532Killer-specific commands or assumptions.
Why I think this would be useful
The standard PN532 is an extremely common and inexpensive NFC controller. Many users already own ordinary PN532 boards and cannot or do not want to purchase a specialized PN532Killer device.
At the moment, it can be difficult for users to understand which Bruce RFID features are provided by the standard PN532 itself and which require PN532Killer-specific functionality.
A dedicated module selector would make this much clearer and would also allow Bruce to gracefully enable/disable features according to the actual hardware capabilities.
Standard PN532: maximum possible functionality
I would especially like to see the standard PN532 implementation reviewed and expanded to use as much of the controller's native functionality as is realistically possible.
For example:
ISO14443/NFC tag detection
UID and tag information reading
NDEF reading
NDEF writing where supported
Compatible data read/write operations
Tag type detection
Saving compatible tag information to files
Loading previously saved compatible data
Standard PN532 target functionality
NDEF target/emulation functionality where supported
Clear indication when a requested operation is not supported by the specific tag/protocol
The goal should not be to pretend that a standard PN532 can magically provide every feature of PN532Killer.
Instead, Bruce could explicitly distinguish:
Supported natively by standard PN532
Supported with limitations
PN532Killer required
This would make the firmware much more transparent and useful for experimentation and legitimate NFC development.
Emulation
I would also like the standard PN532 path to make the best possible use of the PN532's native target/emulation capabilities.
For standards-compatible test scenarios, it would be useful to have a workflow such as:
Read a compatible NFC tag.
Display the information that was successfully read.
Save compatible data.
Allow the user to select an appropriate emulation/target mode.
Start the standard PN532 target functionality.
Clearly indicate which parts of the original tag can and cannot be reproduced.
Return safely to the RFID menu after the operation ends.
If the PN532 hardware or a particular protocol cannot reproduce something, Bruce should report that limitation instead of failing silently.
Important compatibility point
I think it would be especially valuable to keep the implementation modular.
Something along the lines of:
RFID
└── Config
└── RFID Module
├── PN532
└── PN532Killer
Then the RFID subsystem can select the appropriate backend internally.
This could make future support for other NFC/RFID controllers easier as well.
Safety / scope
I am specifically suggesting this for legitimate NFC development, interoperability testing, personal tags, NDEF experimentation, and authorized security research.
For protected payment cards, access-control credentials, or other systems where copying credentials would be inappropriate or technically impossible, the firmware should preserve the existing limitations and avoid presenting unsupported operations as possible.
Expected result
The ideal result would be:
One RFID menu.
A clear module selector.
Standard PN532 works independently of PN532Killer.
PN532Killer retains its specialized capabilities.
Features are automatically filtered according to the selected hardware.
Standard PN532 uses as much of its native NFC/target/NDEF functionality as realistically possible.
Unsupported operations produce a clear explanation instead of a crash, freeze, or misleading success message.
I believe this would make Bruce's RFID subsystem considerably more approachable for users who own a regular PN532 module while preserving the advanced functionality already available through PN532Killer.
Thank you to everyone maintaining Bruce and to the contributors who have already implemented the existing RFID functionality. This is intended as a constructive feature request and, if useful, I would be happy to help test the standard-PN532 implementation on common PN532 hardware.
I would like to propose an improvement to the RFID section of Bruce: adding a clear module selection in the RFID configuration menu between the standard PN532 and PN532Killer, while expanding the functionality available when the standard PN532 is selected.
Bruce already provides an impressive set of RFID features, including tag reading, cloning, NDEF writing, data writing/erasing, saving/loading tag data, and tag emulation. My proposal is mainly about making the hardware configuration more explicit and making the standard PN532 path as capable and reliable as the hardware itself allows.
Proposed configuration
In:
RFID → Config → RFID Module
add/select:
PN532
PN532Killer
The selected module should determine which implementation and capabilities Bruce uses.
For example:
PN532
Standard PN532 functionality
NFC/NDEF operations supported by the PN532
Reading supported tags
Writing supported NDEF/data formats
Saving/loading compatible tag data
Standard PN532 target/emulation functionality where supported by the hardware and protocol
PN532Killer
Existing PN532Killer-specific functionality
Existing advanced features that require the Killer hardware/firmware
Existing emulation/sniffing capabilities where supported
The important part is that selecting PN532 should not require PN532Killer-specific commands or assumptions.
Why I think this would be useful
The standard PN532 is an extremely common and inexpensive NFC controller. Many users already own ordinary PN532 boards and cannot or do not want to purchase a specialized PN532Killer device.
At the moment, it can be difficult for users to understand which Bruce RFID features are provided by the standard PN532 itself and which require PN532Killer-specific functionality.
A dedicated module selector would make this much clearer and would also allow Bruce to gracefully enable/disable features according to the actual hardware capabilities.
Standard PN532: maximum possible functionality
I would especially like to see the standard PN532 implementation reviewed and expanded to use as much of the controller's native functionality as is realistically possible.
For example:
ISO14443/NFC tag detection
UID and tag information reading
NDEF reading
NDEF writing where supported
Compatible data read/write operations
Tag type detection
Saving compatible tag information to files
Loading previously saved compatible data
Standard PN532 target functionality
NDEF target/emulation functionality where supported
Clear indication when a requested operation is not supported by the specific tag/protocol
The goal should not be to pretend that a standard PN532 can magically provide every feature of PN532Killer.
Instead, Bruce could explicitly distinguish:
Supported natively by standard PN532
Supported with limitations
PN532Killer required
This would make the firmware much more transparent and useful for experimentation and legitimate NFC development.
Emulation
I would also like the standard PN532 path to make the best possible use of the PN532's native target/emulation capabilities.
For standards-compatible test scenarios, it would be useful to have a workflow such as:
Read a compatible NFC tag.
Display the information that was successfully read.
Save compatible data.
Allow the user to select an appropriate emulation/target mode.
Start the standard PN532 target functionality.
Clearly indicate which parts of the original tag can and cannot be reproduced.
Return safely to the RFID menu after the operation ends.
If the PN532 hardware or a particular protocol cannot reproduce something, Bruce should report that limitation instead of failing silently.
Important compatibility point
I think it would be especially valuable to keep the implementation modular.
Something along the lines of:
RFID
└── Config
└── RFID Module
├── PN532
└── PN532Killer
Then the RFID subsystem can select the appropriate backend internally.
This could make future support for other NFC/RFID controllers easier as well.
Safety / scope
I am specifically suggesting this for legitimate NFC development, interoperability testing, personal tags, NDEF experimentation, and authorized security research.
For protected payment cards, access-control credentials, or other systems where copying credentials would be inappropriate or technically impossible, the firmware should preserve the existing limitations and avoid presenting unsupported operations as possible.
Expected result
The ideal result would be:
One RFID menu.
A clear module selector.
Standard PN532 works independently of PN532Killer.
PN532Killer retains its specialized capabilities.
Features are automatically filtered according to the selected hardware.
Standard PN532 uses as much of its native NFC/target/NDEF functionality as realistically possible.
Unsupported operations produce a clear explanation instead of a crash, freeze, or misleading success message.
I believe this would make Bruce's RFID subsystem considerably more approachable for users who own a regular PN532 module while preserving the advanced functionality already available through PN532Killer.
Thank you to everyone maintaining Bruce and to the contributors who have already implemented the existing RFID functionality. This is intended as a constructive feature request and, if useful, I would be happy to help test the standard-PN532 implementation on common PN532 hardware.