Hey, I know you all are pretty busy but do you guys have a roadmap for your upcoming shields? I would really like to see a PN532 shield 
John
1 Like
Hey John! We don’t have a roadmap in place yet but we are talking to the 5 people that backed us at the CUSTOM SHIELD level, and one of them has requested that we design a shield for exactly this component. So yes, this one is in the works!
1 Like
that sounds very good!
Hi @jlkalberer, @dominikkv and others interested in a PN532 or more generally in an NFC Shield. I would like to know if you have experiences with other similar shields that you would like to share and specially what would you improve in the existing models that you might have used. I am aware of the existience of three such modules: (you’ll have to Google as I could not add more than two links as a new user)
- AdaFruit NFC Shield 1.3
- SeeedStudio NFC Shield v2
- Elechouse NFC RFID Kit
Personally, I have only used the Elechouse one over SPI. It works fine but still I think we can make a better NFC shield. One of the things I’ve considered is the possibility to use the PN544 instead of the PN532 and make sure that in terms of libraries we ideally join forces with other projects like libnfc to make it really easy, although is not sure that we can obtain documentation for the PN544 for an open source project, I’ll check if we can get that done through Spark. Would the interested readers of this thread like to share what use cases do you have in mind?
Renamed this thread “Custom Shield - NFC Shield” so that we can dig in on this topic further!
Hi Guys,
I was wondering what type of use cases this shield would be used for ?
@adrian Although I do expect we would be able to get the necessary documentation for the PN544, my gut says that we should use the PN532 since it is already being used widely in the open source community, and therefore we’ll have more resources available to develop our shield.
My suggestion is that we start with one of the three Shields you mentioned above, and build upon a design that has already been validated. Has anyone used one of the three, and if so, any feedback on these shields would be great before we get started!
@adrian I have worked with the SeeedStudio NFC shield. The libraries they have for it are ports from the AdaFruit NFC libraries. I had to hack on them quite a bit to get my arduino to work with NDEF packets coming from Android as well as mifare classic cards. I am working on a kegerator with NFC authentication In the future I want to integrate stripe or some payment API to work over NFC on my kegerator.
I am not a hardware guy so whatever chip is used does not matter to me. I just said the PN532 since there are already a bunch of libraries written but the other chip looks really nice. I think that if we could get libnfc working with one of the chips, that would be the best route. I really had to hack my implementation to get it to read cards and communicate with Android at the same time.
@zach I really can’t give much feedback on the Seeed shield other than it works as far as my purposes are concerned. The library needs some work but some guys on the Seeed forums are have been improving it a lot. When I was getting my shield to work, I read a lot of posts on the AdaFruit forum and I think that their library is a lot more solid.
One use case I have thought of is for a portable point of sale device in a restaurant.
The server takes the Spark device to the table and the customer taps their smartphone against the device and the payment is made over Wi-Fi.
Hi Zach,
I am not trying to create more work for you buddy
An idea you might want to consider is adding a microphone and speaker to this shield.
There are around 200 million NFC enabled smartphones shipped today - out of around 1 billion smartphones. It looks like Apple are going to create their own proprietary NFC.
These guys have developed a technology to enable NFC for all smartphones today :
http://nearbytes.com/en/
It uses sound to transmit the data between devices.
Fascinating! Thanks for sharing @rockvole. I don’t think we’ll need this in the current rev since there’s no need for future proofing; our development process is quick enough that if this NearBytes thing takes off, we could spin up a mic/speaker shield in a jiffy and have it on the market pretty fast.
@Rockvole That seems like pretty cool tech. I am also concerned with the fact that Apple doesn’t want to implement NFC. Personally I would love to be able to pay with my phone by tapping some device on my table. That’s my goal at least with my kegerator hardware. Tap, pay, pour.
Thanks for asking @Rockvole. The use cases of NFC devices in general can be grouped in three categories:
- A device acts as a “NFC target” which fundamentally is an RFID barcode. Instead of using a laser to read the barcode in a box or a boarding pass you touch the device with a reader (like one of those 200 million NFC smartphones) and you do something based on the contents of the tag. For example, you “check in” in FourSquare touching a core with the shield in the door (or of course, check in at school or the office).
- A device acts as an “NFC initiatior” basically the reader that reads a target, since a target can also be a much dumber and cheaper device than a Spark Core with an NFC shield. You can use an initiator to write some data in a Mifare (from NXP) or FeliCa (from Sony) sticker that you can then put in a book in a library, a piece of jewlery or a frequent flyer card and then use that inexpensive tag to get some other Spark Core + Shield to do something. This initiator an also interact with standard cards like electronic passports (those with the [–o--] sign in the cover).
- And finally, NFC allows peer-to-peer communications. This is what allows users to exchange photos or vCards between Galaxy S3 phones. In this mode, you have two more capable microcontrollers communicating over a very short range wireless channel (hence Near Field Communications) that nevertheless allows for far quicker connection than actually plugging a cable in a socket while providing the possibility for highly secure exchanges.
This is the use case that I’m more interested in because I imagine that soon some thread will be starting to discuss the security of the exchanges between the Spark Core and the Spark Cloud. There are some people who couldn’t care less as long as it works but there are also those who would say that everything going in or out of their network they want to control and authorise and monitor (or prevent from being monitored).
The main function I would like to add in an NFC shield that is not present in those already out there is the addition of a secure element that communicates with the NFC chip to provide cryptographic the capabilities required to generate, store and use keys used in cryptographically secure exchanges. The key to this is the secure core element depicted in page 20 of the PN532 datasheet. Ideally, the NFC shield with a secure core would also provide the Spark Core with cryptographic functionality for those who would need it.
With that cryptographic capability present, it is possible then then to satisfy the needs of the pragmatic -with cryptographic keys known by the Spark Cloud- as well as those of the paranoid (or those who can’t trust anyone including their governments 
) who would be provided a documented path to “jailbreak” the shield, put their own keys and do as they please including hosting their own controlling cloud in their newly created security domain. We could even create some Cryptographically Secure Virtual Currency or at least a credits based system for parking, transport, loyalty and so on.
Interesting use cases @adrian . It would be neat to have a row of parking meters with Spark Cores in them communicating with each other and sending data down via a single internet line. Then just paying for parking by tapping on the meter.
Exactly, tapping with your NFC enabled phone that would later remind you where the car is parked and give you the option to recharge remotely.
1 Like