Osprio Mini

Osprio Mini is the compact Osprio hardware platform for host-connected OSDP work. It runs one firmware personality at a time and is designed for three primary jobs: passive capture, active emulation, and PD provisioning.

It is the hardware tier aimed at lab users, developers, and engineers doing development, testing, and debugging from a host-connected setup.

Platform overview ​

Hardware overview ​

Osprio Mini is the smaller, more focused member of the Osprio hardware family. In practical use it provides:

• host-connected control for desktop-oriented workflows
• direct OSDP bus attachment
• a shared update path across all three firmware personalities
• status LEDs used for mode, activity, and fault signaling

In normal use, the hardware stays the same while the active behavior changes depending on the firmware personality loaded onto the device.

Runtime model ​

Three-app model ​

Osprio Mini currently has three user-facing firmware apps:

• Capture: for passive capture and live bus inspection
• Emulator: for active device simulation and test-oriented workflows
• Provisioner: for commissioning PDs over USB-C — setting address and baud and writing the SCBK in install mode

Only one of these apps is active at a time. Moving between capture, emulation, and provisioning is not a mode toggle inside one runtime. It is an app change on the device.

Shared behavior ​

From a user perspective, all three firmware personalities share a few common traits:

• they are managed from the same hardware platform
• they share the same general update path
• they expose device status through the same physical indicators
• they are intended to work with the same higher-level Osprio software ecosystem

What changes is the job the device is performing on the bus.

LEDs and status behavior ​

Osprio Mini has three status LEDs — green, yellow, and red. The same three LEDs mean different things depending on which of the two top-level modes the device is in: running one of the firmware personalities, or sitting in the bootloader during a firmware update.

At a glance:

• green — the app is actively doing its job
• yellow — standby/idle, or brief flashes of bus activity
• red — a fault: short blinks for transient events, solid for a held error

Application mode

While a personality is running, the LEDs use these states:

The three personalities share this behavior but differ in what "running" means and which extra signals they use:

• Capture — green breathing while it is capturing OSDP traffic, yellow breathing when capture is stopped. Bus and USB faults show as red blinks.
• Emulator — green breathing while it is emulating one or more peripherals, with brief yellow flashes as it handles OSDP commands and events. A latched error condition holds the red LED solid until the fault clears.
• Provisioner — stays in yellow breathing standby, because it runs install steps on demand rather than holding a continuous running state. A failing step surfaces as red blinks (NACK, drop, or USB error). Identify works the same as the other personalities.

Bootloader and update mode

When the device is in the bootloader — during a USB firmware update, when the recovery strap is held at power-on, or when no valid application is present — it shows a signature the personalities never use:

Solid red and green together is unique to the bootloader, so it is an unambiguous "this unit is in update or recovery mode" signal. While blocks are being written, red stays solid and green and yellow alternate to show progress. When the update finishes, the device resets and returns to the application LED behavior above.

Bootloader and update path ​

All apps share the same update path. From a product perspective, that means Capture, Emulator, and Provisioner are not separate hardware products. They are separate firmware personalities on the same board.

User-facing roles ​

Hardware role on the bus ​

The active firmware personality changes how the device behaves on the bus:

• Capture uses a listen-only path for passive capture
• Emulator actively participates in test and simulation workflows
• Provisioner actively drives install-mode commissioning — COMSET and secure-channel keying — as a CP on the bus

That separation is important when planning test setups. The same hardware connector serves every job, but not with the same runtime behavior.

Capture app ​

Use the Capture personality when you need passive observation of live traffic.

It is best suited for:

• capture and inspection of bus activity
• debugging or support sessions where you do not want the device to participate on the line
• generating evidence for later review in host software

Emulator app ​

Use the Emulator personality when you need the device to behave like part of the system under test.

It is best suited for:

• CP or PD style simulation
• repeatable lab and integration testing
• profile-driven validation workflows
• active participation on the bus rather than passive observation

Provisioner app ​

Use the Provisioner personality when you need to commission OSDP PDs over USB-C.

It is best suited for:

• setting a PD's address and baud rate
• writing the SCBK in install mode
• benched or staged commissioning before a unit is deployed

Best fit ​

Choose Osprio Mini when the job is primarily host-driven and you want compact hardware dedicated to one active role at a time.

It is especially well suited to:

• development benches
• protocol and integration testing
• debugging sessions
• repeatable lab workflows where a full field device would be unnecessary