This step involved looking at hardware options that would allow for the laboratory to monitor the solar inverter output, while being able to upload this information to a server and also connect to logging equipment already being utilised. Multiple devices at this stage were considered, allowing for cost, physical size, availability and ease of programming.
Outputs files of the solar inverter were updated every ten minutes, leading to the requirement of having lab specific hardware capable of handling requests for data while not interrupting this communication. This was handled with a raspberry pi.
78
4.4.3. Lab access without installs
The remote laboratory used in this study needed to be designed to make accessing the laboratory as easy as possible for the students. The laboratory would in no way be formally assessed by students, and it was decided to ensure the laboratory worked on the wide range of devices used by students studying electrical engineering. By having a laboratory that was not formally assessed, students with any issues accessing the laboratory could possibly avoid re- attempting to access the laboratory once the issues had been resolved, meaning that the laboratory needed to be as easy and reliable to access as possible, over the multiple devices, operating systems and web browsers expected to be accessing the laboratory. Due to this, a method of allowing multiple devices to access the laboratory without needing to install any additional software was created.
With the idea of creating a server able to handle multiple different access types, it was decided to use the LAMPS package. This enables the server to run dynamic web pages without the need to have extra software installed, and also enabled a MySQL database to be used not only to store all data, but to be used in order to set flags high, and to therefore communicate with the raspberry pi. Each component of this design needed to be able to communicate with the other, and to effectively manage data flow between themselves. This laboratory also was required to function as part of a larger system (that being the solar inverter) in a way that did not interrupt the data gathering from that system. A basic overview of the functionality of all components directly related to the remote laboratory is presented below in Figure 3:
79 Figure 3: Shows the overview of the hardware chosen and its purpose in relation to student access
The strength of this layout is that it allowed the end user to view all data in the database from an html page, with PHP handling all requests to the database. This was set up in such a way that all data was securely stored, and that the database was not accessed directly by the student, but instead only responded to scripts the student called, therefore removing the ability for the student to interfere with, and possibly modify the database logged data. This layout was selected as it easily allowed for a web server to be created that did all processing server side, therefore not requiring the user to do any processing, leading to more control over the exact content they had available, as well as control over the format this content was presented.
Raspberry Pi -Log all data -Send data to server -allow communication between all other aspects of the system Web Server -Host data -Queries server for data updates -host logged data -allow multiple student access Database -Receive data from pi -Format for Web server -Respond to web server requests for data Student accessing laboratory
80 The raspberry pi was responsible for querying the solar inverter for the exact data being generated. This was then sent to the database using the User Datagram Protocol (UDP) protocol, an alternate to the TCP/IP protocol. The database (or more specifically the computer the database is on), running linux, then receives the data, formats it into a usable format, timestamps the data and stores it in the database. The joules generated over the last ten seconds is what is received, and therefore at this stage the watts generated over this time is determined, and this is also stored.
What this means is that every ten seconds a data point is generated, leading to a new row in the database being created, containing a specific row ID, joules and watts generated over the last ten seconds and the year, month, day minute hour and second this data was generated. This method of storing information means that when data is called, the exact time information can easily be found as well. In addition to this, the method used to display the x axis of the logged data graph (displaying time data was collected) requires information to be called from the database, meaning that this time information must be generated and stored automatically.
This also becomes important when considering the data logs, as the data averages one data point every ten seconds, but can often be generated at a rate faster or slower than this, often by a few seconds. What this means it that if only the solar power output was stored, there would be no way of accurately knowing at what time the data was generated, as multiplying ten seconds by the number
81 of data points created would not be as accurate as having the current stored information.
The web server in this setup was required to allow multiple students to access the data at any given time. This meant that all data displayed had to be unique to the student viewing it, instead of as a static web page, however students accessing simultaneously would still be exposed to the same data as it was updated live. As renewable energy data was stored in a database, access time dictated what students saw, however if accessing over an extended period, these differences would be single data points, and therefore not disruptive to students experiences. What this eventually meant was that the time students began accessing the data did not inhibit their experience at a later time.
By having a server with separate hardware to the data logging hardware (raspberry pi), the data logging hardware needed to constantly be in communication with the server. This was done through an Ethernet port, and by ensuring both setups had a static IP address. Both devices running Linux were set up so that a script establishing communication between the two was executed on start-up, leading to a system that was capable of re-establishing communication, and therefore lab functionality even through power failures. This was also done automatically, meaning that the laboratory did not require constant monitoring to ensure it was fully operational.
Html coding was required to provide an interface for students to access the laboratory. It allowed for a catch all access mode for students, with scripts running from PHP able to interface with the required databases. This PHP
82 programming language was used in this case as it allowed for access of specific database information quickly and easily, with plenty of support available. Since this web server architecture was developed in house, a design needed to be developed that allowed for ease of programming, as debugging and implementation needed to easily and efficiently occur. Having a large amount of online support for html, PHP and general MySQL database design was essential for the completion of this laboratory.
One of the benefits of setting up a system such as this is that programming for specific operating systems or more importantly different devices is not required. Oftentimes creating a mobile interface is a requirement for students wishing to use a laboratory from a mobile device, however for this laboratory that is not the case. Due to mobile devices often containing pinch to zoom, and designing around the concept of having information shown in easy to access locations, a mobile device is adequate to see the information in this remote laboratory.
The design overview of the laboratory involved using updated database values to act as flags for interacting with other devices. The html page was able to view and stare values in a MySQL database, meaning that advance functionality could easily occur, with extra features being added at a later date if required.
83 Figure 4: Shows the comparison of the web site accessed from a phone compared to a computer browser
As can be seen in Figure 4, the access device chosen does not affect the user experience. Things like navigation through specific windows, accessing live updated data and viewing the logged information (as is shown in Figure 4) are all still very possible. This homogeneous access was also a way of solving the design goals for this laboratory, as it meant that students accessing the laboratory via multiple devices would not lead to issues of debugging and redesigning for different devices at a later date.
Another benefit of this design is that it allows multiple users to access the remote laboratory at identical times. Parallel access to this laboratory was
84 handled due to the fact that the web server can handle multiple requests from users at any given time. This removed the need for a scheduling server.
The methodology discussed contained a further two section, those being the identification of research participants as well as the requirement of gathering and analysing results. The method used to gather results extended beyond simply asking users to give feedback on their experiences in the laboratory, and while this step was taken, it was possible to further track their behaviour. The implementation of such laboratory functionality in order to create a method of analysing students’ behaviour and access patterns will be discussed in the next section.