Role of Wi-Fi Data Loggers in Remote Labs Ecosystem

  • Venkata Vivek GowripeddiEmail author
  • B. Kalyan Ram
  • J. Pavan
  • C. R. Yamuna Devi
  • B. Sivakumar
Conference paper
Part of the Lecture Notes in Networks and Systems book series (LNNS, volume 22)


All data are important and useful but what is more important is the way this data is used. Wi-Fi Data-logger is a major step towards making use of data for effective management of a remote lab. The purpose is to build a real-time data-logger with Wi-Fi capabilities to remotely monitor the equipment status and environmental conditions inside a remote lab containing high-end electrical and electronic machinery. This device should be adaptive, flexible, easy to use and should give deterministic results to take action.

The structure of Wi-Fi data logger consists of two zones: (a) device-level-hardware zone and (b) server-level-software zone.

  1. (a)

    A micro-controller is connected to various sensors such as Temperature, Humidity, Gas, motion sensors and to fault testing lines of the equipment and peripherals. The data is continuously obtained in real time is pumped through Wi-Fi over TCP/IP or UDP protocols to a server computer.

  2. (b)

    It consists of a simple program running on the server computer to receive the data from micro-controller through Wi-Fi and organize it. This program also has a script running which throws up possible a warning in case of malfunctioning and possible solution with step-wise instructions is displayed.


Key Outcomes include: (a) Seamless integration of the device with the existing machinery requiring minimal effort (b) Protection to components (c) Over 40% reduction in the time required to detect and fix an issue achieved by impeccable synchronous effort of device and software.

Thus, these Wi-Fi data-loggers enhance the way remote labs operate by taking care of safety issues and increasing the stability of the whole remote labs architecture. This technology can pave way for more complex architecture of remote labs and the evolution of Wi-Fi data-logger technology will result in evolution of remote labs.


Remote labs Internet of Things (IoT) Wireless monitoring Real time Safety Revolutionary 

1 Introduction

Remote labs are undoubtedly the future of laboratory education as they provide opportunities for effective and holistic learning for students and researchers with limited access to laboratories by providing them with that extra flexibility and time required to complete that experiment or make that breakthrough or pull out an amazing research paper like this one [1]. Remote labs have been increasing in numbers with advanced technology day by day with new labs set up in the places spanning all domains [2]. Remote labs serve as a bridge between virtual and real labs as well as serving as they can be used not only in the field of education, but also for doing any measurement-task with real laboratory instruments [3].

The general architecture of a remote lab consists of an experiment set-up inside a room whose structure includes a computer with hardware connected to it, webcam, microphone, feedback of experimental results back to the computer [4]. More importantly everything inside connected to the outside world through the internet or the intranet accessed through a webserver as shown in Fig. 1.
Fig. 1.

Architecture of remote labs

Data loggers are small devices with capability to accumulate mass data through acquisition cards and store them in memory before dumping to mass storage device. Data loggers can be made more purposeful with the advancement of technology and their adaptive implementation can lead to collection of critical data which can be of immense importance [5]. However, data loggers are generally overlooked by most researchers due to their simplicity and deemed by industrialists to be an extra feature rather a required feature. We wish to change that by showing the important role that data loggers play in remote labs ecosystem and their huge influence and boost to the system.

2 Approach

In this section, the build of the data logger whose description has been told towards the end of introduction is discussed in depth. Figure 2 shows the architecture of the data logger in general with two branches of its build – (a) Hardware level and (b) Software Side. Each of the two branches will be dealt in detail in this section and the whole approach to build a data logger and implementing it in the remote lab ecosystem will be discussed.
Fig. 2.

Wi-Fi data logger architecture

2.1 Preliminary Steps

Choosing the Laboratory.

The key to choosing a laboratory is by analyzing its down time and checking for the feasibility of installing the data logger with minimal cost and infrastructure changes. Our primary criteria to choose a laboratory are that it should have a sufficiently high down time and low installation cost.

