Open spuder opened 1 week ago
I'm warming up to NFC (NTAG216) because of the ability to read/write from phones. My biggest focus is on compatibility, and some printers already have RFID readers in them (Eg Bambu).
You already mentioned that the hardware for reading MiFare often has the ability to read NTag216 too, which satisfies the backwards compatibility requirement.
The current RFID tags for OpenSourceRFID call for MiFare Classic 1K tags
While these tags are cheap and ubiquitous; they do not support NFC Forum Type 2 NDEF records
Proposal for change
OpenSourceRFID should transition from
MiFare Classic 1K
to eitherMiFare ultralight
or
NTAG215/216
Reasoning
There are 3 stakeholders in the OpenSourceRFID protocol
Stakeholders 1 & 2 are well served with MiFare Classic 1K. Stakeholder 3 would be better served with an interface that allows reading RFID tags with a cellphone.
Example Use Case
End user picks up filament spool, touches their phone to the tag, and is able to view metadata about the spool (hex color, temperature ranges, manufacture date, ect...). The user benefits by being able to view information without requiring access to specialized RFID reading hardware (RFID Reader, 3d printer ect...)
Demo
NFC Phone Example - Youtube
Technical information
In the above proof of concept, a single
http://
ndef record is written to the NFC tag. (For IOS users it's essential that the NDEF record be record 0). The ndef record provides query string parameters to a website. The NFC tag contains as little information as possible and defers the presentation/business logic to javascript on the website.Here the only required information is
Example javascript
Considerations
Cost differences: A quick search of aliexpress/amazon found Ultralight and NTAG 215 for less money than Classics (in small batches). Production costs would likely be very different.
Memory Size NTag 216 has a size of 888bytes. While smaller than the Classic, 888 bytes should be sufficient.
By comparison, the OpenSpool protocol uses NTAG 215 with 500 bytes tags and has yet to exceed 300 bytes in any real world situation.
Call to action
Criticisms, observations, rebuttals, opinions welcome. I invite the community to weigh on on this proposal.