Dear team could you pls help me with this question
In bts config we have following entries:
trx 0
nominal power 23
! to use full TRX power, set max_power_red 0
max_power_red 20
and
osmotrx tx-attenuation (oml|<0-50>)
So why do we need these «max_power_red 20» and «osmotrx tx-attenuation» which both as i understand weaken the signal?
If we want to have a weak signal why we just don’t use only «nominal power» with whatever weak or strong signal value we want?
--
Mario Lucas
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)
Hello all,
I would like to add two (fake) mobiles by using the osmocomBB platform.
Can you help by indicating how or web pages where I can find useful information.
Actually I follow these instructions found here : https://osmocom.org/projects/baseband/wiki/FakeTRX
Thanks,
BR
MaGo
Dear fellow Osmocom developers,
I would like to invite all developers and contributors to Osmocom [sub]projects
to register for OsmoDevCon 2020 (held on April 24th-27th, 2020 in Berlin).
For details known so far, please check
http://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2020
Please enter your name at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2020#Requested
in case you would like to attend. Registering early allows proper
planning. Thanks!
Looking forward to meeting old and new Osmocom developers in April 2020.
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)
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.
Hi!
I install the project according to the instructions https://habr.com/en/company/pentestit/blog/331406/
A few months ago, the installation was successful, but this month an error related to osmo_sock_init2_multiaddr () occurs when building libosmo-netif.
The file "libosmo-netif / TODO-RELEASE" contains information:
"libosmo-netif stream osmo_sock_init2_multiaddr () is used, requires libosmocore> 1.2.0 (to be released)."
At the same time, the existing version of libosmocore is only 1.2.0
How to set up a project?
I tried using diff to return libosmo-netif to version 0.5.0.2-6563-dirty as described in http://git.osmocom.org/libosmo-netif/commit/?id=592057bb33dc0c336a63003cd7a…
but had no success.
--
Dimoon
I am installing OsmocomBB SDR PHY on ubunt 18.04 and i have
installedosmo-TRX, UHD Driver, Gr-gsm and Gnuradio from ubuntu package
manager.
but when i try to compile osmocomBB with TRX interface i got this problem:
on make
cd host/layer23 && autoreconf -i
/bin/sh: 1: autoreconf: not found
Makefile:91: recipe for target 'host/layer23/configure' failed
make: *** [host/layer23/configure] Error 127
Thank you for your time!!!1
Dear all,
I've been asked by a number of pepole about a possible Osmocom village at the
CCC Camp 2019. I personally didn't really have any plans, but given related
e-mails and "encouragement" I went ahead and registered an "Osmocom Village",
see
https://signup.c3assemblies.de/assembly/3b8f7aa2-95d5-4c44-aadc-de8f2680e9c3
I also created a wiki page (as nobody else did, despite earlier discussion on IRC,
SCNR) for coordinating related efforts at
https://osmocom.org/projects/osmo-dev-con/wiki/CCC_Camp_2019
One of the bigger questions is about having a tent as well as some tables/benches
to sit on and work. The Camp orga team nas been negotiating rates with a tent
rental company, but to be honest I'm rather surprised by the extremely steep
pricing. The smallest possible tent (6m x 3m) would cost 825 EUR. I'm not
sure we want to raise that amount of money? Even if we'd be 10 people sharing
it, its still 82.50 EUR per person. And that excludes any tables/chairs.
I'm attaching the relevant parts of a mail from the assemblies orga team FYI.
Please note there also is some kind of fragmentation / overlap with the
team planning to run the GSM/3G networks at the camp, see Lynxis'
related post at
https://lists.osmocom.org/mailman/private/osmocom-event-orga/2019-June/0003…
It's questionable whether it makes sense to have tow distinct
'villages', but given that e.g. I don't know anyone of that singularity
city, I'm not sure if we'd either be welcome there, nor whether we'd
want to associate us with them? Also, while the GSM network operation
for sure has good reasons to mingle with the POC and whatever facilities
they have, I'm not sure if the wider Osmocom community attendees
unrelated to the GSM network operation wouldn't just be a
disturbance/nuisance.
In the end, to be honest, I personally do not feel I have the time and
mental capacity to take on any additional tasks in terms of organizing
anything. I just created the entry in c3assemblies as I was asked to,
and I similarly created the related mailing list and wiki page.
So please, anyone interested in making an Osmocom village happen one way
or another, step up [and continue this discussion on the
camp2019-village(a)lists.osmocom.org mailing list, without crossposting
everywhere else :)
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 all!
sysmocom has obtained a first batch of 10 GTM-900B with some
FPC-to-2.54mm-breakout adapters from songbosi. They have just
arrived yesterday in Berlin. I'm happy to make them available
for free to [known/existing] Osmocom develoepers/contributors.
Let me know if you're interestd and we'll send you an envenlope, likely
mid next week due to the upcoming extended whitsunday weekend.
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,
I'm currently facing the problem of testing hand-over related channel-activation
in OsmoBTS. Three are various rules about how this has to be done, and a closer
look indicates that both osmo-bts-trx as well as osmo-bts-sysmo don't get that
right at all.
I'd like to write TTCN-3 tests as part of BTS_Tests.ttcn, which uses L1CTL
to control a (virtual or real) L1 for the MS side of testing the BTS.
To break this down to low-level requirements in terms of MS capabilities:
* switch to a different ARFCN
* switch to a speciifed timeslot
* change the synchroniztaion (in terms of where we currently are in the TDMA
multiplex) to a given neighbor cell. The MS will have performed neighbor
measurements before, and as part of that will hav received FCCH + SCH and
hence know the timing both in terms of carrier freq as well as TDMA position
[none of this is relevant for a fake_trx + trxcon setup]
* ability to enable only the receiver for the main channel (SDCCH/FACCH), but
suppress any reception (or passing up of received) SACCH.
* ability to transmit RACH burst[s] in uplink on that new dedicated channel
* ability to later on enable full Rx/Tx of all logical channels on that dedicated
channel
I've looked at the jolly/handover branch from 2013, and rebased that on top of current
master, the result can be seen in laforge/jolly_handover_rebase
Change-Id Iadbc47f006d1f8a019822aedee180814de13cb2d specifically adds new flags
to DM_EST_REQ to
* disable uplink transmission
* use the sync information of a neighbor cell
I would like to get at least that change to L1CTL merged to master, and while
doing that, update all implementations of L1CTL at the same time. It may make
sense to also merge Change-Id I792b52d9bf115a2def9720eed3d62982d8cdbe00 while
at it, which is required for neighbor channel measurements + reporting.
We should also use that opportunity to introduce some kind of versioning support
to L1CTL, to ensure future extensions of the protocol can be made in a way where
incompatibility can at least be detected at runtime.
Now the next question is how to this will impact trxcon/fake_trx. AFAICT,
there is a comment in trxcon hinting that the TRX TUNE comamnd of a DM_EST_REQ
would fail if there was already and established channel before. Is that correct?
If so, what is the suggested/recommended way to get trxcon to support at least
the minimum of what's required for handover in a virtual environment?
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)
Hello every one:
I am making a FAKE BTS defender(DOS of fake bts) since Jul 2017.
This product is used to detect and attack the fake GSM station(running openbts).
I use c118 at first and it work fine. But c118 is not a good idea for production.
I have disassembled many old GPRS modules , at last I found this module is perfect(D751749ZHH). Now I have 500 pcs left
This module have TCK/TMS/TDO/TDI ,I make a custom OsmocomBB firmware , only need modify some IO control for RF switch, there are some picture to share with you.
OsmocomBB is running on an ARM board
You can mail me 79543015(a)qq.com , if you are interested in this :P
Hi im doing this article.
https://bastienbaranoff.wordpress.com/2018/08/10/gsm-base-station-with-two-…
But this error comes at shell #4
root@kali:~# osmo-nitb -c ~/.osmocom/open-bsc.cfg -l ~/.osmocom/hlr.sqlite3
-P -m -C --debug=DRLL:DCC:DMM:DRR:DRSL:DNM
There is no such command.
Error occurred during reading the below line:
timer t3103 0
<0005> bsc_init.c:551 Failed to parse the config file:
'/root/.osmocom/open-bsc.cfg'
Reading config failed. Exiting.
What should i fix it ?
How to do this command. Im following this article.
https://bastienbaranoff.wordpress.com/2018/08/10/gsm-base-station-with-two-…
root@kali:~# osmo-bts-trx -c ~/.osmocom/osmo-bts.cfg -r 99
((*))
|
/ \ OsmoBTS
There is no such command.
Error occurred during reading the below line:
band GSM900
Failed to parse the config file: '/root/.osmocom/osmo-bts.cfg'
*What should I do?*
Im following this article. These errors given. I wanna do this command.
https://bastienbaranoff.wordpress.com/2018/08/10/gsm-base-station-with-two-…
*Shell #3*
# cd trx/src/host/layer23/src/transceiver/
# sudo ./transceiver -a [YOUR ARFCN FOUND WITH RSSI] -2 -r 99
This command doesnt work in trx folder. (kali 18.1)
rot@kali:~/trx/src/host/layer23/src/transceiver# make
CCLD transceiver
/usr/bin/ld: gmsk.o: in function `osmo_gmsk_free':
/root/trx/src/host/layer23/src/transceiver/gmsk.c:83: undefined reference
to `osmo_cxvec_free'
/usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:85:
undefined reference to `osmo_cxvec_free'
/usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:87:
undefined reference to `osmo_cxvec_free'
/usr/bin/ld: gmsk.o: in function `osmo_gmsk_generate_pulse':
/root/trx/src/host/layer23/src/transceiver/gmsk.c:110: undefined reference
to `osmo_cxvec_alloc'
/usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:123:
undefined reference to `expf'
/usr/bin/ld: gmsk.o: in function `osmo_gmsk_generate_rotation_tables':
/root/trx/src/host/layer23/src/transceiver/gmsk.c:145: undefined reference
to `osmo_cxvec_alloc'
/usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:146:
undefined reference to `osmo_cxvec_alloc'
/usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:153:
undefined reference to `cexp'
/usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:153:
undefined reference to `cexp'
/usr/bin/ld: gmsk.o: in function `osmo_gmsk_generate_pulse':
/root/trx/src/host/layer23/src/transceiver/gmsk.c:128: undefined reference
to `sqrtf'
/usr/bin/ld: gmsk.o: in function `osmo_gmsk_modulate_burst':
/root/trx/src/host/layer23/src/transceiver/gmsk.c:209: undefined reference
to `osmo_cxvec_alloc'
/usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:227:
undefined reference to `osmo_cxvec_convolve'
/usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:230:
undefined reference to `osmo_cxvec_free'
/usr/bin/ld: gmsk.o: in function `osmo_gmsk_trainseq_generate':
/root/trx/src/host/layer23/src/transceiver/gmsk.c:256: undefined reference
to `osmo_cxvec_correlate'
/usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:260:
undefined reference to `osmo_cxvec_peak_energy_find'
/usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:265:
undefined reference to `osmo_cxvec_free'
/usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:272:
undefined reference to `osmo_cxvec_free'
/usr/bin/ld: gmsk.o: in function `osmo_gmsk_trainseq_free':
/root/trx/src/host/layer23/src/transceiver/gmsk.c:286: undefined reference
to `osmo_cxvec_free'
/usr/bin/ld: gsm_ab.o: in function `gsm_ab_detect':
/root/trx/src/host/layer23/src/transceiver/gsm_ab.c:53: undefined reference
to `osmo_cxvec_correlate'
/usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gsm_ab.c:57:
undefined reference to `osmo_cxvec_peak_energy_find'
/usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gsm_ab.c:67:
undefined reference to `osmo_cxvec_free'
/usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gsm_ab.c:67:
undefined reference to `osmo_cxvec_free'
/usr/bin/ld: gsm_ab.o: in function `gsm_ab_demodulate':
/root/trx/src/host/layer23/src/transceiver/gsm_ab.c:90: undefined reference
to `osmo_cxvec_scale'
/usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gsm_ab.c:91:
undefined reference to `osmo_cxvec_delay'
/usr/bin/ld: demod.o: in function `gsm_ab_ind_process':
/root/trx/src/host/layer23/src/transceiver/demod.c:51: undefined reference
to `osmo_cxvec_alloc'
/usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/demod.c:62:
undefined reference to `osmo_cxvec_sig_normalize'
/usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/demod.c:70:
undefined reference to `cabsf'
/usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/demod.c:76:
undefined reference to `cabsf'
/usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/demod.c:101:
undefined reference to `osmo_cxvec_free'
collect2: error: ld returned 1 exit status
make: *** [Makefile:360: transceiver] Error 1
How to build transceiver file ?
*root@bilguun-shady:~/Desktop/trx/src# make
HOST_layer23_CONFARGS=--enable-transceiver*
There is another problem on building trx. Im doing this article step by
step.
In this command there comes into that error.
make[3]: Entering directory
'/home/bilguun/Desktop/trx/src/host/layer23/src/mobile'
CC gsm322.o
gsm322.c: In function ‘gsm322_cs_select’:
gsm322.c:1865:3: warning: ‘gsm_arfcn2band’ is deprecated (declared at
/usr/local/include/osmocom/gsm/gsm_utils.h:164): Use gsm_arfcn2band_rc()
instead [-Wdeprecated-declarations]
band = gsm_arfcn2band(index2arfcn(i));
^
gsm322.c: In function ‘gsm322_search_end’:
gsm322.c:2055:30: warning: variable ‘mnc’ set but not used
[-Wunused-but-set-variable]
int tune_back = 0, mcc = 0, mnc = 0;
^
gsm322.c: In function ‘gsm322_nb_check’:
gsm322.c:4196:3: warning: ‘gsm_arfcn2band’ is deprecated (declared at
/usr/local/include/osmocom/gsm/gsm_utils.h:164): Use gsm_arfcn2band_rc()
instead [-Wdeprecated-declarations]
band = gsm_arfcn2band(nb->arfcn);
^
gsm322.c: In function ‘gsm322_nb_new_rxlev’:
gsm322.c:4693:2: warning: ‘gsm_arfcn2band’ is deprecated (declared at
/usr/local/include/osmocom/gsm/gsm_utils.h:164): Use gsm_arfcn2band_rc()
instead [-Wdeprecated-declarations]
int band = gsm_arfcn2band(cs->arfcn);
^
gsm322.c: In function ‘gsm322_exit’:
gsm322.c:5142:7: warning: variable ‘rc’ set but not used
[-Wunused-but-set-variable]
int rc;
^
In file included from /usr/include/string.h:635:0,
from gsm322.c:25:
In function ‘memset’,
inlined from ‘bargraph.constprop’ at gsm322.c:325:2:
/usr/include/i386-linux-gnu/bits/string3.h:86:7: warning: call to
‘__warn_memset_zero_len’ declared with attribute warning: memset used with
constant zero length parameter; this could be due to transposed parameters
__warn_memset_zero_len ();
^
CC gsm480_ss.o
gsm480_ss.c: In function ‘gsm480_tx_ussd’:
gsm480_ss.c:535:2: warning: ‘gsm_7bit_encode’ is deprecated (declared at
/usr/local/include/osmocom/gsm/gsm_utils.h:242): Use gsm_7bit_encode_n()
instead [-Wdeprecated-declarations]
length = gsm_7bit_encode(msg->data, text);
^
gsm480_ss.c: In function ‘gsm480_rx_ussd’:
gsm480_ss.c:779:2: warning: ‘gsm_7bit_decode’ is deprecated (declared at
/usr/local/include/osmocom/gsm/gsm_utils.h:240): Use gsm_7bit_decode_n()
instead [-Wdeprecated-declarations]
gsm_7bit_decode(text, tag_data, num_chars);
^
gsm480_ss.c: In function ‘gsm480_mmss_ind’:
gsm480_ss.c:1221:6: warning: variable ‘rc’ set but not used
[-Wunused-but-set-variable]
int rc = 0;
^
CC gsm411_sms.o
gsm411_sms.c: In function ‘sms_from_text’:
gsm411_sms.c:116:2: warning: ‘gsm_7bit_encode’ is deprecated (declared at
/usr/local/include/osmocom/gsm/gsm_utils.h:242): Use gsm_7bit_encode_n()
instead [-Wdeprecated-declarations]
sms->user_data_len = gsm_7bit_encode(sms->user_data, sms->text);
^
gsm411_sms.c: In function ‘gsm340_rx_tpdu’:
gsm411_sms.c:285:4: warning: ‘gsm_7bit_decode’ is deprecated (declared at
/usr/local/include/osmocom/gsm/gsm_utils.h:240): Use gsm_7bit_decode_n()
instead [-Wdeprecated-declarations]
gsm_7bit_decode(gsms->text, smsp, gsms->user_data_len);
^
gsm411_sms.c:228:19: warning: variable ‘sms_mms’ set but not used
[-Wunused-but-set-variable]
uint8_t sms_mti, sms_mms;
^
gsm411_sms.c: In function ‘gsm411_rx_rp_ud’:
gsm411_sms.c:375:2: warning: format ‘%li’ expects argument of type ‘long
int’, but argument 7 has type ‘int’ [-Wformat=]
LOGP(DLSMS, LOGL_INFO, "TPDU(%li,%s)\n", msg->tail-msg->l4h,
^
gsm411_sms.c:375:2: warning: format ‘%li’ expects argument of type ‘long
int’, but argument 7 has type ‘int’ [-Wformat=]
CC gsm48_cc.o
CC gsm48_mm.o
gsm48_mm.c: In function ‘decode_network_name’:
gsm48_mm.c:269:2: warning: ‘gsm_7bit_decode’ is deprecated (declared at
/usr/local/include/osmocom/gsm/gsm_utils.h:240): Use gsm_7bit_decode_n()
instead [-Wdeprecated-declarations]
gsm_7bit_decode(name, lv + 2, length);
^
gsm48_mm.c: In function ‘gsm48_mmr_dequeue’:
gsm48_mm.c:780:20: warning: variable ‘mmr’ set but not used
[-Wunused-but-set-variable]
struct gsm48_mmr *mmr;
^
gsm48_mm.c: In function ‘gsm48_mm_conn_go_dedic’:
gsm48_mm.c:3252:25: warning: variable ‘nmmh’ set but not used
[-Wunused-but-set-variable]
struct gsm48_mmxx_hdr *nmmh;
^
gsm48_mm.c: In function ‘gsm48_mm_sync_ind_active’:
gsm48_mm.c:3333:25: warning: variable ‘nmmh’ set but not used
[-Wunused-but-set-variable]
struct gsm48_mmxx_hdr *nmmh;
^
gsm48_mm.c: In function ‘gsm48_rcv_rr_sapi3’:
gsm48_mm.c:3603:28: warning: variable ‘nmmh’ set but not used
[-Wunused-but-set-variable]
struct gsm48_mmxx_hdr *nmmh;
^
CC gsm48_rr.o
gsm48_rr.c: In function ‘gsm48_rr_tx_rand_acc’:
gsm48_rr.c:1668:3: warning: ‘gsm_arfcn2band’ is deprecated (declared at
/usr/local/include/osmocom/gsm/gsm_utils.h:164): Use gsm_arfcn2band_rc()
instead [-Wdeprecated-declarations]
LOGP(DRR, LOGL_INFO, "Use alternative tx-power %d (%d dBm)\n",
^
gsm48_rr.c:1668:3: warning: ‘gsm_arfcn2band’ is deprecated (declared at
/usr/local/include/osmocom/gsm/gsm_utils.h:164): Use gsm_arfcn2band_rc()
instead [-Wdeprecated-declarations]
gsm48_rr.c:1676:4: warning: ‘gsm_arfcn2band’ is deprecated (declared at
/usr/local/include/osmocom/gsm/gsm_utils.h:164): Use gsm_arfcn2band_rc()
instead [-Wdeprecated-declarations]
LOGP(DRR, LOGL_INFO, "Use MS-TXPWR-MAX-CCH power value "
^
gsm48_rr.c:1676:4: warning: ‘gsm_arfcn2band’ is deprecated (declared at
/usr/local/include/osmocom/gsm/gsm_utils.h:164): Use gsm_arfcn2band_rc()
instead [-Wdeprecated-declarations]
gsm48_rr.c:1683:4: warning: ‘gsm_arfcn2band’ is deprecated (declared at
/usr/local/include/osmocom/gsm/gsm_utils.h:164): Use gsm_arfcn2band_rc()
instead [-Wdeprecated-declarations]
LOGP(DRR, LOGL_INFO, "Use MS-TXPWR-MAX-CCH power value "
^
gsm48_rr.c:1683:4: warning: ‘gsm_arfcn2band’ is deprecated (declared at
/usr/local/include/osmocom/gsm/gsm_utils.h:164): Use gsm_arfcn2band_rc()
instead [-Wdeprecated-declarations]
gsm48_rr.c: In function ‘gsm48_rr_tx_meas_rep’:
gsm48_rr.c:2736:53: warning: variable ‘multi_rep’ set but not used
[-Wunused-but-set-variable]
uint8_t rep_ba = 0, rep_valid = 0, meas_valid = 0, multi_rep = 0;
^
gsm48_rr.c: At top level:
gsm48_rr.c:813:13: warning: ‘start_rr_t3124’ defined but not used
[-Wunused-function]
static void start_rr_t3124(struct gsm48_rrlayer *rr, int sec, int micro)
^
CC mnccms.o
CC settings.o
CC subscriber.o
subscriber.c: In function ‘gsm_subscr_generate_kc’:
subscriber.c:947:4: warning: ‘comp128’ is deprecated (declared at
/usr/local/include/osmocom/gsm/comp128.h:22): Use generic API from
osmocom/crypt/auth.h instead [-Wdeprecated-declarations]
comp128(set->test_ki, rand, sres, subscr->key);
^
CC support.o
CC transaction.o
CC vty_interface.o
vty_interface.c: In function ‘ms_vty_init’:
vty_interface.c:2840:2: warning: ‘install_default’ is deprecated (declared
at /usr/local/include/osmocom/vty/command.h:364): Now happens implicitly
with install_node() [-Wdeprecated-declarations]
install_default(MS_NODE);
^
vty_interface.c:2885:2: warning: ‘install_default’ is deprecated (declared
at /usr/local/include/osmocom/vty/command.h:364): Now happens implicitly
with install_node() [-Wdeprecated-declarations]
install_default(SUPPORT_NODE);
^
vty_interface.c:2943:2: warning: ‘install_default’ is deprecated (declared
at /usr/local/include/osmocom/vty/command.h:364): Now happens implicitly
with install_node() [-Wdeprecated-declarations]
install_default(TESTSIM_NODE);
^
CC voice.o
CC mncc_sock.o
AR libmobile.a
ar: `u' modifier ignored since `D' is the default (see `U')
CC main.o
main.c: In function ‘main’:
main.c:220:2: warning: ‘msgb_set_talloc_ctx’ is deprecated (declared at
/usr/local/include/osmocom/core/msgb.h:734): Use msgb_talloc_ctx_init()
instead [-Wdeprecated-declarations]
msgb_set_talloc_ctx(l23_ctx);
^
CC app_mobile.o
app_mobile.c:376:2: warning: initialization from incompatible pointer type
.go_parent_cb = ms_vty_go_parent,
^
app_mobile.c:376:2: warning: (near initialization for
‘vty_info.go_parent_cb’)
CCLD mobile
libmobile.a(gsm322.o): In function `memset':
/usr/include/i386-linux-gnu/bits/string3.h:86: undefined reference to
`__warn_memset_zero_len'
collect2: error: ld returned 1 exit status
Makefile:379: recipe for target 'mobile' failed
make[3]: *** [mobile] Error 1
make[3]: Leaving directory
'/home/bilguun/Desktop/trx/src/host/layer23/src/mobile'
Makefile:325: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/home/bilguun/Desktop/trx/src/host/layer23/src'
Makefile:350: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/bilguun/Desktop/trx/src/host/layer23'
Makefile:51: recipe for target 'layer23' failed
make: *** [layer23] Error 2
What should i do ?
How to make this command ?
Im doing this article. Also installed all those libraries. But cannot build
transceiver file. Im installed libosmo-dsp.
https://www.smartspate.com/how-to-create-2g-network-at-your-own-home/
root@bilguun-shady:~/Desktop/trx/src/host/layer23/src/transceiver# make
install
CCLD transceiver
gmsk.o: In function `osmo_gmsk_free':
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:83:
undefined reference to `osmo_cxvec_free'
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:85:
undefined reference to `osmo_cxvec_free'
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:87:
undefined reference to `osmo_cxvec_free'
gmsk.o: In function `osmo_gmsk_generate_pulse':
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:110:
undefined reference to `osmo_cxvec_alloc'
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:123:
undefined reference to `expf'
gmsk.o: In function `osmo_gmsk_generate_rotation_tables':
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:145:
undefined reference to `osmo_cxvec_alloc'
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:146:
undefined reference to `osmo_cxvec_alloc'
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:153:
undefined reference to `cexp'
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:153:
undefined reference to `cexp'
gmsk.o: In function `osmo_gmsk_generate_pulse':
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:128:
undefined reference to `sqrtf'
gmsk.o: In function `osmo_gmsk_modulate_burst':
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:209:
undefined reference to `osmo_cxvec_alloc'
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:227:
undefined reference to `osmo_cxvec_convolve'
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:230:
undefined reference to `osmo_cxvec_free'
gmsk.o: In function `osmo_gmsk_trainseq_generate':
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:256:
undefined reference to `osmo_cxvec_correlate'
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:260:
undefined reference to `osmo_cxvec_peak_energy_find'
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:265:
undefined reference to `osmo_cxvec_free'
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:272:
undefined reference to `osmo_cxvec_free'
gmsk.o: In function `osmo_gmsk_trainseq_free':
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:286:
undefined reference to `osmo_cxvec_free'
gsm_ab.o: In function `gsm_ab_detect':
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gsm_ab.c:53:
undefined reference to `osmo_cxvec_correlate'
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gsm_ab.c:57:
undefined reference to `osmo_cxvec_peak_energy_find'
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gsm_ab.c:67:
undefined reference to `osmo_cxvec_free'
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gsm_ab.c:67:
undefined reference to `osmo_cxvec_free'
gsm_ab.o: In function `gsm_ab_demodulate':
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gsm_ab.c:90:
undefined reference to `osmo_cxvec_scale'
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gsm_ab.c:91:
undefined reference to `osmo_cxvec_delay'
demod.o: In function `gsm_ab_ind_process':
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/demod.c:51:
undefined reference to `osmo_cxvec_alloc'
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/demod.c:62:
undefined reference to `osmo_cxvec_sig_normalize'
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/demod.c:70:
undefined reference to `cabsf'
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/demod.c:76:
undefined reference to `cabsf'
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/demod.c:101:
undefined reference to `osmo_cxvec_free'
collect2: error: ld returned 1 exit status
Makefile:355: recipe for target 'transceiver' failed
make: *** [transceiver] Error 1
What should i do ?
*cd /root/osmocom/trx/src/host/layer23/src/transceiver/*
*./transceiver -a ARFCN -2 -r 99*
*I want to write this command. But it didnt have any transceiver file on
this. I write make command but it seems so many error*
root@bilguun-shady:~/Desktop/trx/src/host/layer23/src/transceiver# make
CCLD transceiver
gmsk.o: In function `osmo_gmsk_free':
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:83:
undefined reference to `osmo_cxvec_free'
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:85:
undefined reference to `osmo_cxvec_free'
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:87:
undefined reference to `osmo_cxvec_free'
gmsk.o: In function `osmo_gmsk_generate_pulse':
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:110:
undefined reference to `osmo_cxvec_alloc'
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:123:
undefined reference to `expf'
gmsk.o: In function `osmo_gmsk_generate_rotation_tables':
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:145:
undefined reference to `osmo_cxvec_alloc'
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:146:
undefined reference to `osmo_cxvec_alloc'
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:153:
undefined reference to `cexp'
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:153:
undefined reference to `cexp'
gmsk.o: In function `osmo_gmsk_generate_pulse':
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:128:
undefined reference to `sqrtf'
gmsk.o: In function `osmo_gmsk_modulate_burst':
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:209:
undefined reference to `osmo_cxvec_alloc'
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:227:
undefined reference to `osmo_cxvec_convolve'
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:230:
undefined reference to `osmo_cxvec_free'
gmsk.o: In function `osmo_gmsk_trainseq_generate':
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:256:
undefined reference to `osmo_cxvec_correlate'
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:260:
undefined reference to `osmo_cxvec_peak_energy_find'
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:265:
undefined reference to `osmo_cxvec_free'
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:272:
undefined reference to `osmo_cxvec_free'
gmsk.o: In function `osmo_gmsk_trainseq_free':
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:286:
undefined reference to `osmo_cxvec_free'
gsm_ab.o: In function `gsm_ab_detect':
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gsm_ab.c:53:
undefined reference to `osmo_cxvec_correlate'
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gsm_ab.c:57:
undefined reference to `osmo_cxvec_peak_energy_find'
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gsm_ab.c:67:
undefined reference to `osmo_cxvec_free'
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gsm_ab.c:67:
undefined reference to `osmo_cxvec_free'
gsm_ab.o: In function `gsm_ab_demodulate':
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gsm_ab.c:90:
undefined reference to `osmo_cxvec_scale'
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gsm_ab.c:91:
undefined reference to `osmo_cxvec_delay'
demod.o: In function `gsm_ab_ind_process':
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/demod.c:51:
undefined reference to `osmo_cxvec_alloc'
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/demod.c:62:
undefined reference to `osmo_cxvec_sig_normalize'
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/demod.c:70:
undefined reference to `cabsf'
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/demod.c:76:
undefined reference to `cabsf'
/home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/demod.c:101:
undefined reference to `osmo_cxvec_free'
collect2: error: ld returned 1 exit status
Makefile:355: recipe for target 'transceiver' failed
make: *** [transceiver] Error 1
What should i do ?
In this command there is something wrong. Im using motorola c118.
Command : ./osmocon -m c123xor -p /dev/ttyUSB1 -s /tmp/osmocom l2 -c
target/firmware/board/compal_e88/trx.highram.bin
Received PROMPT2 from phone, starting download
handle_write(): 39 bytes (39/39)
handle_write(): finished
got 1 bytes from modem, data looks like: 1b .
got 1 bytes from modem, data looks like: f6 .
got 1 bytes from modem, data looks like: 02 .
got 1 bytes from modem, data looks like: 00 .
got 1 bytes from modem, data looks like: 41 A
got 1 bytes from modem, data looks like: 03 .
got 1 bytes from modem, data looks like: 42 B
Received DOWNLOAD ACK from phone, your code is running now!
Enabled Compal ramloader -> Calypso romloader chainloading mode
Received ident ack from phone, sending parameter sequence
opening file: No such file or directory
what was the problem ?
Hello OBB gang,
The Potential Calypso Targets page in your wiki lists a whole bunch of
phones with Silabs Aero II (Si4210) RF transceivers:
http://projects.osmocom.org/projects/baseband/wiki/PotentialCalypsoTargets
I wonder, has anyone ever succeeded in finding a datasheet for this
transceiver? I found the datasheet for the older Aero+ transceiver
(a 3-chip solution), but not for the single-chip Aero II aka Si4210.
Here are the Silabs Aero materials I have found so far:
ftp://ftp.freecalypso.org/pub/GSM/Silabs/
I got the marketing briefs for Aero+ and for Aero II, and the full
technical datasheet for the former of the two. If anyone has a
datasheet for Si4210 and would be willing to share it, I will gladly
add it to the above collection.
In the interest of full disclosure, if I get a hold of this datasheet,
adding it to the above FTP archive may be all that I will ever do with
it: even if I had the datasheet, I do not currently have any realistic
plans of adding Silabs Aero RF support to FreeCalypso, let alone to
OBB. I do have a couple of Motorola W220 phones on their way to me
from ebay, and hopefully at least one of them will actually make it to
me, unlike the first one that appears to have fallen into a black hole
somewhere, but even with ideal documentation (full schematics and chip
datasheets), adding support for a very different RF subsystem (in
particular, Silabs' way of doing AGC is entirely different from TI's
way) would require more systems engineering work than I can do at the
moment. It also doesn't help that the only tpudrv12.c reference TPU
driver we have is a reconstructed source made from the disassembly of
tpudrv12.obj, not TI's original source - thus all quarter-bit timing
numbers (there are lots of them, and they are very critical) are just
"magic" numbers, and their original derivation has been lost - does
not bode well for the task of figuring out what the corresponding
timings should be for a different RF transceiver.
All that being said, however, this Si4210 transceiver does look like
an attractive alternative to TI's Rita: the Si4210 is 5x5 mm compared
to TI's 7x7 mm (every square mm counts in a tightly squeezed modem
module), and it has 4 separate LNA inputs for the 4 GSM bands, to be
contrasted with Rita and Aero+ arrangement of 3 LNA inputs, one of
which is shared between EGSM and GSM850. The Si4210 way with 4
separate LNA inputs allows a fully quadband MS to be implemented in a
much more straightforward way. Thus tracking down a datasheet for
this Silabs Aero II transceiver and adding it to the knowledge base
should be a good step for the GSM enthusiast community as a whole.
I already tried asking Silabs for the datasheet, and got the answer
that the product line in question was sold to NXP back in 2007.
Reading up on Wikipedia, it appears that this stuff did not stay long
with NXP either, transferred first to ST-NXP Wireless and then to
ST-Ericsson, and when the latter closed, it is totally unclear where
the Silabs Aero stuff went, other than the great bit bucket in the
sky. :-(
M~
Hello again OBB folks,
In light of my discovery two days ago through CMU200 testing that
current OBB on all Calypso devices (with or without my OS#3582 patch)
produces grossly incorrect (spec-violating) radio transmissions, I am
making the following offer to your gang in the case that any of you
are interested in doing the work to fix your software and bring its
radio transmissions into compliance. The offer is: if there is anyone
in this so-called "community" who (a) has a CMU200 instrument or is
willing to invest into buying one and getting it properly calibrated,
and (b) is willing to do the major work of bringing OBB's radio
transmissions into compliance as verified with that CMU200 instrument,
then I am willing to send that person a fully tested, fully working
and properly calibrated FCDEV3B GSM MS board free of cost.
To recap, the areas in which OBB's radio transmissions were found to
be non-compliant in my CMU200 tests last Saturday are as follows:
1) At least in the test scenario when the CMU200 instrument acting as
a BTS makes a call to the connected MS, OBB's implementation of GSM MS
transmits at each band's maximum power level instead of the lower
power level commanded by the CMU acting as the BTS.
2) When the CMU200 commands the connected MS to change its Tx power
level, OBB's implementation of GSM MS does not act on these commands.
3) Even when the MS Tx power level is set to each band's maximum on
the CMU200 before initiating the call to the MS and not changed
afterward, the power ramp put out by OBB is flagged by the CMU as
being out of tolerance - despite the OS#3582 patch which makes OBB use
the same Tx ramp template bits as the official FreeCalypso and
Motorola firmwares (I tested on both hw platforms), or FreeCalypso fw
on Motorola's hw, all of which produce perfectly compliant power ramps
as deemed by the CMU200.
4) Without the OS#3582 patch, not only the power ramp but also the
power level itself is out of tolerance.
I do not see how anyone could address these defects without having
their own CMU200 instrument so they can reproduce the problem first,
and see the same thing I am seeing, which is why I am limiting my
FCDEV3B offer only to those who have a CMU200 or are willing to invest
in one. Furthermore, I also know from first-hand experience that many
CMU200 units that sell on ebay for cheap may be defective in very
subtle and non-obvious ways, or may have been subjected to repairs or
repair attempts in less than fully diligent ways. Therefore, unless
you bought your CMU200 from a high-end seller who sells it with a
recent calibration certificate and with all case seals from the
calibration lab intact, the only way to know for sure if the
instrument's measurements are trustworthy is to send it to your
nearest Rohde&Schwarz office for calibration, which costs about $1400
at least at the Columbia, Maryland (USA) office, which is where I had
mine calibrated.
For the above reasons, I further limit my free-of-cost FCDEV3B offer
to those who not just own a CMU200 instrument in some unknown
condition, but are also able to present a recent calibration
certificate for it. (And don't even think about faking one, as I know
what real ones look like - I got my own.) You will also need to have
an N-to-SMA RF cable with precisely known insertion loss at GSM
frequencies (at the center frequency of each uplink and downlink band,
8 frequencies in total), i.e., you need to demonstrate sufficient RF
knowledge to compute a good estimate for these insertion loss numbers
if you don't have access to a VNA to measure them directly.
(In case it isn't already obvious, let me spell it out: producing your
own GSM MS implementation that is safe to use on public airwaves does
require spending a non-trivial amount of money on proper test
equipment.)
If you have the necessary test equipment as above and are interested
in getting a free-of-cost FCDEV3B, you will need to further agree to
do the following upon receiving the board:
1) Connect the FCDEV3B to your CMU200 while the board still runs its
official FreeCalypso fw, and confirm with your own eyes and your own
CMU200 that all RF transmissions put out by the FreeCalypso hw+fw
combo satisfy all of the compliance tests.
2) Run OBB on the same FCDEV3B still connected to your CMU200, and
confirm with your own eyes and your own CMU200 that OBB's transmissions
exhibit the same problems which I see in my test setup.
3) Work toward bringing OBB's RF transmissions into compliance as seen
by the CMU200, i.e., toward being like what the official FreeCalypso
fw puts out.
The tests performed by the CMU200 are the exact same ones which are
performed by official certification labs on candidate GSM MS devices
submitted for type approval testing; I don't know exactly what
equipment those labs use, but I wouldn't be surprised if it is the
very same CMU200 at least for the low-level tests, plus something else
(a real BTS maybe) for higher-level GSM L3 protocol tests.
Aside from the just-detailed offer of a free-of-cost board to whoever
is willing to do the above work and has the necessary setup, I am now
restricting sales of FCDEV3B hardware to OBB users. If anyone is
interested in buying an FCDEV3B for the purpose of running OBB on it,
I will only sell it to you if you can demonstrate that you have one of
the following 3 acceptable setups:
Option 1: a CMU200 or some other instrument acting as a base station
simulator;
Option 2: your own BTS plus all of the numerous pieces which are
required in order to connect an MS directly to a BTS with a cabled
setup without any radiated transmissions;
Option 3: your own BTS plus a solid RF-blocking enclosure (reliably
blocking any leakage) that is big enough to fit both your BTS and
your MS.
If I were to sell a board to an OBB user who does not have any of the
above, then I would be helping facilitate willful interference and
disruption of public radio communication networks, and could
potentially be held liable for whatever damage you will cause by
letting OBB transmit on GSM frequencies in open air, so nope, sorry,
won't do.
And finally let me pre-emptively address one very likely response: if
someone says "why don't you, Mychaela, do the work of bringing OBB's
radio transmissions into compliance and contribute code patches, given
that you already have all of the needed high-end test equipment", my
answer is that this work can only be done by someone who believes that
investing effort into further development of OsmocomBB is the right
thing to do, which is a position I disagree with - instead I believe
that OBB (or at least OBB on Calypso, no opinion regarding OBB on SDR
or the floating-around vaporware idea of OBB on MTK) should be
deprecated from use and retired to the dustbin of history as a failed
project that may have been interesting and may have had some merit at
one time, but is now completely pointless.
Sincerely,
Mychaela Falconia,
Mother of FreeCalypso
www.freecalypso.org
Oops, I accidentally replied to Mychaela directly, here's our conversation so far, please others join in
with thoughts.
On Sun, Mar 10, 2019 at 09:09:31AM -0800, Mychaela Falconia wrote:
> Hi Craig,
>
> > Thanks again for your details Mychaela. I will read this very carefully
> > and keep it in mind as I try to port osmocom-bb to fernvale/mediatek.
> > I already expect a good dose of refactoring in layer1 so maybe I will touch
> > on fixing the issue.
>
> Have you got yourself a CMU200 instrument or not yet? A CMU200 is
> absolutely required if you wish to have any chance of success at your
> idea of OBB on MTK.
I do have a Racal Instruments 6103E GSM Digital Radio Test Set which seems to
work well so far. I have tested some SIM800 modules (mtk6261) with the internal
BTS. Not sure if that will fall short or not but I'll take things one step at
a time. When I need a CMU200 I'll probably get one. :)
> Another question: is there any way to run any official MTK-based
> firmware, however non-free and blob-laden it may be, on Fernvale hw?
Probably. I know from reading that Bunnie and Xobs who designed fernvale did
run standard firmware/OS on some similar 6260 based devices. Maybe we could
track down a good firmware and test on fernvale.
For what it's worth the fernvale isn't exactly my main target. I would much rather
use a SIM800 module or eventually design of my own.
> Has anyone actually done it and posted howto instructions? If not,
> then how do you know if the RF hw on your Fernvale kit is actually any
> good and not physically defective? Whoever physically manufactured
> those Fernvale boards sold by Sysmocom, have they actually tested
> their RF hw and how? And what about calibration - have they performed
> individual per-unit calibration of various RF parameters on those
> Fernvale kits like every standard GSM MS hardware manufacturer is
> required to?
I don't have any clue about these details. Will have to rely on Harald or
maybe inquire of Bunnie and Xobs.
> I calibrate my FCDEV3B boards at production time, use
> the calibration procedure to also serve as a test of the RF tract, and
> ship every unit with turnkey-working official firmware and a fully
> valid and legitimate IMEI, fully fit for operation as an MS on public
> GSM networks - do they do likewise or not? If not, then they are
> substandard.
>
> M~
Thanks for your efforts,
Craig
Hello OsmocomBB gang,
Earlier today I was trying to run OBB against my CMU200 GSM MS RF
tester, with the objective of trying to determine if the change
currently stalled in OS#3582 (switching the Tx APC code in OBB from
the original to my modified version that uses the same numbers as each
target's respective original fw, i.e., Compal's numbers on Mot C1xx or
FreeCalypso numbers on the FCDEV3B) makes things better or worse on
OBB's primary compal_e88 platform (Mot C118).
Running OBB with Tx enabled on a Motorola phone that has its internal
antenna connection fully intact is not only illegal (transmitting in
the tightly regulated GSM bands from an unlicensed device) but actually
dangerous and harmful: as my CMU200 experiments have confirmed, OBB's
transmissions are so wildly out of spec that the risk of causing
*actual* interference and disruption to cellular networks is very real.
While I don't give a damn about silly laws that declare perfectly safe
and harmless things to be illegal, I do very much care about not
disrupting cellular networks which people actually use for important
communication, including safety-of-life communication, hence letting
OBB transmit on real live airwaves is a big no-no.
Instead the *only* safe way to run a Tx-enabled build of OBB layer1 on
a Mot C1xx or SE J100 phone is to insert an RF cable terminated with
an appropriate probe adapter into the RF test port on the back of the
phone, and connect this cable to your own test BTS or to a specialized
GSM MS RF tester like R&S CMU200. Pull out the rubber plug that keeps
dust out, and insert the appropriate adapter. I use a Hirose
MS-147-HRMJ-1 adapter for old-style MS-147 RF test ports on C118 and
C155/156 phones, and a Murata MXHS83QH3000 adapter for the newer style
of RF test ports found on Mot C139/140, SE J100, Openmoko, Pirelli and
most newer phones. Both adapters are from Digi-Key, and both are
still readily and cheaply available there. Both adapters convert the
RF test port to SMA, and unlike the other SMA to MS-147 pigtail sold
by Sysmocom, neither of my adapters requires any disassembly of the
phone case - just pull out the rubber plug. The critical point here
is that when you insert a probe into that RF test port under the
rubber cover, the internal antenna is disconnected.
Because I do not currently have my own sysmoBTS (at least not yet, may
be able to afford one in another couple of months) and I have no
interest in messing with SDR devices or trying to make a poor man's
BTS out of one, the only thing to which I can connect GSM MS devices
under test is my R&S CMU200 instrument. This instrument is generally
considered to be the gold standard in the mainstream professional
(non-FOSS) GSM industry, and I use it all the time to test not only my
own FreeCalypso devices, but also various pre-existing ones, and they
don't have to be TI-based or have hackable firmware. The CMU200 does
have a so-called non-signalling mode that allows low-level Rx and Tx
operations to be tested directly, and this mode of operation does
require GSM MS firmware with special RF test modes that bypass all
higher layers of the protocol stack - but the CMU200 instrument also
has a "signalling" mode in which it acts as a standard BTS, allowing
any MS to be tested as a black box.
This signalling mode of the CMU200 works with every GSM MS in my
experience (with FreeCalypso, with Motorola's original fw on all C1xx
phones, and with various other phones with completely unknown chipsets
and firmware architectures) with the exception of OBB. At first I had
no success with getting OBB to play nice with the CMU200 at all: I
would turn on the simulated BTS downlink signal on the CMU, run OBB's
mobile app, and it would register to the test network - but as soon as
I press the "Connect mobile" (call to MS) button on the CMU, everything
would go haywire. However, after a lot of trial and error I figured
out where at least some of the breakage is happening:
1) In order for the "call to MS" operation to succeed, the MS Tx power
level setting on the CMU200 (i.e., the power level which the CMU acting
as a BTS directs the MS to transmit at) must be set to each band's
respective maximum (PCL 5 for low bands or PCL 0 for high bands), which
is not the default setting. If one tries to make a call-to-MS from
the CMU with the MS Tx power level set to something lower, it works
just fine with every type-approved or would-pass-approval-if-someone-
paid-for-it GSM MS including FreeCalypso and Mot original fw, but if
one tries the same thing with OBB, a message pops up on the CMU200
screen saying "Overload at connector RF2", mobile's vty window says
"% Call has been released", and everything breaks from there onward.
At first I was totally bewildered as to how CMU200's input could
possibly be overloaded when the RF2 port in question is rated for
33 dBm continuous power, the PA on my FCDEV3B or on Mot C1xx phones
cannot put out anything more than 30 dBm in the DCS/PCS high bands,
and my cable has about 2.2 dB of attenuation which I account for in
my calibration and test procedures - an overload sounds physically
impossible in this setup. But then I realized what is happening:
because the CMU200 expects the MS to transmit at the power level
instructed by the CMU acting as the BTS, the instrument software
configures its sophisticated Rx chain for optimal reception at power
levels around that target. What appears to be happening with OBB as
the MS is that OBB does not implement Tx power control correctly, and
transmits at the maximum power level even when the BTS told it to
transmit at some much lower level. The CMU does not expect such gross
misbehaviour from candidate MS devices submitted for type approval
testing, and some stage in the configured Rx chain gets overloaded.
Next experiment: I established a call between OBB and the CMU200 by
setting the MS Tx power level knob to the maximum for the band I am
testing in, and then tried changing it within the active call, i.e.,
had the CMU acting as the BTS command the MS to change its Tx power
level while staying in dedicated mode. I am not sure if this
signalling happens over FACCH or SACCH, but once again it works
without a hitch with every type-approved or would-pass-approval phone
I have available for testing, and I use this method all the time to
verify the complete range of Tx power levels on the MS under test.
Not so with OBB: I don't remember the exact error message displayed by
the CMU200, but it was something along the lines of the MS failing to
act on the Tx power level change command, and then it would drop the
call. So apparently OBB fails to implement this aspect of the spec as
well.
So what about the OS#3582 change? Does it make things better or worse?
Answer: I was unable to test it because the other show-stopping defects
in OBB's GSM MS implementation prevent me from getting that far. The
combination of the two bugs above (no ability to establish the call
unless the MS Tx power level is set to max, and no ability to change
the power level within the test call) makes it impossible to step
through the power levels and see what the mobile puts out at each PCL,
hence no ability to test the change.
There also appears to be something wrong with OBB's timing of various
steps involved in burst transmission, i.e., Calypso TPU programming.
I say so because even if I stay at the band's maximum power level
(don't try to change it), the CMU200 reports the power ramp as being
out of tolerance, even with my OS#3582 patch which makes the actual
ramp programming exactly the same as what each device's official fw
uses to produce perfectly passing ramps - so it is probably something
to do with timing.
OK, so why did I produce this OS#3582 patch if it doesn't make things
any better in practice because of other major bugs elsewhere? The
answer is that it was my knee-jerk reaction to seeing hard-coded
numbers for Tx power levels and ramps and for the VCXO slope that are
completely and obviously wrong for Openmoko/FCDEV3B hardware. The
hard-coded Tx power level and VCXO slope numbers in the current OBB
master are approximately correct (at least within the ballpark of
correctness) for Mot C11x/12x/155/156, but are NOT correct even for
Mot C139/140 (different PA with different characteristics), and are
wildly off-base for the completely different Openmoko/FCDEV3B RF hw -
someone claimed Openmoko gta0x as "supported" all those years ago
without anyone doing any real tests on that platform, and without
noticing the utter bogosity.
What was happening is that people were asking about running OBB on
FCDEV3B hardware, I was trying to support those people in the hope
that they would buy the hardware at the fair commercial price (which
hasn't happened), it was obvious to me from a very cursory glance at
the code that the stuff in current master has exactly zero chance of
working anywhere close to correctly on my hw given those totally wrong
hard-coded numbers, so I felt that at that very minimum, I had to fix
those bogus numbers. Trying to fix just the numbers while keeping the
architecture of the code that uses them was also a non-starter (more
utter bogosity like trying to use GSM900 band APC numbers for all
bands), so I did the only thing that seemed sensible: ripped that gunk
out and replaced it with Tx parameter tables in the chip vendor's
original format, filled with bits read from factory RF calibration
records.
But as today's experiments show, it was pretty much for nothing: while
you do need to apply this patch if you wish to have any chance of ever
putting out spec-compliant radio transmissions, it is nowhere close to
being sufficient.
The *only* way how OBB would ever reach a point of being safe to use
as a GSM MS on live airwaves and being able to seriously compete with
properly functioning, spec-compliant GSM MS products like FreeCalypso
or Qualcomm/MTK/etc phones running their respective official fw would
be if someone were to invest many, many person-years into it, and also
invest their own money into appropriate test equipment - a CMU200 or
equivalent is an absolute must, otherwise you have no way of knowing
what your MS really puts out.
And I will *not* *ever* be that person who invests her time and energy
into whipping OBB into something that could kinda-sorta approach what
MTK, Spreadtrum and FreeCalypso (have I missed any other GSM chipset
vendors? I don't count Qualcomm as they hate GSM and give it the
"unwanted bastard child" level of support) already provide today, with
at least one of the listed vendors freely publishing their full source
code.
Meanwhile, the takeaway lesson is that running current OBB with Tx
enabled on a Motorola phone without disconnecting its internal antenna
is NOT safe, and the danger of interference to GSM or other cellular
networks is way too high. People on this list swear up and down that
no one uses OBB as a phone, instead people who call themselves
"researchers" supposedly use it in their test setups somehow. But how
exactly? I somehow doubt that most of you so-called "researchers"
have expensive Faraday cages or go to the trouble of a fully cabled
setup (lots of extra components required: duplexer, attenuators,
multiple cables, adapters for connecting to RF test ports on phones)
with no radiated transmissions. It seems far more likely to me that
most of you so-called "researchers" probably operate your SDR-acting-
as-a-BTS in open air, with the downlink signal power level set low
enough so you don't get caught despite having no actual license, and
your OBB phone transmits back to your home-grown BTS via open air.
What I am here to tell you is that doing the above is NOT as safe as
you think: if OBB is transmitting at the maximum power level the phone
can put out, which is 2 W in the GSM900 band, if the power control is
not working (OBB does not lower its Tx power when the BTS tells it to)
and the power ramp is wrong for whatever reason (the CMU200 shows it
as being out of tolerance), then only Cthulhu knows what kind of
interference you may be putting out.
My greatest hope is that some day more people will see the light and
do the right thing: retire OBB to the dustbin of history as a project
that may have been interesting once upon a time but is absolutely NOT
worth doing any more work on in the present reality, and redirect their
forces to more productive efforts. I am convinced that it would take
far less work to reimplement the researcher-oriented functionality of
OBB on top of the rock-solid FreeCalypso code base than to bring OBB
to a point of being able to compete on technical merit.
M~
Dear Osmocom community,
starting from 16th of January (until 7th of February) we can apply
Google Summer of Code as an Open source mentor organization. Many
well-known projects, such as Debian, FFmpeg, Apache, Git, GCC,
GNURadio and others, have been participating last year.
Personally, I think it's a great opportunity to move some of our
projects forward. I would like to know your opinions about this
idea, should we participate? I would be happy to be a mentor.
With best regards,
Vadim Yanitskiy.
After a lot of work[1] the gsm tester can finally:
* Start a virtual bts
* Mobile/virtphy processes
* Complete LUs for 10 MS.
The next step (besides having a proper test verdict) is scaling this beyond what a simple physical set-up can provide. Let's go to 100+ BTS and 10k subscribers but somehow I am still holding it wrongly and would like to have feedback to see how to evolve the gsm tester.
What do I need to change to scale this up and how to externally parameterize it?
* suite.conf:
Add one line per virtual bts to reserve (I would prefer to specify type+num)
* resources.prod.conf:
Add more Virtual BTS. I started to pick IPs from 127.0.1.0/24 as it avoids having to configure special IPs.
* register_default_mass.py:
I need to somehow know how many BTS (and NITBs) were reserved. Or in the long run the topology of how to connect M BTS to N BSCs? Currently I can run until I get an exception but that is not desirable.
What's missing:
* High-level API of the SuiteRun to get me the toplogy of the network. It seems undesirable in the specific suite to discover how many BTSs were reserved in suite.conf or what the topology is.
* ARFCN usage. Besides the redundancy all my BTS currently have the same ARFCN. There should be an easy way to configure an band+arfcn pool.
* IMSI/MSISDN pooling. I would like to specify pools of IMSI/MSISDN pairs (and size) and then draw from it. I needs these to program into the mobile, NITB/HLR/AuC and for client to client SMS transfers.
* Configure these capacities from the outside. Changing from 1 to 256 BTS should be a single line (or even a parameter change).
Any idea or comment on how to achieve this?
cheers
holger
[1] Hindsight is 20/20 and the difficulty was not adding scripting to mobile but getting the GSM tester to spawn the network and we are unfortunately not done yet.
> It is the same version of libosmocore that comes with osmocombb.
https://osmocom.org/projects/baseband/wiki/Software_Getting_Started#Depende…
> For osmocomBB, as for several other osmocom projects, you will also need libosmocore.
> Note: Although libosmocore is included when getting osmocom-bb from the git repository,
> you have to install it separately. The libosmocore subtree is only used to compile the
> embedded ARM version of libosmocore.
With best regards,
Vadim Yanitskiy.
sched_clck.o: In function `sched_clck_tick':
/home/imsicatcher/osmocom-bb/src/host/trxcon/sched_clck.c:64: undefined
reference to `osmo_clock_gettime'
sched_clck.o: In function `sched_clck_handle':
/home/imsicatcher/osmocom-bb/src/host/trxcon/sched_clck.c:123: undefined
reference to `osmo_clock_gettime'
Any help is appreciated. Thank you
Hi,
We have been working on the handover feature in OsmocomBB and have
managed to make some progress including SB/BSIC detection in dedicated mode
which was not previously being successfully done in firmware. I wanted to
share it and seek guidance on the last bit of handover implementation on
which we are stuck. I hope someone would be able to help us or make use of
our work.
We took code related to handover from the osmocom-bb jolly branch by
manually adding/deleting stuff in the master branch as updating to the
latest copy was giving us issues. We added code from the “Safely change TPU
offset on TS change or sync change” commit till the “Use only sel_si for
information about the current cell” commit. Using the handover code in the
jolly branch and after making the changes explained below we were able to
obtain the handover command from the BTS. The synchronized handover case
works sometimes though still not every time, however the non-synchronized
case doesn't work at all as we are not able to get the physical information
command from the new cell. I'll explain the changes/additions we made to
achieve this.
Firstly, we noted that in dedicated mode SB burst was not being detected.
Changes were required at three main places in order to correctly perform
FB/SB detection:
- It was seen that the results for SB were being read from DSP API location
dsp_api.db_r->a_sch which is for the idle mode. The results had to be read
from the dsp_api.ndb->a_sch26 location for the dedicated case if
TCH_SB_DSP_TASK is used.
- After reading the FB we needed to update the quarter-bit offset of the
TPU using the TOA of the FB to sync it with the start of frame of the
neighbour cell in order to catch the SB (by changing the vaule of
l1s.tpu_offset using the TOA of the FB).
- Frequency compensation needed to be performed using the afc_correct
function before reading the SB.
* We actually kind of cheated a bit by adding 3 frames to the original idle
frame in order to give us more time to perform FB/SB detection including
the synchronizations mentioned above. This was because we weren't that
proficient with the code and someone with more understanding could do this
better. The call did not get dropped. We used the initial added “idle”
frame to perform the quarter-bit and frequency compensation which was
reversed in the idle frame with the response function to tune back to the
serving cell.
These things, when added to the code did the trick and BSIC of the
neighbours was obtained.
Once the BSICs were decoded the measurement report sent to the BTS became
meaningful and the handover command was received. Upon receiving handover
command, access bursts needed to be sent on the new channel which again was
not currently being implemented properly as in order to tune to the new
cell we needed to know its quarter-bit offset for start of frame, frequency
compensation and absolute frame number which were not previously being
obtained. Now that we were able to detect FB and SB these values were
stored for the neighbours following detection of these bursts and were used
to tune to a neighbour cell in case of a handover to it before the sending
of access bursts. However, here is where we are stuck. We were expecting a
physical information message following the access bursts but were not able
to receive it due to which the handover failed. If only that could be
achieved we believe handover should be successful.
Either we are not syncing properly to the new cell or we might not be
following GSM protocol properly. We also might not be reading the FACCH
properly for physical information message after tuning to the new cell as
we couldn't really understand that bit very well. We wanted someone
expertise on this matter and were hoping our work could be of use. We were
more interested in getting the work done first up.
Best Regards,
M. Awais Aslam
Hi ALL.
Last weekend I compiled osmocom-bb and now I can send English SMS from one peer to another by using its app 'mobile'. But how to make it possible if I want to send SMS including non-English character, like below.
你好
こんにちは
안녕하세요.
สวัสดี
I will be appreciated if you can help me.
-----------------
from dechao
Dear fellow Osmocom developers,
I'm a bit surprised to notice that not more people have signed up for
OsmoDevCon 2019. I guess it was mostly an oversight when the date was
originally announced, and not a lack of interest? ;)
All details about the event are available at the related wiki page at:
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2019
Please enter your name at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2019#Requested
in case you would like to attend. Registering early allows proper
planning. Thanks!
Looking forward to meeting old and new Osmocom developers in April 2019.
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)
Hello,
I am trying to load helloworld firmware into my phone (Motorolla C118) using sysmocom CP2102-25 cable by executing the following command
sudo ./osmocon -p /dev/ttyUSB0 -m c123xor ../../target/firmware/board/compal_e88/hello_world.compalram.bin
But I am not getting any response on pressing power button briefly. The command keeps on executing without any message. What can be the issue and how to deal with/debug this issue.
I have also attached a cu terminal by using following command.
$ sudo cu -l /dev/ttyUSB0 -s 115200
The cu terminal displays this message on pressing power button.
��A@ftmtoolerror
Hi all,
Somoene shared what looks like a quite useful datasheet for MT6260 at the kosagi/fernvale forum. I have downloaded it and looked a bit and it looks very helpful.
I have linked to it in the wiki at: https://osmocom.org/projects/baseband/wiki/MT6260
Original post at kosagi forum: https://www.kosagi.com/forums/viewtopic.php?pid=3313#p3313
I hope to rejoin my effort on porting layer1 firmware to fernvale in about 1 month.
Cheers,
Craig
Hello Andreas,
sorry for late response.
> I set up a network with Virtual Um and multiple OsmocomBB
> phones. They register, they can send and receive SMS
> and I wanted to try voice calls.
First of all, it should be noted that voice support in OsmocomBB
is experimental and undocumented. I have been working on GAPK
back-end integration, and it seems you've already found some
branch, but I would recommend to use 'fixeria/audio' instead of
'fixeria/mncc'.
> calls can be established, but GAPK is never initialized and
> again, I never see voice data appearing as an MNCC message.
Please check out the configuration examples [1] for mobile app.
There you should find the new 'audio' section, where:
io-target hardware
means that audio I/O (by default) should be handled by the
hardware (i.e. by Calypso phone). GAPK is not enabled by default.
In order to use GAPK based back-end, use 'gapk':
io-target gapk
It probably makes sense to rename 'gapk' to 'alsa', because
at the moment 'gapk' enables both voice playback and capture
using the audio system of the host that running mobile.
> I never seem to receive a GSM_TCHF_FRAME-message on
> the MNCC socket.
This can also be configured:
io-target socket
In this case GAPK is not used, and all TCH frames are being
forwarded to the MNCC handler 'as-is'.
See [2] commit description for details.
Please also note that audio I/O target != MNCC handler, that
actually implements the Call Control logic. See [3] for details.
[1] https://git.osmocom.org/osmocom-bb/tree/doc/examples/mobile/default.cfg?h=f…
[2] https://git.osmocom.org/osmocom-bb/commit/?h=fixeria/audio&id=bdb2854503afd…
[3] https://git.osmocom.org/osmocom-bb/commit/?h=fixeria/audio&id=22edbf3f846b1…
With best regards,
Vadim Yanitskiy.
Hi,
I set up a network with Virtual Um and multiple OsmocomBB phones. They
register, they can send and receive SMS and I wanted to try voice calls.
I looked around and found a repository [1] with an MNCC example
application which sends voice samples. Calls are established and can be
picked up, but on the other end, but I never seem to receive a
GSM_TCHF_FRAME-message on the MNCC socket.
I then checked out the fixeria/mncc branch [2] which includes GAPK
integration which can use ALSA devices for audio, because that's what I
need anyway at some point for my project I'm working on.
Again, calls can be established, but GAPK is never initialized and
again, I never see voice data appearing as an MNCC message.
The GAPK audio backend is supposed to be initialized [3] when a CHANNEL
MODE MODIFY message is received from the network. I never see the
network request a channel mode modify though. I don't know enough about
GSM to find out if that message is always supposed to be sent when a
call is established or not.
Did anybody ever transport audio with two OsmocomBB instances over the
Virtual Um interface?
Thanks,
- Andy
[1]: https://github.com/GerardPinto/call-control-mncc-sap
[2]: https://git.osmocom.org/osmocom-bb/log/?h=fixeria/mncc
[3]:
https://git.osmocom.org/osmocom-bb/tree/src/host/layer23/src/mobile/gsm48_r…
== OsmoCon 2018 ==
OsmoCon (Osmocom Conference) 2018 is the technical conference for
Osmocom users, operators and developers!
We are happy to announce the date of OsmoCon 2018. It has been scheduled
on October 18 + 19, 2018 and will happen in Berlin, Germany.
For the second time, the Osmocom Conference brings together users,
operators and developers of the Osmocom Open Source cellular
infrastructure projects, such as OsmoBTS, OsmoBSC, OsmoSGSN, OpenGGSN
and others.
Join us for two days of presentations and discussions with the main
developers behind Open Source Mobile Communications, as well as
commercial and non-profit users of the Osmocom cellular infrastructure
software.
You can find some initial information in our wiki at
http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2018
which will be updated as more information becomes available.
== Call for Participation ==
We're also at the same time announcing the Call for Participation and
call on everyone with experiences to share around the Osmocom member
projects to submit talks, workshops, discussions or other proposals.
You can find the CfP at https://pretalx.sysmocom.de/osmocon2018/cfp
We are particularly looking for contributions about:
* updates on features/functionality/status of individual Osmocom projects
* success stories on how Osmocom projects are deployed in practice
* migration from OsmoNITB to the post-NITB architecture
* tutorials / workshops on how to setup / analyze Osmocom projects
* statistics, reporting, operations aspects of Osmocom projects
* third-party open source utilities to be used with Osmocom projects
Looking forward to meeting many existing and new Osmocom users at OsmCon
this October!
Regards,
Harald Welte
--
- 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)