For this, different laboratories were identified and their downtimes (Down Time Percentage = Total Downtime/Total time) as well as approximate cost factor (Cost of installation of data logger/Cost of remote lab set up). Based on this data, the best of the lot was chosen by Factor of Decision which is weighted sum of the DTP and Cost Factor together according to their proportionality as shown in Fig. 3.
Fig. 3.

Choosing the laboratory using the factor of decision

Factor of decision is 25% when downtime is 25% and cost factor is 25%. Lesser the cost and more the downtime, Factor of decision goes up. So, for a cost-effective installation should be greater than 25% and for a more effective purpose, above 35% was chosen. As shown in the Fig. 3. Five out of the eight have a Factor above 35% and these laboratories were first choice for data logger installation. This understanding gives us a clear idea of laboratories and a head start by helping us the best ones on which the data logger can have its most impact on.

Identifying the Failures.

Failures can be due to varied reasons ranging from simple overheating to equipment malfunction. In this section, some of the failures across the whole remote labs ecosystem are listed out.
  1. 1.

    Sudden Variation in power can cause the system to fail.

  2. 2.

    Faulty machine lines can lead to malfunctioning.

  3. 3.

    Failure of temperature maintenance system can cause severe damage to components due to overheating or overcooling.

  4. 4.

    Increased humidity and water deposition might brick the system.

  5. 5.

    Poor maintenance of infrastructure is an important cause of damage.

  6. 6.

    Use of components or hardware products which are not rated sufficiently high for parameters like current, voltage, temperature can cause burning out of the components resulting in a major failure.

  7. 7.

    Other failures can be attributed to rapid, violent, and unexpected changes that can occur.

  8. 8.

    Loose connections can also be an issue.

  9. 9.

    Mechanical stress between components can lead to damage of critical moving parts.

  10. 10.

    Error in software code that can put the system in infinite loop.

  11. 11.

    If proper security measures are not in place it can lead to misuse.

  12. 12.

    Overflow of memory can hang the system.

  • Finding the Suitable Solution

  1. 1.

    Providing constant power supply to enhance the performance.

  2. 2.

    Constant monitoring of the fault lines for quick error detection can solve the issue.

  3. 3.

    By installing proper safety measures and cooling systems to avoid failure.

  4. 4.

    For better performance, the hardware components must be rated high on parameters like voltage, humidity and temperature.

  5. 5.

    To understand unexpected failures, an error detection system must be designed and controlled using feedback elements.

  6. 6.

    Quality of the solder materials must be good and the solder joints must be strong enough to avoid physical damage or broken connection.

  7. 7.

    Advanced temperature and humidity sensors should be used to give precise data.

  8. 8.

    Software code should be developed with proper techniques.

  9. 9.

    Memory issue should be taken care of clearing the buffer regularly.

  10. 10.

    Software should be maintained and updated regularly.


2.2 Hardware Configuration

Identifying the Suitable Hardware.

It is important to choose the hardware such that it transcends across most types of laboratories and laboratory equipment and the only change that would be required will be change in the implementation of code and connections (Table 1).
Table 1.

Hardware compatibility table

Laboratory type

Type of microcontroller

Type A

Type B

Type C

Type D

Microcontroller Lab 2


Electrical DC machines lab


Measurement Lab 2


Process Trainer Kit (PTK)


As you can see in the given table, Type B is adaptable to more labs than Type A, so Type B is preferred over Type A. Similarly, Type C is preferred over Type D. Even if cost of Type B is slightly greater than that of Type, it is worthy of using as it saves up on cost of spares [6]. Figure 4 shows an example of a Wi-Fi based microcontroller.1
Fig. 4.

Adafruit – Cortex M3 with Wi-Fi microcontroller

  • Choosing Necessary Components

See (Table 2).
Table 2.

List of components used (basic idea).

Components list


Temperature sensor

−80 °C to +70 °C

Humidity sensor

0 to 130 g/m3 Output: 0–13 mV

