Hardware Projects » E1/T1 Hardware Interface (including icE1usb)

h1. USB Protocol

This page describes a proposed mapping of E1 payload to USB, which we want to implement in E1 adapters within the Osmocom project.

* vendor-specific USB device/interface

* isochronous IN and OUT endpoints

The general functional split between USB device is as follows:

# USB device

#* mandatory: bit/octet alignment of basic frames to octet boundaries

#* optional: bit-order reversal on per timeslot basis, on configuration from host

#* optional: CRC-4 verification on receive side (including reporting via "E" bits in TS0 towards remote end)

#* optional: CRC-4 generation on transmit side

# USB host

#* mandatory: CRC-4 multi-frame alignment of the basic frames received from USB Device

#* mandatory: bit-order reversal on per timeslot basis, on configuration from host

#* mandatory: CRC-4 verification on receive side (including reporting via "E" bits in TS0 towards remote end)

#* mandatory: CRC-4 generation on transmit side

Depending on the capabilities of the USB device, the host may then switch off some of the functionalities that the USB device can perform in order to reduce processing requirements on the host.

h2. URB format on ISO IN/OUT endpoints

* Mandatory part: N number of 32-byte octet-aligned E1 "basic frames"

** one byte per timeslot (0..31)

*** TS0 bit-order MSB first

*** TS1..31 bit-order MSB first (default), optionally LSB-first if requested by USB host

* Optional: Trailer of up to 31 bytes of "status" information

** details of this still TBD. Must be odd (< 32) bytes length to distinguish it from E1 basic frames in front

h2. Isochronous USB related notes

After a quick re-read of the relevant sections of the USB spec, we should probably configure our USB endpoints as follows:

* specify the Interval of the endpoints to 1ms (the lowest interval possible)

* set the maximum packet size to something of at least 256 (probably more)

** we expect eight 32 byte frames during 1000ms

** we want to have room fo the "trailer" explained above

** can the host miss to schedule a transfer in one frame? In that case we should be able to transmit twice the amount in the next frame?