esa-sceva/satcom-chunk-collection huggingface dataset:
# Rotational Speed Control Using ANN-Based MPPT for OWC Based on Surface Elevation Measurements
## 4 Results and Discussion
### Control Assessment with Regular Waves  
To assess the power generation improvement offered by the proposed ANN-based rotational speed control strategy, a comparative study using ANN1 and ANN2 with two representative sea conditions from the coast of Mutriku were considered from the wave spectrum of Figure 13.  
The wave's input features consist of a water depth \(h=5\) m and a wave period \(T_{w}=10\) s. The first wave condition has an amplitude of \(A=0.8\) m from 0 s to 97.5 s while the second wave condition has an amplitude of \(A=1.3\) m from 97.5 s to 200 s as presented in Figure 19.  
Figure 20 shows the airflow speed for both waves in the uncontrolled case. With the second wave the airflow speed is stronger which will provoke the stalling behavior.  
To prevent the stalling phenomenon, the proposed ANN rotational speed control increases the speed when the critical values are reached as shown in Figure 21. This successfully increases the speed in terms of average value from 264.2 rad/s to 272.6 rad/s using ANN1 and 274.1 rad/s using ANN2.  
Figure 19: Considered wave input to the implemented OWC model.  
Figure 20: Airflow speed from incoming wave input.  
Figure 22 shows the flow coefficients which, in the first wave, did not exceed the threshold value 0.3 in the uncontrolled so no control action was required in the controlled case. However, in the second wave, the flow coefficient exceeds the threshold value hence the increase of the rotational speed helped adjusting it.  
Figure 23 presents the obtained torques and it is indicated that in the case of the second wave condition the torque in the uncontrolled OWC has decreases significantly at every crest reducing the torque's average value to 61.16 Nm. On the other hand, while using the ANN rotational speed control the torque has been held at the highest speed which offered a higher average value of 63.02 Nm using ANN1 and 66.22 Nm using ANN2.  
Figure 21: Rotational speed for the OWC. (**a**) Uncontrolled case. (**b**) ANN1-rotational speed control. (**c**) ANN2-rotational speed control.  
Figure 22: Flow coefficient for the OWC. (**a**) Uncontrolled case. (**b**) ANN1-rotational speed control. (**c**) ANN2-rotational speed control.  
Figure 24 presents the produced power which is negative because it is absorbed by the grid. The produced power did not suffer a power drop at the crests of the second wave condition. As a result, the average value of the produced power has increased to \(-16.51\) kW using ANN1 and \(-17.39\) kW using ANN2 compared to \(-15.52\) kW in the uncontrolled case. From these results the total power increase obtained from using the ANN rotational speed control for only \(50\) s is \(19.36\) kW corresponding to \(2.53\%\) for one OWC.
# Blockchain Architecture for Lightweight Storage
## 6 Security Analysis  
This paper introduces the concepts of node positivity and the evil-doing factor, elects honest and reliable nodes for block generation, and employs the PBFT consensus method to verify the legitimacy of the blocks, thereby ensuring the security of the system.  
In a traditional blockchain architecture that employs the DPoS consensus algorithm, the selection of agent nodes depends on the number of votes each node holds, and malicious nodes can bribe high-interest nodes to vote for them, facilitating bribery attacks. In LSB, interest constitutes only a part of a node's reputation value, leading nodes to vote for those with higher reputations to protect their interests, making bribery attacks challenging to execute.  
LSB is also tamperproof. To ensure the integrity of the block content, the elements inside the block are processed using the SHA-256 algorithm to generate a unique hash value. If the content of the block is tampered with, the hash value will change, ensuring the data on the blockchain cannot be tampered with. Due to the decentralized nature of blockchain, malicious nodes would need to rewrite the ledger of more than half of the nodes in the network to tamper with the data. The blocks are linked to the previous block by the hash value. If a transaction is tampered with, the hash within the block changes. Nodes can detect tampering by checking the integrity of the previous block's hash.  
Attackers can create multiple nodes to join the network, allowing them to control the entire blockchain; this is known as a witch attack. In LSB, node selection is based on reputation value, with the weight and positivity of newly joined nodes created by an attacker set to 0, preventing them from being selected as consensus nodes and effectively thwarting the witch attack.  
A malicious node sends the same transaction twice in an attempt to fork the blockchain for a double-spend attack. In LSB, blocks produced by the agent node are accepted by the client node and sent to the verification node, which runs the PBFT algorithm to verify the block height and hash values, preventing double-spend attacks.  
To avoid excessive centralization like DPoS, LSB introduces node weight and positivity in the reputation value model, comprehensively assesses node performance, weakens the link between node selection and weight, prevents high-weight nodes from monopolizing block exits, and incentivizes ordinary nodes to participate in consensus, thereby promoting system fairness and impartiality.
## 6 Testing and Measuring Performance: Analysis of PSO, GWO, and Hybrid PSO-GWO Methods
### Method Comparison  
The PSO method allocated traffic light priority to both Street1 and Street4, while Street2 and Street3 were given lower priority. This setting produced a high accuracy score of 0.9981, which means the traffic flow is very good, but there is still potential for further optimization.  
The GWO method assigned different priorities, with Street3 given the highest priority. This method produced an accuracy of 0.9989, which indicates minimal traffic.  
Figure 9: Result of cumulative traffic movement over time for three methods.  
The hybrid PSO-GWO approach performed the best, achieving an almost perfect precision score of 0.99999. Its priorities were more evenly balanced, with slightly higher priority allocated to Street1.  
Compared to other systems, such as [6] use of the Welch-Powell algorithm for signal optimization and [7] use of IoT traffic control for emergency vehicles, hybrid PSO-GWO offers the greatest increase in scale and flexibility. While these systems focus on specific situations, such as emergency vehicle priority or increased signal timing, the integrated approach is suitable for traffic flow and multi-objective optimization, resolving the complexities of traffic jams.  
Likewise, ref. [8] on using NodeMCU ESP8266 and IR sensors was successful for emergency vehicle detection but faced difficulties regarding sensor use and delivery. In turn, our integrated approach reduces reliance on external equipment and manual intervention, making it more robust and efficient in handling diverse and wide-ranging traffic situations.
## 4 Results and Discussion
Figure 9: Resource Utilization Comparison of IC-U-Net, ECGDnet, and 1D-ResCNN (**a**) shows the Process CPU utilization (**b**) shows the GPU utilization (**c**) shows the Process memory in use (MB). Furthermore, _ECGDnet_ exhibits minimal graphics processing units (GPU) utilization, unlike IC-U-Net, which relies heavily on GPUs. This makes _ECGDnet_ highly compatible with low-power devices that typically lack GPU capabilities [3, 38]. Memory efficiency is another standout feature: _ECGDnet_ maintains the lowest and most stable memory usage throughout runtime. This characteristic is particularly beneficial for TinyML applications, where devices are often constrained by limited random access memory (RAM). Overall, _ECGDnet_'s low resource requirements, energy efficiency, and real-time inference capability make it a highly advantageous choice for deploying health-monitoring models on edge devices. The computational efficiency of _ECGDnet_ is a pivotal consideration in its relevance to large-scale datasets and real-time biomedical signal processing. As illustrated in Figure 9, _ECGDnet_ exhibits a moderate yet steady level of CPU utilization, suggesting optimization for parallel computation and minimal processing bottlenecks. In contrast, IC-U-Net shows fluctuating and elevated GPU usage, indicating a greater reliance on GPU acceleration. _ECGDnet_'s consistently low GPU usage implies either a smaller number of trainable parameters or reliance on computationally efficient operations, making it lightweight even for GPU-enabled environments. An analysis of memory consumption further reveals that _ECGDnet_ has significantly lower memory demands compared to IC-U-Net, positioning it as a preferable option for memory-constrained applications, including wearable devices and real-time remote health monitoring systems [39, 30, 28, 40, 41]. Thanks to its minimal memory requirements and optimized CPU utilization, _ECGDnet_ exhibits strong scalability for deployment across large datasets without incurring substantial computational costs. The model's efficiency promotes feasibility for extended ECG analysis over large patient populations. Additionally, the consistent computational footprint suggests that real-time ECG denoising on edge computing platforms is achievable. Nevertheless, the limited GPU usage highlights opportunities for further optimization. Techniques such as hardware-aware quantization, network pruning, or tensor decomposition could enhance inference speed and energy efficiency. Future research should focus on improving GPU parallelism and advancing deep learning acceleration strategies. Such developments are crucial for reducing latency and enhancing the practical deployment of _ECGDnet_ in real-time clinical environments, particularly for ambulatory ECG monitoring and continuous patient surveillance.
## 3 Results
### In-Orbit Results  
#### 3.2.1 CPD Instrument  
Five datasets were obtained from the Liulin detector during the early operations phase of the Ten-Koh mission. Table 6 shows the processed data from three different days when Ten-Koh satellite was flying over Japan. The Liulin detector was operated in a real-time mode, which means that the measured data were transmitted to the ground station without storing them on the SD card. These datasets represent the first in-orbit measurements from the CPD instrument. The real-time mode of the CPD was selected in order to test the system behavior when turning on the major load on-board. The data obtained from the early operations show that, for close L-shell [29] values (1.129 to 1.206) and around the same time conditions (afternoon local time), the fluence has an average value of 0.28 particles/cm\({}^{2}\)/s. For a GEO field with no perturbations and short duration measurements period (less than 1 min), the particles flux is expected to be in this order, i.e., the CPD data are consistent with the expectations. However, the dose rate from the CPD data shows fluctuations. The average dose rate measured was 1.74 \(\upmu\)Gy/h, which is equivalent to 4.832 \(\times\) 10\({}^{-8}\) rad/s. The low dose rate measured in the second spectrum on 18 November 2018, comes from only low energy channels registering hits in the instrument. Figure 11 shows the five spectra and the corresponding average spectrum (in black) from the real time datasets. The horizontal axis in Figure 11 represents the deposited energy (in 256 channels) for the energy range from 0.081 to 20.833 MeV of the Liulin detector. In yellow, the spectrum with the lowest dose rate shows that the instrument registered only deposited energy in the low energy channels, which in turn reduced the received dose. Similarly, the second spectrum on 18 November 2018, measured deposited energy in the low region of the instrument's energy range. In both cases, the total dose rate resulted in less than 1 \(\upmu\)Gy/h. The cause of the fluctuations in the dose rate is associated with the rotation of the satellite, which misaligned the CPD-Liulin detector with respect to the GEO field lines as it was traveling around the Earth. This is observed for the spectrum 2 on 12 November and 18 November 2018, where the precedent spectrum in each case measured a higher dose rate than spectrum number 2. Figure 12 shows the geographic locations of the real-time mode CPD mission performed on Nov 2018. Figure 11: Dose rate and flux spectra obtained from the real time operation mode for the first CPD-Liulin data measurements on November 2018 during the early operation phase of Ten-Koh satellite: (a) dose rate spectrum for each dataset and the average spectrum measured inside Ten-Koh spacecraft; and (b) integral flux spectrum for the 5 real time datasets and the average flux spectrum measured inside the spacecraft.
# Effect of Environmental Parameters on Structural Health Status Assessment Using OMA Techniques
## 7 Data Analysis with Applied OMA Methods
### Application of the Cov-SSI Method and the Poly-Reference Least Squares Complex Frequency Method
The identified frequencies are correlated with the axial force trend and with the temperature trend.
## 3 Results and Discussion
### Milk Volatile Analysis  
Volatile analysis of milks using untargeted GC-MS SPME technique identified 34 compounds present in each of the samples (Table 9). Measurement of the volatiles in the headspace of products provides a representative view of the volatiles relative to the olfactory response [34]. There are a variety of factors that can impact the volatile profile of milk. A comprehensive review of the topic has highlighted a direct transfer of many volatiles from grazing or from conserved forage, some of which are related to plant (forage) metabolism or fermentation during conservation processes but many volatiles are also transferred indirectly post rumen metabolism [35]. In total, 33 compounds were detected in milks from each of the treatments from a variety of chemical groups including benzenes (10), ketones (6), sulfur compounds (1), alkenes (2), aldehydes (5), terpenes (4), and alcohols (2). Principal component analysis of the data revealed that the volatile profile of the CONC diet was distinctly different to the other supplementary feeding systems (Figure 2). A number of volatiles were identified to be  
Figure 1: Principal component analysis of fatty acid methyl esters (FAME) compounds detected from milks from each of the diets, parlour concentrate (CONC), palm kernel expeller (PALM), soya hulls (SOYA), and molassed beet pulp (BEET), principal component analysis (PCA). responsible for this separation (Figure 2A). Dietary treatment was demonstrated to have a significant effect on the volatile profile of millks. Pentanal and hexanal are both aldehyde compounds typically derived from the degradation and oxidation of fatty acids. Pentanal was present at significantly (\(P<0.05\)) higher concentrations in PALM than that of BEET and CONC, while levels of pentanal in SOYA were also significantly higher than that of CONC. Hexenal was significantly higher in BEET-, PALM-, and SOYA-derived millks than that of CONC. Hexanal mostly results from the degradation of oleic acid and linoleic acid, while pentanal can be derived from the oxidation of arachidonic and linoleic acid. Indeed, the levels of pentanal in millks were significantly and positively correlated with concentration of milk linoleic acid (\(P=0.019\), \(r=0.661\)). The volatile p-xylene was present at significantly higher levels in CONC than that of BEET, PALM, and SOYA. The presence of p-xylene may be the result of carotenoid degradation, namely \(\delta\)-carotene degradation [36], or possibly directly transferred from the feed [37]. Figure 2: Principal component analysis of volatile compounds detected from millks from each of the diets, parlour concentrate (CONC), palm kernel expeller (PALM), soya hulls (SOYA), and molassed beet pulp (BEET).
# Remote Low-Cost Differential Isolated Probe for Voltage Measurements
## 3 Probe Test and Validation
### Isolated Voltage Probe as an Oscilloscope Probe
#### 3.1.2 Three-Phase-Controlled Rectifier  
This test is performed to determine the feasibility of the designed probe to be used in non-high-frequency rectification systems such as the circuit shown in the schematic in Figure 13 for a signal frequency of 300 Hz.  
The performance of the proposed probe in this test is compared again with the commercial probes mentioned previously. The measurement setup is shown in Figure 14. In this case, the probes measure the voltage across the resistive load V\({}_{\rm L}\) (Figure 13) at different firing angles of the three-phase-controlled rectifier bridge so that the behaviour under dif  
Figure 12: [PERSON] experimental measurements. Oscilloscope screenshots for signals (**a**) 150 V amplitude and 16 Hz frequency AC signal. (**b**) 230 V and a frequency of 33 Hz. (**c**) 230 V and a frequency of 33 Hz and load current.  
Figure 13: Three-phase-controlled rectifier scheme.  
ferent operating conditions is determined. The experimental results are shown in Figure 15. Channels 1 (yellow) and 2 (green) correspond to the measures obtained using the Tektronix P5205 and the Chauvin Arnoux DP25 probes, respectively. Channel 3 (blue) represents the measurements provided by the proposed isolated probe. Finally, Channel 4 (pink) shows the current load measured using a Tektronix TCP202 hall effect probe.  
Figure 14: Experimental setup to test the operation of the proposed probe using a three-phase-controlled rectifier bridge.  
Figure 15: Three-phase-controlled rectifier experimental measurements. (**a**) \(0^{\circ}\) degree shooting angle control. (**b**) \(60^{\circ}\) degree shooting angle control. (**c**) \(90^{\circ}\) degree shooting angle control. (**d**) More than \(90^{\circ}\) degree shooting angle control. (**e**) Detail of \(90^{\circ}\) degree shooting angle control.  
Figure 15 shows a similar behaviour for all three probes, with a gain error in the proposed probe that can be easily compensated after calibration.
## 2 The Evolution from Cloud Computing to MEC
### Fog Computing  
The Data Centers (DCs) of large companies providing cloud services can be quite far apart, and this can cause some issues such as long end-to-end delays and lack of sufficient bandwidth. These problems have not been addressed completely so far [26]. Fog computing is an architecture initiated by CISCO in 2012 [27], as \"an extension of cloud computing paradigm from the core to the edge of the network. It enables computing at the edge of the network, closer to IoT and/or the end-user devices using virtualization techniques\". NIST offers another definition of fog computing as \"a horizontal, physical or virtual resource paradigm that resides between smart end-devices and traditional cloud computing or data center\" [28] (Special Publication 800-191). According to [29], fog computing is \"a scenario where a huge number of heterogeneous (wireless and sometimes autonomous) ubiquitous and decentralized devices communicate and potentially cooperate among them and with the network to perform storage and processing tasks without the intervention of third parties. These tasks can be for supporting basic network functions or new services and applications that run in a sandboxed environment. Users leasing part of their devices to host these services get incentives for doing so\". Figure 2 presents the basic architecture of fog computing.  
Fog computing is about avoiding exchanging data with remote network elements as much as possible, as one would in a cloud computing paradigm. Instead, devices close to each other can share data directly using device-to-device communication and nearby small cell networks [30; 31]. Furthermore, in a Fog Network (FogNet) [32], the devices at the edge share some of their resources, such as computing power and storage capacity, to help neighboring nodes. Only the tasks that the edge devices cannot handle are sent to the main cloud for processing. Consequently, fog computing reduces the computing load of the cloud remarkably. The differences between fog and cloud computing are summarized in Table 2.
# An Internet of Things-Based Low-Power Integrated Beekeeping Safety and Conditions Monitoring System
## 2 Related Work on Internet of Things (IoT) Beehive Incident Response and Management Systems
### IoT Beehive Conditions Monitoring Systems
In this join process, a 64 bit device identification (ID) (DevEUI) and a unique per application 64 bit application ID (AppEUI) statically set at the LoRaWAN server are used for node-to-server authentication. The data generated from this authentication join process network and application session keys are then used for AES-128 payload encryption and construction of the Message Integrity Code (MIC) in each LoRaWAN transmitted frames' payload [30; 33]. However, since the initial join request message fields are plaintext transmitted, the whole authentication process is susceptible to replay attacks since the DevNonce join request value can be easily predicted. A more robust and adaptive authentication mechanism using a PKI infrastructure [40] is by far more robust and is considered as future work, but the usage of a non-symmetric algorithm for the process of IBSMC data encryption contributes significantly to the end motes energy consumption by increasing significantly transmitted data payload sizes [41]. * Collective information from a specific beekeeping array as well as notifications via the cloud push notification service are presented to the bee farmer via a user-friendly mobile phone application that interacts with the Information System for Management and Control of Apiaries (IMSCA) system services. The management module of the proposed ISMCA system cloud services provides specific capabilities to the apiarist, such as: (a) automated information services monitoring the status of the beehives and beehive array events, (b) monitoring of the beehives using sensors and supervision services with alerts, notifications and forecasts, and (c) recording of the beekeeper's apicultural interventions within the beehive array (regarding nutrition cases or disease events). The IBSMC system will also provide specific cultivation suggestions in order to produce higher quality products and modeling capabilities that focus on the formation of cultivation partnerships and for creation of recognized brand products. Figure 2: Automated beehive cells architecture, sensors and actuators. (**a**) Internal hive cell, (**b**) Hive lid external view, (**c**) Hive lid internal view, (**d**) central beehive system-architecture.