> Anyway, I thought that the GPRS support is part of the OpenBTS
> development, and any hardware that can run OpenBTS is also capable of
> doing GPRS, but it is clear, that there are differences in the level
> of support, even between SDR like devices.
The majority of the code of osmo-pcu has been contributed by or on
behalf of sysmocom. If you take a look at the development of the PCU
for the last 6 months you will clearly see that sysmocom is doing all
the work. Just like with OpenBSC a lot of others benefit from our work
though. ;)
> I still think that it would be nice, to clarify all this packet data
> related stuff on the site.
* When an external protocol changes, the version number needs to
change. I added MNCC protocol versioning as OpenBSC and LCR were
out of sync and then funny things happened. This one line change
of the version number can save you hours in debugging!
* When a new feature is added, ask for a testcase. E.g. specially
the E1 bit fiddling as it is so rarely used that it is likely
to bitrot.
* Check the error paths. Developers tend to only test with a single
phone, not run into error paths, not force them to be taken during
development (faul injection).
* For things like device work-arounds ask if they are really necessary,
e.g. I have my doubts for the RTP timestamp handling.
* General code hygiene. Don't have the action take place four tabs in
in a thousand line code method, don't use magic numbers, don't repeat
yourself etc. Code is read a lot more than it is written. Besides smaller
methods being easier to write unit tests for, they are easier to
understand/review.
I have merged two patches from this patchset but they required multiple
rounds and my spare time is really limited.
cheers
holger
I deduct that
" #if defined(L1_HAS_EFR) && defined(USE_L1_RTP_MODE) "
is why I'm seeing this message logged, but it seems to be #define...
Any pointers, ideas ? This doesn't seem like a configuration thing, but a
compilation time option?
I'd have expected that EFR is fully supported?
osmo-bts.cfg snippet
------------------------------
bts 0
band 850
ipa unit-id 1801 0
oml remote-ip 127.0.0.1
rtp jitter-buffer 100
paging queue-size 200
paging lifetime 0
trx 0
clock-calibration 603
trx-calibration-path (null)
clock-source ocxo
uplink-power-target -75
min-qual-rach -5
min-qual-norm -5
Regards,
Roelf.
--bcaec51b1b6f7f08e204e11a4392
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div>I have FINALLY gotten to play with my sysmoBTS acquired many months ag=
o, and updated to the latest packages using okpg, and am running a NITB.</d=
iv><div><br></div><div>GSM850 test setup in open mode A5/0, and I can SMS a=
nd call between devices.</div>
<div><br></div><div>However, there is no audio, and BTS console logs report=
s many repeats of the following during an established call.</div><div><br><=
/div><0006> tch.c:601 (bts=3D0,trx=3D0,ts=3D7,ss=3D0) Rx Payload Type=
EFR is unsupported<div>
<0006> tch.c:601 (bts=3D0,trx=3D0,ts=3D7,ss=3D0) Rx Payload Type EFR =
is unsupported</div><div><0006> tch.c:601 (bts=3D0,trx=3D0,ts=3D7,ss=
=3D0) Rx Payload Type EFR is unsupported</div><div><br><div><br></div><div>=
about it and demonstrate it operating OpenBTS and OsmoBTS. I could
talk about our open-source development of OpenBTS, if there would be
any interest.
Also I'd love to talk about OsmoBTS/OpenBSC which the new cool. Only
few people heard about OsmoBTS, while it provides great capabilities:
* it works with off-the-shelf SDR transceivers like UmTRX
* it could use VoIP (SIP) soft-switches to connect calls
* it connects to MSCs of legacy GSM networks
* it supports encryption, handover, FR/HR/AMR codecs and GPRS (in beta)
* standards compliant L1/L2 layers, so there are no issues with
various phone models
I love Osmocom approach to development as well - development is open
to all contributors, the code is well structured and tested, even
build results for all sub-projects are available through a continuous
integration suite:
http://jenkins.osmocom.org/jenkins/
On Sat, May 4, 2013 at 9:00 AM, Robin Coxe <coxe(a)close-haul.com> wrote:
> (Apologies for cross-posting. We wanted to reach everyone who might be
> interested in attending. Please respond responsibly.)
>
> Anders Brownworth (Switchcoder), Alexander Chemeris (Fairwaves), and Robi=
n
> Coxe (Close-Haul Communications & Analog Devices) invite those interested=
in
> open GSM hardware and software development to an informal gathering in
> Cambridge, MA on Friday 10 May 2013 from 6-8 pm. Alexander will be visit=
ing
> the Boston area from Moscow.
>
> If you are interested in participating in any capacity in the Boston-area
> open source GSM development community, we look forward to meeting you. O=
ur
> goal is to identify like-minded people involved in or interested in learn=
ing
> more about projects such as OpenBTS, OsmocomBTS, OsmocomBB, and OpenBSC.
> If you have a portable, self-contained demo, feel free to bring it with y=
ou.
>
> When: Friday 10 May 2013, 6-8 pm EDT
> Where: Cambridge Innovation Center, 1 Broadway, 4th Floor, Cambridge, MA
> 02142 USA
> Photo ID required for building entry.
>
> Please RSVP on Eventbrite: http://opengsmboston.eventbrite.com/
>
>
>
>
>
>
>
>
--=20
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / =D0=9E=D0=9E=D0=9E =D0=A3=D0=BC=D0=A0=D0=B0=D0=B4=D0=
=B8=D0=BE
http://fairwaves.ru
keep doing the same style. Good food makes a brain work better.
> Venue-wise, I would again suggest to hold it in Berlin, as it's
> reasonbly well connected, has lots of low-cost flights to it,
> accomodation is not too expensive and holger/me/sysmocom can take care
> of local organization related activities. Hoewver, if somebody has a
> strong opinion against berlin _and_ is willing to organize it, I'm not
> completely against another venue.
Berlin is perfect.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / =D0=9E=D0=9E=D0=9E =D0=A3=D0=BC=D0=A0=D0=B0=D0=B4=D0=
=B8=D0=BE
http://fairwaves.ru
of what if the msgb is 'borrowed' or 'owned/transferred'. Whenever we reach a
_send method we actually transfer the ownership (as the data might be queued
or such).
The other technical part is to make sure we first establish a rule by
1.) adding doxygen/API documentation to the sendmsg function
2.) maybe look into introducing dummy annotations like __borrow, __takes that
we could autocheck in the future (e.g. by extending spaze/smack)
The issue with reviewing such a patch is the question if you have catched
everything. E.g. I think you missed need to convert (and what it calls):
static int gprs_ns_tx(struct gprs_nsvc *nsvc, struct msgb *msg)
{
...
default:
LOGP(DNS, LOGL_ERROR, "unsupported NS linklayer %u\n", nsvc->ll);
msgb_free(msg);
ret = -EIO;
break;
}
return ret;
}
> As reported in ticket #55 SGSN can crash due to double free-ing. You
> can replace 'can' by 'will' in that last phrase. I had a sift through
> the code and tried to solve this by removing the free in gprs_ns.c.
> Whenever the calling function created the msgb-struct, I have made the
> function free it after its use. If the function got the msgb from a
> calling function, there will not be a free (hoping that will be done
> on the higher level).
>
> HTH/F
If you need higher bitrates, implementing header and payload compression
at the SNDCP level in the SGSN is possible.
Also, always keep in mind that while you can offer 7 TS with GPRS/EDGE,
almost no phone has support for a multislot class that allows for 7 TS
in DL. So multiple phones can fill the 7 TS, but it's unlikely one
phone can use all of them.
Regards,
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)
