Development and Evaluation of Wireless Interfaces to Monitor and Control Cycling Exercise During Home Telerehabilitation

Introduction

Advances in information technologies, sensor manufacturing, and cloud computing have greatly expanded the role of telecommunication technologies in the management of chronic health conditions.¹⁷ Telemedicine evaluation studies demonstrated that this approach could lower healthcare costs and improve the quality of life of both patients and their caregivers.^18–20 Telerehabilitation utilizes telemedicine approaches to deliver rehabilitation services to patient homes which improves patient access to care, facilitates patient-provider communication, and allows remote supervision of patient performance.^21–24 The importance of using telerehabilitation has been especially recognized since the start of the COVID-19 pandemic, when its usage has surged in response to social distancing guidelines promulgated by the World Health Organization (WHO).²⁵ Recent studies have shown its effectiveness in monitoring patients’ progress, ameliorating disease symptoms, and improving clinical outcomes.^2–6 In order to extend physical rehabilitation from a hospital or ambulatory settings to patient homes as a part of routine care of patients with chronic health conditions,¹ successful telerehabilitation programs should support scalable and cost-effective means for prescribing individualized exercise programs, monitoring safety and adherence with exercise, two-way communication between patient and providers, and timely feedback based on patient performance.^26–28

Training of the upper and lower extremities is often performed by using cycling exercise equipment, which is widely available in rehabilitation facilities, where patient exercise is supervised. Cycling was shown to improve clinical outcomes in patients with Parkinson’s disease, chronic pulmonary disease, recovery stage after hip fracture, and patients with other chronic health conditions.^8–12 Telerehabilitation, with special attention to the remote control and monitoring of cycling exercise,⁷ could broaden the use of home-based programs from expert settings to homes of people with chronic health conditions. In previous studies, we demonstrated that real-time monitoring of cycling exercise is well accepted by older adults, patients with chronic neurodegenerative conditions, and cancer.^29–31 In addition, we demonstrated that cycling exercise in which speed is controlled via the Internet in real-time significantly improves adherence with prescribed exercise speed trajectory.³² The remotely controlled cycling exercise using a motorized bike can be especially instrumental for facilitating exercise in individuals with muscle weakness, paraplegia, or Parkinson’s disease.^33,34 Thus, scalable approaches supporting accurate and cost-effective telemonitoring and remote control of cycling exercises at patient homes can greatly facilitate the implementation of successful telerehabilitation programs in patients with chronic health conditions. However, existing solutions for remote monitoring of cycling exercise are designed primarily for healthy athletes and may be cost-prohibitive for older adults or people with chronic health conditions. The current solutions are limited by an absence of low-cost wireless interfaces allowing to monitor exercise progress in real time using simple graphical and numerical representation, a lack of remote connectivity with a team of rehabilitation professionals, and an absence of an alert system that would prevent exertion levels exceeding those approved by the rehabilitation team.

The goal of this project was (1) to design and implement low-cost wireless interfaces for telemonitoring of cycling exercises using arm or leg-controlled bikes; (2) to design and implement wireless interfaces for remote control of cycling trajectory using a motorized bike; (3) to test accuracy and reliability of the resulting interfaces.

Materials and Methods

Remotely Monitored Interfaces

Two interactive biking systems (iBike) have been designed and implemented to support remote monitoring of users’ exercise by communicating through either Wi-Fi or BLE protocols. We used the same hardware and user interface for both designs. Figure 1 shows an iBike system which consisted of a tablet PC and a low-cost portable bike. The cycling intervals were detected by a reed switch and then sent through wireless communications from built-in systems to tablet PC. When the telerehabilitation users were engaged in cycling exercises, the information was provided to them through an app developed for the tablet PC. To simplify the user interface, each of the apps and the iBikE had only one button to start/stop an exercise session.

Figure 1 System design for interface to monitor cycling exercise.

Tablet PC

