Hi,
I've hacked something together to quickly test non-combined CCCH.
However, I've hit a problem when trying to receive anything on another
timeslot than 0.
The TX side seems to work fine as the BTS can see my location update
request and answers with a reject, but on the MS side, I never see the
reject and wireshark only shows invalid incohrent data on the RX.
The frames for SDCCH/8 show really nothing valid (looks like random
bytes), things like
09 80 7f 47 49 06 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
09 00 47 d5 2d 06 1e 00 00 69 7c a0 91 3d 22 ff ab fe 6c 4f 56 4f 36
...
while the frames for the associated SAACH show at least something gsm-like :
03 03 01 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
but that's not quite a SI5/6 ...
To RX/TX on TS=1, I just delayed the RX/TX window by 625 bits (4 *
156.25) when I'm in dedicated channel mode by chaning the 'start' in
l1s_tx_win_ctrl / l1s_rx_win_ctrl
Is there something else that should be done ?
Cheers,
Sylvain
Hi!
Recently we've had the idea of using OsmocomBB with a simple firmware
that synchronizes to an existing GSM networks FCCH and use the resulting
13MHz clock to drive the USRP for airprobe or OpenBTS.
Ideally, we would even use the Calypso-internal PLL (for ARM or DSP) to
multiply it up to the required 52 MHz. However, neither the Openmoko
nor the Compal/Motorola phones expose any of the 3 clock output pads :(
So the only choice is to use something along the lines of the
http://focus.ti.com/docs/prod/folders/print/cdcvf25084.html
as a quad clock multiplier and attach it to the CLK13OUT signal of the
phone.
The chip is available for 9 USD in single quantities at digikey, and
possibly cheaper at other sources. Combined with a sub-20EUR phone it
might be a very cheap but still accurate frequency source for OpenBTS -
at least as long as there are any commercial gsm networks available.
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 guys,
I dunno if that is the right place for my concern about building the
osmocomBB source. Here is what I already have done:
- downloading the sources for osmocomBB and GNU toolchain for ARM,
- setting the PATH for the arm-elf-* executables,
- calling make in the src directory.
Now, this appears as response of the make command in the terminal:
cd shared/libosmocore/build-host && ../configure
configure: error: cannot find install-sh, install.sh, or shtool in ".."
"../.." "../../.."
make: *** [shared/libosmocore/build-host/Makefile] Error 1.
If you need details about my system, you can look at the following
snippet from the config.log file:
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by libosmocore configure UNKNOWN, which was
generated by GNU Autoconf 2.65. Invocation command line was
$ ../configure
## --------- ##
## Platform. ##
## --------- ##
hostname = ubuntu-stefan
uname -m = x86_64
uname -r = 2.6.32-24-generic
uname -s = Linux
uname -v = #41-Ubuntu SMP Thu Aug 19 01:38:40 UTC 2010
/usr/bin/uname -p = unknown
/bin/uname -X = unknown
/bin/arch = unknown
/usr/bin/arch -k = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo = unknown
/bin/machine = unknown
/usr/bin/oslevel = unknown
/bin/universe = unknown
PATH: /usr/local/sbin
PATH: /usr/local/bin
PATH: /usr/sbin
PATH: /usr/bin
PATH: /sbin
PATH: /bin
PATH: /usr/games
PATH: /home/stefan/osmocomBB/gnuarm-4.0.2/bin
## ----------- ##
## Core tests. ##
## ----------- ##
configure:2032: error: cannot find install-sh, install.sh, or shtool in
".." "../.." "../../..".
So, I would be very glad, if someone could give me a hint to solve the
problem. Thank you in advance.
Regards,
begy
On 06/08/2010 09:41 PM, Huseyin Turan wrote:
> root@name1-desktop:/home/name1/osmocom/gnuarm-4.0.2/bin# ls -l arm-elf-gcc
> -rwxrwxrwx 1 name1 name1 112344 2006-02-17 23:59 arm-elf-gcc
> root@name1-desktop:/home/name1/osmocom/gnuarm-4.0.2/bin# ./arm-elf-gcc
> bash: ./arm-elf-gcc: cannot execute binary file
> root@name1-desktop:/home/name1/osmocom/gnuarm-4.0.2/bin# uname -a
> Linux name1-desktop 2.6.28-19-generic #61-Ubuntu SMP Wed May 26 23:35:15
> UTC 2010 i686 GNU/Linux
>
please try b.) again (you miss the file part) and also please reply to
the mailinglist.
Hi All,
I now have a V171 phone and cable so I thought I might get started with
this.
I checked out the code and started make. Osmocon built with no problem, but
I got this error next:
cd shared/libosmocore/build-target && ../configure \
--host=arm-elf-linux --disable-vty
--enable-panic-infloop \
--disable-shared --disable-talloc --disable-tests \
CC="arm-elf-gcc" CFLAGS="-Os -ffunction-sections
-I../../../../target/firmware/include"
configure: WARNING: if you wanted to set the --build type, don't use --host.
If a cross compiler is detected then cross compile mode will be used
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for arm-elf-linux-strip... no
checking for strip... strip
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make sets $(MAKE)... (cached) yes
checking for arm-elf-linux-gcc... arm-elf-gcc
checking whether the C compiler works... no
configure: error: in
`/mnt/site/osmocom-bb/src/shared/libosmocore/build-target':
configure: error: C compiler cannot create executables
See `config.log' for more details
make: *** [shared/libosmocore/build-target/Makefile] Error 77
Checking config.log I can see it chokes here:
/usr/bin/arm-elf-ld: this linker was not configured to use sysroots
collect2: ld returned 1 exit status
I am running Arch Linux and have the packages cross-arm-elf-binutils
and cross-arm-elf-gcc-base installed. Does anyone have any suggestions to
fix this?
Thanks!
Hello Marten,
First of all please be aware that OsmocomBB is now in a state where it
can be used for voice calls without any special tricks so there is no
need to tune on the voice traffic of the HP8922 GSM testset, you can use
the GSM testset as a normal basestation.
On Wed, 29 Sep 2010 23:00:44 +0000, "Marten Christophe" <technosabby(a)gmail.com> wrote:
>
> Q.1) i learned from wiki how to change ARFCN from Layer on application by
> using below command, but how to tune right TS ?
>
> ./layer23 -a 871 -i 127.0.0.1
For my inital TCH testing I did not use Layer23 at all, I only used Layer1
in the phone with special test code using a fixed ARFCN.
> Q.2) even If OsmocomBB Layer1 CTL is able to tune to right ARFCN and Time
> Slot, will i be able to listen what so ever broadcasting from HP8922 from
> C123 speaker or PC speaker. non-encrypted, debugging non-hopping)
Yes.
> Q.3) what command and interface will be used to enter the frequency hoping
> parameter, in case i will use FH option? to tune OsmocomBB l1CTL
You have to write your one code if you want to do this without Signalling
beeing involved.
> Q.4) How to enter Minimalistic L1 interface, what is interface available to
> insert theses command to layer1
You can use the L1CTL API to setup a TCH with your own code, but its
probably easier to setup the TCH with signalling (either MOC or MTC),
this way you don't need to modify the code and still get the TCH running.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello,
Thanks u all this gr8.. work ..
forgive me for my little novice question.. most probably goes to Mr.
Deiter.. but any one from list be kind enough help me from list..
I'm pretty new to Osmocombb
i made a setup as advised on *Sun, 01 Aug 2010* blog. with hp8922.
===Q===
" You just "tune" to the right ARFCN and time slot (I don't use hopping
during testing) and see that you get your code running."
===UQ==
Q.1) i learned from wiki how to change ARFCN from Layer on application by
using below command, but how to tune right TS ?
./layer23 -a 871 -i 127.0.0.1
Q.2) even If OsmocomBB Layer1 CTL is able to tune to right ARFCN and Time
Slot, will i be able to listen what so ever broadcasting from HP8922 from
C123 speaker or PC speaker. non-encrypted, debugging non-hopping)
Q.3) what command and interface will be used to enter the frequency hoping
parameter, in case i will use FH option? to tune OsmocomBB l1CTL
Q.4) How to enter Minimalistic L1 interface, what is interface available to
insert theses command to layer1
DEDIC_MODE_EST_REQ , LAYER1_RESET, DEDIC_MODE_DATA_IND
thanks , Martin
Hello,
Thanks u all this gr8.. work ..
forgive me for my little novice question.. most probably goes to Mr.
Deiter.. but any one from list be kind enough help me from list..
I'm pretty new to Osmocombb
i made a setup as advised on Sun, 01 Aug 2010 blog. with hp8922.
===Q===
" You just "tune" to the right ARFCN and time slot (I don't use hopping
during testing) and see that you get your code running."
===UQ==
Q.1) i learned from wiki how to change ARFCN from Layer on application by
using below command, but how to tune right TS ?
./layer23 -a 871 -i 127.0.0.1
Q.2) even If OsmocomBB Layer1 CTL is able to tune to right ARFCN and Time
Slot, will i be able to listen what so ever broadcasting from HP8922 from
C123 speaker or PC speaker. non-encrypted, debugging non-hopping)
Q.3) what command and interface will be used to enter the frequency hoping
parameter, in case i will use FH option? to tune OsmocomBB l1CTL
Q.4) How to enter Minimalistic L1 interface, what is interface available to
insert theses command to layer1
DEDIC_MODE_EST_REQ , LAYER1_RESET, DEDIC_MODE_DATA_IND
thanks , Martin
Hello,
I'm involved with an open source hardware user group based in London:
http://oshug.org
Our next meeting is on Thursday 21st October and for which the theme is
radio. We have one confirmed speaker who will be presenting on OpenHPSDR,
and wondered if there might be someone around London at that time who might
be willing to do a presentation on OsmocomBB and/or OpenBSC.
For more info on OSHUG see the website for details of previous talks and
photos and video.
Regards,
Andrew
--
Andrew Back
mailto:arback@gmail.com
Hi!
I just found some time to have a look at the recent commit history and
had a look at the SIM related code and had the following suggestions:
1) split the definitions from GSM TS 11.11 into a separate header file
from the definitions that are OsmocomBB specific, and move the 11.11
header file into libosmocore
2) use msgb's for SIM messages. This way we can avoid all those manual
buffer[N] = M type assignments and rather use msgb_put() constructs
3) even if not going for suggestion '2', it might be good to add some kind of a
inline function abstracting out all the blocks that look like
+ buffer[0] = GSM1111_CLASS_GSM;
+ buffer[1] = GSM1111_INST_TERMINAL_PROFILE;
+ buffer[2] = 0x00;
+ buffer[3] = 0x00;
+ buffer[4] = length;
with something like a "sim_buf_init(buffer, GSM11_INST_TERMINAL_PROFILE);"
Of course those are simply suggestions... maybe for the day where somebody on
this list is feeling bored and is looking for a quick and easy task to resolve.
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)
I have a job offer in my company for a project to research into and build defenses against over-the air attacks breaking current 2G/3G basebands. The location is in Berlin, Germany, starting soon if possible. Remote work arrangements are not an option. The project is solidly financed by a public research grant, the company is nicely profitable for many years now.
Requirements are detailed GSM knowledge, very good reverse engineering and at least decent C/C++ coding skills plus ability to work with a small team in english or german language. All research results of the project will be public and large parts of the development aspect will be on improving the open GSM / 3G tools and thus flow back to the community. Working hours are very relaxed, we are looking for someone who really dives into his work and does not just attend it.
Mail me off list if you think you fit the profile.
Thanks & Greetings from Berlin,
Frank Rieger
> * we should not try to introduce new 'hacks' but rather remove old
> ones by proper code
hi harald,
if you sync the osmocore of osmocom-bb, i could remove some "#warning"s
due to unavailable structures:
struct gsm48_frq_redef
struct gsm48_ho_cpl
struct gsm48_ho_fail
regards,
andreas
Hi,
In my sylvain/testing branch, there a a few interesting changes:
* Priority support for items in a scheduler bucket
Basically for each sched_item, there is a now a priority field and
they are executed in order.
This allows for example to ensure that a scheduled freq change is
executed before accesing the L1 parameters, or to make sure that a
control channel RX is scheduled before a RACH TX ...
For new items added into the bucket while executing itself (like
the abort), those will obviously not be able to obey the priority and
will always be executed afterwards.
* Common DSP & TPU Scenario init & end
Previously, each primitive _cmd initialized the TPU (with
network/offset) to the timeslot and also ended the tpu & dsp scenario.
This scheme doesn't work when you have several primitives that have
a TPU window to open and/or a dsp scenario to run.
(this happens when doing RACH in the same frame as reading a
CCCH/BCCH bursts, or in the case of SDCCH8[4:7]).
Now, each item specifies via some flags if he has a need for TPU
and/or DSP. If one item of the bucket needs it, then the common code
will handle. :
- Aligning the TPU (via offset/network) to the 'base' timeslot
(+3 TX offset still has to be added by the primitive)
- Restoring base TPU alignement at the end.
- Ending both TPU / DSP scenario when everything is done.
* A5 support
Andreas actually made L23 support and added a stub l1ctl_ command itself.
Dieter and I actually made the L1 work in // and not surprisingly
came up with very similar results given it's mainly:
. Load the key in DSP API NDB & set the mode.
. Set a fn parameter properly at each frame
The rest is handled inside the dsp.
I will now work on merging Dieter's work into the main branch above what I did.
- TOA regulation loop to prevent drifting
- TX power control
- TCH support
Cheers,
Sylvain Munaut
hi,
i like to add layer1 control for measurement reports. my idea is use use
normal L1CTL_DATA_REQ with SACCH channel type for sending the (updated)
report to layer1.
the protocol and message type will be decoded by layer1, so it can
detect if this is a measurement report or not. if it is a measurement
report, it will overwrite the last stored measuement report. it will be
sent whenever there is no other SACCH message in the queue of SACCH
messages. if it is not a measurement report, it will be queued as usual.
any better idea?
andreas
Hi,
> What's the easiest way to list out the API for layer1.bin? (I can start
> searching through the code myself but I thought I would ask first.)
See include/l1ctl_proto.h
But it's a pretty high level: things like
- Go camp on the bcch/ccch
- Open a dedicated channel with those parameters
- Send this L2 frame
...
PS: Make sure to answer to the list and not me.
Sylvain
> then i would suggest to expand the scheduling thing. i will see how
> complex that would be...
ok, i see that there is also a "one shot" scheduler with full frame
number range. (sched_gsmtime.c) i think that i can use this to modify
the current channel set. i have code to test it. i don't know if the
callback function of the scheduled event is called before or after the
actual transmission/reception of the burst, which also sets the right
frequency. even if not, there will be only one frame lost.
> The only function in rfch.c returns the parameter for a given time.
> It does _NOT_ and should _NOT_ make any change to the parameter
itself.
> That's left up to the caller because we need to call that function
several time.
> If you want to introduce some call that configure the channel and
make changes and stuff, put it into another function and make sure it's
called when required.
then i would suggest to expand the scheduling thing. i will see how
complex that would be...
> Using the scheduler should be relatively easy, you can simply call
> sched_gsmtime() and provide it a framenumber and a 'tdma_sched_item'.
the
> latter will contain the callback that is to be called once the current
> framenumber will reach 'fn' as specified.
what if there is already a scheduled item? in this case i must schedule
the frequency change item before any other item. also the frame number
of frequency change may be more than 255 frames ahead.
my suggestion: because hopping sequence is a function of time, the
starting time should also be included in this function (rfch.c).
Hi all,
after some days digging into the various tools around the GSM opensource
playground arena i started understanding better the various piece of
software.
It seems to me that there's a net separation between the GSM
implementation stack of OpenBTS and Osmocom, also because the projects
are born with different goals.
With the current bb implementation of Osmocom inside Calypso based
baseband processor of motorola, all the DSP logic is done directly by
the mobile phones chip, right?
Which with OpenBTS, it's OpenBTS itself that does the
modulation/demodulation along with the USRP.
Is there some project and or ideas to bring together the DSP codebase of
OpenBTS, together with OsmocomBB to make a MS terminal based on USRP1
device with RFX900 boards?
Fabio
hi,
as you can see in the git log, i checked in the "ASSIGNMENT COMMAND"
processing. it modifies timeslot, subslot, and hopping sequence. this is
required when the network assigns an SDCCH before the actual TCH is
allocated: after receiving the "ASSIGNMENT COMMAND", the layer2 is
release locally (without sending anything), the dedicated mode is
released and established with a new parameters (e.g. TCH/F), and the
layer2 is established again, finally the "ASSIGNMENT COMPLETE" is sent
to the network. this process is incomplete, but it should work in most
cases. (no "starting time" processing).
in my local copy of the git, i already completed the assignment process.
additionally "FREQUENCY REDEFINITION" is completed, "IMMEDIATE
ASSIGNMENT" supports "starting time", MDL-error processing is added, and
"HANDOVER COMMAND" parsing is done. the handover process is not
completed, because it depends on unimplemented layer1 features, like
RX-only channels or "4 successive HANDOVER ACCESS bursts on DCCH".
except the handover process, the RR protocol for basic phone calls is
complete now.
before i can check it in, it depends on two things. first, there are
additional messages to be defined in osmocore:
"[osmocore] Adding handover and frequency redefiniton message headers"
http://home.eversberg.eu/osmocore.patch
second, it depends on "starting time" support for layer1:
http://home.eversberg.eu/modify.patch
it adds a L1CTL message to store modified frequency allocations (ma,
ma_len, HSN, MAIO, TSC) for hopping and a "starting time". this starting
time is the frame number at which the modified frequencies are used. if
the frame number lies in the past, the new modified frequencies are used
after the L1CTL message is received.
sylvain already noted, that the event of "starting time" should be
triggered by the scheduler. since i don't know how the scheduler exactly
works, i would ask someone to change my patch. note that the dedicated
mode can be released before the "starting time" elapses.
as soon as both things above are in the master branch, i will commit my
latest work on RR.
regards,
andreas
Hi all, from what i learned, osmocombb provide gsm protocol stack and dsp
signal process code.
So why need to use Ti Calypso/Iota/Rita. Is it possible to run on other
common arm7+dsp chipset?