esa-sceva/satcom-chunk-collection huggingface dataset:
## 3 Task Scheduling Problem  
### System Architecture  
In the Fog environment, the processing takes place in a data hub on a smart device, or in a smart router, gateway, switcher, local server, etc. Because of limited processing capacity, some Fog nodes cooperate regionally together, simultaneously connecting to Cloud nodes known as Cloud virtual machines to satisfy mobile user's need. It was assumed that our system consists of \(f\) Fog nodes and \(c\) Cloud nodes as well as a Fog broker. Fog nodes communicate directly to mobile users. All requests from mobile users are forwarded immediately to Fog broker, who is responsible for analyzing, estimating and then scheduling all tasks to be executed in the Cloud-Fog system. The Fog broker is close to the Fog nodes, thus the time consumed for data communication between each other is negligible.  
To guarantee the performance of system, the TCaS algorithm, which is installed on the Fog broker, aims at finding an optimal task executing schedule achieving time and cost efficiency. The operation of our system model is described step by step in Figure 1.  
Firstly, a mobile user sends a request (Step 1), which is handled by Fog node it is connected to. This request (or job) is immediately forwarded to the Fog broker (Step 2). To be processed in distributed system, each job is decomposed into a set of tasks (Step 3), and then the number of instructions and the resource usage needed are estimated (Step 4). Handling all information of tasks and nodes, the Fog broker runs a scheduling algorithm (Step 5) to find a good task assignment. Following the output, tasks are sent to the corresponding Cloud nodes and Fog nodes (Step 6). Each node is responsible for processing all tasks assigned (Step 7) and then sends the results back to the Fog broker(Step 8). Once all tasks are completed, the result of the job is combined (Step 9) by the Fog broker. Subsequently, the response is sent to the mobile user through the Fog node that user connects with (Step 10).
## 3 The Proposed IoT-Based Master-Slave Regionalized Intelligent LED Light-Controlling System
### System Processes and Architecture  
Figure 4 shows a flowchart of the proposed system processes, and Figure 5 shows the system architecture of the proposed system. The proposed system first establishes a connection with the cloud server. When there is no connection, the proposed system repeatedly tries to establish a connection. After the connection is established, the proposed system waits for commands from the application on the one hand and starts to accept the external triggered signal. There are two possibilities for the content of the command. One is the triggered message from other LED lights, requesting to enter the high-light mode. The other is to set the LED lights parameters (high-light mode power (%), low-light mode power (%), high-light duration (T), field domain), and then the system checks whether the connection continues and repeats the whole process.  
When the proposed system starts to receive externally triggered signals, it will run in the low-light mode if no pedestrian/vehicle is detected and will continue to receive triggered signals. As long as pedestrians or cars are passing by, they will immediately turn into the high-light mode. It lasts for T seconds (the user can set the parameter T through the IoT module, and its default value is 30 s), and it will automatically switch to low-light mode after \(T\) seconds.  
\begin{table}
\begin{tabular}{c c c c} \hline
**No.** & **Feature** & **This Work** & **[1]** \\ \hline
4 & Timing control & Programmable (flexible setting) & RC charge/discharge (fixed) \\ \hline
5 & Control method & Master-Slave & No control mechanism \\ \hline
6 & Mobile device app. & Yes & No \\ \hline
7 & Application field & Large-scale field & Small-scale field \\ \hline \end{tabular}
\end{table}
Table 3: _Cont._Figure 4: Flowchart of the system processes.  
Figure 5: System architecture (see Figure 6 for the hardware block diagram of IoT LED).  
The proposed system can also upload the LED lights' high-light mode power, low-light mode power, high-light duration T, field and other parameters, and Master-Slave mode control data to the cloud through Wi-Fi 2.4 GHz wireless transmission. The terminal device performs parameter settings. The terminal device can be a mobile phone, tablet, or computer. When the Master LED light receives the command information from the cloud, it will immediately transmit it to other slave LED lights via Wi-Fi 2.4 GHz wireless transmission. Hence, the parameters of the LED lights belonging to the same zone can be easily set together instead of individually setting them one by one.
# Optimizing the Use of RTKLIB for Smartphone-Based GNSS Measurements
## 2 Strategies  
### PPK Solution  
Post-processed kinematics, or PPK, is a popular use case for RTKLIB, as it allows for high precision position results for previously recorded kinematic data. The PPK solution can utilize the provided GNSS observation file, an additional observation file from a nearby base station, and multi-constellation ephemeris files in order to perform precise positioning at each epoch. In addition to pseudorange measurements, PPK also utilizes the available carrier phase in the navigation solution. PPK in RTKLIB also allows the user to implement a noncausal Kalman filter computation, operating both forwards and backwards in time. By doing this, RTKLIB is able to detect directional anomalies, such as cycle slips, and combine both the results to produce results with better accuracy and integrity.
## 4 The Scheduler Architecture
### Checking the Possibility of Deadline  
This is where the system takes a decision on whether to transmit packets or not or if the packets meet their deadline upon transmission. The main reason for dropping a packet that misses its deadline is to conserve RF bearer resources. Prior to commencing transmission, the transmission throughput is unknown up till the end of the transmission. Therefore, the possibility of a deadline check needs to be against a throughput estimate. These assumptions can be the maximum interference from neighboring transmitting beams, the average throughput, or the highest theoretical throughput calculated in the system. Each of these approaches has its pros and cons since in the scenario of a false positive, the system drops packets that are unable to reach the UE on time or, conversely, the packets consume resources that are put to waste.
# Projected Augmented Reality Intelligent Model of a City Area with Path Optimization
## 2 Model Proposed
### Mobile Interface  
Figure 8 shows a picture of the cell phone user interface developed to control the system. As the figure shows, the interface is minimalist, optimized for small screens. After login, it shows a list of points of interest sorted by alphabetical order. The user can choose as many points of interest as desired and press \"START\" to send the information to PARIMC. Once the request is received by PARIMC, the GA is started. When the solution has been optimized, the path is shown in the PAR.  
Figure 7: Example of a population of the genetic algorithm, for the problem of visiting five different places. The population contains four individuals, each individual consisting of five genes—one for each location.  
Figure 9 details the process of communication between the mobile interface and the control unit. The communication protocol implemented assumes PARIMC is the server and the mobile application will play the role of a client. The server is listening to the socket, awaiting for incoming connection requests from the clients. Communication is asynchronous, using the TCP protocol.  
When a user chooses a number of places to visit in the interface and presses the START button, the application will generate a string with the request and send it to the server. The string starts with a prefix which is either A* or TSP, followed by the identification numbers of the places to visit. Prefix A* is used when the number of places is just two, for in that case it is not necessary to use the genetic algorithm to find the best path. When the number of places to visit is three or more, then the prefix will be TSP, meaning it will be necessary to optimize the path using the genetic algorithm.
## 3 Results and Discussion
### Physical Fiber Quality
#### 3.6.2 Fiber Diameter and Fineness  
The retted fibers' diameter and their corresponding fineness are shown in Figure 8 and Table 3. The kenaf fibers' bundle diameter retrieved from APPB and solvent-augmented retting, on the microscopic scale, ranged from 105.86 (0.10 mm) to 84.20 um (0.08 mm). These findings are comparable to the degummed fibers (113 um) reported by [65]. In textile technology, fiber fineness is described as weight per unit length, also known as linear density. It is the positive relationship between the fiber's surface area and the substances present in its composition. The observations of the fibers' diameters revealed that the uninoculated fibers possess higher fiber diameters, which, in turn, yielded coarser kenaf fibers (Table 3).  
Figure 8: SEM images of the retted kenaf fibers at a 1 mm magnification, showing the fiber diameters. (**a**). Uninoculated with SW. (**b**) Uninoculated with FW. (**c**) APPB1 with SW. (**d**) APPB1 with FW. (**e**) APPB2 with SW. (**f**) APPB2 with FW.  
Among the retting treatments, the differentiations of non-cellulosic gums and the fiber dimensions were also observed. The surface and diameter of the natural fibers were aligned with the adjacent gums, and their elimination through the retting process reduced its dimensions and improved fineness [66]. The finer fibers showed the fibers possess a lower mass per unit of length. Natural cellulosic fibers with excellent fineness are suitable for fabrics and textiles. The fineness scores determined the end uses of the fiber as coarse fiber could use as rope, mat, or geotextile and fine fiber for textile fabric and clothing [67; 68].
# Iteratively Refined Multi-Channel Speech Separation
## 2 Proposed Method
### Initial Separation
During the MVDR beamforming, these separated waveforms are employed in the computation of the relevant SCM in the MVDR beamformer, i.e.,  
\[\hat{\mathbf{\Phi}}_{f}^{\text{Target}}=\frac{1}{T}\sum_{t=1}^{T}\hat{\mathbf{Y}}_{q, t,f}\hat{\mathbf{Y}}_{q,t,f}^{H} \tag{6}\]  
\[\hat{\mathbf{\Phi}}_{f}^{\text{Interfer}}=\frac{1}{T}\sum_{t=1}^{T}\left(\mathbf{Y}_{ t,f}-\hat{\mathbf{Y}}_{q,t,f}\right)\left(\mathbf{Y}_{t,f}-\hat{\mathbf{Y}}_{q,t,f}\right)^{H} \tag{7}\]  
where \(\hat{\mathbf{\Phi}}_{f}^{\text{Target}}\in\mathbb{C}^{\text{C}\times\text{C}}\) and \(\hat{\mathbf{\Phi}}_{f}^{\text{Interfer}}\in\mathbb{C}^{\text{C}\times\text{C}}\) represent the SCMs of the speech and interference sources. \(\hat{\mathbf{Y}}_{q,t,f}\in\mathbb{C}^{\text{C}\times\text{I}}\) is the estimated clean signal vector composed of the STFT coefficients of C microphones at the time-frequency bins, which is computed from the output signals of multiple TFDPRNN modules for the \(q^{\text{th}}\) speaker. \(\hat{\Upsilon}_{t,f}\in\mathbb{C}^{\text{C}\times 1}\) is the multi-channel signal vector, which also consists of the STFT coefficients of C microphones at the time-frequency bins. The notation \(H\) denotes the Hermitian transposition operation. Based on these SCMs, the MVDR beamformer's weights can be obtained as follows:  
\[\mathbf{w}_{f}=\frac{\left(\hat{\mathbf{\Phi}}_{f}^{\text{Interfer}}\right)^{-1 }\hat{\mathbf{\Phi}}_{f}^{\text{Target}}}{Tr\bigg{\{}\left(\hat{\mathbf{\Phi}} _{f}^{\text{Interfer}}\right)^{-1}\hat{\mathbf{\Phi}}_{f}^{\text{Target}} \bigg{\}}}\mathbf{u} \tag{8}\]  
where \({}^{-1}\) denotes the inverse of a matrix, \(\text{Tr}\left\{\ \right\}\) denotes the trace of a matrix, which is the sum of the diagonal elements of the matrix, and \(\mathbf{u}\) denotes a one-hot vector representing the reference microphone. Subsequently, the signal separated by the MVDR beamformer is given as:  
\[\hat{z}_{q}^{(1)}=\text{ISTFT}\Big{\{}\mathbf{w}_{f}^{H}\mathbf{Y}_{t,f}\Big{\}} \tag{9}\]  
where \(\hat{z}_{q,c}^{(1)}\) denotes the estimated signal of the \(q^{\text{th}}\) speaker in the initial separation and \(\text{ISTFT}\{\ \}\) denotes the ISTFT operation. During the post-separation process, the output \(\hat{z}_{q}^{(1)}\) is regarded as additional input along with the original mixed signal xc and sent to the post-separation network to obtain the initial separation output \(\hat{y}_{q,c}^{(1)}\). Importantly, the post-separation network has the same structure as the pre-separation network.
# NR Sidelink Performance Evaluation for Enhanced 5G-V2X Services
## 3 Literature Review
Both technologies show comparable communication reliability at short ranges. The research also explores elements such as resource block collisions in LTE, hidden terminals in DSRC, and channel attenuation. In this work, we focused on the vehicles' average speed, vehicles' density, and the number of vehicles to evaluate sidelink's strength and drawbacks. We used simulation frameworks (NS3 and SUMO) to compare 5G NR Sidelink performances in urban and highway scenarios.
# Multiscale and Failure Analysis of Periodic Lattice Structures
## 6 Summary and Conclusions  
If a lattice structure consists of many periodic geometries, finite element analysis with modeling every lattice member is very time-consuming. To address this issue, a full-cycle multiscale analysis technique was proposed for lattice structures made of beams. The multiscale technique can determine both stiffness and stress of the lattice structure efficiently and accurately.  
To verify the multiscale analysis technique, both displacements and stresses were compared between the results obtained using the multiscale analyses and the detailed finite element analyses for multiple example problems. Those were the cantilever beam and the beam clamped at both ends. Those beams were constructed with square or rectangular shapes of lattice structures with or without diagonal lattice members. The size of those beams and the geometric configuration of internal lattice members were varied. Both upscaling and downscaling processes were assessed individually. The full-cycle multiscale analysis gave very accurate displacements and stresses as compared to those of the detailed finite element analyses.  
Furthermore, experiments were conducted on lattice structures to determine their failure loads, which were also predicted using multiscale analysis with the recent failure criterion. It uses both stress and stress gradient conditions to predict failure. Because the lattice members were subjected to both axial and bending loads, the failure was governed by the stress gradient condition. The predicted failure loads agreed well with the experimental values.  
Even though this study was focused on 2-D lattice structures, the proposed full-cycle multiscale analysis methodology can be extended to 3-D lattice structures with a 3-D unit cell model. If a lattice structure has a buckling failure mode, that can be predicted from the lattice members under compressive loading. The next study is the application of the current multiscale framework to 3-D auxetic structures to predict their failure loads.  
Conceptualization, Y.K.; analysis and methodology, Y.K.; specimen preparation and testing, M.M.; data validation, Y.K. and M.M.; writing--original draft preparation, Y.K.; writing--review and editing, M.M.; supervision, Y.K.; project administration, Y.K.; funding acquisition, Y.K. All authors have read and agreed to the published version of the manuscript.  
Figure 10: Comparison of experimental and predicted failure loads.  
**Funding:** This research was funded by the Office of Naval Research, and the funding document number is N0001424 WX02019.  
**Institutional Review Board Statement:** Not applicable.  
**Informed Consent Statement:** Not applicable.  
**Data Availability Statement:** All the data are included in the paper.  
**Conflicts of Interest:** The authors declare no conflicts of interest.
# Robotic Grasping of Unknown Objects Based on Deep-Learning Based Feature Detection
## 2 Methodology
### Objects without Parallel Detected Edges  
If a suitable pair of straight edges cannot be found after the loosening of constraints due to the shape of the object, the algorithm is equipped with additional logic to identify the general shape of such objects and hence execute a different grasping strategy. For an object with multiple features detected but none that fulfill the requirements for a parallel pair of edges, the algorithm identifies the longest straight edge based on \(l_{E_{i}}\) as the point of contact for the first finger. The middle point of the edge \((x_{E_{i}},y_{E_{i}})\) is projected at 90\({}^{\circ}\) towards the other side of the object and moves along the edge until it intersects the first nearest perimeter \(P\) at point \(K\) with coordinates \((x_{K},y_{K})\). This marks the position of the second finger. The algorithm then checks the distance between these two points to ensure it is not larger than the gripper maximum opening \(d_{max}\).  
\[\sqrt{(x_{K}-x_{E_{i}})^{2}+(y_{K}-y_{E_{i}})^{2}}\leq d_{max} \tag{10}\]  
If the distance is graspable, then these two points give the grasp position. Otherwise, the algorithm discards them and moves on to the next longest edge to repeat the process until this condition is met. The grasp position is then established.  
If \(|E|=n=1\) and \(A\) is small, the object could be a very small, stick-like object such as a spoon, as shown in Figure 12a. The algorithm grasps at position \((x_{E_{1}},y_{E_{1}})\) and orientation \(\theta_{E_{1}}\), as illustrated in Figure 12b.  
Figure 11: Object without parallel straight edges: A triangle is shown with 3 detected straight edges. When the threshold is set at 0\({}^{\circ}\), there is no suitable combination of parallel pairs. When the threshold is loosened to 20\({}^{\circ}\), a pair is chosen and the grasp position is established.  
Figure 12: (**a**) An object with a small area and only one straight edge is detected. (**b**) The algorithm grasps at that straight edge.
## 3 Materials and Methods
### Stream Processing and Storage of Manufacturing Data
#### 3.3.4 Multithreaded Parallel Data Consumption  
With the continuous development of computer technology, multi-threading technology has been gradually adopted by smart factories, the main purpose of which is to reduce the idle time of the central control computer of the smart factory, give full play to its performance so as to enhance the throughput of the whole system, and improve the response speed and overall performance of the data acquisition end and the application side. However, in a large number of devices in a smart factory, the individual acquisition threads do not continuously send and receive data but are only activated when the data state changes. As a result of this feature, threads are frequently created and destroyed, which puts greater pressure on system resources and reduces processing efficiency.  
For this reason, this paper uses a custom implementation of a thread pooling mechanism based on Python's threading module to process the real-time data obtained from Kafka for multi-threaded consumption, as shown in Figure 9. Thread pools avoid the overhead of frequent thread creation and destruction by pre-creating a fixed number of Worker Threads that pull pending Kafka messages from a shared task queue. In the specific implementation, the thread pool is configured with the following parameters:  
1. Thread pool size (number of worker threads): set to 8, according to the number of CPU cores (4 cores and 8 threads) of the experimental server, to achieve a balance between concurrency and system resource occupation;
2. Task queue size: set to 1000 to cache the pending messages consumed by Kafka to avoid thread blockage caused by burst data.
3. Blocking policy: When the task queue is full, the producer thread (Kafka consumer) blocks the waiting queue to have empty seats to ensure the stable operation of the system.
4. Thread lifecycle management: All threads start when the main program is initialized and continue to cycle through the task until the program exits.  
This mechanism realizes the quasi-real-time concurrent processing of Kafka messages in actual operation, which has good throughput and system responsiveness and avoids the additional overhead caused by frequent thread creation. The thread pool size and queue capacity can be flexibly adjusted based on Kafka message throughput and server resources.  
Figure 8: Example of sending and consuming Kafka messages.
## 4 Proposed Solution
### Selection of Wireless Communication Technology
\begin{table}
\begin{tabular}{c c c c c} \hline \hline
**Technology** & **Standard** & **Data Rate (bit/s)** & **Range (km)** & **Required Power** \\ \hline NB-IoT & 3 GPP Cellular & 250 k & Urban 8, Rural \(>\) 25 & Low \\ \hline LoRa & Proprietary & \textless{}50 k & Urban 5, Rural \(>\) 15 & Very Low \\ \hline Sigfox & Proprietary & 100 & Urban 10, Rural 50 & Very Low \\ \hline Ingenu & Proprietary & 20 & Urban 3, Rural 15 & Very Low \\ \hline Dash7 & ISO/IEC 18000–7 & 13 k, 55 k, 200 k & 1–2 & Very Low \\ \hline
6 LoWPAN & IEEE 802.15.4 & Less than 250 k & \textless{}0.1 & Low \\ \hline ZigBee & IEEE 802.15.4 & 20 k, 40 k, 250 k & \textless{}1 & Low \\ \hline Wi-Fi & IEEE 802.15.11 & Up to 54 M & 0.2 & High \\ \hline New Wi-Fi & IEEE 802.15.11 ah & \textgreater{}150 k, \textless{}7.8 M & 1 & Low \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Low-Power Wireless Area Network technologies basic features. LoRa: Long-range. Figure 3: (**a**) LoRa network protocol for the WARM system, (**b**) LoRaWAN protocol stack.
# Telecommunication Systems for Small Satellites Operating at High Frequencies: A Review
## 5 Comparison  
The three missions are very different in terms of goals, mission trajectories, mission lifetime, and environment. Hence, it is hard to compare telecommunication systems developed to satisfy different needs and requirements. However, as a summary, a comparison (Table 4) lists the different telecommunication characteristics for these three missions:  
In terms of reliability, it is worth noticing that these systems are not fully redundant as is generally the case for large space missions and commercial satellites. This is the result of the \"CubeSat design philosophy\", which is agile in terms of cost and development schedule. That does not mean reliability is not considered, since measures are still taken to minimize failures and to reduce risks. For example:  
1. The systems are not fully redundant but they have some redundancy in terms of antennas or frequencies used. ASTERIA has a single radio but two antennas which can be used alternatively. MarCO has two receivers (UHF and X-Band), three X-Band transmitting antennas (LGA, MGA, HGA), and three receiving antennas (one at UHF, and two at X-Band). ISARA has an uplink/downlink system at UHF and a Ka-Band downlink.
2. Each component was carefully tested at the vendor and at JPL (at the system level for the spacecraft integrated at JPL: MarCO and ASTERIA).  
\begin{table}
\begin{tabular}{c c} \hline \hline
**Parameter** & **ISARA Antenna** \\ \hline Frequency & 26 GHz (transmit) \\ Peak gain & 33.5 dBi \\ Half-power beamwidth & 2.5 deg \\ Power handling & 10 W \\ Impedance & 50 Ohm \\ Polarization & RHCP \\ Temperature Range & \(-\)40 deg C to +85 deg C \\ \hline \hline \end{tabular}
\end{table}
Table 3: ISARA’s antenna characteristics.  
Finally, the value of technical communication cannot be stressed enough. In each of these projects, communication with the vendors and within the different subsystems allowed us to identify issues and components' idiosyncrasies early on. This allowed the development of procedures to work around and minimize problems, and to maximize the functionality for each of the components during operation.