We’re currently involved in a national JISC programme to support the wide scale implementation of Learning Analytics in UK Higher Education (Sclater and Footring, 2016). A Learning Analytics readiness review undertaken at the University of Brighton by JISC indicated that the University could improve the speed at which attendance data is gathered and processed, as timely analysis of attendance data in other institutions has been
(Sclater, 2014).
The eLearning team looked for opportunities to improve our attendance data gathering, and talked to Deshinder Singh Gill in the school of Computing Engineering and Maths, who has been using an RFID card reader to log student cards for a number of years.
The device reads the userID into a spreadsheet on a standalone PC, and the data is then handled by the Course Administrators to construct an official register.
It was envisaged that this system could use a web form to improve efficiency, however following discussions it was identified that the standalone PC is not connected to the network, and that using the networked lectern PC was impractical, as there are always a few stragglers who come in late. Wide scale adoption of any solution would also be hampered by the cost of the Unicard scanner at around £200.
A better solution would be to have a standalone unit, like a wall mounted card swipe.
The JISC consultants highlighted the approach taken at Aberystwyth University who had deployed a large number of Arduino based Mifare card readers as part of their attendance tracking offering, and it was the Aberystwyth approach that prompted this project, with an aim of creating some inexpensive devices which could gather attendance data for use in our Learning Analytics Pilot activities.
I took the opportunity to meet the Aberystwyth University team at the JISC offices in Castle Park Bristol during a workshop to devise a specification for attendance recording.
Leslie Johns from Aberystwyth University described their legacy attendance system and the shortcomings in terms of useful data generation, and their new solution which used a branded Arduino Uno running on Power over Ethernet (POE), with an rc522 RFID reader shield, and buzzer/LED breakout board at a cost of around £57 per unit. The device passes data to a central server.
Their initial deployment of 200 access points registered 400,000 attendances in the first semester, and was expanded to 350 access points, failure rates are very low, and the system has been a success.
At the same meeting Chris Stedham the Head of Service Planning and Governance – IT Services at Bath Spa outlined their aim to improve their student retention though the use of effective Learning Analytics. A key part of their Learning Analytics solution was to gather accurate attendance data.
Bath Spa operate across multiple sites, with lots of grade 1 listed buildings, so can’t fit devices to walls like at Aberystwth, and settled on a card reader in a podium bolted to the floor with a metal plate, more expensive at @£250 each using power over ethernet – the Gemini 2000 desktop case.
The devices are configured through DHCP and web services, (option 72 on DHCP set to card reader), and write to a simple database that only records: student activities that are expected, successful card reads, card reader configuration including mac address and card location.
On power up their device reads a configuration from DHCP, which tells the reader which web server to use. The reader sends a Power Up message, checks a security key, then sends configuration of silent mode, with a “heartbeat” every 60 seconds to check in.
Their setup provided a tutor interface that showed a photo classlist highlighting those students who had swiped in.
The common aspects to both of the card swipe based hardware solutions seemed to be the use of wired ethernet connections, with POE to minimise wiring, and keeping the units as simple as possible, reading only cardID and performing any processing on servers.
I undertook a period of rapid prototyping a range of hardware solutions based on these two principles. It is interesting to note that the final result did not adhere to either of these principles.
Our Unicards are based on NXP Mifare 4k cards, which offer 4096 bytes of data storage, with the memory split into 40 sectors protected by A (read) and B(write) keys. 16 bytes of each sector are reserved for keys and access information, and the first 16 bytes contains the read only unique serial number of the card and manufacturer details. The serial number can be read directly without any keys. Initial investigations identified a USB card reader for @£10. However, the Unicard system doesn’t use this cardID, so instead we need to access the userID which is held in Sector 2 Block 8
The previously undocumented complication here is that whilst we count the blocks from 0-3, identifying the UserID data as being stored in Sector 2 Block 0, and assigning each sector blocks 0,1,2, &3, the Mifare card library understands this as Block 2 sector 8, if you count (zero based) through the sectors, Mifare encryption is proprietary (crypto1) and uses a 48bit key, the table shows the location of the UserID U on the Mifare card. Key A = A, Key B = B, Protected bytes = P.
My first attempt version 0.1 used an Arduino nano linked to a RC522 RFID 13.56MHz card reader.
The device read the cardID which is accessible without the need for encryption keys, and passed it to the serial monitor.
version 0.1 of the card reader
Version 0.2 replicated the Aberystwyth approach, using an Arduino Uno, and RC522 card reader and a HanRun Ethernet shield (not POE as provision of POE access points was uncertain. The device worked, but I wasn’t happy with security as it couldn’t run https as the Uno doesn’t have sufficient processing power. The more advanced Arduino Yun mates an Arduino to a coprocessor running a minimal Linux install and would allow a more secure connection, but at a much higher cost, the boards costing around £60 compared to £3 for an Arduino clone.
To avoid the network access issues, I tried a wholly software approach, presenting the tutor with a list of student data and photos which they could tap to record presence. The initial iteration of the software was tested and met some needs, but the card swipe approach was requested for larger cohorts, so Iteration 0.3 used an Arduino Leonardo which has the ability to act as a Human Interface Device(HID) on a USB connection, and thus act as a plugin USB Keyboard card scanner. A smaller ABS case was tested in v0.4.
The device design changed in version 0.5 to improve robustness when carried in a bag, using a smaller ABS case, a lower profile activation button, and moving the “active” LED and “read” LED to the side, also making them easier to see. The buzzer fitted to the initial device was removed as it was a distraction, and the whole thing was filled with hot glue.
version 0.3 (right) and version 0.4 (left)
internals of version 0. 4 showing RC522 card with soldered leads to Arduino Leonardo clone
Version 0.5 with lower profile switch, and side mounted LEDs
I provided access control through a Blackboard secondary role which allows the user to add a custom HTML “course” widget to a module page. The widget passes the username and module code to a php script that looks up the students registered on that module and displays their photos and details, writing the register to a MySQL database. It would have probably been easier to do all this within a Building Block, but my .jsp is rustier than an old plough.
To provide a little more security the scripts require windows 401 authentication challenge and perform a referrer check.
As with the hardware the software went through a number of iterations, with adaptations based on user feedback.
There are four major components in the software, the compiled C code running on the Arduino, the html widget running on the studentcentral platform, the php scripts providing the attendance registers, and the MySQL database storing the data.
Instructors with special secondary roles can add the widget to a course dashboard
The Arduino code consists of a short setup routine that imports the required libraries and initialises a number of pins on the Arduino to talk to the RC522, pin 9 is connected to the RESET, pin 10 to SDA the data line. Pin 16 to Master Out Slave In, and pin 14 to Master In Slave Out, with the clock running on pin 15.
Additional connections are made to pin 2 which is set as a pull-up, activated by the switch (This doesn’t turn the device off, but merely prevents it from acting a s a keyboard) pin 3 to a green LED through a 220Ohm resistor which will be triggered to indicate a swipe, and a Red LED to indicate the device is active on pin 5.
The script creates an instance of the A read key for the UserID, and then in a main loop looks for cards presented to the tag reader. When a card is presented a brief bounce check happens to prevent multiple writes, and the ASCII is written to the keyboard followed by a carriage return, and a flash from the LED.
The standalone card swipe register gives autofocus to the form field. When the card reader is used it writes the UserID into the field, and sends a carriage return. The form writes to the database and returns a list of the last ten card swipes as a confirmation that a particular card has been read.
Whilst the hardware and software to record attendance are relatively simple to build and implement, the infrastructure within which they exist is complex.
The chief lesson learnt was that one solution does not meet all needs. A large lecture cohort could use the Unicard swipes, but had too many folks to make the use of photo classlist practical.
Similarly, the use of swipe boxes in smaller cohorts could take up too much time, and a simple photo classlist that could be checked by the tutor at the start or end of a session was far more useful.
The devices and software are being piloted throughout Semester 2 by the Business school, and useful feedback continues to be gathered, and iterations developed.
So what’s next? The Teaching Space Modernisation Programme are looking providing an integration with the timetabling solution, which would add a swipe in facility to teaching space doors, much like the Bath Spa solution.
There is also the potential to use inexpensive mobile devices, as many android devices have an RFID, reader. Unfortunately, iOS doesn’t allow programmatic access to the inbuilt RFID API.
I am trying some small scale tests using a first generation Nexus 7 tablet. Unfortunately, only phones that have NXP brand of NFC hardware are fully compatible with Mifare Classic Tags, which seems fairly arbitrary, as the original Nexus 7 had support, the next generation Nexus 7 doesn’t.
To sum it all up, I’d say security concerns can dictate the route the solution takes, but gathering attendance data requires an understanding of the variety of teaching sessions that may be recorded, and it is vital that any decisions are tested to gather the range of situations that will be encountered.
The value of the actual attendance data gathered in terms of learning analytics is yet to be determined, although initial returns from early business school pilots shows a definite correlation between attendance and grade, and absence and grade.
References
Bailey, P. (2016) Effective learning Analytics [Online], Available: https://analytics.jiscinvolve.org/wp/2016/08/04/exploring-approaches-to-attendance-tracking/
Martin, T. and Downes, A. (2012) Programmable e-learning and experience tracking [Online], Available: https://tincanapi.com
Sclater, N. (2014) Learning analytics the current state of play in UK higher and further education/licenses/by/3.0, [Online]. Available: http://repository.jisc.ac.uk/5657/1/Learning_analytics_report.pdf
Sclater, N. and Footring, S. (2016) Effective learning analytics [Online], Available: https://www.jisc.ac.uk/rd/projects/effective-learning-analytics