The app was designed and implemented for the Windows operating system based on a touchscreen tablet PC, using C# (Figure 2). The first page of the app has two images of a pulse oximeter and the iBikE. To start a cycling exercise session, a user needed to push a button to connect a wrist-worn pulse oximeter. The device (WristOx2^®, Model 3150) sends oxygen saturation level and pulse rate values to the tablet PC via Bluetooth connection. The information could be later monitored through the app when the user is engaged in a cycling exercise.

Figure 2 User interface. Users first need to push a button to pair the app with the oximeter and then push the button on the right to pair the app with iBikE equipment.

Once the oximeter was connected and the iBikE was turned on, the user needed to click the picture of the iBikE button on the app to connect the tablet to iBikE equipment (Figure 2). This triggered the connection of the app to the bike through either BLE or Wi-Fi. After making the connection, user could see the second page of the app, where the start of an exercise activates real-time visualization of the exercise progress via an app installed on a tablet PC. On this page, real-time cycling speed (RPM), pulse rate, oxygen saturation level, total session duration, and elapsed session time were shown in real-time (Figure 3). In addition, the user’s entire exercise record was stored on a remote server and locally in the form of csv files.

Figure 3 Real-time monitoring of the speed (red line, rpm), pulse rate, and oxygen saturation during cycling.

iBikE Exercise Equipment

The design of the iBikE exercise interface was divided into two parts, the hardware, and the software. The hardware consisted of three modules (Figure 4A): 1) control and computing module (MCU), 2) magnetic switch module, and 3) either BLE or Wi-Fi communication module.

Figure 4 Exercise equipment. The bike is manufactured by AGM. (A) All the components, including the reed switch, push switch, MCU and BLE modules, and power control module are inside the iBikE equipment. (B) The user interface is only a physical button to make it easy to use the equipment. We used a laser tachometer, DT-2100, Nidec-SHIMPO,14 in non-contact continuous measurement mode to detect the measured RPM in real-time to compare the results with data taken from iBikE equipment. Both Wi-Fi and BLE iBikE systems have the same hardware design.

Hardware

We used FireBeetle ESP32 IoT Microcontroller with integrated Wi-Fi and dual-mode Bluetooth to design both iBikE systems. Cycling intervals were first detected by the magnetic switch and the interval times were calculated through the MCU. Each cycle was then sent to the tablet PC via either BLE or Wi-Fi. The control and computing module consisted of a single push button to turn on/off the MCU and a DC power source (Figure 5). We used the Adafruit push-button power switch to control the DC power source.¹³ The power source had eight AAA rechargeable batteries (3.7 V, 6000 mAh). The push-button uses a latching analog circuit that is triggered by a push of the switch button. As it was shown in Figure 5, when the user pushes the switch button, the inputs of the first NAND gate (MC14093B, ON Semiconductor^®) were LOW, causing its output to HIGH (C1 capacitor became open circuit) and, therefore, the inputs of the second NAND gate were HIGH. This resulted in a LOW voltage of the gate in P-channel MOSFET (DMG3415U, DIODES^®) and caused a flow of current from the power source to the MCU. The MCU stays on by the feedback (100 K resistor) connected from the MOSFET gate to the input of the first NAND gate. If the user presses the switch button again, the HIGH voltage over C1 applies to the inputs of the first NAND gate and causes the gate of the MOSFET to turn HIGH. This results in turning off the MCU and saving power. If the user forgets to turn off the MCU, the algorithm in the MCU turns off the system after 90 seconds to save power. In this case, if the algorithm does not detect any new cycles from the reed switch for more than 90 seconds, the digital output pin (D18 in Figure 5) in MCU applies HIGH voltage to the Q1 transistor (2N2222), resulting in applying HIGH voltage to the MOSFET gate and shutting down the system. The reed switch (magnetic switch) converted magnetic field changes into electrical signals. It is normally an open circuit. By approaching the magnet to the reed switch, the reed switch detected the change in the magnetic field and the switch becomes a short circuit. When the magnetic field is removed, the magnetic switch detected another change and became an open circuit again. These changes (on/off signal) could be detected by MCU. In our application, the sensor was exposed to a magnetic field once during each cycle. By continuous detection of changes in rising and falling edges, we measured the cycle time intervals and prevented errors in on/off detection. We also identified the cessation of the iBikE exercise session by a user if there was no detection of on/off changes for more than 90 seconds.

