# Device communication protocols Simhub can communicate in various ways to your devices, some protocols are pre implemented,\ No matter the protocol they all need you to be able to assign to your MCU a proper **PID/VID you own**. ## SimHub Standard Serial protocol The most universal protocol, it can be implemented on any device with just a CDC either by using the [standard-serial-firmware-builder](https://manual.simhubdash.com/standard-serial-firmware-builder "mention") (for atmega32u4) or copying the existing protocol ## Screen pass-through Both USBD480NX and Vocore offer to drive leds through the screen. In such case you can use this protocol to instruct simhub to use the screen for the LEDs control. ## SimHub Standard HID protocol When things will get more serious you might want to switch a proper HID implementation, Simhub can identify the HID interface based on the HID Usage and usage page. The report ID and report length can be specified. Make sure to properly include the report in your device HID descriptor, descriptors not specifying the report id won't work. To be able to support multiple device instance, make sure your device exposes an unique HID serial number. #### HID Report Format This example shows a **64-byte HID report** used to update RGB LEDs efficiently.\ Shorter or longer reports (e.g. 32 or 128 bytes) can be used depending on the microcontroller capabilities, just adapt the maximum number of LEDs per packet. ### Report Layout | Byte | Description | Example Value | | ----- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------- | | 1 | **Report ID** | `0x68` | | 2 | **Start LED index** | `0x00` | | 3 | **Affected LED count** | `0x14` (20) | | 4 |

Draw flag

| `0x00` | | 5–7 | **LED #1** → R, G, B | `0xFF 0xFF 0xFF` | | 8–10 | **LED #2** → R, G, B | `0xFF 0xFF 0xFF` | | … | **Next LEDs...** | `…` | | 62–64 | **Last LED** → R, G, B | `0xFF 0xFF 0xFF` | ### Notes * This example assumes **64-byte reports**, but it works with any size depending on the HID endpoint. * The **“Draw” byte** (Byte 4) indicates when the update is complete : this allows physical LEDs (e.g. WS2812B) to be refreshed only once per full frame. * The **Report ID** is an example; typically, the report is part of a **vendor-specific HID interface**. * The optional `on connect` report and `on disconnect` report\* will send a report using 2 or 3 " as a draw flag all other data (RGB, start led, affected led count ...) will be set to zero. {% hint style="info" %} Warning the `on disconnect` report can't be guaranteed in case of process being killed or usb issue causing a disconnect for instance. Simhub sends a keep alive "draw" every 5 seconds even if nothing has changed. Using an internal firmware timeout of 6s would be relevant in cases of automations to be triggered after a software disconnect. {% endhint %} ### Examples Example 1 — Updating 2 LEDs *Update the first 2 LEDs (LED #0 → #1):* ``` 0x68 0x00 0x02 0x01 FF FF FF FF FF FF 00 00 00 ... 00 ``` Example 2 — Updating 22 LEDs (split across packets) *Update the first 20 LEDs (LED #0 → #19):* ``` 0x68 0x00 0x14 0x00 FF FF FF FF FF FF ... FF FF FF ``` *Update the last 2 LEDs (LED #20 → #21):* ``` 0x68 0x14 0x02 0x01 FF FF FF FF FF FF 00 00 00 ... ``` Example 3 — Updating 42 LEDs (split across packets) *Update the first 20 LEDs (LED #0 → #19):* ``` 0x68 0x00 0x14 0x00 FF FF FF FF FF FF ... FF FF FF ``` *Update the next 20 LEDs (LED #20 → #39):* ``` 0x68 0x14 0x14 0x00 FF FF FF FF FF FF ... FF FF FF ``` *Update the last 2 LEDs (LED #40 → #41):* ``` 0x68 0x40 0x02 0x01 FF FF FF FF FF FF 00 00 00 ... ``` Example 3 — Optional on connect report *Sends a draw byte set to 2 on connection.* ``` 0x68 0x00 0x00 0x02 00 00 00 00 00 00 ... 00 00 00 ``` Example 4 — Optional on disconnect report *Sends a draw byte set to 3 before disconnecting.* ``` 0x68 0x00 0x00 0x03 00 00 00 00 00 00 ... 00 00 00 ```