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)
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!
I've been offered a 'developer room' at FrOSCon 2010 (http://www.froscon.de/)
which will be at FH Bonn-Rhein-Sieg (http://www.fh-brs.de/) in Sankt Augustin
from August 21/22 this year.
Before sending a response, I would like to inquire whom of you would actually
have any intention of visiting this conference and spending time in the
developer room to work on OpenBSC or OsmocomBB ?
I think the idea is great to meet some of you guys [again], not only at the
annual CCC congress in winter. But there is little point for me to go there if
there is no interest from the wider project community.
Please provide your feedback ASAP.
--
- 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 have been looking for sometime at OsmocomBB project, but haven't tied it yet.
I have seen that software supports a number of Compal phones :
Supported Phone hardware
Information specific to certain Calypso based phones that we support
Designed + Manufactured by Compal, OEM by Motorola
MotorolaC115/C117 (E87)
MotorolaC123/C121/C118 (E88) -- our primary target
MotorolaC140/C139 (E86)
MotorolaC155 (E99) -- our secondary target
MotorolaV171 (E68/E69)
SonyEricssonJ100i
So, I was wondering:
1) Which would be best to have to start with, as the most supported target ?
2) Where I can get this phone quickly and easily ?
3) What additional equipment is needed (how do you flash the software
and how do you debug) ?
4) Is there some software simulator in which I could see what is
happening and how the SW works without actual HW equipment ?
Best regards,
Drasko
hi,
i like to do extensions to the RSLms layer of osmocom. before that i
like to ask and discuss if this would be the correct way:
instead directly of calling l1ctl_* functions of l1ctl.c, i would like
to use RSL messages between layer 2 and layer 3. the lapdm.c would then
convert these messages and call l1ctl_* functions. (maybe i could split
up lapdm.c into lapdm.c and layer2.c. the selecting the handler for an
RSL request could be made at layer2.c, as well as selecting the right
handler for the frames received from layer1. only the lapdm part could
be handled in lapdm.c. )
the RACH request could be sent using RSL_MT_CHAN_RQD, the confirm could
be the same message type, but i prefer to invent a new one: 0x18, but
using the same IE layout. also including RSL_IE_MS_POWER_PARAM with the
RACH request, could tell the layer 1 about usage of power and TA (which
is normally 0 for RACH request).
the (UNIT) DATA request may also include RSL_IE_MS_POWER_PARAMS. if
omitted, the stored value from the last message with
RSL_IE_MS_POWER_PARAMS could used.
the (UNIT) DATA indication and request of SACCH may include
RSL_IE_L1_INFO IE to receive power and timing control as well as send
the actual power and timing advance. i could handle these IE at layer 3
(radio ressource) and forward them to layer 1 (RSL_IE_MS_POWER_PARAM)
depending on the supported radio power and on special VTY settings to
mess with power and fake timing advance.
regards,
andreas
Hi!
As indicated in other mails, we now have support for gcc-style constructors
in OsmocomBB. The way to use them is relatively easy: Simply put
"__attribute__((constructor))" at the function that you want to be
called during initialization.
The way how this works is like this:
* gcc and the linker create a table of function pointers to all the
functions with that attribute
* the code in compal_ramload_start.S takes care of calling
lib/ctors.s:do_global_ctors() which iterates over the list
and calls each constructor
This concept is now used for things like prim_fbsb_init() in layer1,
but I have also started to use it for board_init(). This means that
board_init() no longer needs to be called from the main() function
of each app.
We can probably put more stuff into constructors, but we should also
be careful as with gcc-4.0.2 we cannot yet indicate priorities and thus
there is no explicit way to control the ordering in case of dependencies.
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!
JFYI: The AGC control in L1 is now active. At least it didn't make things
worse for me. Maybe people who have had problems acquiring weak cells
should give it a try again.
I've also fixed some compile problems due to a missing header file,
and there is now a L1CTL_DM_REL_REQ where Layer23 can explicitly release
the dedicated mode and return to idle mode.
Right now the 'mobile' program (specifically gsm322/gsm48_rr) issue another
L1CTL_PM_REQ after a location update reject hap[pens, i.e. layer1 is still
in dedicated mode but it gets some power measurements. This results in
L1 trying to do Transmit in parallel with power measurements and it
crashes at some point.
I suggest to add the L1CTL_DM_REL_REQ into the state machine, I suppose
it should avoid that problem.
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,
The good news, is that hopping and ts[0:4] work just fine and were
surprisingly easy to implement. The bugs I thought I had were in fact
not related to these and just prior bugs that were never noticed
before. (see my sylvain/testing branch).
Only L1 is changed, so you'll need to tweak l23 (either the mobile app
or layer23 for quick tests) if you want to try them out somehow.
Current limitations:
- SDCCH8 subchannel 4,5,6,7 won't work.
For those, we need to TX and RX in the same frame ... which just
isn't possible with the way the primitives work right now. (each
assume to have the full frame for themselve).
- TS >= 4 may not work
When using TS>=4 we should also change the interrupt alignment so
that the DSP still has time to do it's job. Switching 'forward' is
easy, but when switching 'back', we need to be conscious that we need
to skip 1 frame at the very least ...
IMHO to solve both those issue, we need a better scheduler/primitives
that possibly have some knowledge of the 'span' (in terms of qbit) of
each operation. Because if we do a TX on TS=5 for instance, there is
no way we can do a RX on TS=0 on the next frame, the tpu window
overlap.
- No ciphering.
That should be trivial to add. Just setup the fn and the kc and set
the flag ... the 'l1s.next_time' contains the godd time of the frame
TX/RX frame during the primitive execution, so that's the FN to use.
Once that's done, the few bits missing from mobile app could be
added (and from a quick look, not much is missing ... just the l1ctl_*
calls because they don't exists yet) and a full location update with
auth and ciphering could be done.
The need for a SIM interface grows quickly :)
Some 'gotchas' you might encounter that are not fixed yet:
- The L1 completion handler crashes.
In target/firmware/layer1/prim_tx_nb.c ,
l1s.completion[L1_COMPL_TX_NB] is set in l1s_tx_test() but that's
never called. So you need to comment out
l1s_compl_sched(L1_COMPL_TX_NB) in the 'resp' handler temporarly until
a proper fix.
- Wireshark SDCCH8 subchannel decoding in IMMEDIATE ASSIGNEMENT is
just plain wrong. (source code uses % 0x38 instead of & 0x38), need to
send a patch for this
- layer23 doesn't currently filter much the IMM.ASS it receives so
you may end up on a channel that's not yours ... beware.
Sylvain
> - layer23 doesn't currently filter much the IMM.ASS it receives so
> you may end up on a channel that's not yours ... beware.
hi sylvain,
what do you mean with "much"? i filter the channel with the channel
request number (includes random number) in the IMM.ASS message. maybe in
the future we can filter the time slot where it was sent (RACH confirm)
and compare it also. but this requires RACH confirm with GSM time where
it was sent.
andreas
@harald: is there any time stamp in the RACH confirm? what format would
it be?
.... from the IMM.ASS parsing:
/* 3.3.1.1.2: ignore assignment while idle */
if (rr->state != GSM48_RR_ST_CONN_PEND || !rr->wait_assign) {
LOGP(DRR, LOGL_INFO, "Not for us, no request.\n");
return 0;
}
/* request ref */
if (gsm48_match_ra(ms, &ia->req_ref)) {
/* channel description */
memcpy(&rr->cd_now, &cd, sizeof(rr->cd_now));
/* timing advance */
rr->cd_now.ta = ia->timing_advance;
/* mobile allocation */
memcpy(&rr->cd_now.mob_alloc_lv, &ia->mob_alloc_len,
ia->mob_alloc_len + 1);
rr->wait_assign = 0;
return gsm48_rr_dl_est(ms);
}
LOGP(DRR, LOGL_INFO, "Request, but not for us.\n");