Infrared sensor

760 nm wavelength

Passive infrared sensor

Up to 20 m

Voltage sensors

0–30 V

Current sensors

0.2–1.6 A & 2–10 A


32 bit


12 V

Box case with heat sink

Special PVC material (Resistant up to 150 °C)

Buck boost converter

12–24 V and 12–5 V

Mains supply

240 V, 10 A

SD card, hard disk

32–128 GB, 1 TB

Adding Components to Board.

This is a 3-stage process where in the components are put in a circuit on a breadboard to test their working. This is illustrated by the Fig. 5. Then the components are soldered manually onto the PCB board and made as shown.
Fig. 5.

Adding components to board: (a) Testing the hardware design on breadboard (b) Soldering the components onto a circuit (c) Design of PCB and production

Encapsulating and Enclosing the Hardware Platform.

This step involves packing the whole hardware side in a high-grade case by making required openings for Inputs and outputs through the device. Figure 6(a) and (b) clearly describe the packaging and its features.
Fig. 6.

(a) Hardware packaged in a IP60 box (b) Openings through the case are well sealed.

2.3 Software Configuration

Choosing the Right Software for Hardware Side as Well as Client Side.

This step involves choosing the software that is most suited to embedded programming [7] and client side software application [8].

Arduino is an open-source electronics platform based on easy-to-use hardware and software.

LabVIEW is an integrated development environment designed specifically for engineers and scientists building measurement and control systems.

Arduino is chosen for:
  • Simplicity

  • Strong Hardware – Software interaction

  • Code at an Embedded C level

  • Open Source and a huge Community for support

  • Large database of libraries and binaries

LabVIEW is chosen for:
  • Excellent Design in form of front panel and block diagram

  • Built in Libraries and tools

  • Precision measurement reading

  • Highly Customizable

Programming the Hardware.

Arduino IDE was used to program the microcontroller by embedding C code onto the device. Figure 7 illustrate how the same device can be adapted to read different parameters which makes the device universal and adaptive.
Fig. 7.

(a), (b) and (c) show how with a few lines of modification in the code different parameters can be read.

Programming the Client Side.

Client side programming is done through LabVIEW, various loops, conditions are designed. All the conditions, restrictions and boundary conditions are set in the LabVIEW block diagram with indicators and user output data on Front Panel. Figure 8 illustrates LabVIEW programming logic done on block diagram window of LabVIEW software.
Fig. 8.

LabVIEW programming

2.4 Server Configuration

To facilitate remote monitoring the LabVIEW front panel can be made as a standalone running program on a server which can be accessed through remote desktop connection on an operator’s PC [9]. Option of using existing remote lab server or setting up an exclusive server for datalogger are available.

Local Server.

This is the simplest approach where an already existing remote lab server can be used for running the Monitoring VI. This option requires no additional cost and is not recommended as failure of remote server night lead to failure of the whole system.

Exclusive Server.

An exclusive server for the data logger monitoring can be installed to provide a more robust architecture as failure in main server will not affect monitoring and is recommended for long term installation.

Auto – Alerting through SMS and Email.

Using MQQT, conditions can be given such that email and SMS notification are sent to concerned personal [10], which is depicted in future sections.

3 Working

3.1 Different Cases of Operation

Following set of Figures illustrate how monitoring front panel looks like in different cases of operation.

Figure 9 shows a typical remote lab monitoring screen where everything looks okay. Temperature and Humidity are under control. Fault lines are off and a message is displayed that indicating the same.
Fig. 9.

Normal state of operation

Figure 10 shows a warning state of operation where the temperature is higher than usual but temperature is not high enough to cause a damage to components, message is displayed for operator indicating the same and instructions are provided for operator to sort this error in simple terms.
Fig. 10.

Warning state of operation

Figure 11 illustrate the error state of operation where the lines are faulty and red light indicates the machine has stopped running. Message is displayed indicating the same and a solution is provided for the operator. Since, this condition may require expertise, notification using auto alerting is sent to concerned personnel.
Fig. 11.

