Hi.
There seems to be a disagreement between Osmocom libraries as to which
is the length of AMR SID RTP payload. According to libosmocodec it's 7
bytes (see amr_len_by_ft in gsm690.c), according to libosmo-netif it's 6
bytes (see amr_ft_to_bytes in amr.c). However, than I look at 3GPP TS
26.101 Table 6 it seems like it should be 8 bytes.
Reading http://www.rfc-base.org/txt/rfc-4867.txt did not shed a light
except that it can't be lower than 5 bytes.
Please help me out - what's the right number of bytes?
--
Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
Previously I wrote about the "Broken Pipe" error sporadically causing our
gerrit tests to fail for unknown reasons. To try and avoid those (successfully
as it seems), I reduced the nr of executors for our OsmocomBuild1 debian slave
to 2; used to be 6 IIRC. My argument was that 'make -j 9' would anyway utlize
the resources, except during the python testing phase.
But the build slave queue is getting awfully long sometimes and builds are just
sitting and waiting for a long time. But when I 'top' on the build slave, I see
the CPU idling between 50% and 90% ... assuming that the CPU activity in docker
is also shown on the host OS. So now I increased the nr of executors to 3,
seraching the optimum that still avoids the 'Broken Pipe' error. Would of
course be much nicer to fix this particular curious failure and just hammer the
nr of executors up to the roof again.
~N
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
Hi Tom and all,
After a quick look at the 4th patch, related to your optimized
Viterbi decoder, I have noticed that currently the convolutional
code definitions from the 'src/gsm/gsm0503_conv.c' are out of
the 'tests/conv' test coverage...
So, I would like to extend the test coverage. All I need are
the test vectors, which I'll add to existing ones. Some of them
I already found in your 4th patch, but some pending I need to
write myself.
Right now I have a simple question...
Let's look at one example:
{
.name = "GSM RACH (non-recursive, flushed, not punctured)",
.code = &gsm_conv_rach,
.in_len = 14,
.out_len = 36, // ???
.has_vec = 0,
.vec_in = { },
.vec_out = { },
}
As I noticed, the 'in_len' may be taken from the code definition:
const struct osmo_conv_code gsm0503_rach = {
.N = 2,
.K = 5,
.len = 14, // The 'in_len' is here!
.next_output = xcch_output,
.next_state = xcch_state,
};
But I don't know how to calculate the 'out_len'...
Could you please give me some hint?
I already started to work on your 4th patch:
https://gerrit.osmocom.org/1542https://gerrit.osmocom.org/1543
With best regards,
Vadim Yanitskiy.
I would like to see https://gerrit.osmocom.org/#/c/1411/ fixed and merged.
Firstly, the way the code is written leaves it unclear whether it works as
intended.
Secondly, this is blocking the effort to do more sanitizer builds in jenkins
/ gerrit build jobs.
Aravind, would you please provide feedback on your availability -- will you get
around to this any time soon, or should we try to assign this to someone else?
Thanks!
~N
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
I find the link https://osmocom.org/news/ quite valuable, but it's not easy to
get there. I would expect a "News" link on http://osmocom.org to point there,
so I placed one.
We do have a "Planet" link -> http://planet.osmocom.org/ , which is currently broken.
Firefox outright refuses to display it: the certificate is
invalid/unknown/expired and the site is marked as "only show when secure", so
one cannot add a security exception (fail: that should be the user's choice!).
Chromium redirects to https://admin-trac.openmoko.org/trac/ ... doesn't match.
So I took the liberty to remove the "Planet" link -- for now?
All this by editing, in our redmine jail, file
/usr/local/www/redmine-3.2.3/plugins/impressum_plugin/init.rb
Feedback welcome!
~N
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
Hi,
according to a lot of sources one would think, that EC20 is based around the
Qualcomm MDM9615, but the picture of naked EC20[1] clearly shows, that there
is Qualcomm MDM9215 chip soldered on the board. Which source is true? :-) Or
it's just a wrong text on that BGA?
1. https://osmocom.org/attachments/download/2501/ec20-naked-top.jpg
-- ynezz
hi
I compliled OpenBSC in linux kernel 4.2.* and all test was successful but
when upgrade my linux to kernel v4.8.* , we face 2 failed test.
logs attached
Regards
Hossein
Hi Tom,
Recently I already asked for your permission to relicense
the GSM 05.03 code from OpenBTS, and now I am contacting
you with the same purpose. I am going to move your optimized
Viterbi decoder forward, but currently it is licensed under
the LGPL v2.1 (or later). To avoid license mix within the
core Osmocom library, it would be better to relicense your
code to the same one, if you agree.
So, the question is: do you agree to relicense your code
under the GPLv2-or-later?
With best regards,
Vadim Yanitskiy.
Dear Osmocom Community,
[please respect the Reply-To and post all follow-up discussion to this
to openbsc(a)lists.osmocom.org, so we avoid having long threads
cross-posted to several mailing lists.]
>From 2012 to 2016 we were running a series of small, invitation-only
Osmocom Developer Conferences. Access was intentionally restricted
to those community members who have demonstrated an existing track
record of contribution to any of the projects under the Osmocom
umbrella.
This format of a small, tightly knit group of about 20 people has been
successful over the years, and I have received a lot of positive
feedback from past participants.
On the other hand, the Osmocom project has grown in scope and diversity,
and some of those projects don't have all that much relationship to each
other - except being started by people from within the same group.
There's the cellular communications (GSM/GPRS/EDGE/UMTS and hopefully at
some point LTE) protocols which is attracting a lot of professional
users. And then there's pure community projects like rtl-sdr,
OsmocomBB, OsmocomGMR and many other efforts.
Particularly the cellular infrastructure projects (OsmoBTS, OsmoPCU,
OsmoBTS, OsmoNITB, OsmoSGSN, OpenGGSN, OsmoIuh & co) are somehow
"standing out" of the othe projects in the context of having a wider
user bsae, and in that user base also primarily commercial users.
So I'd like to start a discussion on how to possibly change the event
format to accomodate the various interests and parties. I definitely
don't want to loose the "annual meeting of old friends" atmosphere,
while at the same time also opening up to other interested parties.
One idea would be to keep OsmoDevCon as-is and have a separate event
where non-contributing/developing users / sysadmins / system integrators
could also be attending.
Another idea would be to split into a 'user day' and 'developer days'
format. This is something the netfilter developer workshops have been
using for many years, and from my limited insight quite successfully so.
The "user day" is more like a traditional tech conference, with a large
auditorium and talks oriented towards users / sysadmins / integrators of
the software. The "developer days" are the invitation-only part, for
known contributing developers only, similar to what we have at
OsmoDevCon.
Having both events (or both parts of an event) back-to-back has the
advantage that a large number of potential speakers for the 'user day'
are already present, and they don't have to travel yet another time.
One could even structure it further and say we have one user day, one
public 'Osmocom cellular developer day' and then the closed 'OsmoDevCon
classic', maybe reduced from 4 days to 3 or even 2 days only?
What is the general opinion about this?
Are there people lurking on this list who would be interested in
attending a public 'user day' or even 'developer day' about the Osmocom
cellular projects, with presentations and workshops around topics such
as running Osmocom based cellular networks?
In terms of when/where, I would suggest to keep the tradition of April
in Berlin/Germany. But I'm of course very happy if somebody wants to
host it some place else...
Regards, and looking forward to meeting you [again] in 2017,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)