Figure 5 The control and computing module in iBikE exercise equipment.

Detected cycle intervals were sent from the MCU, through either BLE or Wi-Fi communication mode, to the app. For the MCU, we used FireBeetle ESP-32, a low-power consumption micro-controller designed for Internet of Things (IoT) projects. FireBeetle ESP-32 integrates a Dual-Core ESP-WROOM-32 module. The module supports both MCU and Wi-Fi & Bluetooth dual-mode communication. It could also work with a 3.7-Volt external lithium battery power supply. In this project, we designed and developed two iBikE systems to test and compare both Wi-Fi & BLE communication. The BLE system needs the tablet PC to be directly connected to the MCU. Cycle intervals were sent in 2-byte packets, a low byte, and a high byte. The low byte was the least significant part of an integer and the high byte was the most significant part of an integer. Wi-Fi system required both the tablet PC and the MCU to be connected to the same Wi-Fi network. We configured the tablet PC as a server and the MCU as a client. We used UDP protocol to communicate between the tablet PC and the bike.

To start an exercise session, the user first needs to press the red button on the iBikE exercise equipment to wake up the MCU and start Wi-Fi/Bluetooth communication with the tablet PC. On the app side, the user was required to press the button (Figure 2) to commence an exercise and allow the tablet PC to connect to the Wi-Fi/Bluetooth communication pairing with the iBikE exercise equipment. After the commencement of the communications between the tablet PC and iBikE the targeted speed trajectory appeared on the second page of the interface (Figure 3). During an exercise session, the users could monitor their actual speed value, heart rate, oxygen saturation level, and session time and compare these values to the prescribed targets in real time.

Software

The cycling interval calculation algorithm in MCU was developed to provide accurate real-time cycling information taken from the magnetic switch. The algorithm is the same for both BLE and Wi-Fi iBikE systems. A major difference is the communication protocol between the BLE and Wi-Fi systems. Each detected cycling interval is sent to the tablet PC through either Wi-Fi or BLE communication mode. Figure 6 shows the algorithm flowchart for the detection of the real-time cycling intervals using the MCU in the BLE communication mode. The algorithm is coded in C++ and Arduino IDE is used to program the MCU.

Figure 6 Algorithm flowchart for detection of the real-time cycling intervals in remotely monitored BLE iBikE.

In the software, we used the interrupt service routine (ISR) to detect the cycling intervals. An internal pull-up resistor was activated and the ISR was called whenever the MCU digital pin detected the falling edge (short circuit of the reed switch). Each detection of a falling edge means one completed cycling interval. The duration time of each interval is measured and then sent to the tablet PC via either BLE or Wi-Fi.

In the BLE communication mode (Figure 6), random device and characteristic IDs were defined, and then read, write, and notify properties were defined for the BLE server characteristic. When a cycling interval is detected by the MCU, ISR is deactivated and the characteristic value would be updated by two bytes, representing the interval value. Then the BLE server notifies the client. After updating the value, the BLE connection is closed and the ISR is activated to detect new cycling intervals.

Figure 7 shows the algorithm flowchart for the detection of the real-time cycling intervals using the MCU in the Wi-Fi communication mode. In Wi-Fi communication mode (Figure 7), both iBikE (client) and the tablet PC (server) need to be connected to the same router. To connect the MCU to the router, we need to have the username and password to be set in the code. The server IP address and the port number are set to later send cycling intervals to the server. When a cycling interval is detected by the MCU, the ISR is deactivated and the UDP connection from the client to the server is activated. Then data is sent to the server. Finally, the UDP connection is deactivated and the ISR is activated to detect the new cycling intervals.

Figure 7 Algorithm flowchart for detection of the real-time cycling intervals in remotely monitored Wi-Fi iBikE.

Remotely Controlled Interfaces

