## 3 Simulation Environment and Approaches
### Software and Hardware Configuration for PIL and HIL
#### 3.3.2 Sensor Emulator  
Software verification and validation are crucial prior to deploying a flight-ready CubeSat model. To facilitate this, a real-time sensor emulator is implemented to transmit sensor data simulated by Matlab/Simulink. This includes sensor noise and employs communication protocols such as USB and I2C.  
The real-time emulator computer transmits sensor parameters to a sensor simulation block implemented on a developed board. This data is sent via I2C to an Attitude Determination and Control System (ADCS) block, which generates the 6-DOF CubeSat dynamics orbit data. This information is then relayed back to the developed board and forwarded to the simulation computer. The sensors used in the emulator include sun sensors, magnetometers, and gyroscopes.  
For transmitting sensor simulation data, the USB OTG FS communication protocol is employed, supporting data transfer rates up to 12 Mbps in USB 1.1. This choice eliminates the need for additional hardware on the development boards, thereby optimizing energy consumption. In contrast, RS232, designed for long distances and transmitting up to 11,520 Bytes/s, is unsuitable for the proposed testbed. UDP, while faster, suffers from data loss and depends on network quality, making it unreliable. TCP, despite its high data security, introduces latency due to handshaking, making it non-deterministic for real-time simulation. Both UDP and TCP add complexity in programming for low latency and efficient data management, requiring extensive network management and significant memory buffers in MCUs. Additionally, the compatibility of development boards with TCP/IP Middleware for these protocols must be considered.  
I2C is recommended for data transmission in sensor emulation due to its computing efficiency and minimal hardware requirements compared to other communication protocols, which may require more hardware and computing processes. For example, the CAN communication protocol, with speeds between 100 Kbps and 1 Mbps, requires additional hardware such as CAN transceivers and controllers, increasing energy consumption and space requirements.  
The I2C communication protocol follows a structured approach: the simulation PC generates emulated data for the sensors (sun sensors SLCD-61N8 from Advanced Photonix, Tokyo, Japan, magnetometer MMC5603 NJ from Memsic Inc., Tianjin, China, and gyroscope L3 GD20 from STMicroelectronics, Geneve, Switzerland). Both the magnetometer MMC5603 NJ and gyroscope L3 GD20 have 16-bit resolution per axis (48 bits per measurement). Magnetometer and gyroscope measurements along the x, y, and z axes are multiplexed to two bytes each, resulting in a total of six bytes per measurement. Conversely, sun sensors SLCD-61N8 provide single measurements transformed into two bytes each. The total bytes transmitted are 12 bytes, combining data from the six sun sensors, magnetometer, and gyroscope. I2C is configured in interruption mode with a 400 kHz fast mode using a pull-up configuration with 4.3 K\(\Omega\) resistors. This configuration mitigates jitter by closely aligning with the expected data and reception timings, ensuring reliable communication over extended periods, as illustrated in Figure 8.