Documentation

Osprio Hardware

Osprio hardware exists because OSDP work is not just a matter of connecting two wires to a generic adapter. The Osprio family is built for capture, emulation, provisioning, and field workflows where timing, device behaviour, and operational feedback matter.

Why Osprio hardware exists ​

A generic USB to RS-485 converter is not enough for the workflows Osprio is designed to support. A converter can expose a serial line, but OSDP is a real-time protocol and the workflows around it need a purpose-built device.

Protocol and signal handling ​

A converter hands the host raw bytes and leaves everything else to software. Osprio takes on the parts a generic adapter cannot:

  • OSDP framing, timers, and bus arbitration live in a dedicated layer instead of being mixed into host application code, so each layer keeps a single responsibility
  • inter-character gaps and bus turnaround windows measured in microseconds are met by a dedicated controller, rather than left to host USB scheduling and operating-system jitter
  • the start of a packet is detected in hardware, so capture and emulation stay accurate even at high baud rates and on a busy bus instead of leaving the host to guess where frames begin
  • the host receives decoded, validated events rather than a stream of raw serial bytes, freeing its CPU for workflow logic instead of parsing and checksum work
  • behaviour is identical across Windows, macOS, and Linux — and on phones or tablets that could never drive RS-485 timing themselves — with no per-host driver quirks or USB-latency differences to chase
  • a purpose-built RS-485 interface, with correct biasing, termination, fail-safe behaviour, and ESD protection, keeps the bus reliable and protects the host from electrical faults a bare adapter leaves exposed

Workflow and product ​

Beyond the wire, Osprio hardware is a complete tool rather than a bare transport link:

  • passive capture that can observe the bus without behaving like a normal endpoint
  • active emulation and provisioning workflows that need purpose-built device behaviour
  • user-facing status and workflow control rather than a bare transport link
  • managed update, diagnostics, and workflow integration with the wider Osprio software surface

In short, a converter can expose a serial line. It does not become a capture device, emulator, field tool, or provisioning device by itself.

Hardware family ​

The Osprio family currently separates into three: two bench and field instruments, and one deployed peripheral device.

Osprio Pro ​

Osprio Pro is the field-oriented platform.

It is intended for:

  • provisioners
  • technicians carrying the device on site
  • users who need an onboard interface and battery-backed operation
  • jobs that benefit from wireless workflows and removable storage

Osprio Pro is the richer, more self-contained hardware option. Its capture, emulator, and provisioner surfaces run from a single unified firmware, switched on-device without reflashing.

Osprio Mini ​

Osprio Mini is the compact lab-oriented platform.

It is intended for:

  • developers
  • test engineers
  • protocol debugging and validation work
  • host-driven capture, emulation, or provisioning from a desk or bench setup

Osprio Mini is the simpler, more focused hardware option for development, testing, and debugging. It runs one firmware app — Capture, Emulator, or Provisioner — at a time, switched with the App Switcher.

Osprio IO ​

Osprio IO is the deployed platform, and the one member of the family that is not a test instrument.

It is an OSDP peripheral device: opto-isolated voltage inputs and relay outputs — four of each on IO4, eight on IO8 — driven by whatever access control unit owns the bus. It is intended for:

  • installers bringing door, gate, and auxiliary circuits onto an existing OSDP bus
  • integrators who need contacts and switched loads without a second controller or a new cable run
  • systems where the I/O must be visible on the bus rather than behind a vendor-specific side channel

Where Pro and Mini are brought to a bus and taken away again, Osprio IO joins one as a node and stays. It is commissioned from a configuration page it serves over its own WiFi access point, and then behaves like any other PD on the segment.

Connection model ​

The hardware family supports different connection styles depending on the device and the user.

Bus connection ​

Every member of the family attaches directly to the target bus — Pro and Mini to capture, emulate, or provision on it, and Osprio IO to live on it as a peripheral device.

USB ​

USB is important across the family:

  • Osprio Mini is primarily a host-connected USB device
  • Osprio Pro also uses USB for wired workflows, maintenance, and update-related tasks
  • Osprio IO uses USB-C for bench power and a first flash, but runs from the panel supply once installed — and takes firmware updates over its own WiFi or as an OSDP file transfer from the ACU

Wireless ​

Wireless connectivity is part of the Osprio Pro story, not the Osprio Mini story. That makes Osprio Pro better suited to mobile and field-oriented work, while Osprio Mini stays focused on bench and lab use.

Osprio IO uses wireless for a different purpose entirely: it raises its own WiFi access point to serve its configuration page and to take firmware updates, and does no wireless work on the bus itself.

Choosing the right device ​

Choose Osprio Pro when you need ​

  • field-carry hardware
  • provisioning-oriented work
  • onboard UI and direct user feedback
  • battery-backed operation
  • wireless workflows

Choose Osprio Mini when you need ​

  • compact bench hardware
  • development and debugging workflows
  • repeatable lab testing
  • a simpler host-driven capture, emulator, or provisioner path

Choose Osprio IO when you need ​

  • I/O points on the bus rather than an instrument on your bench
  • door strike, maglock, gate, or auxiliary relay control from the ACU
  • contact inputs reported to the ACU as part of the OSDP segment
  • hardware that is installed once and left in place

Next pages ​