We modified the control board of a motorized bike to develop a system that gives a remote server ability to remotely control the bike’s exercise speed according to a cycling speed trajectory prescribed by a clinical rehabilitation team. The new system also provides real-time visualization of both prescribed and actual speed trajectory through an app installed on a tablet PC screen, analogous to the remotely monitored iBikE systems (as explained above). In this design, the communication between the tablet PC and the motorized bike is carried out through conventional Bluetooth. An app was developed using C# to test the system. In the app, incoming real-time RPMs could be monitored when the exercise session started. In addition, it had three buttons to send the commands from the app to the bike and to control the speed (up and down) and direction of motor rotation. Like the app in the monitored iBikE system, the addition of an oximeter allows monitoring of oxygen saturation level as well as heart rate.

In the motorized iBikE exercise equipment, we used NPN transistors (2N2222) to replace the mechanical push button in its control circuit board (Figure 8). Then, the base gate source of each transistor was controlled by a digital output pin of the MCU (ESP-32). We also used a hall sensor (A3144) to measure cycling intervals. As shown in Figure 9, a magnet was mounted on the bike pedal. In the motorized bike, we utilized an approach that was analogous to the interval detection in the iBikE systems using a reed switch. In the motorized iBikE system, when a magnet passes by the hall sensor, which is mounted inside the bike frame, the time of cycling intervals was measured by the MCU and then sent to the tablet PC via Bluetooth. However, the cycling interval detection algorithm was different in the motorized iBikE. As shown in the algorithm flowchart, we had two main parts in the algorithm. The first part was measuring the cycling intervals and the second part was looking for the commands coming from the tablet PC to control the motor speed and direction. Whenever the user pressed any control buttons on the app, a character was sent to the MCU via Bluetooth. Based on the defined target of the character, the MCU was sending a pulse to its representative transistor (mechanical switch). In the first part of the program, we used a delay time of 20 milliseconds and a flag to make sure the detected interval was not false. When the hall sensor came near the magnet, the MCU read the sensor state multiple times. Therefore, we added a delay timer to read the sensor value every 20 milliseconds. However, if the magnet had stayed near the sensor for some time, the sensor could have been activated every 20 milliseconds. Therefore, we added a state flag to address this issue and make sure the resulting value is not false (Figure 10).

Figure 8 Control buttons in motorized iBikE were replaced by transistors to be controlled with ESP32. ESP32 communicates with the tablet PC through Bluetooth.

Figure 9 Remotely controlled and monitoring exercise equipment. The motorized bike is manufactured by HOMGIM.

Figure 10 Algorithm flowchart on detection of the real-time cycling intervals in remotely controlled motorized iBikEs.

For BLE and Wi-Fi iBikE systems, two of the co-authors performed three separate 1-minute sessions using an arm bike at slow, medium, and fast. For the motorized iBikE system, the authors performed four consecutive sessions of hand-cycling with the cycling speed defined by the bike control system (from the slowest speed to the highest grade four speed). The speed was controlled by the developed app during each 1-minute cycling experiment. For all iBikE systems, the recorded data taken from a laser tachometer, during the hand-cycling experiments, were compared to its representative collected data from the iBikE system.

Data Collection

For remotely monitored interfaces (BLE and Wi-Fi iBikE systems), a group of nine individuals performed 3 sessions of hand cycling for each iBikE system, with one-minute duration for each session. They started with one-minute hand-cycling at a slow pace, followed by one-minute rest. Then they proceeded with one-minute hand-cycling at a medium pace, followed by one-minute rest. Finally, they continued with one-minute hand-cycling at a fast pace. The meaning of slow, medium and fast pace was based on the user’s interpretation. Participants in the study comprised nine healthy individuals aged between 21 and 61 years old, the average age was 37±14 years old, and 44% of participants were females. They performed the tests on two different days. On the first day, data was collected from the iBikE system with the BLE communication mode. On the second day, data was collected from the iBikE system with Wi-Fi communication mode. Users completed a total of 18 sessions (54 phases). Data was collected from both the iBikE system and tachometer in parallel during each session. The iBikE system recorded completed cycling intervals and sent the data to the tablet PC. Simultaneously, the tachometer collected RPM values and sent them to a PC at the sampling rate of 10 Hz.

