# A Long-Distance Communication Architecture for Medical Devices Based on LoRaWAN Protocol
## 4 Hardware and Software Implementation  
The general hardware architecture of the medical experimental device is proposed in Figure 3, and it is designed and developed around an ARM Cortex M3 microcontroller to  
Figure 2: The architecture of the m-IoT system. which different sensors and communication interfaces are connected. The ADC (Analog-to-digital converter) Sensor and DAC (Digital-to-analog converter) interface are the acquisition sensors of the ECG system that can transmit analog values or use built-in DAC converters to convert the measured analog value to a digital one and transmit the final value to the acquisition board. This way, the signal immunity for the ECG signal obtained from the human body is much precise, and the obtained values are much accurate to be processed. DAC sensor could be the ADAS1000 ECG IC, which has built-in ADC's and transmits the final ECG digital signal to the MCU in order to be processed. We use LoRaWAN gateways placed in key-points and develop the coverage area to perform the best possible communication between the devices. USI(r) WM-SG-SM-42 low-power long-range LoRaWAN(r) module (see Figure 4), based on the STMicro STM32L0 series ARM Cortex M0 + 32 bit microcontroller (MCU) and Semtech SX1272 ultra-long-range wireless transceiver, is a low power wide area network (LPWAN) wireless module that supports the LoRaWAN long-range wireless protocol. Figure 4: USI® WM-SG-SM-42 low-power long-range LoRaWAN Module. Figure 3: Hardware architecture of the medical experimental device. From the software point of view, this device is developed with the help of a real-time operating system (RTOS) for modularization and efficient control of the response times. The Keil RTX 5 RTOS is used for development. The application on the microcontroller is divided into 6 tasks, each task having a unique priority. The tasks, in descending order of priority, are LoRa, Bluetooth Acquisition, Processing/Aggregation, Logs, and HMI. These tasks use the inter-task communication mechanism provided by RTOS to cooperate through synchronizations and data exchange. The application tasks and the data flow between them are presented in Figure 5. The LoRa task deals with communication through the LoRaWAN interface. It will retrieve data from the Processing/Aggregation and Logs tasks to transmit them to the LoRaWAN gateway. Bluetooth handles short-distance communication via the Bluetooth interface. It will retrieve data from the Processing/Aggregation and Logs tasks to send them to a gateway that is usually a smartphone. The ACQUISITION task deals with the acquisition of data from sensors connected to the microcontroller. The acquired raw data is transmitted to the Processing/Aggregation task for processing and aggregation. The LOGs task retrieves data from the Processing/Aggregation task for long-term storage on an SD flashcard. The HMI task handles the user interface. From here, we can start a new EKC acquisition, and we can view the data acquired from the sensors. The advantage of the proposed device is the use of LoRaWAN communication. The LoRaWAN(r) module can perform data transmission over long distances with baud rates range from 0.3 kbps to 50 kbps, and it allows to achieve communication on distances greater than 10 km with reduced power consumption. Patients can view acquired data after receiving the ECG signal. This can be done from a PC or a smartphone. Figure 6 shows how to view an ECG capture on a PC, and Figure 7 shows the view from a smartphone. The data can be downloaded and saved on the flashcard that was inserted into the PC, on the smartphone, or by connecting via Bluetooth to the device. After viewing, the patient can agree that the data be transmitted to the central server via LoRa. As can be seen from Figures 6 and 7, the ECG capture is not very good in quality because it is made at home but may indicate whether it is necessary to call the patients to the doctor's office for a more detailed consultation with professional devices. Figure 5: Software architecture of the medical experimental device.