Error state of operation

3.2 Different Labs in Operation

Figure 12 illustrates how parameters vary from lab to lab and the same can be displayed on the monitoring screen. This particular example shows the graph of power consumption along with other necessary parameters. It can be seen that there is a sudden spike in power consumption [11] and this is depicted in real time, warning displayed as well.
Fig. 12.

Monitoring different kinds of labs by displaying related information

3.3 Viewing the Recordings

In case of failure, logs are generated and can be viewed later on. The logs are generated and stored on a local storage such as a SD card or hard disk. These can be retrieved later when the system is back online through TCP/IP or physically [12]. This storage serves as black box and the data can be analyzed to find the reason for failure.

4 Outcomes

4.1 Seamless Integration

From Fig. 13 gives an overview see how cost of datalogger compares against total cost of remote lab and how man hours required to install a data logger fares against man hours required to build a remote lab. From the figure, which has logarithmic Y axis, it can be observed that typically cost of a datalogger varies between 8–14% to that total cost of remote lab and man hours required to setup a datalogger is less than 1/15th to that of remote lab. This proves the motto of “Seamless Integration” [13]. With minimal cost incurred and minimum effort, data logger can be installed to most remote labs.
Fig. 13.

Shows how cost of datalogger and its installation fares against total remote lab cost for different kinds of labs.

4.2 Reduced Time to Detect a Failure and Rectify It

Since the laboratory is continuously monitored for various physical parameters and fault lines, in case of an error, warning or error is shown which was depicted earlier in the Working Section earlier, the time required to detect an error is drastically lower than before. As illustrated in Fig. 14, for most labs it just takes 1/3rd of the usual time required to detect and fi failure unlike without datalogger, I think this is the most important feature of the whole architecture as it drastically improves the availability of lab for use and helps in easy maintenance of infrastructure.
Fig. 14.

Compares the time required to detect a failure and correct it with datalogger (in red) vs. Without datalogger (in blue)

4.3 Increased Working Efficiency

As the time required to detect the failure and correct it is minimized, efficiency of the system goes up. In Fig. 15 it can be seen that downtime for most of the labs in less than 4% which translates to an efficiency of more than 96% compared to 86–91% earlier. This is a significant result which proves the need for datalogger.
Fig. 15.

Downtime Comparison with and without dataloggers for different labs

4.4 Cost Efficiency

Finally, the important measure of outcome for sustained use of dataloggers is the savings due to the installation over a certain period ranging from one year to five years extending to ten years [14, 15]. According to the statistics, savings over five years are generally more than cost of datalogger itself which can be seen in Fig. 16. Our estimates show that breakeven point occurs two to three years from time of installation. This proves that data logger is profitable venture both from a qualitative and quotative perspective.
Fig. 16.

Compares cost of data logger, yearly savings due to datalogger and savings made over five years

5 Conclusion

The discussion of this paper started with importance of Remote Labs in current context and need for Wi-Fi Datalogger for efficient functioning of remote labs was well established. Approach to build the data logger was discussed from scratch. The foundation of Datalogger from choosing the lab to choosing components and hardware was discussed. The building of datalogger in hardware, software and server aspect is well illustrate in Sect. 2. Working of the datalogger, with live screens from different labs and different states of operation is shown in working section. Data logger was judged on the parameters of integration costs and effort, time to detect a failure and rectify it, efficiency and finally cost perspective. The results clearly prove the effectiveness of data logger. The importance of data loggers in remote labs ecosystem is well established through this paper.


  1. 1.

    The mentioned microcontroller was used for microcontroller lab and the product contains a Cypress WICEDTM chip. It is sold by Adafruit Industries based in New York.



