OsmocomBB

h1. Minimalistic L1CTL interface

{{>toc}}

This is the description of the minimal interface between L1 and higher layers.

Please see 'include/l1ctl_proto.h' for more details.

h2. Implementation over RS232

When we transport the messages of this interface over RS232, we have to consider:

* multiplexing of L1A<->L23 messages with console/debug messages

* bandwidth management

h3. Multiplexing with console messages

Instead of a protocol with a fixed header (including length of payload), we chose a minimalistic subset of HDLC.  This has the advantage that it provides multiplexing between up to 255 different channels, and it is auto-synchronizing, i.e. when data is lost, the next frame start will still be recognized by the other side.

The minimal subset of HLDC consists of UI frames only, with no CRC.

h3. Bandwidth management

The UART in the Calypso DBB can only run up to 115200bps with standards-compliant baud rates. Higher baud rates are possible (up to 812500bps), but only as non-standard rates. While there are serial chips like FTDI's chip that can support this, regular serial ports and popular PL2303 based cables don't support it. The CP210X based adapters need some additional configuration, see [[HardwareCP210xTutorial]].

Therefore, we have to assume that the RS232 link runs at 115200bps:

* 115200bps means roughly 11,520 characters per second

* at a TDMA frame interval of 4.615ms, this means 53 characters per TDMA frame

* however, since four TDMA frames are merged into one L1 payload, we have about 212

   bytes of RS232 bandwidth for each L1 payload that we receive (260 bits == 32.5 bytes)

This means that regular L1A operation on a single dedicated timeslot is very well possible even with lots of overhead for protocol layers, anciliary data as well as a bit of debug output. But it also means that we can not print much debug info from L1 during every TDMA IRQ.

Also, actual L1A messaging should have a higher priority than serial console messages. It would be great to have a strict priority between those two in the serial driver layer of the phone software.