Dear team,
I did set up GSM network with SDR (LimeSDRmini).
SMS are ok.
However when try to make voice call got following message on osmo-bsc terminal:
<0003> abis_rsl.c:1372 (bts=0) CHAN RQD: reason: call re-establishment (ra=0x41, neci=0x01, chreq_reason=0x02)
<0007> osmo_bsc_sigtran.c:305 Initializing resources for new SIGTRAN connection to MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP...
<0007> osmo_bsc_sigtran.c:351 Opening new SIGTRAN connection (id=31) to MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP
<0003> abis_rsl.c:1372 (bts=0) CHAN RQD: reason: answer to paging (ra=0x9b, neci=0x01, chreq_reason=0x01)
<0007> osmo_bsc_sigtran.c:305 Initializing resources for new SIGTRAN connection to MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP...
<0007> osmo_bsc_sigtran.c:351 Opening new SIGTRAN connection (id=32) to MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP
<0004> abis_nm.c:344 BTS 0 reported connected PCU version 0.8.0
<0016> input/ipaccess.c:411 Bad signalling message, sign_link returned error: Operation not permitted.
<0016> input/ipaccess.c:411 Bad signalling message, sign_link returned error: Operation not permitted.
WHat is this bad signalling message operation not permitted?
--
Mario Lucas
Dear baseband-developers team,
Would you be so kind to advise me on the following:
I desire (dramatically want very much) to learn / understand Osmocom projects.
I am a beginner in programming and i try to understand / learn C files that the project is build of.
As an example i tried to learn / understand for example an Osmocom message buffer — msgb.h file.
But immediately faced some syntax difficulties:
This is the extract of msgb.h file:
struct msgb {
struct llist_head list; /*!< \brief linked list header */
/* Part of which TRX logical channel we were received / transmitted */
/* FIXME: move them into the control buffer */
union {
void *dst; /*!< \brief reference of origin/destination */
struct gsm_bts_trx *trx;
};
As it can be seen a structure «msgb» has as one of its components another structure — «gsm_bts_trx»
But in whole Osmocom BB project files i could not find definition / description of struct «gsm_bts_trx».
Would you kindly advise me please how to see which components / constituents / elements are in this gsm_bts_trx structure?
From which components is struct gsm_bts_trx build of?
Thank you so much for your kind advise.
--
Mario Lucas
Dear all,
I am using LimeSDRmini to run osmo-bts…
During operation from time-to time (and sometimes quite frequently) following messages pop-up in terminal:
«Dropped packets by HW!» and «Dumping Stale bursts...»
I guess my LimeSDRmini is dropping some packets.
LimeSDRmini configuration is: Firmware 6, Hardware 3, Protocol1, Gateware 1.3.
Would you advise — may be there is more or less stable firmware version that to some extent is stable while working with Osmo-bts ?
Thanks
--
Mario Lucas
Dear baseband developers team,
I built home gsm network with Osmo-stp-msc-hlr-bsc-bts, osmo-trx limeSDR.
I managed and registered phones. I did send sms between each other.
However when i decided to make a call — i noticed following message in terminal: «PCU socket not connected, dropping message».
I searched on Osmocom web site and it is said that pcu socket is involved in GPRS things (i.e. in internet).
Therefore why does such message appears when i try to make simple call between two mobiles — it has nothing to do with GPRS…
And what would you advise me how to resolve this ?
P.S. initially when i was about to start osmo-bts-trx i got message «PCU L1 socket failed» and i just renamed the pcu_bts file to some other name and osmo-bts-trx started.
Thank you so much for your kind reply.
Best regards
--
Mario Lucas
Dear all,
Pls help me with the following issue: I want to run a transceiver having motorola c115…
i follow the procedure described in CalypsoBTS page : http://osmocom.org/projects/baseband/wiki/CalypsoBTS
without chainloader i get:
/home/ubuntu# /home/ubuntu/trx/src/host/osmocon/./osmocon -m c123xor -p /dev/ttyUSB0 /home/ubuntu/trx/src/target/firmware/board/compal_e88/trx.highram.bin
got 7 bytes from modem, data looks like: 66 74 6d 74 6f 6f 6c ftmtool
Received FTMTOOL from phone, ramloader has aborted
got 1 bytes from modem, data looks like: 65 e
got 1 bytes from modem, data looks like: c1 .
got 1 bytes from modem, data looks like: 66 f
and with chainloader i get:
/home/ubuntu# /home/ubuntu/trx/src/host/osmocon/./osmocon -m c123xor -p /dev/ttyUSB0 -c /home/ubuntu/trx/src/target/firmware/board/compal_e88/trx.highram.bin
got 2 bytes from modem, data looks like: 04 81 ..
got 5 bytes from modem, data looks like: 1b f6 02 00 41 ....A
got 1 bytes from modem, data looks like: 01 .
got 1 bytes from modem, data looks like: 40 @
Received PROMPT1 from phone, responding with CMD
read_file(chainloader): file_size=32, hdr_len=4, dnload_len=39
got 1 bytes from modem, data looks like: 00 .
it seems with chainloader it is trying to do more but still stuck….
pls help….
Mario
--
Mario Lucas
Dear fellow Osmocom developers,
as you all know, we've sadly had to postpone OsmoDevCon 2020 back in
April this year. At the time, we discussed to re-visit the situation
in October 2020.
While legally it is no problem at all to host an event with ~ 20
participants in Berlin/Germany (specific regulations really only start
from 50+ participants) - I'm not entirely convinced it would be the
smartest move.
Legality and public health regulations are only one part of the equation
- common sense and profound care for the key members of our community
for sure are more relevant considerations to me.
I'm not 100% in favour and not 100% against. Hence, I would like to get
your input. Should we
a) try to get an event organized on-site in Berlin? We'd have to move
to a larger venue than IN-Berlin with proper ventilation and sufficient
space so we can keep physical distance, but I think that's
manageable for sysmocom as organizer.
b) simply postpone to 2021? I'm convinced the situation will not change
significantly (in a positive way) until late April 2021, so it's not
really a "solution" as it will likely mean we have to think of late
2021 or 2022.
c) plan some kind of online conference? To be honest, I think this
model works fine for events where a single speaker wants to give
lectures to hundreds or thousands of participants. But OsmoDevCon
is much more interactive. We could record or live-stream some talks
or screencasts from home, sure. But that only captures one part of
the event. We could also try to set a date for a collaborative
mumble, or the like - for the "hallway track".
What are your thoughts? Let's avoid cross-posting the discussion to all
of the mailing lists and simply have it on openbsc(a)lists.osmocom.org.
Regards,
Harald
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
There is an urgent need to migrate our most important public
infrastructure to a new server, and I will be doing that on
*Sunday, July 19 2020*, starting about 9am CEST.
The migration involves redmine (main osmocom.org website), jenkins, gerrit,
git, and cgit.
In theory, the migration should be quick. I would expect (significantly)
less than one hour of downtime. However, we all know Murphys law.
Services not affected are mail (including mailman lists), ftp, dns. So in case
of doubt, we can still use mailing lists to communicate.
In case anyone urgently needs osmocom source code on Sunday morning
during the downtime: There are public mirrors available on github.
Regards,
Harald
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hello! During build OsmocomBB I have problem. When I do "make", I get
errors: *** No rule to make target `geo.c', needed by `geo.o'. Stop.
vgsm@vgsm:~/osmocom/osmocombb/src$ make nofirmware
make -C host/layer23
make[1]: Entering directory `/home/vgsm/osmocom/osmocombb/src/host/layer23'
Making all in include
make[2]: Entering directory
`/home/vgsm/osmocom/osmocombb/src/host/layer23/include'
Making all in osmocom
make[3]: Entering directory
`/home/vgsm/osmocom/osmocombb/src/host/layer23/include/osmocom'
Making all in bb
make[4]: Entering directory
`/home/vgsm/osmocom/osmocombb/src/host/layer23/include/osmocom/bb'
Making all in common
make[5]: Entering directory
`/home/vgsm/osmocom/osmocombb/src/host/layer23/include/osmocom/bb/common'
make[5]: Nothing to be done for `all'.
make[5]: Leaving directory
`/home/vgsm/osmocom/osmocombb/src/host/layer23/include/osmocom/bb/common'
Making all in misc
make[5]: Entering directory
`/home/vgsm/osmocom/osmocombb/src/host/layer23/include/osmocom/bb/misc'
make[5]: Nothing to be done for `all'.
make[5]: Leaving directory
`/home/vgsm/osmocom/osmocombb/src/host/layer23/include/osmocom/bb/misc'
Making all in mobile
make[5]: Entering directory
`/home/vgsm/osmocom/osmocombb/src/host/layer23/include/osmocom/bb/mobile'
make[5]: Nothing to be done for `all'.
make[5]: Leaving directory
`/home/vgsm/osmocom/osmocombb/src/host/layer23/include/osmocom/bb/mobile'
make[5]: Entering directory
`/home/vgsm/osmocom/osmocombb/src/host/layer23/include/osmocom/bb'
make[5]: Nothing to be done for `all-am'.
make[5]: Leaving directory
`/home/vgsm/osmocom/osmocombb/src/host/layer23/include/osmocom/bb'
make[4]: Leaving directory
`/home/vgsm/osmocom/osmocombb/src/host/layer23/include/osmocom/bb'
make[4]: Entering directory
`/home/vgsm/osmocom/osmocombb/src/host/layer23/include/osmocom'
make[4]: Nothing to be done for `all-am'.
make[4]: Leaving directory
`/home/vgsm/osmocom/osmocombb/src/host/layer23/include/osmocom'
make[3]: Leaving directory
`/home/vgsm/osmocom/osmocombb/src/host/layer23/include/osmocom'
make[3]: Entering directory
`/home/vgsm/osmocom/osmocombb/src/host/layer23/include'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory
`/home/vgsm/osmocom/osmocombb/src/host/layer23/include'
make[2]: Leaving directory
`/home/vgsm/osmocom/osmocombb/src/host/layer23/include'
Making all in src
make[2]: Entering directory
`/home/vgsm/osmocom/osmocombb/src/host/layer23/src'
Making all in common
make[3]: Entering directory
`/home/vgsm/osmocom/osmocombb/src/host/layer23/src/common'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory
`/home/vgsm/osmocom/osmocombb/src/host/layer23/src/common'
Making all in misc
make[3]: Entering directory
`/home/vgsm/osmocom/osmocombb/src/host/layer23/src/misc'
make[3]: *** No rule to make target `geo.c', needed by `geo.o'. Stop.
make[3]: Leaving directory
`/home/vgsm/osmocom/osmocombb/src/host/layer23/src/misc'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/home/vgsm/osmocom/osmocombb/src/host/layer23/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/vgsm/osmocom/osmocombb/src/host/layer23'
make: *** [layer23] Error 2
vgsm@vgsm:~/osmocom/osmocombb/src$
Hi all!
It is quite some time since it was brought to our attention that there's
an old Huawei module that also uses the Ti Calypso chipset and hence
can be used with OsmocomBB: The GTM-900B.
It's just a modem module with a FPC connector, so no easy to use interfaces
for any of the related signals, no SIM holder, etc.
At sysmocom we've finally found some time to do a carrier board design for this,
which will expose all the relevant signals (audio, UARTs, power, reset, ...).
Martin (Cc) is working on it right now.
The discussion regarding this breakout board can be followed at
https://osmocom.org/issues/4030
If you have any input, please provide it now, as we are trying to complete this design
by the end of the week so we can order prottoypes.
The actual design files (EAGLE) including a PDF export of the schematics can
be found in the osmo-small-hardware.git repository.
Thanks for your input.
Once the prototype is validated, we plan to make the boards (bundled with GTM900B)
available in the sysmocom webshop.
Regards,
Harald
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)