Solutions / Connected-device testing
Test the firmware between your devices.
Each controller can work on its own and still fail as part of the product. Sim86 runs supported controllers together, with their firmware and connections, so you can inspect the interactions before deploying to more devices.
Inspect the public project, then sign in and fork it to make changes.
Start with a working circuit
An ESP32-C3 and RP2040, in the same project.
The example brings two different controller architectures together with sensors, a display, and a serial connection. Inspect the wiring and firmware, then use it as a starting point for embedded integration testing.
Follow the connection from the code on one controller to the behavior on the other. Change one firmware build at a time and compare the outputs you care about.
Read the example and firmware-format guide ↗A practical first integration test
- Open the example and inspect both controller builds and their connections.
- Run it and record the expected serial or display behavior.
- Change one input or connection in your fork.
- Check the response on both devices, then turn the expectation into an assertion.
This is a connected-device example, not a fleet-scale or OTA benchmark. Assess your own topology, protocol support, and capacity with us.
Test the connections your product depends on.
Wired interactions
Connect supported controllers and peripherals over modeled buses and signals. Use the firmware’s output, serial logs, and signal traces to check whether a change in one part affects another.
Inspect the connected circuit ↗Wireless IoT testing
Supported radios can share an RF Environment. Explore modeled signal loss, noise, and overlapping transmissions, then inspect frame outcomes and firmware behavior.
The RF model operates on frames and reception conditions. It does not calculate modulation waveforms or replace antenna measurements.
Understand the RF model ↗Define the behavior you need before a rollout.
For OTA update testing, start with your update protocol, firmware versions, and recovery requirements. Identify which devices must communicate and what should happen if communication fails.
Bring that scenario to us to assess the required models and controls. A working two-controller example is a starting point; it does not establish support for every update stack or fleet size.
Discuss your rollout scenario ↗Keep a test the team can repeat.
Record each firmware build, the circuit, configuration, seed, and controlled inputs. Keep logs or traces with the result. Live Internet services can change independently of your simulation.
For pytest automation, use the CLI through our closed-access program. Use the SDK when building a web dashboard or integration.
Match the models to your system.
We run simulation models on GPU- and FPGA-accelerated hardware and compare behavior using our physical hardware farms. Check the timing and peripheral behavior relevant to your own firmware before moving tests off the bench.
The web catalog covers dashboard models; additional models are available to partners. We add controllers on demand, free of charge for users who ship us a development board. Ask about your controller or component.
