Phase 4- NFC: Scripting and testing the arduino
Updated: May 5, 2019
The scripting and test of the NFC was bittersweet. We picked up an Arduino to use to create the nfc reader from James and proceeded to pick up a Seeed Studio's NFC shield from just outside Winchester. When we got back I plugged in the Arduino and proceeded to download the libraries needed for the shield to function. The shield was very easy to apply we just had to line up the pins to the Arduino and put it in, however the antenna was another story. We struggled for 20 minutes trying to push the clip onto the Arduino. The shield didn't come with any instructions and we were coming to the conclusions that we must have to solder it on. Luckily enough I persevered and managed to find the grip to push it on. I don't think it helped that it was so tiny. I then proceeded to copy the relevant lines of code from the Seeed wiki resource and upload it to the Arduino. I didn't have any trouble doing this and everything was really easy to find. We went to view my work in serial monitor and carry out the first test using the 'read' sketch I had uploaded. When we did we were greeted with the message "Tag is not NDEF formatted". I realised I'd bought the wrong tags pretty much straight away. I bought the tags online and was getting lost amongst NFC tags and NFC cards. Me and Rubi wanted to test some card designs so I opted for the tags that came as stickers and rushed the order through. The ones I bought were in a different frequency than the shield. For future reference I need tags that communicate at 13.56MHz.
Me getting far too over excited about, unsuccessfully, reading my
uni id card!
Uploading code to Arduino and writing messages on NFC cards
After the fiasco with the NFC tags I had to wait another week or so to receive the correct NFC cards. As I knew these were correct, I decided to format the NFC cards first. This was all very easy, I copied the code and uploaded to the board. I then placed the unformatted cards over the antenna and held for a few seconds. They all formatted within seconds. I can use this sketch in the future if I want to clear the cards of their data.
Writing NFC tags
I then proceeded to copy the writing code for the NFC shield. In the field:
NdefMessage message = NdefMessage();
I wrote in the brackets the messages for the card. For this prototype I took the names of some of our cards along with some arbitrary spell names and values. The second of line of message will contain data in the final product next semester. I then went on to upload the code for writing messages to the NFC cards. After holding them over the antenna for a few seconds the cards had been written. I then tested them with read sketch that I had created when I was trying to read the university cards the other day. All of the cards were successful and when placed above the antenna you can read the messages on serial monitor.
Process of formatting, writing and read NFC tags
As this reader is used physically within the game it needs to be located within the 3d printed cauldron. In order to for this to have power, there would either have to be a battery holder or a mains powered plug.
Data to unity problems
For the NFC cards to be used within the game, triggering the resulting AR animations,
it requires the data to be sent to the Unity and processed. I have looked online at various examples of how this can be done. There is a plugin for unity called 'Uduino' that sends this data to Unity. Here Unity will process the NFC data to see if a spell is a success or a failure and therefore which particle system to trigger. Upon further inspection I would also need this to be able to communicate over bluetooth, as the Arduino will be housed in the cauldron and will not be connected to a computer. I believe this is still achievable with bluetooth, as I can see the use of it in an app example on youtube (https://www.youtube.com/watch?v=mGzMv_IVyao). However this will require more research next semester.
After my tutorial with Adam last week I looked into the Fritzing service that creates printed circuit boards. I have identified the components that will be used for the reader are: an Arduino Uno, NFC shield, Bluetooth shield and a battery holder. However the Fritzing service uses a different NFC shield to what I have been using and I therefore do not understand where the NFC shield they use goes on the Arduino. I need to read a bit more about the Arduino and the bluetooth and battery pack in order to understand where they connect up. This knowledge will help me create a schematic and therefore have the PCB manufactured.
As we decided to apply the concept card designs to the NFC cards, I decided to re-formate and re-write the cards NFC messages. This is so they correspond to the name on the card design.
Conclusions for GPP
Looking at Beasts of Balance really inspired the project. The idea of utilising physical play to influence a digital scene lined up well with our concept of using technology as a family whilst co-located with a singular device. This led to the finding of the technology used in the game, Near-Field Communication. The technology is wireless short-range data transmission that has been utilised in products such as digital payment systems and identification cards. They have been used in the realm of games to communicate object data to a digital scene and have proved quite popular amongst children. This stemmed the idea for this project as a turn-based family game, working together combining such data to continue through a narrative. This created the idea of combining the cards in order to cast a spell, this adds to the user experience. By reading 2 NFC cards Unity will combine them to create a success rate. The NFC device will be used to write messages (data) onto NFC tags (on the ingredient cards), read the tags and send the data to the application to determine the next outcome. Research into this topic kept leading us back to the RFID (Radio-frequency identification) system in smartphones. The game requires an external reader inside the cauldron object as opposed to tapping the ingredient card to the phone. In turn Arduino’s were found as a source of computer which an NFC shield can be applied to as a reader. Using NFC cards this was tested, by adding messages to the cards which contained names and values, which was successful. The NFC card tags are imperative to get right, prior to the prototype tags in a different frequency and already formatted tags were purchased. In their sticker form it is essential that the right frequency is selected.
This resulted in the test cards being pre-maid and applied with their design. The NFC’s use to trigger a successful or failed spell requires the data to be sent to unity and processed. Unity can receive the messages from an Arduino, however a plugin called Uduino simplifies this process of data transfer. Here the game will require script to determine the combination as a success of fail and then accordingly play the result for the player. In the prototype the NFC reader/writer is powered by USB. Although appropriate for writing the messages to the tags it is a hassle for a game of this kind to be plugged into a laptop or mains. For this reason, there will need to be a Bluetooth shield, to transfer data to the app, and a battery pack, to power the Arduino. However, with this the size of the overall Arduino build becomes larger. A way to solve this is by creating a schematic and using a service such as ‘Fritzing’. As well as this Arduino will be housed in the 3D model within a compartment and cannot have a lot of wires sticking out. To create a successful and good quality outcome the project will require ‘Fritzing’s’ services to create a custom circuit board, so that it is implemented in the cauldron. This service turns individuals’ in-depth circuits into custom made boards, reducing the size of the unit. As well as this the prototype has served well for play testing, the players have been able to test the tactile nature to evaluate the touch-tap action and its suitability.