I tried to install CalypsoBTS have libosmocore installed, osmo-bts osmobsc,
libosmo-netif, libosmo-abis, ortp, trx, libosmo-dsp everything went without
errors, following the instructions I created: touch ~/.osmocom/open-bsc.cfg
, then when you run : osmo-nitb -c ~/.osmocom/open-bsc.cfg-l
~/.osmocom/hlr.sqlite3-P-C --debug=DRLL:CC:MM:RR:RSL:NM shows me:<0005>
bsc_init.c:498 Failed to parse the config file:
'/root/.osmocom/open-bsc.cfg' file tried to create as administrator but
without success , pleas help me
--
View this message in context: http://baseband-devel.722152.n3.nabble.com/Calypso-BTS-tp4026753.html
Sent from the baseband-devel mailing list archive at Nabble.com.
Hello! I Need Help
I install these three programs OpenBTS, OsmocomBB, Asterisk
Then run them, Everything works well
OpenBTS sent an SMS to my phones
I answered and he checked me
I registered into OpenBTS a second phone
I tried to transfer SMS between phones - all good
but when I try to call from one to another I did not get
Asterisk writes
================================================================
*CLI> Retransmission timeout reached on transmission 755803415(a)127.0.0.1 for
seqno 179 (Critical Response) -- See
wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 32001ms with no response
================================================================
Why?
What do I do?
--
View this message in context: http://baseband-devel.722152.n3.nabble.com/OpenBTS-OsmocomBB-Asterisk-tp402…
Sent from the baseband-devel mailing list archive at Nabble.com.
Hi,
Don't get me wrong, but your current description sounds like
"I have a problem, but I wouldn't say any details about that".
Please provide at least mobile application logs, and also try
to figure out some things yourself:
1) What is difference between both SIM cards you use?
2) Does mobile with "non-working" SIM perform successful LU?
3) Does mobile with "non-working" SIM receive any Paging Request?
4) Does one answer to Paging Request by sending Paging Response?
5) Then, does the L1 switch to a dedicated channel?
6) What is happening on a dedicated channel?
7) ... ?
OsmocomBB is not for end users, so you should do / learn a lot
of things yourself. After all, the source code is always available.
With best regards,
Vadim Yanitskiy.
Hello FreeCalypso and Osmocom communities,
I am in the process of creating an informal organisation representing
the interests of those members of the GSM universe whose interests are
not represented by GSMA etc, and I am inviting you to join me in this
venture. I propose that we name our informal organisation GSMUA,
standing for GSM Users Association, and my vision for this GSMUA is to
be a counter-body (antibody?) to the official GSMA. I just registered
the gsmua.org domain name, but there is no website or mailing list set
up yet. If someone from the Osmocom camp would like to host the
server infrastructure for gsmua.org, I will happily point the DNS to
you, otherwise the FreeCalypso family can host it on our server.
My vision for GSMUA is to represent the interests of GSM end users
(empowered end users who wish to fully own and control all aspects of
their user equipment while operating on public mobile networks in a
fully spec-compliant manner), small boutique manufacturers of GSM
devices (both MS/user equipment and network infrastructure), small
community network operators and others whose interests are not
represented by GSMA etc, especially in cases where our interests are
in direct conflict with the interests of big players such as giant
device manufacturers, giant commercial network operators and
governments.
A key goal of GSMUA is to be project-neutral, that is, every person
and every small company belonging to any of the categories listed
above (empowered end user, small boutique device manufacturer, small
community network operator etc) should be fully welcome regardless of
which specific project they are associated with. As of today there
are at least two different projects offering GSM MS implementations
(OsmocomBB and FreeCalypso) and at least two different projects
offering network-side GSM implementations (Osmocom and OpenBTS), and I
hope that this number of available alternatives will continue to grow:
freedom of choice is always a good thing. But at the present time
there exists no neutral soil on which members of different projects
with a common interest (GSM networks and devices serving the interests
of end users rather than big corporations and governments) and a
common enemy (just named) can meet, and this lack of neutral meeting
ground is the problem which GSMUA is meant to solve.
I also have one practical application for GSMUA in mind already: to
manage and legitimize recycling of wasted IMEI number ranges. By the
official rules of GSMA etc each different *type* of GSM mobile
equipment requires a different TAC, i.e., a range of at least 1 million
IMEI numbers. So if a small boutique GSM device manufacturer makes a
boutique MS device of which no more than 100 units will ever be made,
999900 IMEI numbers have to be wasted by the official rules. While I
don't know of any manufacturer who got a range of 1 million IMEIs and
only made 100 devices, we do have examples like Openmoko GTA01/02 and
Pirelli DP-L10. In the case of Openmoko GTA02 I've been told that
about 15 thousand units were made in total; in the case of Pirelli
DP-L10 it appears that the total number produced was somewhere under
100 thousand. In each case a full range of 1 million IMEIs was
allocated, and at least 900 thousand numbers out of each range are
currently unused and wasted.
If a small boutique manufacturer wishes to offer a boutique GSM MS
product to the general public and wishes to ship each unit with a
world-unique IMEI that stands a good chance of being accepted as valid
by common GSM networks, and the product in question does not qualify
for IMEI allocation by the official rules (e.g., the product is a
development board specifically intended for users to run their own
firmware and connect to live public networks with it, taking full
personal responsibility for their actions) - the situation I found
myself in with my GSM MS development board - I feel that the small
boutique manuf in question should be empowered to squat on a small
subrange of someone else's IMEI range if it is known beyond reasonable
doubt to be wasted and unused.
However, this recycling of wasted IMEI number ranges could be better
organized and given at least some aura of semi-legitimacy if there
were a community body set up to manage it, and this is where my
proposed GSMUA can come in. Once we get our GSMUA up and running and
assign a group of volunteers to be IMEI recycling managers, any small
GSM or 3G+ device manufacturer who needs a small range of IMEI numbers
will be able to request one from GSMUA, and we will allocate and
assign these small subranges out of whatever wasted range we decide to
squat on, ensuring that each requestor gets a different subrange.
So these are my ideas, and I would like to see them turn into reality.
We are going to need a simple website and a community mailing list at
gsmua.org, and for the IMEI recycling service we will need a small
group of volunteers to serve as its managers - I and Das Signal from
FreeCalypso will be happy to serve on that panel, but it would be nice
to also have someone from the Osmocom camp for better neutrality.
Bright Blessings,
Mychaela Falconia,
Mother of FreeCalypso
Hi
I needed some information from you, I want to implement a GSM Mobile stack with USRP as RF Frontend. Is it possible to build the DSP part of osmocommbb in a different TI DSP board other than calypso. As it is very difficult to find calypso phones now a days.
BR
Snehasish
Hey guys, first of all I want to express my deep respect for this project,
this is truly amazing project and very well developed.
Second, I'm doing a few studies regarding GSM security (no, I'm not
hacking.) and I need to develop a feature for osmocombb, which is: the
ability to turn the L23 app as a zombie (C unix domain socket) waiting for
instructions (e.g.: connect to the network with predefined parameters
(IMSI), collect RAND, send sms,...).
Is there any documentation or flow regarding the code? It's very hard for a
non C coder to follow the flow... Or is there someone that can help me in
the Architectural level?
Thank you.
Hi Herald
I needed some information from you, I want to implement a GSM Mobile stack with USRP as RF Frontend. Is it possible to build the DSP part of osmocommbb in a different TI DSP board other than calypso. As it is very difficult to find calypso phones now a days.
BR
Snehasish
I was thinking about how to setup an automated real device test for the repo and/or PRs especially. I have devices and cables, just was thinking about how to automate the re-loading of firmware (via an interface to the power button I suppose).
Any work ongoing on this front? I'd be happy to contribute as I have a server I'm going to use for nano3g, calypsobts, development.
-Craig
--------------------------------------------
On Thu, 5/18/17, Harald Welte <laforge(a)gnumonks.org> wrote:
Subject: OsmocomBB compile testing / Re: libosmocore embedded build
To: "André Boddenberg" <dr.blobb(a)gmail.com>
Cc: baseband-devel(a)lists.osmocom.org, "OpenBSC" <openbsc(a)lists.osmocom.org>, "Vadim Yanitskiy" <axilirator(a)gmail.com>
Date: Thursday, May 18, 2017, 1:24 PM
Hi Andre and others.
We currently have a series of patches from
Vadim pending in gerrit for
OsmocomBB.
They cannot move ahead, as we have no compile testing /
jenkins job which would give this a +1.
To resolve this, we should
also start to have a jenkins compile testing
job for OsmocomBB. The "host" (PC)
part of the code is built against
regular
libosmocore, just like e.g. openbsc or osmo-bts. That
should be
possible even so far, and it might
make sense to start with that.
Basically you need to:
* git
clone osmocom-bb
* cd src/host/layer23
* regular 'autoreconf -fi &&
./configure && make'
compile-testing the 'embedded'
(firmware) part is not possible easily in
the current master. However, as a second
step, and after the
libosmocore embedded
build has run (and it is installed to
/usr/local/arm-none-eabi), and if you use the
laforge/remove-libosmocore
branch in
OsmocomBB, you should also be able to compile-test the
firmware using
* git clone osmocom-bb
* cd
src/target/firmware && make
There currently is no "make check"
tests for either the host utilities
or the
firmware, and of course we have no clue if the resulting
binaries
will do anything useful on an
actual pone [yet!], but I still think the
two steps above would be very useful to move
ahead, and to unify the
patch
submission/review/verification/approval/merge process in
gerrit
with what we have established for the
network-side projects like OsmoBTS
& co.
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)
Hi Vadim,
see attachment.
This was my 'test ballon': We now have automatic jenkins build
verification at least for the host part of OsmocomBB. Please re-push
your patch series again into jenkins, so they will get build-verified.
--
- 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)
Dear all,
when we originally moved a lot of generic code from OpenBSC to
libosmo{core,gsm} to re-use it from OsmocomBB, we created an 'embedded'
build of libosmocore, which can use [most of] the library code also in
deeply embedded, OS-less 'bare metal' microcontroller environments.
The ability to build libosmocore this way has been broken for many
years, but I've fixed that in recent libosmocore master. Below command
works for me [tm]:
./configure --prefix=/usr/local/arm-none-eabi \
--host=arm-none-eabi \
--enable-embedded \
--disable-shared \
CFLAGS="-Os -ffunction-sections -fdata-sections -nostartfiles -nodefaultlibs"
What we'd need now is:
1) make sure embedded builds continue to work by building libosmocore
for embedded as part of the jenkins setup (using gcc-arm-none-eabi
debian package). Any volunteers?
2) start to use this embedded build from simtrace2 firmware, osmocom-bb
and the upcoming fimrware for the RFDN[1]. So far,
* osmocom-bb uses an old clone of libosmocore,
* simtrace2 is using some copy+pasted fork of some libosmocore files
* rfdn is using some copy+pasted fork of some libosmocore files
The above is no longer required.
3) consider if we can shrink the resource requirements of some
libosmocore parts. One issue coming up are the static buffers in
osmo_hexdump[] or the like. If your total processor RAM is 8k or
16k, then spending 4k on the buffer for hex-dumping is indeed a bit
excessive.
Any help is appreciated, particularly on the jenkins side.
Regards,
Harald
[1] (1:8 splitter-combiner with adjustible step attenuators, part of the
osmo-gsm-tester setup we're building at sysmocom). Code will be
released as soon as the hardware is validated.
--
- 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)
Hi,
> The arm build does not succeed (yet) [2].
>
> Can someone else may have a quick look at log [2] to point me in the
> right direction? Afaics build dependencies are available but the
> compilation itself fails.
As I can see from the console output, build fails because we are
trying to test disabled features, which we haven't compiled.
Fixed by fixeria ;)
https://gerrit.osmocom.org/#/c/2682/1
With best regards,
Vadim Yanitskiy.
> Can someone else may have a
> quick look at log [2] to point me in the
> right direction? Afaics build dependencies are
> available but the
> compilation itself
> fails.
> [2] https://jenkins.osmocom.org/jenkins/job/TEST_libosmocore_arm_none_eabi/arch…
Looks like the tests are failing. My build seems to work but when I run "make check-am" in tests I get a different error related to talloc. This is on a Debian 8 stable box using arm-none-eabi and newlib from debian packages. Maybe the
make of timer_test fails and doesn't log somehow? I"m not sure.
craig@z500:~/libosmocore/tests$ vi timer/timer_test.
timer_test.c timer_test.ok
craig@z500:~/libosmocore/tests$ vi timer/timer_test.c
craig@z500:~/libosmocore/tests$ make check-am
make timer/timer_test sms/sms_test ussd/ussd_test smscb/smscb_test bits/bitrev_test a5/a5_test conv/conv_test auth/milenage_test lapd/lapd_test gsm0808/gsm0808_test gsm0408/gsm0408_test gb/bssgp_fc_test gb/gprs_bssgp_test gb/gprs_ns_test gprs/gprs_test kasumi/kasumi_test gea/gea_test logging/logging_test fr/fr_test codec/codec_test loggingrb/loggingrb_test strrb/strrb_test vty/vty_test comp128/comp128_test utils/utils_test smscb/gsm0341_test stats/stats_test ctrl/ctrl_test bitvec/bitvec_test msgb/msgb_test bits/bitcomp_test tlv/tlv_test gsup/gsup_test oap/oap_test fsm/fsm_test write_queue/wqueue_test socket/socket_test coding/coding_test conv/conv_gsm0503_test abis/abis_test endian/endian_test sercomm/sercomm_test
make[1]: Entering directory '/home/craig/libosmocore/tests'
CC timer/timer_test.o
In file included from timer/timer_test.c:31:0:
../include/osmocom/core/talloc.h:4:20: fatal error: talloc.h: No such file or directory
#include <talloc.h>
^
compilation terminated.
Makefile:1336: recipe for target 'timer/timer_test.o' failed
make[1]: *** [timer/timer_test.o] Error 1
make[1]: Leaving directory '/home/craig/libosmocore/tests'
Makefile:1529: recipe for target 'check-am' failed
make: *** [check-am] Error 2
Hi Harald and Craig,
> select.c:27:24: fatal error: sys/select.h: No such file or directory
> #include <sys/select.h>
I have the same issue with:
gcc-arm-none-eabi 4.8.2-14ubuntu1+6
binutils-arm-none-eabi 2.24-2ubuntu2+4
libnewlib-arm-none-eabi 2.1.0-3
> * remove 'talloc emulation' from osmocom-bb and use pseudotalloc from
> libosmocore.git (plus an embedded 'malloc' like umm_malloc)
Why do we need this hack (pseudotalloc)?
What if we could cross-compile libtalloc too, and link it against core?
> * have an (optional?) osmocom-bb makefile step to git clone + configure
> + make install libosmocore
Great idea! What about to have libosmocore as a git submodule inside
OsmocomBB (like OpenCL headers in hashcat)?
Also, I think it would be good to make libosmocore more modular,
because it could allow us to create more flexible builds (e.g. to compile
only what we need, not a whole library). This makes sense in case of
low RAM / ROM embedded systems. What do you think?
With best regards,
Vadim Yanitskiy.
I got around this error by adding a #if (!EMBEDDED) around all of select.c and moving the #include "../config.h" to the top.
diff --git a/src/select.c b/src/select.c
index 8ed7f1b..e51e50a 100644
--- a/src/select.c
+++ b/src/select.c
@@ -20,6 +20,8 @@
* MA 02110-1301, USA.
*/
+#include "../config.h"
+#if (!EMBEDDED)
#include <fcntl.h>
#include <stdio.h>
#include <string.h>
@@ -30,7 +32,6 @@
#include <osmocom/core/linuxlist.h>
#include <osmocom/core/timer.h>
-#include "../config.h"
#ifdef HAVE_SYS_SELECT_H
@@ -235,3 +236,4 @@ struct osmo_fd *osmo_fd_get_by_fd(int fd)
/*! @} */
#endif /* _HAVE_SYS_SELECT_H */
+#endif /* !EMBEDDED */
After that the next error in building is related to talloc.
make[3]: Entering directory '/home/craig/libosmocore/src'
CC select.lo
CC utils.lo
In file included from ../include/osmocom/core/utils.h:4:0,
from utils.c:30:
../include/osmocom/core/talloc.h:4:20: fatal error: talloc.h: No such file or directory
#include <talloc.h>
I didn't see the laforge/pseudotalloc branch. Did you forget to push it? How is this dealt with currently in osmocom-bb for embedded?
Thanks,
Craig
Looks like in package libnewlib-dev for stretch (unstable) we have sys/select.h but in jessie (stable) it is not included.
https://packages.debian.org/stretch/libnewlib-devhttps://packages.debian.org/jessie/libnewlib-dev
craig@box:~/libosmocore$ ./configure --prefix=/usr/local/arm-none-eabi --host=arm-none-eabi --enable-embedded --disable-shared CFLAGS="-Os -ffunction-sections -fdata-sections -nostartfiles -nodefaultlibs"
craig@box:~/libosmocore$ make
make all-recursive
make[1]: Entering directory '/home/craig/libosmocore'
Making all in include
make[2]: Entering directory '/home/craig/libosmocore/include'
make all-am
make[3]: Entering directory '/home/craig/libosmocore/include'
make[3]: Nothing to be done for 'all-am'.
make[3]: Leaving directory '/home/craig/libosmocore/include'
make[2]: Leaving directory '/home/craig/libosmocore/include'
Making all in src
make[2]: Entering directory '/home/craig/libosmocore/src'
make all-am
make[3]: Entering directory '/home/craig/libosmocore/src'
CC select.lo
select.c:27:24: fatal error: sys/select.h: No such file or directory
#include <sys/select.h>
^
compilation terminated.
Makefile:510: recipe for target 'select.lo' failed
make[3]: *** [select.lo] Error 1
make[3]: Leaving directory '/home/craig/libosmocore/src'
Makefile:373: recipe for target 'all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory '/home/craig/libosmocore/src'
Makefile:519: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/craig/libosmocore'
Makefile:382: recipe for target 'all' failed
make: *** [all] Error 2
--------------------------------------------
On Tue, 5/16/17, Harald Welte <laforge(a)gnumonks.org> wrote:
Subject: removing ancient libosmocore fork from osmocom-bb.git
To: baseband-devel(a)lists.osmocom.org
Date: Tuesday, May 16, 2017, 11:18 AM
Dear all,
when we initially crated OsmocomBB, we moved the code that
it shared
with the pre-existing OpenBSC project into libosmocore.git,
where
libosmocore and libosmogsm are built. As libosmocore
was quite a bit in
flux (and we didn't have jenkins+gerrit yet), we decided to
have a local
clone of libosmocore.git as a git-subtree module inside
osmocom-bb.git
Meanwhile, upstream libosmocore received more and more code,
and none
of that was ever built with an 'arm-non-eabi' toolchain and
--enable-embedded.
I've been working quite a bit during the last week on making
that
embedded build work again.
The idea is to be able to configure + build libosmocore.git
master using
something like
./configure
--prefix=/usr/local/arm-none-eabi \
--host=arm-none-eabi
\
--enable-embedded \
--disable-shared \
CFLAGS="-Os
-ffunction-sections -fdata-sections -nostartfiles
-nodefaultlibs"
and then install it onto the host pc. I've used
/usr/local/arm-none-eabi as the prefix, but it could of
course be
anywhere.
The above already works for me on Debian unstable using
libosmocore.git
master. I have some patches pending in laforge/sercomm and
laforge/pseudotalloc, but those are not mandatory to make
the build work
The local clone of libosmocore in OsmocomBB
src/shared/libosmocore will
be removed, and the Makefiles of osmocom-bb instructed to
use the
system-installed libosmocore from /usr/local/arm-none-eabi
(see my
'laforge/remove-libosmocore' branch in). This also
already "works" on
my Debian unstable system, in as far as there are no
unresolved symbols
or other compilation/linking issues, and the firmware images
are
generated. I have not tested any of the resulting
binaries yet, and as
I'm travelling without compatible hardware (and overloaded),
it's
unlikely that I'll be able to test it soon.
Nevertheless, this is what I would like to move to. If
anyone wants to
try if he can build the embedded libosmocore and resulting
osmocom-bb
from laforge/remove-libosmocore branch, please do so and
report your
progress/success/issues here.
Next steps (after validating the above) are:
* remove old sercomm.c code from osmocom-bb and use the new
code from
libosmocore
* remove 'talloc emulation' from osmocom-bb and use
pseudotalloc from
libosmocore.git (plus an embedded 'malloc' like
umm_malloc)
Further ideas:
* create Debian/Ubuntu package of cross-compiled libosmocore
for
embedded-arm, which we can add to the Osmocom nightly
builds apt
repository.
* have an (optional?) osmocom-bb makefile step to git clone
+ configure
+ make install libosmocore
Anyone interested in helping out with this, please feel free
to join in.
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)
Dear all,
when we initially crated OsmocomBB, we moved the code that it shared
with the pre-existing OpenBSC project into libosmocore.git, where
libosmocore and libosmogsm are built. As libosmocore was quite a bit in
flux (and we didn't have jenkins+gerrit yet), we decided to have a local
clone of libosmocore.git as a git-subtree module inside osmocom-bb.git
Meanwhile, upstream libosmocore received more and more code, and none
of that was ever built with an 'arm-non-eabi' toolchain and
--enable-embedded.
I've been working quite a bit during the last week on making that
embedded build work again.
The idea is to be able to configure + build libosmocore.git master using
something like
./configure --prefix=/usr/local/arm-none-eabi \
--host=arm-none-eabi \
--enable-embedded \
--disable-shared \
CFLAGS="-Os -ffunction-sections -fdata-sections -nostartfiles -nodefaultlibs"
and then install it onto the host pc. I've used
/usr/local/arm-none-eabi as the prefix, but it could of course be
anywhere.
The above already works for me on Debian unstable using libosmocore.git
master. I have some patches pending in laforge/sercomm and
laforge/pseudotalloc, but those are not mandatory to make the build work
The local clone of libosmocore in OsmocomBB src/shared/libosmocore will
be removed, and the Makefiles of osmocom-bb instructed to use the
system-installed libosmocore from /usr/local/arm-none-eabi (see my
'laforge/remove-libosmocore' branch in). This also already "works" on
my Debian unstable system, in as far as there are no unresolved symbols
or other compilation/linking issues, and the firmware images are
generated. I have not tested any of the resulting binaries yet, and as
I'm travelling without compatible hardware (and overloaded), it's
unlikely that I'll be able to test it soon.
Nevertheless, this is what I would like to move to. If anyone wants to
try if he can build the embedded libosmocore and resulting osmocom-bb
from laforge/remove-libosmocore branch, please do so and report your
progress/success/issues here.
Next steps (after validating the above) are:
* remove old sercomm.c code from osmocom-bb and use the new code from
libosmocore
* remove 'talloc emulation' from osmocom-bb and use pseudotalloc from
libosmocore.git (plus an embedded 'malloc' like umm_malloc)
Further ideas:
* create Debian/Ubuntu package of cross-compiled libosmocore for
embedded-arm, which we can add to the Osmocom nightly builds apt
repository.
* have an (optional?) osmocom-bb makefile step to git clone + configure
+ make install libosmocore
Anyone interested in helping out with this, please feel free to join in.
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)
Hi,
> I found that the manual from the main site is outdated.
Yeah, still couldn't find some time to update the wiki.
> If I understood it correct, I have to setup calypso bts
> as bts of type nanoBTS, correct?
Why do you think so? No, CalypsoBTS has nothing related
toip.access nanoBTS. From the other side, we don't have
a dedicated type for OsmoBTS, so you can use 'sysmoBTS'.
> I can sync with commercial cell, I can run OsmoBSC and
> OsmoBTS but I still cannot find my network from my personal
> phone in searching mode.
Please watch a great Sylvain's talk, where he explained
almost everything you need to know:
"Further hacks on the Calypso platform"
https://media.ccc.de/v/29c3-5226-en-further_hacks_calypso_h264
In short: BTS should transmit a continuous beacon on C0 to be
detected. Normal MS can't do that. CalypsoBTS was hacked to
perform the following timeslot layout: Tt_R_ttt, where
'T' means TX on Downlink, 'R' means RX on Uplink, and 't' means
channel filling - dummy bursts. Phone cannot RX and TX at the
same time, so one phone serves only one TS. With two phones
you have the following layout: TT_RRttt, so you have two
timeslots served.
This is why you will have some detection troubles even with
working BSS setup :/
> In logs of osmo-bts I can see:
>
> <0000> rsl.c:246 Tx RSL RF RESource INDication
> <000b> trx_if.c:397 transceiver (phy0.0) rejected TRX command with
> response: 'RSP SETTSC -1'
> <0000> rsl.c:2353 (bts=0,trx=0,ts=0,ss=0) Rx RSL BCCH_INFO
Just delete the 'settsc' line from your config, because CalypsoBTS
transceiver only supports 'setbsic'.
Have a fun!
With best regards,
Vadim Yanitskiy.
Dear colleagues,
Could you please tell me when I am wrong in my assumptions?
My story is about beacon channel.
>From different resourses I got the information that we transmit bcch data
(fcch,sch,bcch) which is required for MS to find our network. OK?
On the pictures it's drawn like we transmit BCCH on C0T0. So DL TS1-7 can
be used for i.e. TCH. So if we want just to create bts which can be found
by MS and that's all, we may not transmit on TS1-7 at all. OK?
When we are talking about CalypsoBTS we say that we must transmit several
burst in a row. So here I am a bit confused. So if we want to just transmit
bcch messages we can transmit every TS0 and rest on TS1-7. Why not? Why I
can see in manuals and videos pictures like Ttt_R_tt? Why do I need these
dummy "t" bursts? Why one burst is "t" and another is "T"? Sure I
understand that we must receive something for normal BTS operation like
RACH and need some time to switch Tx/Rx. But why we just cannot use mask
like T_R_T_R_ ...? I understood that we cant use mask TTT_RR because
calypso phone was not hacked to receive two bursts in a row.
Thanks in advance!
Hi,
> I setup CalypsoBTS to work with 2 old motorola c123, I know that isn't the
> best way to do that, but I would like to have a cheap solution. I got the
> setup working with a normal phone and the BTS seems to work correctly
> (using jolly/testing), but from my understanding it support only GSM calls
> and SMS and GPRS is not implemented into the transceiver. I'm wrong or
this
> part has not been implemented yet?
Right, isn't implemented. When you run OsmoBTS, it first does some basic
configuration of transceiver, including timeslot type setting. PDCH has
its own dedicated type, which is being indicated by the SETSLOT command.
So you can look at OsmocomBB sources, and check whether the transceiver
handles this type or not.
> Also, given that CalypsoBTS can only provide single (or two?) timeslot,
> there are a long list of reasons why it would not work straight-forward.
> But technically also possible to make work.
With two Calypso phones it becomes possible to serve two timeslots.
Basically, second phone serves one TCH timeslot, but (if I am correct)
PDCH has no fundamental differences from TCH, so its support could be
implemented too.
After a quick look at OsmoTRX source code, I can assume, that the only
difference between TCH channel combinations (I, II and III) and PDCH
channel combination (XIII) is a fillerModulus value. Correct me if I am
wrong.
With best regards,
Vadim Yanitskiy.
Hi everybody,
I'm pretty new to the GSM/UMTS environment and I'm doing some tests.
Currently I need to analyze some IoT devices that use 2G network to
comunicate via GPRS.
I setup CalypsoBTS to work with 2 old motorola c123, I know that isn't the
best way to do that, but I would like to have a cheap solution. I got the
setup working with a normal phone and the BTS seems to work correctly
(using jolly/testing), but from my understanding it support only GSM calls
and SMS and GPRS is not implemented into the transceiver. I'm wrong or this
part has not been implemented yet?
If needed to use a GPRS BTS can you suggest the best cheap SDR to use with
OsmoBTS? (I saw BladeRF and LimeSDR but I was unable to understand if they
are full supported via OsmoBTS)
Thank you in advance.
inode
> what are problem should i expect
> while porting to qcom hexagon
> is it a bad idea
There would be a lot of questions and things to research. I am not familiar with qcom hexagon SDK. I am a little familiar with osmocom-bb source code and 2G GSM details. I am currently in the very beginning stages
of porting osmocom-bb to the MediaTek 6260/6261 chip which supports 2G. I also have ideas to try and work through 3G on a MediaTek 6735 (ZTE Obsidian phone).
Recently there have been mentions of re-writing the PHY layer of osmocom-bb for an SDR platform like LimeSDR.
https://github.com/axilirator/osmocom-bb
So at the current time I assume that osmocom-bb communicates with the DSP chip on the motorola phones
in a way that abstracts the PHY layer details away and relies on the proprietary Texas Instruments firmware in the DSP as-is.
So I would imagine you might have to implement the PHY layer and also the interface to the PHY layer.
There was a discussion about this recently on IRC #osmocom.
It seems the thought was that qcom had released enough with their Hexagon SDK to allow development of a PHY layer + whatever else.
Some links of interest.
https://developer.qualcomm.com/ - SDK
https://github.com/ttsou/openphy - LTE PHY for Ettus USRP
https://androiddatahost.com/fgd43 - qcom flash image loader
I have a few qcom modems that I'd be happy to do experiment on if that helps.
-Craig
> isn't fixed in branch jolly/testing I am using for calypsoBTS.
> So all I needed is just implement the fix and recompile from sources.
You can also use an older version of toolchain as a temporary
solution: https://github.com/axilirator/gnu-arm-installer - in this
repo I have fixed some installation (texinfo) related issues.
With best regards,
Vadim Yanitskiy.
Dear colleagues,
I am trying to setup CalypsoBTS with two c113 phones.
Don't you know why can't I sync to any commercial cell with transceiver
from branch jolly/testing?
What I have:
Motorola c113 and c113a, tried both.
All other apps like, RSSI, mobile, ccch_scan works like a charm.
What I am doing:
Built jolly/testing according to maual
https://osmocom.org/projects/baseband/wiki/CalypsoBTS
Load firmware
./osmocon -r 99 -m c123xor -p /dev/ttyUSB0 -c
../../target/firmware/board/compal_e88/trx.highram.bin
Found several strongest cells with RSSI and cell_log.
Trying to sync:
./transceiver -a 50 -r 99 -e 1
Here is the log:
50
41
1
<000c> l1ctl.c:77 Tx Reset Req (1)
<000c> l1ctl_link.c:171 Sending: '0d 00 00 00 01 00 00 00 '
<0012> l1ctl.c:383 Reset received: Starting sync.
<000c> l1ctl.c:95 Sync Req
<000c> l1ctl_link.c:171 Sending: '01 00 00 00 00 32 00 64 27 10 03 20 03 07
00 00 00 '
After that phone hangs, no reaction in osmocon on key pressures, holding on
power off button...
The last messages are:
L1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=50, flags=0x7)
Starting FCCH RecognitionFB0 (2515:4): TOA= 3552, Power= -64dBm, Angle=
1328Hz
FB1 (2525:8): TOA= 8543, Power= -64dBm, Angle= 114Hz
fn_offset=2523 (fn=2525 + attempt=8 + ntdma = 6)
delay=8 (fn_offset=2523 + 11 - fn=2525 - 1
scheduling next FB/SB detection task with delay 8
=>FB @ FNR 2523 fn_offset=2523 qbits=3988
Synchronize_TDMA
LOST 3398!
I tried different cells, maybe I need to wait some time to warm the
crystal? But can it be so important?
Kind regards,
Anton
Hi Anton,
> There are some ideas floating around of doing a new run of this using
> OsmoTRX as basis, but I don't know if there is any actual progress yet.
> Vadim should be able to say more about it.
Yeah, I started to work on SDR based PHY about a year ago, but so far
I was busy with libosmocore development. Right now almost everything
(including libosmocoding of course) is in master branch, so it's good
point to resume this work.
If you would like to contribute this direction or something else, we are
always open for that, so feel free! The source code is currently on GitHub:
https://github.com/axilirator/osmocom-bb/
BTW: Harald, is it possible to create a new branch for that work in the
project's repo? If yes, I can send you my public key in PM. Thanks!
With best regards,
Vadim Yanitskiy.
Hello,
I test osmocombb for some time with motorola c115. I can make calls but not always receive calls. I tried 2 sim cards one of them is working fine but the other doesn’t receive anything. I really need some help to solve my problem.
thanks in advance.
Hi everybody,
I'm pretty new to the GSM/UMTS environment and I'm doing some tests.
Currently I need to analyze some IoT devices that use 2G network to
comunicate via GPRS.
I setup CalypsoBTS to work with 2 old motorola c123, I know that isn't the
best way to do that, but I would like to have a cheap solution. I got the
setup working with a normal phone and the BTS seems to work correctly
(using jolly/testing), but from my understanding it support only GSM calls
and SMS and GPRS is not implemented into the transceiver. I'm wrong or this
part has not been implemented yet?
If needed to use a GPRS BTS can you suggest the best cheap SDR to use with
OsmoBTS? (I saw BladeRF and LimeSDR but I was unable to understand if they
are full supported via OsmoBTS)
Thank you in advance.
inode
Dear collegues,
Could you please help me to understand one thing..
If I understood everything correct, osmocombb project consist of all the
code for GSM stack L1-L3 functionality but Calypdo DSP code is not
Opensource and layer1.bin ask non-opensource DSP module to do execute L1
tasks from ghis list:
https://osmocom.org/projects/baseband/wiki/TSM30Layer1#DSP-Tasks
Of cource we can patch DSP and ask it to do whatever we want, like send raw
bursts to the host, but now osmocombb uses mostly DSP firmware written by
Texas Instruments, not its own opdnsource.
Is it correct or not?
Thanks in advance!
is it possible to add new project page to osmocom site.
as i mentioned earlear sourcecode already available for qcom
i think none intrested in it. is it true .why?