The authors wish to extend thanks to various universities and industries across India and across the world for providing with opportunities to test the datalogger architecture and make findings.


  1. 1.
    Auer, M.E.: Virtual lab versus remote lab. In: 20th World Conference on Open Learning and Distance Education (2001)Google Scholar
  2. 2.
    Ram, B.K., Kumar, S.A., Sarma, B.M., Mahesh, B., Kulkarni, C.S.: Remote software laboratories: facilitating access to engineering softwares online. In: 2016 13th International Conference on Remote Engineering and Virtual Instrumentation (REV), pp. 409–413. IEEE, February 2016Google Scholar
  3. 3.
    Pruthvi, P., Jackson, D., Hegde, S.R., Hiremath, P.S., Kumar, S.A.: A distinctive approach to enhance the utility of laboratories in Indian academia. In: 2015 12th International Conference on Remote Engineering and Virtual Instrumentation (REV), pp. 238–241. IEEE, February 2015Google Scholar
  4. 4.
    Esche, S.K., Chassapis, C., Nazalewicz, J.W., Hromin, D.J.: An architecture for multi-user remote laboratories, dynamics (with a typical class size of 20 students), 5, 6 (2003)Google Scholar
  5. 5.
    Outram, J.D., Outram, R.G.: Adaptive data logger. U.S. Patent No. 4,910,692, 20 March 1990Google Scholar
  6. 6.
    Yunlong, F., Fang, A., Li, N.: Cortex-M0 processor: an initial survey. Microcontrollers Embed. Syst. 6, 33 (2010)Google Scholar
  7. 7.
    D’Ausilio, A.: Arduino: a low-cost multipurpose lab equipment. Behav. Res. Methods 44(2), 305–313 (2012)CrossRefGoogle Scholar
  8. 8.
    Gontean, A., Szabó, R., Lie, I.: LabVIEW powered remote lab. In: 2009 15th International Symposium for Design and Technology of Electronics Packages (SIITME). IEEE (2009)Google Scholar
  9. 9.
    Auer, M., Pester, A., Ursutiu, D., Samoila, C.: Distributed virtual and remote labs in engineering. In: 2003 IEEE International Conference on Industrial Technology, vol. 2, pp. 1208–1213. IEEE, December 2003Google Scholar
  10. 10.
    Aloni, E., Arev, A.: System and method for notification of an event. U.S. Patent No. 6,965,917, 15 November 2005Google Scholar
  11. 11.
    Shnayder, V., Hempstead, M., Chen, B.R., Allen, G.W., Welsh, M.: Simulating the power consumption of large-scale sensor network applications. In: Proceedings of the 2nd International Conference on Embedded Networked Sensor Systems, pp. 188–200. ACM, November 2004Google Scholar
  12. 12.
    Tinga, T.: Application of physical failure models to enable usage and load based maintenance. Reliab. Eng. Syst. Saf. 95(10), 1061–1075 (2010)CrossRefGoogle Scholar
  13. 13.
    Vuletid, M., Pozzi, L., Ienne, P.: Seamless hardware-software integration in reconfigurable computing systems. IEEE Des. Test Comput. 22(2), 102–113 (2005)CrossRefGoogle Scholar
  14. 14.
    Robinson, R.: Cost-effectiveness analysis. BMJ 307(6907), 793–795 (1993)CrossRefGoogle Scholar
  15. 15.
    Tanner, M., Eckel, R., Senevirathne, I.: Enhanced low current, voltage, and power dissipation measurements via Arduino Uno microcontroller with modified commercially available sensors. APS March Meeting Abstracts (2016)Google Scholar

Copyright information

© Springer International Publishing AG 2018

Authors and Affiliations

  • Venkata Vivek Gowripeddi
    • 1
    Email author
  • B. Kalyan Ram
    • 2
  • J. Pavan
    • 1
  • C. R. Yamuna Devi
    • 1
  • B. Sivakumar
    • 1
  1. 1.Dr. Ambedkar Institute of TechnologyBangaloreIndia
  2. 2.BITS-Pilani KK Birla Goa CampusGoaIndia

Personalised recommendations