This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Vadim Yanitskiy axilirator at gmail.comDear all, I just wrote a simple test to ensure, that the new library performs valid transcoding. I used a DCCH "LAPDM U, func=UI" frame for simplicity, and good news is that test passed. See attachment for details. In the test I wrote the best signal quality is assumed. So, ubit 0 is sbit -127 and ubit 1 is 127. But there is no such things as miracles, and on practice error correction takes place. So, we need to make sure, that correction works. I am going to write tests and I have some questions: 1) How can I know the maximum count of bits can be corrected for a specific channel type? 2) In case of: gsm0503_*_decode(... int *n_errors, int *n_bits_total); What do the two last params mean? 3) Can anyone provide me some samples for GPRS and EDGE? It will take some time to set up PDCH support in my test network. Thanks in advance! With best regards, Vadim Yanitskiy. 2016-09-26 11:05 GMT+07:00 Harald Welte <laforge at gnumonks.org>: > Hi Vadim, > > sorry for the late foll-wup. > > On Mon, Sep 12, 2016 at 10:56:11PM +0600, Vadim Yanitskiy wrote: > > > I think there's one option that I would prefer: Having a new library > > > > Ok, one may be a separate library in separate repo, or may be included > > into libosmocore as a sub-library, if re-licensing would be successful. > > Let's go this way. > > As re-licensing is approved by all authors meahwile, a sub-library > inside libosmocore.git seems the solution. > > > > like libosmogsmphy (or libosmogsm-phy or libosmogsm_phy?) which > contains > > > the gsm0503 code and has dependencies to libosmocore and libosmocodec. > > > > IMHO, 'phy' may sound a little bit confusing. I would prefer something > > like 'libosmo-coding' or 'libosmocoding', without 'gsm' prefix, because > > there are GPRS and EDGE too. > > I wanted the 'gsm' to indicate 2G. Most people speak of "GSM" when they > actually mean GSM+GPRS+EGPRS, i.e. second-generation technologies. > > > Also, this may be a potential place for other transcoding things, > > unrelated to GSM at all. We are talking about channel coging, right? > > :) > > I would assume most projects would be interested in the coding of one > specific technology, and not all of them at the same time. Yes, there > might be exceptions as a multi-RAT signal analyzer, but that could then > very easily link several libraries. > > So my preference would be to have a '2g' specific library, and reflect > that in the name by using either '2g' or 'gsm' as part of the name. > > Regards, > Harald > -- > - Harald Welte <laforge at gnumonks.org> > http://laforge.gnumonks.org/ > ============================================================ > ================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. > A6) > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20160928/6755cbb2/attachment.htm> -------------- next part -------------- A non-text attachment was scrubbed... Name: coding.c Type: text/x-csrc Size: 1629 bytes Desc: not available URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20160928/6755cbb2/attachment.bin>