Osprio Mini

Osprio Mini is the compact Osprio hardware platform for host-connected OSDP work. It runs one firmware app at a time and currently supports five jobs: passive capture, active emulation, PD provisioning, conformance testing, and raw USB-to-RS-485 bridging.

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 firmware apps
• status LEDs used for mode, activity, and fault signaling

In normal use, the hardware stays the same while the active behavior changes with the firmware app loaded onto the device.

Runtime model ​

Five-app model ​

Osprio Mini currently has five 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 on the RS-485 bus — setting address and baud and writing the SCBK in install mode
• Conformer: for driving structured OSDP conformance tests against a PD or ACU
• Bridge: for transparent USB-to-RS-485 access from Serial Monitor or compatible host software

Only one of these apps is active at a time. Moving between jobs is not a mode toggle inside one runtime. It is a firmware-app change on the device, performed from App Switcher in Osprio View.

Shared behavior ​

From a user perspective, all five firmware apps 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 LEDs mean different things depending on whether a firmware app is running or the device is in the bootloader during an 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 an app is running, the LEDs use these states:

The firmware apps 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 apps.
• Conformer — is active while it drives a conformance procedure and returns to standby between runs. Detailed test state and evidence remain in Osprio View.
• Bridge — is active while the host has attached the transparent bus bridge. RX/TX activity is shown in Serial Monitor; connection and transport faults use the shared error indications.

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 apps 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. Capture, Emulator, Provisioner, Conformer, and Bridge are not separate hardware products; they are switchable firmware apps on the same board.

User-facing roles ​

Hardware role on the bus ​

The active firmware app 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 an ACU on the bus
• Conformer drives and evaluates repeatable tests against a device under test
• Bridge exposes raw RS-485 traffic without imposing an OSDP workflow

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 app 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 app when you need the device to behave like part of the system under test.

It is best suited for:

• ACU 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 app when you need to commission OSDP PDs on the attached RS-485 bus while controlling Mini 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

Conformer app ​

Use the Conformer app when the Mini is the driving unit in an Osprio View conformance bench. A second Mini running Capture independently records the bus evidence.

It is best suited for:

• PD and ACU conformance runs
• repeatable automated and operator-assisted tests
• results tied to independently captured bus traffic

Bridge app ​

Use the Bridge app when you need transparent byte-level access to the RS-485 connection instead of an OSDP-specific workflow.

It is best suited for:

• Serial Monitor in Osprio View
• raw ASCII or hexadecimal transmit and receive
• existing host tools that work with a USB serial adapter

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