esa-sceva/satcom-chunk-collection huggingface dataset:
# Internet of Things (IoT) Operating Systems Management: Opportunities, Challenges, and Solution
## 1 Introduction  
Internet of Things (IoT) is the main driving force behind revolutionizing all aspects of technology. The seamless integration of all the technologies is the challenging task [1]. Recent advancements in Millimeter Wave (mmWave) [2], emerging cellular networks [3], Fifth Generation (5G) spectrum potential for intelligent IoT [4], caching techniques in cellular networks [5], coextinense of wireless technologies [6], fog computing [7], Vehicular to Everything (V2X) [8], Device to Device (D2D) Communications [9], IoT resources [10], and IoT Operating Systems (OS) [11, 12] etc. research paves the way towards next generation IoT. Advancements in IoT technologies and availability at lower prices thriving the devices connectivity and remote accessibility. Hence, the adaptation of standards are essential to allow communication among these heterogeneous networks in IoT. Connectivity of industry components using central or distributed manners to increase the productivity and efficiency is must for Industrial IoT (IIoT). The fourth industrial revolution or industry 4.0 is still evolving. It opens up humongous challenges for smart and autonomous system that generates huge amount of data to be processed and hence needs to be intelligent by adopting machine learning algorithms.  
IoT OS continuous development by practitioners and researchers are crucial to provide platform that supports latest protocols standard for the future intelligent IoT. The device heterogeneity in IoT is challenging however, IoT OS needs to support different hardware architectures, boards and devices. There are variety of IoT OSs namely Contiki-OS [13], RIOT [14], and Zephyr [15] are available to facilitate tremendous growth in this area. IoT devices are resource-constrained in terms of hardware resources and usually with limited battery capacity. Consequently, well known mature OS cannot be run on these devices. IoT OS code requires to be optimized with essential Transmission Control Protocol/Internet Protocol (TCP/IP) capabilities for seamless integration with the global internet. Therefore, IoT OS needs to be very efficient to manage the resources on all the communication layers.  
Majority of IoT OSs provides complete IP networking stack with standard User Datagram Protocol (UDP) [16], TCP [17] and Hypertext Transfer Protocol (HTTP) [18]. Moreover, it also supports latest standards like Internet Protocol version 6 (IPv6) over Low-Power Wireless Personal Area Networks (6 LoWPAN) [19], Routing over Low Power and Lossy Networks (ROLL), and Constrained Application Protocol (CoAP) [20].  
The rest of the paper is organized as follows. Section 2 briefly discusses the IoT OSs key features and characteristics. Section 3 deliberates the supported hardware. Section 4 provides future research directions. Section 5 summarizes the accepted paper. Finally, Section 6 concludes the paper.
## 4 Results
### Statistical Analysis
#### 4.1.3 \(t\)-Test on Heart Rate
\begin{table}
\begin{tabular}{l l l l l l l l} \hline \hline
**Variable** & **Group** & **N** & **Pre** & **Post** & **Source** & \(\mathbf{F}\) & \(\mathbf{p}\) & **ES (\(\mathbf{\eta_{p}^{2}}\))** \\ \hline \multirow{4}{*}{Tension} & AR & 10 & 9.3 \(\pm\) 2.98 & 7.4 \(\pm\) 2.45 & Time (T) & 7.744 & 0.012 & 0.301 \\  & Offline & 10 & 8.5 \(\pm\) 3.68 & 6.2 \(\pm\) 1.47 & \multirow{2}{*}{\begin{tabular}{l} TxG \\ Time (T) \\ \end{tabular} } & Group (G) & 1.034 & 0.323 & 0.054 \\  & AR & 10 & 7.2 \(\pm\) 1.93 & 5.8 \(\pm\) 1.54 & \multirow{2}{*}{\begin{tabular}{l} TxG \\ Time (T) \\ \end{tabular} } & 0.070 & 0.794 & 0.004 \\  & Offline & 10 & 6.8 \(\pm\) 2.69 & 5.5 \(\pm\) 0.97 & \multirow{2}{*}{\begin{tabular}{l} Group (G) \\ TxG \\ Time (T) \\ \end{tabular} } & 0.232 & 0.636 & 0.013 \\  & AR & 10 & 10.9 \(\pm\) 3.07 & 9.1 \(\pm\) 2.28 & \multirow{2}{*}{\begin{tabular}{l} Time (T) \\ \end{tabular} } & 8.769 & 0.008 & 0.328 \\  & Offline & 10 & 9.3 \(\pm\) 4.57 & 7.4 \(\pm\) 2.67 & \multirow{2}{*}{\begin{tabular}{l} TxG \\ Time (T) \\ \end{tabular} } & \multirow{2}{*}{0.006} & 0.228 & 0.080 \\  & AR & 10 & 6.8 \(\pm\) 1.03 & 5.0 \(\pm\) 0.00 & \multirow{2}{*}{\begin{tabular}{l} TxG \\ Time (T) \\ \end{tabular} } & \multirow{2}{*}{0.006} & 0.937 & 0.000 \\  & Offline & 10 & 7.2 \(\pm\) 3.85 & 5.4 \(\pm\) 0.96 & \multirow{2}{*}{\begin{tabular}{l} Group (G) \\ TxG \\ Time (T) \\ \end{tabular} } & \multirow{2}{*}{0.272} & 0.609 & 0.015 \\  & AR & 10 & 14.8 \(\pm\) 3.79 & 15.5 \(\pm\) 4.30 & \multirow{2}{*}{\begin{tabular}{l} TxG \\ Time (T) \\ \end{tabular} } & \multirow{2}{*}{0.000} & 0.100 & 0.000 \\  & Offline & 10 & 14.9 \(\pm\) 5.21 & 17.4 \(\pm\) 4.52 & \multirow{2}{*}{\begin{tabular}{l} TxG \\ Time (T) \\ \end{tabular} } & \multirow{2}{*}{0.887} & 0.359 & 0.047 \\  & AR & 10 & 10.4 \(\pm\) 2.17 & 8.8 \(\pm\) 1.61 & \multirow{2}{*}{\
\begin{tabular}{l} Time (T) \\ \end{tabular} } & 8.926 & 0.008 & 0.331 \\  & Offline & 10 & 9.3 \(\pm\) 2.83 & 7.8 \(\pm\) 1.13 & \multirow{2}{*}{
\begin{tabular}{l} TxG \\ Time (T) \\ \end{tabular} } & \multirow{2}{*}{0.196} & 0.179 & 0.098 \\ \hline \hline \end{tabular}
\end{table} 
Table 3: The results of the RM ANOVA for mood states. maximum heart rate of the experimental group was 150.4 bpm (75.2%), which corresponds to moderate-intensity exercise. The average maximum heart rate of the comparison group was 154.6 bpm, which is 77.3% of the maximum heart rate, corresponding to hard activity exercise. This is 1.3% higher than the medium intensity standard of 76%. And \(p\) value of heart rate during exercise is (\(p<0.05\)).
## 1 Introduction
In this work, we make an initial effort towards closing the outlined, increasing gap between state-of-the-art research in the numerics community and best practices in applications. As covering the entirety of numerical methods available is impossible in practice, especially for nonexerts in every single aspect, we initially restrict the scope of view to a rather narrow subset of methods. The added benefit of this approach is that this enables us to remove methods that would otherwise render making a problem-oriented choice largely ambiguous. The contributions of this work to address the abovementioned problems are twofold: First, we propose a unifying approximation taxonomy that enables recovering the most prevalent grid-based numerical methods by imposing some well-defined abstractions, albeit with a relatively narrow scope for now. Secondly, we propose a generalized framework for choosing an appropriate, that is, stable and performant, numerical scheme given a fixed set of inputs. These include the system of PDEs and the triangulation where the problem is defined, as well as the available computing hardware. As such a method necessitates a unified view of all the numerical methods considered to enable quantifiable comparisons, this heavily builds on the first part of this article. In combination, this enables an application expert to make an informed choice of which scheme to use on a per-field basis given some equally well-defined inputs. Since in an application setting, stability is typically more important than convergence rate, we focus our effort on providing methods that produce stable solutions but do not fall behind too much compared to the utmost performant alternatives. The remainder of this work is, thus, structured as follows: We first present a brief review of works in the literature that are concerned with comparing the mentioned numerical schemes that we subsequently build upon. The theory necessary to construct such a baseline will be covered in the following sections. We will then proceed by analyzing typically given inputs for a PDE problem and assemble a method to systematically derive suitable numerical schemes. The results of choosing and implementing numerical methods according to our developed framework will be demonstrated afterward. We will investigate two distinct benchmark problems, each comparing two methods that would be closest to being optimal in that specific case. Special attention will be given to accuracy concerning the analytical solution as well as computational complexity and performance. Finally, we will demonstrate the effectiveness of the presented framework by assessing a complex and currently relevant multiphysics problem. We show how to systematically arrive at a mixed choice of discretization schemes using the proposed decision method. Finally, we indicate some relevant works in the literature that employ similar approximations, highlighting the validity and relevance of this work.
## 4 Implementation
### Developing Edge Nodes for Collecting and Managing Data by [PERSON]  
The edge nodes are developed using the LattePanda Alpha, as shown in Figure 6. The LattePanda Alpha, which is similar to a mini PC, is a board capable of performing computation-intensive tasks or image processing. Therefore, the edge nodes in this study were developed using the LattePanda Alpha board, since a large number of biosignals must be collected, analyzed, and monitored in real time.  
For developing an edge node-based real-time data collection and management system, a framework must be capable of collecting, storing, and analyzing a vast amount of biosignal data in real time. Thus, this study proposes a node-based framework. Nodes exhibit better computation properties than do other web development technology, such as PHP/Nginx, and are frequently employed in real-time or high-speed applications.  
The system for collecting and storing data and analyzing emergency situations is a node-based socket server framework that can access and collect the data measured by IoT medical equipment through a wireless network. Packets transmitted to the TCP socket are analyzed and stored in InfluxDB, which stores time-series data. Furthermore, emergency situations are discerned using SpO2 and PR among the analyzed packets. When emergencies occur, emergency messages are sent in a JSON format to the cloud using WebSocket.  
Figure 5: The IoT pulse oximeter board and the pulse oximeter measurement.  
Figure 6: Edge node board.  
A ward monitoring system uses a web-based graphical user interface (GUI). The web-based GUI can be independently executed in an Internet-connected terminal device on which a web browser is installed. Users with access rights to this system can access it from anywhere in the world. The edge computing-based monitoring system presents raw data, SpO2, and PR in real-time, among the data measured by IoT pulse oximeters. Particularly, raw data measured from multiple IoT pulse oximeters must be presented in charts in real time. Therefore, this study developed a hospital room monitoring system and a GUI, as shown in Figure 7. The development framework used Node's Express, which provides an integrated web programming interface based on HTML5, CSS, and JavaScript.  
Patients in each ward are registered so that their PR, SpO2, and raw data can be presented in real time. Server-Sent Events (SSE) is used to express real-time data. To show a large amount of data in a monitoring system, the data must be continuously transmitted through one-way communication. Particularly, real-time charts that visualize the raw data must be shown continuously, without interruptions. However, a network delay or a delay between a server and client may occur. Due to such delays, real-time charts may show interruptions when presenting data. In this study, buffering technology is used to maintain the continuity of data.
# A High Efficiency Multistage Coder for Lossless Audio Compression using OLS+ and CDCCR Method
## 7 Adaptive Golomb Code and Context Adaptive Binary Arithmetic Coder
### Short-Term Feature of the Probability Distribution  
Analysing the closest neighbourhood composed of samples \(x(n-i)\) and the prediction error signal \(e(n-i)\), the fact that there are short-term dependencies between the coded data in sequence can be used. On the basis of these features, the correct type of distribution of the currently coded modified prediction error \(\widetilde{e}(n)\) value can be determined quite accurately, where \(\widetilde{e}(n)=2e(n)-1\) for \(e(n)>0\), and \(\widetilde{e}(n)=-2e(n)\) in otherwise.  
Starting from this assumption, a contextual arithmetic coder is usually designed so that has \(t\) distributions of probabilities associated with individual context numbers from 0 to \(t-1\). Theoretically, it is expected the increase in compression efficiency with the increasing number of contexts. However, there is the problem of too slow adaptation of their distribution to the approximate actual state. The adaptive nature of calculation of probability distributions requires a quick defined of the approximate target shape of each of \(t\) distributions. Therefore, a certain compromise should be made between the number of contexts and the speed of adaptation of their distributions. In coding of images \(t\) is 8 [33], 16 and even 20 [38].  
The proposed solution uses nine classes that define coarse signal characteristics from a short-term point of view, using principles similar to those used in the works [39; 40]. The \(\omega\) parameter is calculated as a weighted average of \(z=17\) previous prediction error modules \(|e(n-i)|\):  
\[\omega=\frac{5}{4z}\sum_{i=1}^{z}\frac{\left|e(n-i)\right|}{\sqrt{i}}. \tag{27}\]  
The \(\omega\) value is quantised using \(t-1\) thresholds \(\mathfrak{t}_{h(j)}\), to obtain the short-term arithmetic context number. For \(t=9\), thresholds were set as \(\mathfrak{t}_{h}=\{4,\,10,\,30,\,50,\,80,\,180,\,500,\,1100\}\), receiving \(b_{\text{medium}}\) number belonging to the range \(\overline{0;8}\).  
It is possible to include ultra-short-term features based on only the closest four errors, by calculating the \(\max\{e(n-1),\,e(n-2),\,e(n-3),\,0.6\cdot e(n-4)\}\) value. If the value is greater than 1500, the \(b_{\text{ultra}}\) bit assumes value 1, otherwise 0.
## 3 Experiments
### 5G Delay Experiments
#### 3.4.1 Methodology  
To understand how the 5G back-haul affects end-to-end responsiveness, we placed the Raspberry Pi 4 B + SIM8200 EA-M2 gateway on a public 5G network and used iperf3 to upload payloads of increasing size (1 KB \(\rightarrow\) 100 MB) to a cloud server. Three link-rates were imposed to emulate typical field conditions (Figure 10):  
* 100 Mbbs--fringe or throttled coverage.
* 500 Mbbs--average urban cell.
* 1 Gbs--near-peak sub-6 GHz performance.  
Figure 10 illustrates two usage scenarios, where the x-axis (logarithmic scale) represents the bandwidth in Mbps and the y-axis shows power consumption in Watts. The active usage related to power consumption and bandwidth is represented by the yellow line, and the channel load related to power consumption and bandwidth is represented by the red line. The power consumption increases with the bandwidth in both scenarios. These two scenarios are quite critical when we are dealing with energy-battery consumption. When dealing with low data rates, the system can be power balanced, while high rates require higher power supply capacity.
## 7 Proposed Framework
### Framework for Application Area 2: Food Supply Chain  
Figure 6 shows the proposed architecture for application area 2. The agribusiness supply chain, like that of any other industry, begins with crop loading and continues all the way to stocking the shelves of retail stores and foodservice operations. However, since it is connected to food, the procedure is much more crucial in this case. How can you guarantee that the food that has been provided is safe to consume? Except if the food supply chain is well controlled, everyone from the food producers to the merchants will be unable to determine if the food being given is of high quality. By being a viable option, blockchain in agriculture helps to provide transparency to the agricultural industry. With precision agriculture, blockchain may be used to record information about the crop, such as crop quality, seed kind, and the weather circumstances whereby the crops were planted, among other things [47].  
The same is true if the crops have been delivered to the refineries using IoT-enabled trucks, since it is simpler to record the temperature at which they have been exposed. This is important when food-processing firms are competing for contracts. At the very same time, it checks to see whether the food item being delivered is of high quality or not. In the provision of processed foods to wholesalers and retailers, the same procedure might be followed.  
This traceability method is equally applicable to the end user, the consumer. They may retrace the information in the following ways:  
* Information from farm origination;  
Figure 6: Proposed framework for application area 2.  
* Information from transportation;
* Information about batch numbers;
* Information about food processing;
* Information from factory;
* Information from expiry.  
At the same time, when the transparency of the supply chain improves, it will have a significant influence on the following areas:  
* Reducing fraudulent food issues;
* Removing mislabeled food;
* Removing intermediaries from the process;
* Ensuring food producers get paid on time;
* Allowing consumers to understand what they are paying for;
* Recording and updating the status of crops by the farmer;
* Tracking farmers through the process of planting, harvesting, and delivery.  
For the purposes of conclusion, we can say that blockchain has significant potential in the supply chain industry in terms of cost-cutting, seamless interaction and handling orchestration between various involved parties related to global supply chain and logistics business, as well as in terms of cost-savings. The involvement of the public, on the other hand, is a significant obstacle to large-scale blockchain deployment. Multiple actors collaborate in the supply chain, and in order to use BCT to improve efficiency and transparency in supply chains, all participants must work together. BCT is a collaborative effort. What exactly do we understand by collaboration in this context? They must agree to participate on a shared platform and adopt the set of criteria that have been agreed upon.
## 2 Materials and Methods
### Data Sampling and Analysis  
Two field trips were conducted in the study area. The first and second field trips were conducted on 28 March 2018, and 16 April 2019, respectively. During the first campaign, 30 in situ samples were collected from 30 sampling points. Meanwhile, 30 water samples were obtained from the second field trip collected from 30 stations. The distance between each sampling point is 1 km. Both field trips were conducted concurrently with the passing of Landsat 8 over the study area. Sample testing was conducted 2 h before and 2 h after the passing of Landsat 8 to maintain a strategic distance from the impact of TSS changeability related to tides and nearby streams [5,41]. Water samples, approximately 1.5 L, were collected inside a profundity of 1 m, and sample concentrations were measured employing a pondering method [42,43]. The TSS concentration was calculated based on the difference of a filter paper before (without TSS residue) and after (with TSS residue) the filter was dried. A Sartoris MGF glass fiber filter (47 mm diameter) was used. In this study, a well-mixed sample was filtered through a weighed standard glass-fiber filter, and the TSS residue was retained on the filter. Before removing the filter from the filtration apparatus, 3 successive 10 mL volumes of deionized water were used to wash the filter, allowing complete drainage between washings. Then, the filter was removed and dried in an oven at 103-105 \({}^{\circ}\)C for 1 h and left it cool in desiccators. The cool filter paper with TSS residue was weighed using a weighing balance. The process of heating, cooling, and weighing was repeated until a constant weight was obtained or until weight change was less than 4% of the previous weighing or 0.5 mg--whichever was less. The TSS concentration in the water sample was calculated using the following formula:  
\[\text{TSS}\;(\text{mg}/\text{L})=\frac{(\text{A}\;-\text{B})}{\text{Volume of filtered sample}\;(\text{L})} \tag{1}\]  
where,  
A = mass of filter + dried residue (mg),  
B = mass of filter (tare weight) (mg)
# Modelling the Microphone-Related Timbral Brightness of Record Signals
## 3 Brightness Modelling
### Initial Modelling of Brightness
#### 3.2.1 Automated Metric Selection: Across All Sources  
A linear regression model was calculated for each of the candidate metrics, and calibrated to the overall scaled brightness ratings. Linear regression was chosen as the modelling technique since the simplicity of the method reduces the likelihood of producing an overfitted model, therefore producing a model that is more likely to be generalisable. The performance of each candidate model was then assessed in terms of its Pearson's r (correlation), Spearman's rho (rank correlation), and root mean square error (RMSE), shortlisting the metric that performed best for each of these measures.  
The highest Pearson's r and lowest RMSE were achieved by the same model, which used one of the \(SC\) and Ratio\({}_{2}\) metrics. The highest [PERSON]'s rho was achieved by two models, both of which used one of the \(SC_{fc}\) and Ratio\({}_{1}\) metrics. These metrics were therefore shortlisted and the corresponding parameters are summarised in Table 2. Of the  
\begin{table}
\begin{tabular}{l l l} \hline \hline
**Metric** & **Variables** & **Total Number** \\ \hline \(SC\) & Audio weighting: 3 options & 168 \\  & Spectral smoothing: 7 options & \\  & Frequency scale: 4 options & \\  & Log transform: 2 options & \\ \hline \(SC_{fc}\) & Audio weighting: 3 options & 1512 \\  & Spectral smoothing: 7 options & \\  & Frequency scale: 4 options & \\  & Crossover frequency: 9 options & \\  & Log transform: 2 options & \\ \hline Ratio\({}_{1}\) \& Ratio\({}_{2}\) & Ratio type: 2 options & 756 \\  & Audio weighting: 3 options & \\  & Spectral smoothing: 7 options & \\  & Crossover frequency: 9 options & \\  & Log transform: 2 options & \\ \hline \(SC\)/\(SC_{fc}\) and Ratio Combination & \(SC\) type: 2 options & 6048 \\  & Ratio type: 2 options & \\  & Audio weighting: 3 options & \\  & Spectral smoothing: 7 options & \\  & Frequency scale: 4 options & \\  & Crossover frequency: 9 options & \\  & Log transform: 2 options & \\ \hline \hline \end{tabular}
\end{table}
Table 1: Summary of all 8848 candidate metrics for modelling brightness.  
two models that achieved the best Spearman's rho, the difference between the underlying metrics was the logarithmic transformation, with the logarithmic version performing much better in its Pearson's r and RMSE.