Survival Sensor Box: Taking on the PSOC™ Edge AI Boss Battle

Introduction

Welcome to the PSOC™ Edge AI Boss Battle!

Together with Hackster.io, we created PSOC™ Edge City, a cyberpunk-inspired learning experience designed to introduce developers to the possibilities of Edge AI with Infineon technology. Throughout the challenge, participants explored learning modules, completed quizzes, got familiar with the PSOC™ Edge platform and eventually made their way to the final destination: the AI Arena.

And every AI Arena needs a Boss.👾

For the final Boss Battle, participants are challenged to create their own futuristic AI project using the PSOC™ Edge AI Kit and DEEPCRAFT™ Studio and see if they can outwit, outsmart and outplay the Infineon team.

But we couldn’t challenge the community without building something ourselves.

So we created the Survival Sensor Box.🤖

Our idea was simple: how much awareness can we get from a single PSOC™ Edge AI Kit?

Using the onboard sensors, the Survival Sensor Box can react to its direction, motion and vibration, environmental conditions, and nearby wireless activity.

Instead of treating each sensor as an individual demo, we wanted them to work together. By combining the information available from the board with Edge AI and sensor fusion, the device can build a more complete picture of what is happening around it.

We then turned the development kit into something that looked like it belonged in PSOC Edge City. A custom 3D-printed cyberpunk enclosure transforms the board into a portable Survival Sensor Box, while integrated LEDs provide immediate visual feedback for its different sensing functions.

The result is our Infineon Survival Sensor Box— a demonstration of what can be achieved using the hardware already packed into the PSOC™ Edge AI Kit.

And now it becomes the Boss.

Hardware

The Hardware was all 3D designed and 3D printed and the parts are found below.

On Bambu studio we added the writing and Infineon logo:

Heat Inserts

Button

Adding a drop of strong glue to add the button then on top of the button.

Schematics

The schematics are quite easy, all you need is the leds, the button and the battery!

For the LEDs we chose the 5V programable LEDs (WS2812B).

Software

This section explains the software side of the project. The code turns the sensor board into a compact measuring device with four modes:

1. Wi-Fi Presence: Lists nearby networks once, then watches the configured network and shows its RSSI strength on LEDs 7-9

2. Environment: Evaluates temperature, humidity, air pressure, and gravity/acceleration plausibility on LEDs 4-6.

3.Motion: Uses acceleration and gyroscope measurements to show stability on LEDs 1-3.4. Siren Detection: Uses acceleration and gyroscope measurements to show stability on LEDs 1-3.

Inside Wi-Fi Presence, holding the button for 1.5 seconds starts Wi-Fi direction finding. The device measures the selected access point at 90°, 0°, and 90, estimates its strongest direction, and guides the user while they turn. A short press otherwise advances to the next main mode.The same physical button has two roles. During the four-second boot window, pressing it starts the application. The application starts in Wi-Fi direction mode. It then cycles through Wi-Fi strength, environment, motion, and back to Wi-Fi direction. A short press advances from Wi-Fi strength, environment, or motion to the next mode. In direction mode, a long press ends the direction display and changes to the next mode; pressing it while the device is being guided to a measurement angle cancels that turn.Program Flowdiagram

Safe Startup

There is a four-second startup window after power-on. `device_main` is only imported if the button is pressed during that time. Otherwise, the MicroPython REPL remains accessible. The reason for that is, that if you want to make changes it is easier. You don't have to open the case and press the RESET and USER Button..

while time.ticks_diff(time.ticks_ms(), started) < 4000:
    if button.value() == 0:
    import device_main
    break

Sensor InitializationAt startup, `main()` configures the pins, I2C bus, and watchdog. All sensors share I2C bus 0:

i2c = machine.I2C(
    0,
    scl=machine.Pin("P8_0"),
    sda=machine.Pin("P8_1"),
    freq=400000,
)

The program then checks that the SHT40 (`0x44`) and DPS368 (`0x77`) respond. They can be used after a simple I2C presence check. The BMI270 is initialized separately because it first requires a reset and an internal feature configuration before its acceleration and gyroscope readings are valid. Its 8 KB configuration blob is sent to the sensor register in 16-byte chunks, which keeps the memory use small and matches the sensor's configuration interface. The program waits for the BMI270 to confirm that initialization is complete before enabling measurements.

The SHT40 read routine also verifies both CRC bytes. Invalid I2C readings are therefore not treated as valid temperature or humidity data.Consistent NeoPixel OutputThe physical LED chain contains 13 NeoPixels (WS2812B) although the application needs only twelve functional LEDs. We added a LED before, because the first LED was sometimes green in the beginning (So if you also have a similar issue, you can solve it that way :) ).The 13 NeoPixels are controlled without an additional library. The `_Pixels` class manages a 39-byte buffer and transmits it using `machine.bitstream()`. This saves memory and provides one central brightness limit:

LED_BRIGHTNESS = 0.2

We set the LED brightness to 20%. The reason for that is, that the LED were just to bright. :)The relevant output code is included directly in "device_main.py":

class _Pixels:
    def __init__(self, pin):
        self.pin = pin
        self.pixels = self
        self.buffer = bytearray(39)
        self.pin.init(machine.Pin.OUT)
        self.off()
    def __setitem__(self, index, color):
        offset = index * 3
        self.buffer[offset] = int(color[1] * LED_BRIGHTNESS)
        self.buffer[offset + 1] = int(color[0] * LED_BRIGHTNESS)
        self.buffer[offset + 2] = int(color[2] * LED_BRIGHTNESS)
    def write(self):
        machine.bitstream(self.pin, 0, (400, 850, 800, 450), self.buffer)

__setitem__() applies the brightness limit and stores each color in the GRB order required by the LEDs. `write()` then sends the complete buffer directly to the chain.

Every RGB value is scaled by this factor before it is written. The LEDs remain clearly visible without being distracting or using unnecessary power.

Deliberately Limited Wi-Fi ScanningEntering Wi-Fi Presence makes one full scan and prints all visible access points. This makes it easy to confirm the available networks over the serial console. After that first scan, the mode only scans for the configured SSID.

WIFI_TARGET_SSID = "survivor"
networks = wlan.scan(ssid=WIFI_TARGET_SSID)

Filtering by SSID lets every Survival Sensor Box in a team look for the same configured signal, such as a shared safe point or communication relay. If several access points use that name, the normal presence display selects the strongest one. For a direction measurement, _target_network() stores that access point's BSSID. The next two measurements accept only the same BSSID, so all three RSSI values describe one consistent signal source.

A 12-second watchdog is fed before and after each scan. It cannot interrupt a blocked driver call, but it ensures that the board restarts afterward. The safe boot launcher then keeps the board accessible.

In our setup, placing a sheet of aluminum foil on the outside of one side of the enclosure made the RSSI difference between orientations more noticeable. This can give the Wi-Fi receiver a more directional response and can make the direction estimate easier to distinguish. The effect depends on the antenna position and the surrounding room, so it should be tested with repeated measurements before it becomes a permanent part of a build. Keep conductive material away from the board and its antenna to avoid detuning or blocking the signal completely.Wi-Fi Signal Strength

In signal-strength mode, RSSI is read every five seconds. RSSI is a negative dBm value: a value closer to 0 indicates a stronger signal. The code maps the practical range from about -90 dBm to -40 dBm onto the LED bar:

_meter(pixels, WIFI_LEDS, (network[3] + 90) / 50)

_meter() creates the LED bar graph. A value from 0 to 1 controls both the number of active LEDs and their color transition from red through yellow to green.

Wi-Fi Direction from Three MeasurementsHold the button for 1.5 seconds while Wi-Fi Presence is active to start this measurement. It is intentionally part of the same mode rather than a separate menu item.The direction finder combines Wi-Fi measurements and the gyroscope. The sequence is deliberately simple and easy to follow:

1. Hold the device still so the gyroscope can be calibrated.

2. Take an RSSI measurement at 0°.

3. The LEDs guide the user to turn left to 90° for the second measurement.

4. Guide the device back to the center.

5. The LEDs guide the user to turn right to 90° for the third measurement.

Before turning, the code calculates a zero offset from 120 gyroscope samples. The measurement is rejected if its spread is too high. This prevents movement during calibration from being stored as the sensor offset.

The turn angle is produced by time integration of the offset-corrected angular velocity:

Long delays, such as a Wi-Fi scan, are excluded from the integration. Otherwise, one gyroscope reading could be integrated over several seconds and create a rotation that never happened.

The three RSSI values are fitted to a parabola and the maximum value is calculated.

The estimate is accepted only when the parabola opens downward and its peak lies between the outer measurements. If the three values do not form a useful peak, the code safely falls back to the angle with the strongest measured RSSI value.

For easier debugging, the serial output lists the measured angles and RSSI values, followed by the calculated target angle:RSSI measurements: -90 degrees: -56 dBm, 0 degrees: -41 dBm, 90 degrees: -43 dBm
CALCULATED ANGLE: 37.0 degrees | Best value: -41 dBmThe three direction LEDs then show the deviation from the target: red means turn left, green means the target is reached, and blue means turn right.

Siren Direction with Edge AIThe currently deployed emergency-siren direction detector samples the two onboard digital PDM microphones as a stereo input at 16 kHz and 16-bit PCM. The generated Deepcraft model has ten outputs: eight 45° arrival sectors plus Noise and unlabeled. The CM55/U55 audio pipeline is initialized when the application starts and continuously produces the latest classification; Siren Direction mode maps that result to the LEDs. CM55 sends the strongest label index and confidence to the MicroPython application on CM33 using IPC.

