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!
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
Hello Sebastien,
On Mon, 30 Aug 2010 07:27:19 +0200, "=?UTF-8?Q?S=C3=A9bastien_Lorquet?=" <squalyl(a)gmail.com> wrote:
>
> For example, i don't remember what does a SIM says when it has to reply
> data, but javacards reply 61XX and not something that starts with 9YXX.
For GSM its 9Fxx (GSM11.11, 9.4. contains a list of all status codes).
Not sure if this trace here is usefull (at the same site there is also
one for an USIM):
http://www.wrankl.de/UThings/SIM-ME-Communication.pdf
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Andreas,
On Sun, 29 Aug 2010 13:29:06 +0200, "Andreas.Eversberg" <Andreas.Eversberg(a)versatel.de> wrote:
>
> - add crpyto-key request to layer 1 and l1-l2 interface (dieter ?)
I can take care of Encryption support in Layer-1. However I will
probably not find time for it before next weekend.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
hi,
i committed the SIM client process for layer23. it turns reading and
writing jobs (from and to SIM files) into APDUs. because the SIM reader
is not yet finished, it cannot be tested yet.
after attaching the SIM card, a process in mobile/subscriber.c will
request all required files form that card before starting the network
selection process. (untested, as noted above)
the mobility management is now cleaned up: TODO comments in the source
code are replaced by SIM update commands to the SIM client.
in order to make mobile application work with public networks, we need
to perform the following steps:
- finish the SIM reader and interface in layer 1
- add BTSAP interface to layer23
- add measurement reports to both TCH and SDCCH4/8 (*)
- send updates for measurement report from layer23 via l23 api of layer
1
- add crpyto-key request to layer 1 and l1-l2 interface (dieter ?)
* tests showed that the measurement report on SDCCH4/8 is requred. if
not sent, the network releases a call (cleanly) after the mobile stays
for a some seconds on an SDCCH4/8 (probably waiting for measurements,
before completing the call). sending some dummy measurements completed
the call successfully.
beside that, the following issues need to be solved soon, in order to
make the layer 1 firmware usable and stable:
- additional structures for the libosmocore, see
http://home.eversberg.eu/osmocore.patch
<http://home.eversberg.eu/osmocore.patch>
- freeze of layer 1 after about 40-60 data messages, see
http://home.eversberg.eu/data.patch
<http://home.eversberg.eu/data.patch> for testing. after a few location
updates firmware freezes. (the location update will fail, because the
patch disturbs location updating process, but the bug show up.)
- syncing problem
- clock drifts away after sync
- subchannels 4..8 of SDCCH/8
and maybe
- tch mode l1ctl message to select signalling only / speech codec of
TCH/F / TCH/H. (including bearer capability processing in layer23)
regards,
andreas
Hi!
It's about time that we find some kind of graphical project logo for the
Osmocom project.
Osmocom is intended as an umbrella project for software like OpenBSC, OsmoSGSN,
OsmocomBB and others.
So it might even be interesting to have some kind of 'family' of logos that
all have the same general theme.... At least the bigger projects like OpenBSC
and OsmocomBB definitely deserve their own incarnation within that family.
If you want to contribute to our project but are not a die-hard C developer,
this is your option to contribute!
The logo must be under a license that permits use+modification for the
Osmocom project itself. Editability for the general public is not important.
With regard to formats, I would prefer something as SVG that we can then
render into pngs of various sizes whenever there is demand for it.
If you have a proposal, simply send it (or a link to a URL) to the
openbsc(a)lists.gnumonks.org mailing list.
Thanks in advance for any submissions!
--
- 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)
