Easitag Pty Ltd commissioned a machine to replace the manual process of counting and encoding large amounts of NFC tags using their Tools app (see Easiwayv NFC Tools tab). My vision was essentially a reel-to-reel lying flat, with an NFC antenna in between the two rolls. Two motors, and a number of potentiometers operating in a feedback loop provide the necessary "rolling" and tensioning of the rolls of tags. A Flask web app serves as the controls interface: users create "jobs" which are handled by routes which create entries in a shared SQLite database on the SD card of the Raspberry Pi. Once a user has created a job, there is a hardware barrier stopping the user from starting the machine remotely: a physical button must be pressed to start the machine. This button press fetches the newest job or pauses as necessary. Once a job has been completed, the user is notified via email and the machine resets to a state ready for the next job.
The most challenging aspect of the project was dealing with the limiting hardware and meeting changing requirements as the physical components were completed. The Raspberry Pi experienced intermittent voltage drops caused by the USB and Ethernet subsystems drawing too much power. This severely impacted performance at times which was very difficult to debug and I will take considerably greater care in the future to ensure my hardware is not the source of presumed complex software problems.
While Flask is an extremely powerful and lightweight framework, its performance and reliability plummets when run as part of a multi-threaded program. Simple HTTP requests were taking as long as 5 seconds to complete (on a Gigabit LAN), an unfortunate shortcoming of the technology. All hardware code was moved to a separate program and an additional issue related to the Raspberry Pi's hardware API's (GPIO) threading was discovered. Threading was swapped out for multiprocessing as the overhead from the process spawning was insignificant compared to the gains from eliminating the GPIO software interrupt performance decrease.
A second is an eternity for a modern computer program but these were the speeds being experienced by the synchronous database bindings for Python. This caused many issues such as tags being fed through the NFC antenna without being counted or encoded onto. I dabbled with using a RAM database (to eliminate write time overhead) but found the memory sharing was too intricate and not viable (given it was not supported by SQLite) -- I tried a system of asynchronous batch exporting data from the memory database to a shared on disk database but again found the lack of data integrity and race conditions outweighed the benefits. I decided to attack from a different angle, as the above techniques were also revealing other integrity issues. The stepper motors were retuned to work with more "torque" but with a considerably shorter movement cycle. The motors now await a signal from the encoding process as to whether the current tag has successfully been connected to and written to. Without this signal, their movement cycle does not continue -- the downside is that jobs now take up to 0.1s per tag longer but ensuring every single tag (in a roll of over 2000) is accounted for was worth it.
Easiwayv, Easitag's NFC brand, required an app for clients/customers to use with their Easiwayv NFC tags (and to also market the technology). I developed a rudimentary reader/writer app using Cordova and the Ionic Framework. Ultimately, the technology proved too primitive to add future required features - also performance was noticeable on older devices.
The second version of the app I wrote using Android's official API - while recreating functionality from the old app was very simple and straight forward, it appears that there is still relatively poor support for NFC in general and there are few up-to-date resources available. Indeed, it was very difficult to add more features such as Business Card records given there are no "tutorials" available, I had to find the RFC and adhere as necessary (however in retrospect, this was a cakewalk compared to WiFi records). "WiFi Connection Handover" records contain information necessary to connect to a WiFi network -- when tags with the record are tapped, your WiFi settings are decoded and your phone attempts to connect to the network. However, as of Android 5.0.0 you can long tap on a WiFi connection and write that connection to a tag ("Write to NFC tag") and Google appears to encourage this method only as there is no API to achieve similar functionality. A very thorough investigation (by me) of the Android source code yielded no results.
My solution? Using a copy of the WiFi Alliance "Wi-Fi Simple Configuration Technical Specification Version 2.0.5" I was able to replicate the functionality. By manipulating a very large number of
char arrays, I had to manually set each byte in the 150b payload for the NFC WiFi Handover. While an incredibly tedious process, it was a valuable lesson in adhering to a concrete specification (and a great ASCII refresher).
A client requirement mandated that the app supported older versions of Android, the consequence being I was restricted to a fairly old version of the Android API and many "helper" methods were unavailable. Further, many custom data types/record types were required but there was no support for such tasks and I was required to write replacement helper methods for many different record types (which I plan on open sourcing soon).
WaterWatcher is a web-based environmental research tool for the gathering, storage, management and representation of data collected by buoys which have been deployed to various waterways throughout South-East Queensland. The buoys are extremely low powered and can last up to a year in the field, allowing them to autonomously send their reading data to the WaterWatcher server (via a 3G connection) without a researcher attending to them. The system has also shown to have a greater potential for the collection of data outside the scope of water quality and waterway research. Lastly, the system includes a mobile application for field workers to quickly and easily identify a successfully deployed buoy immediately.
In the past, water quality researchers who have needed access to water quality data were confined to a manual and inefficient process of travelling out to the field and taking readings with manual tools such as Secchi disks. This method of gathering data was impractical and not scalable as it is very time consuming and relatively inaccurate in comparison to digital sensors. However, it is a very necessary process as the data is typically very valuable to researchers who may use it for models directly influencing governmental policy with respect to the environment. Another concern is that during a flood event it is extremely dangerous for a researcher to be taking measurements in rough currents with water-borne detritus (when the data is most important).
Working in a 6 person team, my role was product manager and lead developer of a buoy simulator used for various types of testing for both developers and scientists. It was an incredibly satisfying and challenging project that taught me many things about management and myself. For more information about this project, please contact me privately.
Experimentary is a whole new way of doing (and teaching) science. Experiments are introduced and explained by Dr Rob in short entertaining videos. Students then form their groups and go about conducting the experiments as explained, all the while recoding their predictions and findings in Experimentary's online lab book. Once finished, group or class results can be presented, compared and discussed. The experiments available will span all areas of science and can be selected by year level, duration, resources required or curriculum. And speaking of curriculum, there's plenty of engineering technology and mathematics in here as well. STEM hungry kids can finally get their fill, all in the one place.
I developed the prototype in tandem and am currently working on a back-end API to support a considerably more powerful and feature rich version of the platform. I cannot go into more detail publicly.