# A Low-Cost Remotely Configurable Electronic Trap for Insect Pest Dataset Generation
## 2 Materials and Methods
### Design and Architecture
#### 2.2.1 Embedded System Operation  
The trap is managed internally using a state machine developed in C++ under the ESP-DIF framework. Figure 6 shows the 6 internal states of the trap and their relationships. In the following paragraphs, a brief description of each state is included. * State: Connection. In this state, event handlers for the Wi-Fi driver are configured, and the connection with the remote service is initiated. This state persists until a connection is established, with controlled retry attempts to prevent lockups. * State: Configuration Waiting. After establishing the connection, the system transitions to this state. Here, a system cyclic task (Configuration Task) is launched, which periodically queries the current device configuration through a GET request to the API. * State: Camera Testing. This state corresponds to a remote reconfiguration regime. Upon entry, the Perception and Communication tasks are initiated, responsible for capturing images and sending them to the server via a POST request to the API. Given the configuration regime, this cycle accelerates, as does the Configuration task, to facilitate agile configuration changes. Images captured in this testing regime are not stored in the final image repository but in a specific temporary testing storage. * State: Monitoring. This state corresponds to the normal operation cycle of the trap. Upon initiation, the Perception and Communication tasks are launched with a standard working period, and the captured images are sent to the server for storage in the regular repository. * State: WebServer. In this state, the device initiates the WebServer Task, which implements an embedded web server. Upon access, it presents a user interface with full camera configuration accessibility, along with a real-time frame streaming feature that enables users to experiment with real-time configuration adjustments. This state is designed for deployment scenarios to expedite the initial device setup. * State: Idle. When device configuration determines it, it remains in a latent state with no image capture and transmission. In this state, the only active task is the Configuration task. In Figure 7, every state is described in detail. Colors of the boxes representing tasks have been assigned according to the color of the _States_ in Figure 6.  
The trap starts connecting to Wi-Fi, as described in \"State 0: Connection\". This task remains active checking the Wi-Fi connection is alive all the time. After that, the trap checks if there is a new configuration sent by the server in \"State 1: Waiting for configuration\". This state is alive checking periodically if there is a new configuration. Figure 6: Internal working states of the trap. If a new configuration has been assigned, it is applied in \"State 2: New configuration\". Depending on the configuration, up to 4 states may be started: \"State 3: Testing camera\", \"State 4: Monitoring\", \"State 5: WebServer\", and \"State 6: Idle\". The \"State 2: New configuration\" is in charge of selecting different states according to the configuration set by the server. Therefore, this state is probably the most complex. If there is a change in camera parameters without changing the working mode (either Monitoring or Testing), the Camera task is stopped, the new configuration parameters are applied, and the Camera task is started again. In case the period is set to 0 in the configuration, \"State 6: Idle\" is activated, in which tasks Camera and WebServer are stopped. If the new selected mode is either Monitoring or Testing, the WebServer task is stopped (in case it was active). The main differences between the Monitoring or the Testing modes are the URI parameter, which is set to a different destination, and the sending image period, which is faster in testing mode. In both cases, the Camera task is restarted applying the new set of parameters (including URI).