<div dir="ltr">Dear all,<br><br>I just wrote a simple test to ensure, that the new library<br>performs valid transcoding. I used a DCCH "LAPDM U, func=UI"<br>frame for simplicity, and good news is that test passed. See<br>attachment for details.<br><br>In the test I wrote the best signal quality is assumed. So,<br>ubit 0 is sbit -127 and ubit 1 is 127. But there is no such<br>things as miracles, and on practice error correction takes<br>place. So, we need to make sure, that correction works.<br><br>I am going to write tests and I have some questions:<br><br>1) How can I know the maximum count of bits can be corrected<br>   for a specific channel type?<br>2) In case of:<br>   gsm0503_*_decode(... int *n_errors, int *n_bits_total);<br>   What do the two last params mean?<br>3) Can anyone provide me some samples for GPRS and EDGE?<br>   It will take some time to set up PDCH support in my<br>   test network.<br><br>Thanks in advance!<br><br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>With best regards,<br></div><div>Vadim Yanitskiy.<br></div></div></div></div></div></div>
<br><div class="gmail_quote">2016-09-26 11:05 GMT+07:00 Harald Welte <span dir="ltr"><<a href="mailto:laforge@gnumonks.org" target="_blank">laforge@gnumonks.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Vadim,<br>
<br>
sorry for the late foll-wup.<br>
<span class=""><br>
On Mon, Sep 12, 2016 at 10:56:11PM +0600, Vadim Yanitskiy wrote:<br>
> > I think there's one option that I would prefer: Having a new library<br>
><br>
> Ok, one may be a separate library in separate repo, or may be included<br>
> into libosmocore as a sub-library, if re-licensing would be successful.<br>
> Let's go this way.<br>
<br>
</span>As re-licensing is approved by all authors meahwile, a sub-library<br>
inside libosmocore.git seems the solution.<br>
<span class=""><br>
> > like libosmogsmphy (or libosmogsm-phy or libosmogsm_phy?) which contains<br>
> > the gsm0503 code and has dependencies to libosmocore and libosmocodec.<br>
><br>
> IMHO, 'phy' may sound a little bit confusing. I would prefer something<br>
> like 'libosmo-coding' or 'libosmocoding', without 'gsm' prefix, because<br>
> there are GPRS and EDGE too.<br>
<br>
</span>I wanted the 'gsm' to indicate 2G.  Most people speak of "GSM" when they<br>
actually mean GSM+GPRS+EGPRS, i.e. second-generation technologies.<br>
<span class=""><br>
> Also, this may be a potential place for other transcoding things,<br>
> unrelated to GSM at all. We are talking about channel coging, right?<br>
> :)<br>
<br>
</span>I would assume most projects would be interested in the coding of one<br>
specific technology, and not all of them at the same time.  Yes, there<br>
might be exceptions as a multi-RAT signal analyzer, but that could then<br>
very easily link several libraries.<br>
<br>
So my preference would be to have a '2g' specific library, and reflect<br>
that in the name by using either '2g' or 'gsm' as part of the name.<br>
<div class="HOEnZb"><div class="h5"><br>
Regards,<br>
        Harald<br>
--<br>
- Harald Welte <<a href="mailto:laforge@gnumonks.org">laforge@gnumonks.org</a>>           <a href="http://laforge.gnumonks.org/" rel="noreferrer" target="_blank">http://laforge.gnumonks.org/</a><br>
==============================<wbr>==============================<wbr>================<br>
"Privacy in residential applications is a desirable marketing option."<br>
                                                  (ETSI EN 300 175-7 Ch. A6)<br>
</div></div></blockquote></div><br></div>