[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [HLL] Frames again...

Status: RO
Content-Length: 1221
Lines: 29

Hi Volker,

Looks like you're into it!

> So it mainly interprets the 4 mode-bits and splits frames accordingly.
> Our frames might be structures as described in the "quick and dirty"
> proposal earlier. Fields should be in this sequence:
> *   4 Bits coding operation-mode "mode-bits"
> * 260 Bits coding used as "G-channel" (13000 Baud @ 20mSec/Frame)
> *   8 Bits coding used as "X-channel" (  400 Baud @ 20mSec/Frame)
> This makes up a minimum frame of 34 bytes.
> If frames are longer, any extra bytes belong to the "X-channel".

Disclaimer: I am no protocol designer. But...

Doesn't doing it this way mean that we can't switch to a slower codec?  (I'd
love to have a mode that does (shitty) voice over 9600). More generally
said: should the speed of the GSM codec be hardcoded in the lowest layers of
the protocol? On the other hand 260 bits payload per 24 bytes seems
acceptable, although it would be nasty if other GSM rates produced different

For reference: can anyone post the standard speeds at which the GSM codec
works and the frame size for each speed? A URL to a more detailed
description of the GSM codec would be perfect for our new website to be...