those harmonics) must be above:
-30 dBm @ 30 kHz span above 1 GHz
-36 dBm @ 30 kHz span below 1 GHz
In case of UmTRX without an amplifier it's enough to use a ceramic or
SAW duplexer to bring harmonics below those levels.
For those buying UmTRX's as a lab package of universal UmDESKs, we
offer to buy an external ceramic duplexers. These improves coverage
and solves the out of band noise issues.
For those buying band-specific UmDESK's, we use SAW duplexers, which
are even more efficient in reducing out of band noise.
>> A calibrated USRP N200 running osmo-trx passes RF spectrum and
>> modulation accuracy requirements of 3GPP 05.05 by very large margins
>> and is competitive with commercial GSM equipment in this regard. Other
>> SDR devices are also capable to varying degrees.
>
> The policy of FCC vs. European Union is quite different. There are more
> norms that apply in Europe.
You're obviously more proficient in European norms. Could you point me
to a link where we could find these differences between the ETSI
published GSM Standard and European harmonized norms?
It would be a very good addition to the OpenBSC wiki's "Standards" page.
--=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
> 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