For remotely controlled interfaces (conventional Bluetooth system), two healthy individuals performed four consecutive sessions of hand-cycle with the speed defined by the bike control system (from the slowest speed to grade four speed, 1 minute each). The speed was controlled by the developed app during the 1-minute cycling experiment.

The accuracy of all the iBikE systems was evaluated by collecting data from a laser tachometer as a reference, DT-2100, Nidec-SHIMPO.¹⁴ The data from the laser tachometer was collected during each exercise in non-contact continuous measurement mode to detect the measured RPM in real-time (10 Hz sampling frequency).

In addition to cycling information, which was sent by the MCU to the app, other information, including heart rate, SpO2 (oxygen saturation level), and PAI (Pulse Amplitude Index), was sent from the pulse oximeter to the app.

Ethical Considerations

As there were no health risks and the participants were all authors of this paper, we did not require institutional review board approval. No protected health information was collected, and the resulting analytical data set was fully de-identified. No compensation was provided to the study participants.

Results

In order to evaluate the iBikE system's functionality and accuracy, the two collected data sets from each 1-minute session for each user (iBikE system and tachometer) were first averaged separately and then plotted (Figure 11). The plots illustrate the linear relationship between the two collected data sets.

Figure 11 Collected data from BLE, Wi-Fi, and motorized iBikE systems and their representative collected data from the tachometer (in each 1- minute session) was averaged and compared. The results show the capability of our iBikE systems to measure the RPMs accurately.

For remotely monitored interfaces, the mean, standard deviation (SD), minimum, maximum, and 95% confidence intervals (CI) of the tachometer RPMs, were shown in Table 1. The results are calculated from all RPM values in 1-minute slow-paced, 1-minute medium-paced, and 1-minute fast-paced sessions for a total of 18 sessions for each system (nine experiments with BLE system + nine experiments with Wi-Fi system).

Table 1 RPM Distribution at Different Cycling Paces

For remotely controlled interfaces, each 60-second session was divided into 4 sub-sessions, including 10-second, 20-second, 30-second, and 60-second sub-sessions, for measured data from the tachometer and iBikE systems. For example, in a 20-second sub-session, both collected data from the iBikE and tachometer in each 60-second session were divided into 3 bins of 20 seconds. Then the mean of the RPMs was calculated separately for each 20-second bin. Then the mean difference was calculated from each iBikE sub-session bin and its representative tachometer bin. Then the mean value of all the bins was calculated. Finally, the mean values of all the similar means for each experiment (9 experiments for each system) were averaged. Tables 2 and 3 summarize the calculated final averaged mean, standard deviation, and mean confidence interval range for all similar sub-sections for all the participants (total of 9 experiments).

Table 2 Confidence Interval Range as Well as Mean and Standard Deviation (SD) of All the Collected Mean Differences Between Wireless Interface and Tachometer in Each Subsection with Similar Bins for Wi-Fi iBikE System

Table 3 Confidence Interval Range as Well as Mean and Standard Deviation (SD) of All the Collected Mean Differences Between Wireless Interface and Tachometer in Each Subsection with Similar Bins for BLE iBikE System

Discussion

Our developed iBikE system interfaces provide remote control and monitoring of in-home cycling exercises for patients requiring a telerehabilitation exercise system. We designed the systems to be low-cost and support user-friendly interfaces for both the app and the iBikE. Test results showed that the implemented hardware solutions and software algorithms resulted in accurate measurements of cycling intervals and reliable transmission of the information from the iBikE to the app by the wireless interfaces. In the case of a motorized iBikE, our developed system was also capable of transmitting motor speed commands from the app to the motorized bike to control cycling speed in real-time.

