My use is for an NFC activated child’s development/entertainment device. I’ve been using a xenon with a pn532 board. I could cut costs, size, labor time for attaching the board, and bad units by using strictly the xenon, which I feel I can trust.
We have a product in a factory environment where users often are not allowed access to their phones. Sometimes we want to know that an operator has switched parts, or for a custom user sign-in feature, or for maintenance to tag in. On an operational basis, barcodes are often used to track part-related things, but NFC is a viable alternative to sign-in a part to a machine or workstation.
Basically there are a bunch of people, tasks, and items that generally need to be tracked as far as being checked in and out of a specific area or machine. While NFC isn’t the only way to do that, it is pretty much the only one that doesn’t require either engineering effort to add a barcode scanner or something else. There are other HMI’s available that can input this information, but extra HMIs add lots of complexity and potential for unnecessary IT integration.
Frankly, I can’t really think of any major use cases for tag emulation only. To me, the tag reading / interaction is the only reason I would use NFC in my industry. All other solutions require extra layers of hardware. One of the big draws of the mesh stuff is the ability to add more nodes of HMI via NFC mesh endpoints at different parts of a single workstation at a low cost and no extra integration. Essentially, if we got tag reading NFC there is a chance we would buy way more mesh hardware than otherwise (currently we would just stick to gen 2 or gen 3 gateways only).
Our software product is for managing workspaces, such as coworking hubs and corporate offices. 18 months ago we pre-ordered about two hundred Gen3 devices with a view of creating a hardware product to make everything in these businesses a lot more seamless. Bluetooth and NFC combined would allow all building users (even those that haven’t downloaded an app), to walk up to a meeting room or a desk to book it without fuss; or to walk up to the reception to sign in, register for an event or notify their host that they have arrived. There are many use cases for our industry and we’d planned to create a very configurable system that enables many different use cases.
A Bluetooth only route isn’t great for us as it requires more setup than a casual user can handle and it may exclude too many building users. NFC is so simple for the end user, it’s hard to compete with. Unfortunately, since discovering Particles ‘tag only’ NFC limitations, we’ve been selling our mesh devices and planning our next product around other hardware providers. It’s a shame as we’re huge fans of Particle.
I think it is desperately disappointing that there isn’t Type 4 support for NFC. I have been exploring similar product ideas. I hope this is one area where Particle Product Management feel that they can invest some of the Series C funding and upgrade to a latter version of the nRF5 SDK which supports read and write - at least there isn’t a hardware constraint.
Have been doing a bit of exploration of nordic’s nRF SDK - even under SDK 15.0.0 (latest is 15.3.0) they have examples for Type 4 tag which is what I believe is what everyone here is after? What works currently are; Launch App (with Android), Text Record, URI message but not NFC UART (read and write) - not sure about Wake on NFC (which would be very handy for a low power device).
It is the opposite. Nordic refer to NFC devices as polling (readers - like a smartphone) and tags. In the case of Particle Gen3 - the devices are always tags and don’t have the capability to power up and read another unpowered tag. Currently Type 2 tags are supported on Gen3 so this means they can be read by a polling device. However, if support was enabled for Type 4 tags then a Gen 3 device could read from the polling device (or the polling device could write to the tag) as well as being read by the polling device. There are further (experimental) applications where NFC can be used to setup BLE or WIFI - this is enabled by bi-directional communication.
I can imagine a use cases where gen3-powered device can be added to the existing mesh simply by tapping it on another existing device instead of going through the long complicated “claim a device” workflow.