Dear all,
when we initially crated OsmocomBB, we moved the code that it shared
with the pre-existing OpenBSC project into libosmocore.git, where
libosmocore and libosmogsm are built. As libosmocore was quite a bit in
flux (and we didn't have jenkins+gerrit yet), we decided to have a local
clone of libosmocore.git as a git-subtree module inside osmocom-bb.git
Meanwhile, upstream libosmocore received more and more code, and none
of that was ever built with an 'arm-non-eabi' toolchain and
--enable-embedded.
I've been working quite a bit during the last week on making that
embedded build work again.
The idea is to be able to configure + build libosmocore.git master using
something like
./configure --prefix=/usr/local/arm-none-eabi \
--host=arm-none-eabi \
--enable-embedded \
--disable-shared \
CFLAGS="-Os -ffunction-sections -fdata-sections -nostartfiles -nodefaultlibs"
and then install it onto the host pc. I've used
/usr/local/arm-none-eabi as the prefix, but it could of course be
anywhere.
The above already works for me on Debian unstable using libosmocore.git
master. I have some patches pending in laforge/sercomm and
laforge/pseudotalloc, but those are not mandatory to make the build work
The local clone of libosmocore in OsmocomBB src/shared/libosmocore will
be removed, and the Makefiles of osmocom-bb instructed to use the
system-installed libosmocore from /usr/local/arm-none-eabi (see my
'laforge/remove-libosmocore' branch in). This also already "works" on
my Debian unstable system, in as far as there are no unresolved symbols
or other compilation/linking issues, and the firmware images are
generated. I have not tested any of the resulting binaries yet, and as
I'm travelling without compatible hardware (and overloaded), it's
unlikely that I'll be able to test it soon.
Nevertheless, this is what I would like to move to. If anyone wants to
try if he can build the embedded libosmocore and resulting osmocom-bb
from laforge/remove-libosmocore branch, please do so and report your
progress/success/issues here.
Next steps (after validating the above) are:
* remove old sercomm.c code from osmocom-bb and use the new code from
libosmocore
* remove 'talloc emulation' from osmocom-bb and use pseudotalloc from
libosmocore.git (plus an embedded 'malloc' like umm_malloc)
Further ideas:
* create Debian/Ubuntu package of cross-compiled libosmocore for
embedded-arm, which we can add to the Osmocom nightly builds apt
repository.
* have an (optional?) osmocom-bb makefile step to git clone + configure
+ make install libosmocore
Anyone interested in helping out with this, please feel free to join in.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi,
> I found that the manual from the main site is outdated.
Yeah, still couldn't find some time to update the wiki.
> If I understood it correct, I have to setup calypso bts
> as bts of type nanoBTS, correct?
Why do you think so? No, CalypsoBTS has nothing related
toip.access nanoBTS. From the other side, we don't have
a dedicated type for OsmoBTS, so you can use 'sysmoBTS'.
> I can sync with commercial cell, I can run OsmoBSC and
> OsmoBTS but I still cannot find my network from my personal
> phone in searching mode.
Please watch a great Sylvain's talk, where he explained
almost everything you need to know:
"Further hacks on the Calypso platform"
https://media.ccc.de/v/29c3-5226-en-further_hacks_calypso_h264
In short: BTS should transmit a continuous beacon on C0 to be
detected. Normal MS can't do that. CalypsoBTS was hacked to
perform the following timeslot layout: Tt_R_ttt, where
'T' means TX on Downlink, 'R' means RX on Uplink, and 't' means
channel filling - dummy bursts. Phone cannot RX and TX at the
same time, so one phone serves only one TS. With two phones
you have the following layout: TT_RRttt, so you have two
timeslots served.
This is why you will have some detection troubles even with
working BSS setup :/
> In logs of osmo-bts I can see:
>
> <0000> rsl.c:246 Tx RSL RF RESource INDication
> <000b> trx_if.c:397 transceiver (phy0.0) rejected TRX command with
> response: 'RSP SETTSC -1'
> <0000> rsl.c:2353 (bts=0,trx=0,ts=0,ss=0) Rx RSL BCCH_INFO
Just delete the 'settsc' line from your config, because CalypsoBTS
transceiver only supports 'setbsic'.
Have a fun!
With best regards,
Vadim Yanitskiy.
Dear colleagues,
Could you please tell me when I am wrong in my assumptions?
My story is about beacon channel.
>From different resourses I got the information that we transmit bcch data
(fcch,sch,bcch) which is required for MS to find our network. OK?
On the pictures it's drawn like we transmit BCCH on C0T0. So DL TS1-7 can
be used for i.e. TCH. So if we want just to create bts which can be found
by MS and that's all, we may not transmit on TS1-7 at all. OK?
When we are talking about CalypsoBTS we say that we must transmit several
burst in a row. So here I am a bit confused. So if we want to just transmit
bcch messages we can transmit every TS0 and rest on TS1-7. Why not? Why I
can see in manuals and videos pictures like Ttt_R_tt? Why do I need these
dummy "t" bursts? Why one burst is "t" and another is "T"? Sure I
understand that we must receive something for normal BTS operation like
RACH and need some time to switch Tx/Rx. But why we just cannot use mask
like T_R_T_R_ ...? I understood that we cant use mask TTT_RR because
calypso phone was not hacked to receive two bursts in a row.
Thanks in advance!
Hi,
> I setup CalypsoBTS to work with 2 old motorola c123, I know that isn't the
> best way to do that, but I would like to have a cheap solution. I got the
> setup working with a normal phone and the BTS seems to work correctly
> (using jolly/testing), but from my understanding it support only GSM calls
> and SMS and GPRS is not implemented into the transceiver. I'm wrong or
this
> part has not been implemented yet?
Right, isn't implemented. When you run OsmoBTS, it first does some basic
configuration of transceiver, including timeslot type setting. PDCH has
its own dedicated type, which is being indicated by the SETSLOT command.
So you can look at OsmocomBB sources, and check whether the transceiver
handles this type or not.
> Also, given that CalypsoBTS can only provide single (or two?) timeslot,
> there are a long list of reasons why it would not work straight-forward.
> But technically also possible to make work.
With two Calypso phones it becomes possible to serve two timeslots.
Basically, second phone serves one TCH timeslot, but (if I am correct)
PDCH has no fundamental differences from TCH, so its support could be
implemented too.
After a quick look at OsmoTRX source code, I can assume, that the only
difference between TCH channel combinations (I, II and III) and PDCH
channel combination (XIII) is a fillerModulus value. Correct me if I am
wrong.
With best regards,
Vadim Yanitskiy.
Hi everybody,
I'm pretty new to the GSM/UMTS environment and I'm doing some tests.
Currently I need to analyze some IoT devices that use 2G network to
comunicate via GPRS.
I setup CalypsoBTS to work with 2 old motorola c123, I know that isn't the
best way to do that, but I would like to have a cheap solution. I got the
setup working with a normal phone and the BTS seems to work correctly
(using jolly/testing), but from my understanding it support only GSM calls
and SMS and GPRS is not implemented into the transceiver. I'm wrong or this
part has not been implemented yet?
If needed to use a GPRS BTS can you suggest the best cheap SDR to use with
OsmoBTS? (I saw BladeRF and LimeSDR but I was unable to understand if they
are full supported via OsmoBTS)
Thank you in advance.
inode
> what are problem should i expect
> while porting to qcom hexagon
> is it a bad idea
There would be a lot of questions and things to research. I am not familiar with qcom hexagon SDK. I am a little familiar with osmocom-bb source code and 2G GSM details. I am currently in the very beginning stages
of porting osmocom-bb to the MediaTek 6260/6261 chip which supports 2G. I also have ideas to try and work through 3G on a MediaTek 6735 (ZTE Obsidian phone).
Recently there have been mentions of re-writing the PHY layer of osmocom-bb for an SDR platform like LimeSDR.
https://github.com/axilirator/osmocom-bb
So at the current time I assume that osmocom-bb communicates with the DSP chip on the motorola phones
in a way that abstracts the PHY layer details away and relies on the proprietary Texas Instruments firmware in the DSP as-is.
So I would imagine you might have to implement the PHY layer and also the interface to the PHY layer.
There was a discussion about this recently on IRC #osmocom.
It seems the thought was that qcom had released enough with their Hexagon SDK to allow development of a PHY layer + whatever else.
Some links of interest.
https://developer.qualcomm.com/ - SDK
https://github.com/ttsou/openphy - LTE PHY for Ettus USRP
https://androiddatahost.com/fgd43 - qcom flash image loader
I have a few qcom modems that I'd be happy to do experiment on if that helps.
-Craig
> isn't fixed in branch jolly/testing I am using for calypsoBTS.
> So all I needed is just implement the fix and recompile from sources.
You can also use an older version of toolchain as a temporary
solution: https://github.com/axilirator/gnu-arm-installer - in this
repo I have fixed some installation (texinfo) related issues.
With best regards,
Vadim Yanitskiy.
Dear colleagues,
I am trying to setup CalypsoBTS with two c113 phones.
Don't you know why can't I sync to any commercial cell with transceiver
from branch jolly/testing?
What I have:
Motorola c113 and c113a, tried both.
All other apps like, RSSI, mobile, ccch_scan works like a charm.
What I am doing:
Built jolly/testing according to maual
https://osmocom.org/projects/baseband/wiki/CalypsoBTS
Load firmware
./osmocon -r 99 -m c123xor -p /dev/ttyUSB0 -c
../../target/firmware/board/compal_e88/trx.highram.bin
Found several strongest cells with RSSI and cell_log.
Trying to sync:
./transceiver -a 50 -r 99 -e 1
Here is the log:
50
41
1
<000c> l1ctl.c:77 Tx Reset Req (1)
<000c> l1ctl_link.c:171 Sending: '0d 00 00 00 01 00 00 00 '
<0012> l1ctl.c:383 Reset received: Starting sync.
<000c> l1ctl.c:95 Sync Req
<000c> l1ctl_link.c:171 Sending: '01 00 00 00 00 32 00 64 27 10 03 20 03 07
00 00 00 '
After that phone hangs, no reaction in osmocon on key pressures, holding on
power off button...
The last messages are:
L1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=50, flags=0x7)
Starting FCCH RecognitionFB0 (2515:4): TOA= 3552, Power= -64dBm, Angle=
1328Hz
FB1 (2525:8): TOA= 8543, Power= -64dBm, Angle= 114Hz
fn_offset=2523 (fn=2525 + attempt=8 + ntdma = 6)
delay=8 (fn_offset=2523 + 11 - fn=2525 - 1
scheduling next FB/SB detection task with delay 8
=>FB @ FNR 2523 fn_offset=2523 qbits=3988
Synchronize_TDMA
LOST 3398!
I tried different cells, maybe I need to wait some time to warm the
crystal? But can it be so important?
Kind regards,
Anton