The app, hardware, and cycling intervals detection algorithm were the same for both monitoring iBikE systems. However, they used either BLE or Wi-Fi communication protocol to connect the app to the bike for sending information. In the cycling intervals detection algorithm, we used ISR to detect the cycling intervals from the magnetic switch. We noticed random “false” interruptions with small values that were detected by ISR. These values were less than 140 ms for the BLE system and less than 250 ms for the Wi-Fi system. These “false” interrupts, detected by MCU, could be due to the capacitive structure of the magnetic switch and external magnetic field (EMF) effects.^15,16 When the system battery went below its ~ 70% capacity, “false” interrupts were more frequent and longer, around 180 ms for BLE systems and around 300 ms for Wi-Fi systems. The effect was more frequent, and the durations were larger in Wi-Fi systems. It seems that enabling Wi-Fi in ESP-32 impacts the ISR functionality. In addition, Wi-Fi consumes more power compared to BLE in a similar session and this can directly impact the ISR functionality. Overall, in terms of battery usage and ISR performance, the BLE system was a better choice than the Wi-Fi system. To solve the ISR issue, a hold-off timer was added in the ISR to prevent the counter from increasing on the “false” interrupts (Figures 6 and 7). This did not affect cycling interval values as the highest RPM value measured during the fast pace recorded session was 142 RPM. For our application, both BLE and Wi-Fi systems were able to send data to the app fast enough without losing information. However, in applications with a higher frequency of data transmission, this issue needs to be considered.

We designed both BLE and Wi-Fi systems easy to operate by patients who had to use a single physical push button on the bike and a single push button on the app. The user was able to start/stop an exercise session just by pushing a button (Figures 2 and 4). There was no issue detected on starting/stopping communication in the systems. However, the Wi-Fi system needs to have the username and password of an active router in the area to be connected to Wi-Fi and to communicate with tablet PC. By changing the system location, where a new router is active, the MCU program needs to be updated with a new username and password. This requires special software (Arduino IDE, etc.) and knowledge of using the software to update the information. Such a restriction does not apply to the BLE system.

For a remotely controlled iBikE system, we used conventional Bluetooth to send/receive data between the app and a motorized bike system. We used a low-cost commercially available motorized bike in which we replaced its control buttons with transistors to control them with MCU (ESP-32). By sending commands from the app to the MCU, we could change the speed and cycling direction of the bike. In addition, we could send the real-time cycling intervals from the bike to the app. The bike performance and testing results demonstrated the reliability and accuracy of the system in remote control and monitoring of all cycling exercise sessions in all study participants.

As the next step, we are planning to assess both monitored and controlled iBikE systems in a broad spectrum of individuals with mobility impairment. The testing will include longer cycling time, different exercise speeds, physiological response assessment, and patient feedback. Patient adherence to regular use of the system for a prolonged period of time will be assessed.

For the iBikE monitoring system, the MCU algorithm could be further modified to lower the system power consumption by activating the sleep mode of the MCU and waking up the system whenever the data is ready to be transmitted. In the current project, we used eight rechargeable batteries to power the unit for monitoring iBikE systems. Further improvement of the system power management could help us to optimize the power unit and get an estimation on how long the system will function accurately. In addition, the design could be further modified to make it easier for the patients to recharge the power unit.

In the motorized bike, we had to use the cycling speed increments which were pre-defined for its motor by the manufacturer. Further design and development of a motor drive for the system should overcome this limitation. The new design could also be used for all types of motorized bikes on the market, regardless of their control/drive design. In addition, compared to the monitoring iBikE system detection algorithm, the motorized iBikE showed less accuracy in cycling interval detection. Although the results were satisfactory for our application, further design modification in both hardware (eg, using different sensors), and software (eg, using ISR) may improve the system performance.

Conclusion

We developed and tested low-cost wireless interfaces to monitor and control cycling exercise during home-based telerehabilitation. The interfaces demonstrated sufficient accuracy and reliability for future use in telerehabilitation systems. Both monitored and controlled systems could be further developed to include virtual televisits by therapists and caregivers, social exergaming, extension of exercise options, support for treatment adherence, automated assessment of levels of exercise exertion, inclusion of cardiovascular monitoring, interactive health education and empowerment, and cuff-less measurement of blood pressure during exercise.^27,35–38 Patient preferences and needs should be fully reflected in the next generation of telerehabilitation systems to achieve high acceptance in the home environment.³⁹ Therefore, further testing of the home-based exercise cycling systems is warranted in randomized trials to evaluate the clinical impact in people with various chronic health conditions.