The selected LED alternates blue and red every 250 ms, inspired by emergency warning lights. Its brightness is proportional to the model confidence. Three LEDs provide a concise left/center/right cue; the serial console retains the exact ten-class result, including the front/back and diagonal label.For another identical KIT_PSE84_AI, the complete deployment consists of three parts: the CM55 Deepcraft image, the CM33 MicroPython firmware with PDM clock preparation, and the MicroPython application files. `deploy_walkie_talkie.py` automates this order and verifies each firmware image through OpenOCD.

The included CM55 image is ready to use with the trained siren-direction model. Users who want to adapt the project can also create and train their own audio model with DEEPCRAFT™ Studio. To run a custom model on the board, export it into a CM55 firmware image that matches the PDM audio format and the CM33 IPC interface, then flash that CM55 image together with the rest of the package. When the model uses different output labels, update the LED mapping in device_main.py to match.The demo GIF below shows the siren-direction detection in action. A siren sound is played from behind the fire-truck image, and the board detects its direction and provides visual feedback.

Environment and Motion ModesThe environment mode combines temperature, humidity, and acceleration magnitude into a score from 0 to 100 percent. Air pressure is displayed as an additional reading but is not part of this score:

Because the SHT40 is mounted close to the board, the measured temperature is calibrated with TEMPERATURE_OFFSET_C. This value depends on the hardware and enclosure and can be adjusted for another build.

Motion ModeIn motion mode, the code calculates a stability score from the acceleration magnitude and the highest gyroscope speed. A stationary device near 1g gets a high score, while strong turns or vibration reduce the number of illuminated LEDs:

Installing on Another Board

For another identical KIT_PSE84_AI, use the self-contained Survival_Sensor_Box_Flash_Package included with this project. It contains the trained Deepcraft model in the tested CM55 image, the matching CM33 MicroPython firmware with PDM clock preparation, the MicroPython application, and the required OpenOCD tooling.

The package includes precompiled application bytecode and transfers its files as small Base64 chunks over the MicroPython Raw REPL. As a result, DEEPCRAFT™ Studio, mpy-cross, and a separately built proj_cm55.hex are not required on the deployment computer.

Python, pyserial, mpy-cross, KitProg3, and the included OpenOCD package are required on the deployment computer:

cd .\Survival_Sensor_Box_Flash_Package
py -m pip install -r requirements.txt

Use the trained Deepcraft model for this project, packaged in the matching `proj_cm55.hex` CM55 image, then deploy the complete stack to a compatible board as follows:

1. Connect the board to the computer with USB.

2. Close any serial monitor that is using the board's COM port.

3. Run the deployment script with the correct COM port and CM55 image path:

python .\deploy_walkie_talkie.py --port COM68

4. Restart the board and press the button during the four-second startup window to launch the application.Replace COM68 with the board's KitProg3 USB-UART port. The script erases, overwrites, and verifies the CM55 and CM33 firmware image sectors, then verifies the size of each uploaded application file. If the CM33 reset assigns the KitProg3 USB-UART a different COM number, the script follows the same board by its USB serial number.

python .\flash_walkie_talkie.py --port COM68

The flasher verifies the transferred size after every file and flash it on your PSOC™ Edge AI board.

The GitHub flash package includes an editable app/survival_config.py file. Change its values before an application-only update; do not edit the precompiled app/device_main.mpy file:

WIFI_TARGET_SSID = "survivor"
TEMPERATURE_OFFSET_C = -13.5
LED_BRIGHTNESS = 0.2
TARGET_WINDOW = 4

To use a different Wi-Fi network, change only WIFI_TARGET_SSID. It must exactly match the network name. The first direction measurement selects the strongest access point with that name and stores its BSSID. The following two measurements use the same BSSID, so all three RSSI values belong to one consistent signal source.

LED_BRIGHTNESS accepts values from 0.0 (off) to 1.0 (full brightness); 0.2 is the current default. The temperature correction and accepted target deviation can also be adapted to the specific build and use case. Save the file, close any serial monitor, and upload the settings with:

Farewell

The Infineon Team's Survival Sensor Box combines Wi-Fi presence and direction finding, environmental sensing, motion feedback, and an edge-AI emergency-siren direction detector in one portable build. The Cortex-M33 keeps the interface responsive in MicroPython while the Cortex-M55 and U55 NPU process the current PDM-only stereo audio path with the Deepcraft model. Clear LED feedback turns that data into an immediate cue: nearby network strength, device state, or the horizontal direction of an approaching emergency vehicle.

The project demonstrates how the PSOC™ Edge AI Kit can move beyond isolated sensor demos into a compact, interactive awareness device. The enclosure, source code, firmware deployment script, and technical diagrams are included with the project files.