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!
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 converted the X font 5x8 for use in BB and added an goto_xy
routine in case anyone wants to put something entertaining on
the LCD (besides Hello World).
Compared to the old 8x8 font..
- doesn't miss the topmost line of pixels :-)
- needs 475 bytes instead of 4k (only includes characters
ASCII 32 .. 126)
- allows for 19x8 characters on the screen
hello_world.bin prints out all glyphs for testing.
Applies to current "master" (as of 9.4.2010/15:30 MESZ).
Chris
Hi all!
In case you're interested, there seems to be a public project on
code.google.com that contains the build environment and baseband
firmware sdk from mediatek:
svn checkout http://mobile-phone-mtk-project.googlecode.com/svn mtk-project
Please note that I don't know about the legality of this. However, it
is distributed on a public server/service without any kind of
authentication...
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 like to change some tracked files without committing them. when i do
"git commit -a", every change is comitted.
sometimes i like to play with layer1 code or even change Makefile.inc,
but i don't want to reset my changes before committing.
any idea how to create a list of omitted files?
andreas
Hi!
I think we corrently have the following TODO list.
GSM Layer 1:
* implement transmit power control for transmit
* implement SDCCH/8 on TS1-7 (Sylvain)
* implement frequency hopping
* proper split between synchronous and asynchronous part of L1 (Harald)
* TCH/F support (Dieter, after L3 RR/MM/CC is working)
* A5/1 and A5/2 encryption support
GSM Layer 2:
* implement a real layer2 that deserves the name (full LAPDm implementation)
* properly encapsulate / abstract the L1 "MPH" primitives so L3 doesnt
call L1 directly anymore
GSM Layer 3:
* test most of the code that Andreas has written (depends on L1 / L2)
Misc:
* SIM card driver + ISO7816 FS API
* Battery charger driver
* UI framework
* minimal journalling flash file system
* decide which RTOS kernel we want to use (Harald)
* fully support a working firmware build for the openmoko gta01/gta02 GSM modem
using calypso romloader
For people who don't feel like they can take any of this work, there is some
other work, regarding the mid-term port to our next target platform:
* implement host utility for the medaitek MT622x romloader serial protocol
* try to get a minimal hello world codebase to run on the MT622x
* write hardware drivers for UART, PMU, I2C, SPI, ... of the MT622x
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 Harald,
On Wed, 28 Apr 2010 20:26:07 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote:
>
> GSM Layer 1:
> * implement transmit power control for transmit
> * implement SDCCH/8 on TS1-7 (Sylvain)
> * implement frequency hopping
> * proper split between synchronous and asynchronous part of L1 (Harald)
> * TCH/F support (Dieter, after L3 RR/MM/CC is working)
> * A5/1 and A5/2 encryption support
I can take care of
* implement frequency hopping
* A5/1 and A5/2 encryption support
in addition to
* TCH/F support
because this would fit together (just different setting on the GSM
testset to do frequency hopping or encryption with a TCH).
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
> This is a known problem, but despite working from morning through
night I
> really don't have any time to fix the various layer1 issues at the
moment,
> sorry. In fact, there are some fundamental changes/cleanups required,
and
> I've already literally spent days in coming up with an architecture
that seems
> to make sense to me :/
> I know it must be frustrating for you, but it seems our schedules
didn't match
> very well.
hi harald,
i am currently testing the process of cell selection. when i limit the
number of cells down to 1, i can test some parts of the process.
don't worry about frustrating me. i can wait until these issues are
solved. until then, there is so much more for me todo:
- system information parsing test
- testing location update procedure
- working on incomplete radio ressource process
- maybe start working on some layer 4 application (lcr interface)
regards,
andreas
hi,
while debugging my layer3 code and testing bcch_scan, i got the following problem:
the fist 'tuning' message L1CTL_NEW_CCCH_REQ to layer 1 works, system informations are received. subsequently tuning to another channel does not give any rx data. any idea?
andreas
Mit freundlichen Grüßen,
.-.
/'v'\
(/ \)
------------------------------------------------------------------"-"-
|_|
i.A. Andreas Eversberg
Network Operations / 2nd Level Data - KC Internet
Versatel Nord GmbH
Nordstr. 2
D-24937 Flensburg
Fon: +49-461-9099749 | Fax: +49-461-909960749
andreas.eversberg@versatel.de@versatel.de | www.versatel.de
Sitz der Gesellschaft: Flensburg, Registergericht: Flensburg, HRB 3395 FL
Geschäftsführer: Dr. Hai Cheng, Dr. Max Padberg, Joachim Bellinghoven
> - rslms_recvmsg() frees message if discriminator is not known,
otherwhise it forward it to rslms_rx_rll().
> - rslms_rx_rll() forwards messages to rslms_rx_rll_*_req(), but does
not free it when RLL message type is unknown.
it seems that the message is freed by the receiving layer (or function),
but i cannot understand why layer2_read() in main.c does it after
calling l1ctl_recv.
hi,
1) thanx for that info. i can see that you tried running it...
2) i have not checked it. i hope that msg->l3h points to l2 pseudo header.
3) before fixing that, i need to have an issue solved:
two approaches to free a message, if it passes a layer border?
a) the sending layer frees the message after calling the other layer.
b) the receiving layer frees the message.
i prefer the second approach, because the message can be queued by the receiving layer without duplicating it. but if i read lapdm.c, i cannot figure out what approach is ment to be used:
- rslms_recvmsg() frees message if discriminator is not known, otherwhise it forward it to rslms_rx_rll().
- rslms_rx_rll() forwards messages to rslms_rx_rll_*_req(), but does not free it when RLL message type is unknown.
this issue must be solved soon, i think.
thanx for looking at it,
andreas
-----Ursprüngliche Nachricht-----
Von: Sylvain Munaut [mailto:246tnt@gmail.com]
Gesendet: Montag, 26. April 2010 15:22
An: Andreas.Eversberg
Cc: baseband-devel(a)lists.osmocom.org
Betreff: Re: Layer 3 status
Hi,
> i will start testing it tonight and hope to get results soon.
Here's a few bug reports
Sorry, there are no 'proper' fix or patches for them, I just worked
around them with ugly hacks see if I could get up to LOCATION UPDATE
REQUEST, then it was kinda late ... I hope just pointing them out will
help you a bit anyway.
1) Typo in src/host/layer23/src/gsm322.c -> gsm322_a_sel_first_plmn
/* if no PLMN in list */
- if (plmn_first) {
+ if (!plmn_first) {
2) BCCH message don't have the same header.
See in src/host/layer23/src/gsm48_rr.c in gsm48_rr_unit_data_ind
struct gsm48_hdr *gh = msgb_l3(msg);
But in BCCH some message don't have this header and have a 'L2 pseudo
length' field ...
3) You do a msgb_free on messages in , but the layer 1 will actually
have freed those message already.
See src/host/layer23/src/main.c in layer2_read(struct bsc_fd *fd)
l1ctl_recv((struct osmocom_ms *) fd->data, msg);
msgb_free(msg); // <======
Sylvain
hi,
i like to give a short update about the current layer 3 development.
everything compiles, but is not tested and debugged yet. it is divided
into five processes:
- radio ressource
this process is partly complete. it implements functions to establish
radio ressource connection. especially handover and release/abort is not
implemented, but will follow soon. most things here depend on services
of the radio part. as the radio part gets more and more functionality,
the radio ressource can be more and more completed.
- mobility management
this process is complete. it also implements the location update
process.
- call control
this process is complete. the MNCC interface of the call control is
almost identical to the openbsc. therefore i would suggest to merge both
"mncc.h" header files and put them into osmocore. currently there is a
minimal application in mnccms.c which rejects any call. (any MS must at
least do this.) later, a small telephone application could be used.
- cell selection
this process is complete. it does not do any measurements on the radio
part for cell (re-)selection. what it does is taking the results and
storing them in a structure. the structure is then used for selecting a
cell. it also controls the frequency used by the radio part.
- PLMN selection
this process is complete. but the manual cell selection requires a user
interface, which does not yet exist. it uses informations from cell
selection process to select available networks.
the term 'complete' refers only to basic call/data service. there is no
VGCS, VBS, multislot, GPRS, SoSLA support. since there is no interface
to the SIM card process (reading of data / storing data), there is just
a comment in the source code whenever data has to be transferred from/to
the SIM. also some special things, like NCC or cell priorization may be
missing.
i will start testing it tonight and hope to get results soon.
regards,
andreas
Hello Sylvain,
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
>
> When you look deeper into the call, there is the PLL setup that is done
> even earlier, to ensure that it's finished by that 'start' time.
The earlier versions I refer to did no yet switch RX/TX for each burst,
they used to switch after four burst were received/transmitted. In those
versions only the ABB windows was used with the TPU, however we had the
same situation because the code till enabling the TPU took longer than
the "AT" value.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Sylvain,
On Sun, 25 Apr 2010 15:16:48 +0000, 246tnt(a)gmail.com wrote:
>
> * For RX it always worked for TS=0 because in l1s_rx_win_ctrl we put the
> first command AT(DSP_SETUP_TIME - 100) ... which when you do the modulo
> 5000 is somewhere around 4944. So when we start executing the TPU scenario
> in the interrupt handler, that first AT command will force to wait almost
> an entire frame and the rx window will be properly placed in the next frame.
To be true, I don't know where the "- 100" in the recent versions come
from. In earlier version the actual AT time was 54 (DSP_SETUP_TIME -
TSP_DELAY - 6). This is about 50 us. However we had the same situation
(actual processing happens in the next frame) because the time to
execute the code after the interrupt occured till the TPU was
enabled took a little bit more than those 50 us. Probably the
code has changed in recent versions so that it tooks less than
those 50 us and "- 100" is needed.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi all,
as this has been a quite weird bug so far, and Sylvain now seems to have
run into some related problems when trying to make a SDCCH8 on TS1 work,
I'll elaborate a bit more on it.
Before commit 0e9d250407f589cff312adc6c9e2c83f6af37de5, what happened was as
follows:
1) The time between the TDMA interrupt happening and starting to execute
l1_sync() and actually being able to configure the TPU window and tell the
DSP what to do was too short for performing the scheduled work in the
very same TDMA frame.
2) As a result, the actions that we thought were performed in the same TDMA
were actually performed one TDMA later. Somehow we must have had another
off-by-one error and thus the two errors compensated themselves in most
cases, particularly for Rx
3) When trying to send, we hand a MAC BLOCK of 23 bytes to the DSP, after
which the DSP has to do the FEC, Fire CRC, burst spreading, etc -
before being able to generate the bits for the furst burst. Those
bits then get sent over the TSP to the ABB (into its burst buffer),
from where they are sent based on TPU signals.
So what happened is that the data of the first burst was not in the
burst buffer yet, and the TPU signals triggered sending the last burst
of the previous MAC block, rather than the first burst of the current.
This is why Dieter added the
> tpu_enq_at(5000 - 10); /* TPU_CLOCK_RANGE - EPSILON_SYNC */
to l1s_tx_win_ctrl(), thereby delaying the TPU signal generation by one
TDMA frame. At that time, the DSP has by long finished writing the new burst
bits in to the ABB burst buffer, and we can transmit the correct burst data.
I personally believe it would be better to simply move the TDMA interrupt a bit
more ahead. Rather than occurring immediately before TS0, we could set SYNCHRO
in a way that it occurs at a defined point in time still quite a bit into TS7.
In this case we hopefully have enough time for the DSP to be able to transmit
in TS0, making the timing sequence easier to understand.
Hope that helps to explain...
--
- 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've playing for a while with the buzzer & PWT registers and I'm able to
hear 'sound' according to the frequencies supported. The thing I can't
not understand well is the relation between the PWT (pulse width tones)
and the PWL (pulse width light), if exists:
A) After loading some frequency into the PWT, set the volume and hear
the it, if I change PWT to BU in the ASIC_CONF_REG, backlight intensity
changes and sound stops.
B) With LT output selected in the ASIC_CONF_REG instead of PWL, changes
over the PWT registers produce nothing.
Hi,
I was reading the bl_mode_pwl function at backlight.c and found
that PWL_CTRL is being written at 0xfffe8002 (0xfffe8000 + 2)
which doesn't map to any known reg. According to the second datasheet
PWL_CTRL (Control Register (PWL_CTRL_REG) (Read / Write)) is located at
0xfffe8001.
maybe i'm wrong?
regards,
emerson.
Hi!
As you can see, there is not really that much progress throughout the last 2
weeks or so. Dieter and myself were the only two who actually looked at how
to driver the DSP, TPU and RF hardware, write the drivers for it and the
existing layer1 code. Now we're both busy with other (paid) work, and
the project almost seems stuck.
I would like to see this change. I'm quite sure there are some other folks
on this list who would be interested in diving in those lower layer bits
of the system. However, I also understand there is not all too much that
can be done without running your own non-hopping BTS (as we don't do frequency
hopping at the moment). So a working OpenBTS, OpenBSC setup or something
like a CMD55 or Racal 6103 are a precondition.
Nonetheless, a number of people on this list have access to those devices.
I'd like to encourage some other people to also look at this and remove the
dependence on Dieter and myself in that area.
Furthermore, members of the IRC channel have certainly noticed the growing
interest in a potential port to the Mediatek chipset based devicees. Mediatek
is churning out more than 95 million chipsets every quarter, so there is plenty
of phones around.
The data sheets, reference schematics and other training materials can easily
be found on a lot of chinese developer websites - as is the Mediatek SDK.
However, the critical layer1 and DSP API part is only provided in object code,
and the documentation does not document it.
Still I believe it is feasible. So if you want to stay out of the GSM part,
feel like the Calypso is too boring for you: Why not work on getting a minimal
custom software image for the MT622x running, including bootloader support,
keypad/touchscreen and graphics output? If that is done by the wider
community, the so-called experts can focus on looking at the GSM side of things
once they have time.
Even on the Calypso there are many tasks that still need to be finished,
including battery charging, power management, file system, SIM Card API,
etc.
If you know somebody who understands C development for microcontrollers and
wants to help building the worlds first Free Software GSM baseband chipset
software, please motivate them to join. We can really need every helping hand
we get.
Happy hacking,
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 found this, searching google/codesearch for 'ftm_cmd'
svn co http://hwplatform.googlecode.com/svn/trunk/
about 1.5G of datasheets, sourcecode, and tools
for various phones.
willem
Hi!
I've written an introductory text on GSM mobile phone architecture,
and before officially posting/announcing it, I thought I'd invite
the members of this list to do some review and give feedback!
--
- 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 Jake (and others),
On Tue, Apr 13, 2010 at 10:09:52AM -0700, Jacob Appelbaum wrote:
> > I've written an introductory text on GSM mobile phone architecture,
> > and before officially posting/announcing it, I thought I'd invite
> > the members of this list to do some review and give feedback!
>
> Do you have the latex available? It's hard to edit and send a diff of a
> pdf...
see attachment.
--
- 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 everyone,
prom is using the crc16 as implemented in the Linux Kernel for his bootloader
work, and I'm planning to add an optional crc16 check for sercomm. To have
crc16 easily accessible in baseband, this commit adds it to libosmocore.
Chris
Hi,
this patch adds a new DLCI, Numbered 11, which just echoes
whatever it recveices on the mobile back to the PC. It is
very useful for debugging serial port problems.
Chris
Hello Christian,
I had the suspicion that a UART reset in the code is missing,
however I could not verify that because I never had those
problems with wrong bytes.
Out of curiousity, have you tried if just the following line is
enough to fix the problems you noticed ?
> + uart_reg_write(uart, MDR1, 0x07); /* turn off UART */
This should cause the UART to be reset and I would expect that
setting the XON/XOFF characters is not needed as long XON/XOFF
handshake is not turned on.
Thanks and best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi,
I've seen a lot of systematic character swaps on the serial port,
especially in the vincinity of 0-bytes. As the XON/XOFF registers
are the only thing in the UART that look like they would consider
the actual data sent, I've added this initialisation to uart.c
This makes the problem go away completely on my C123.
To check for it I've added CRCs to the HDLC protocol and checked
for bad frames, and also compared them in a (patched) osmocon
that just sends random garbate in a special DLCI. The bad
frames I observed always looked like this (number in
parenthesis define number of omitted bytes, for brevity):
<------ good bytes ----------> <-recvd|sent-> <----- identical again ------>
d0 e0 00 00..(107)..f7 ce 17 c4 < 0c 00|00 0c > db 70 ba cb..(67)..d8 6d 3a 1f
31 e1 00 00..(47)..38 ca 2f e5 < 0c 00|00 0c > f8 a3 77 5f..(127)..5b 72 ff 4a
<-- good -> <--- bad -----> <---- good again ------------->
dc e1 00 00 < 0c 00|00 0c > 87 cb 24 83..(178)..2f 69 b3 51
ae e2 00 00..(167)..bd 18 6f a1 < 0c 00|00 0c > 2f 53 d2 b2..(7)..da c7 1b 63
dc e3 00 00..(131)..8e 2c b0 a8 < 0c 00|00 0c > 40 62 56 5f..(43)..f0 3a 47 f7
Formerly I was observing about 10 packets for every 2000 sent (with 192
bytes of payload each). Now, with the added initialisation, I see
(as the time of writing this email) 12000 packets with 192 bytes each
sent, with 0 bytes missing, corrupted, flipped).
Please have a look and tell me if it's helping for you. I'll send the
HDLC/CRC patch in another email.
Chris
Hello Andreas,
On Mon, 5 Apr 2010 17:20:24 +0200, "Andreas.Eversberg" <Andreas.Eversberg(a)versatel.de> wrote:
>
> i would like to participate (and others maybe too). what if we have
> somethink like a conference for all the people not in berlin?
>
> in our company we do it this way:
>
> - a conference number is dialed by all members.
> - a phone with hands free option can be used on one place where multiple
> members are.
> - netmeeting is used for presentation. this can also be via VNC remote
> desktop.
A conference call sounds good. If it is done this way, I would participate
too.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi,
when I tried to read the secure-romloader of an Alcatel VLE5-series
phone, I noticed a small bug in calypso_bootrom(), which prom already
tried to fix, but his fix only worked on targets which have nIBOOT tied
to high (Compal).
I've committed a fix for this to steve-m/pending.
Regards,
Steve
Hi!
Andreas has asked me about this, and it might be interesting to a wider
audience, so I've added the information to the wiki at
https://calypso.gnumonks.org/trac/wiki/libosmocore
Here's a copy of what I wrote there:
== Development Cycle ==
As we are still developing the GSM protocol stacks on the network side
(OpenBSC) and phone side (OsmocomBB),
every so often there is a need to add some new code to libosmocore.
Even worse, we sometimes need to break
the API and ABI of the library.
However, by keeping libosmocore in a separate git repository, we run
into one problem: Checking out an old
version of e.g. OpenBSC or OsmocomBB will result in failed builds, as we
don't remember which old version
of libosmocore was required. This makes debugging and things like git
bisect very hard to impossible.
In order to solve this problem, we use
[http://github.com/apenwarr/git-subtree git-subtree] to import the
full libosmocore.git repository into OsmocomBB.
This way, we ensure that there is always a compatible version of
libosmocore inside the tree if we check out old OsmocomBB versions from
git.
=== Making changes to libosmocore ===
'''NEVER COMMIT CHANGES DIRECTLY TO
osmocom-bb.git:src/shared/libosmocore'''
Instead, use the following process:
1. make your changes to your local copy of libosmocore
1. test them together with OsmocomBB and OpenBSC
1. test if libosmocore still builds for both host and target (ARM)
1. create a ''diff'' of your local libosmocore changes
1. apply that diff to the libosmocore.git repository
1. use the script in osmocom-bb.git/src/shared/update-libosmocore.sh
(uses git-subtree) to import your changes from libosmocore.git
1. test + commit your OsmocomBB changes that depend on the newly
introduced code to libosmocore
It is important that the steps are followed in the order state above to
ensure consistency of our repositories
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!
As Andreas has pointed out to me in a phone call yesterday and steve-m
mentioned on IRC: Building layer23 with the not-installed (make
install) libosmocore from osmocom-bb resulted in link failures.
I've now addressed those problems and the repo should be building just
fine again.
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 Prom!
I've now merged (a rebased version of) your prom/pending, including the
manifest part.
Only one minor issue that I've noticed: 'make clean' does not remove
the board/*/*.manifest.o files. Maybe you can fix that at some point.
Also, I think it would be better to only export a 'struct manifest' that
then has members for all the various parameters (so far only strings
with versions, but there might be more stuff in the future).
Thanks,
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 Harald,
On Thu, 8 Apr 2010 05:18:15 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote:
>
> Also, layer1 TX side still has a problem where it transmits the bursts
> all off-by-one timeslot, i.e. only 3 out of 4 bursts of a message are
> received correctly by the BTS, the other burst is sent at a different
> (wrong!) point in time, disturbing some other phone on the same cell.
With my fix from a while ago sending works as expected. In the meantime
I extended my test code so that I could also verify the correct behaviour
against a GSM test set when doing a Location Update.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
hi,
currently i am working on radio ressource layer and the sub processes
for 1) network selection, 2) cell selection, and 3) location update
trigger process. i have problems expecially with the cell selection
task. since it requires measurements and detection of carriers (for some
time depending on the slot configuration), it must work together with
the layer 1 (radio part). here are some examples of messages what i
think must exist between layer 1 and cell selection process:
(the primitive names are just examples and do not conform to GSM specs.)
L1CTL_DM_EST_REQ (which already exists) tune to a channel in dedicated
mode (by given channel, frequency and later hopping sequence)
L1CTL_IM_EST_REQ tune to a BCCH channel in idle mode (by given
frequency)
L1CTL_IM_EST_CNF confirm valid carrier signal.
L1CTL_IM_INFO_IND info when reading of BCCH was enough for a cell
selection (depends on the channel configuration), shall include
measurement
L1CTL_MEAS_IND periodic info of measurements from the selected channel.
(required for cell reselection)
take these only as examples, not as required messages. while reading GSM
05.08, this is what i think is required to do cell (re-)selection
process or abort radio connection if fails (below minimum level).
any help/ideas/suggestions?
andreas
Hi Andreas,
some comments to your issues.txt:
> How do we send MEASUREMENT RESULTS to RSL? (maybe RSL_MT_MEAS_RES)
> what triggers the sending? Or do we just send it from time to time to
> layer 1 where it is stored and sent when the time is right? (Then we
> might get something like RSL_MT_MEAS_CNF, so we can send the next one,
> if we have new measurements available, otherwhise the L1 will use the
> old measurement results and resends them without confirming it.)
measurement results are sent on the SACCH. The Layer1 has independent
transmit queues for the main channel (SDCCH/TCH) and its associated
SACCH. So the L23 code needs to send the respective packet to a
chan_nr/link_id that indicates transmission over the SACCH.
In the GSM TS, there is a primitive by which L1 can indicate that it
needs the next L23 message for a given channel, which we don't implement
(as we're tunnelling L1CTL through HDLC/serial, the answer would never
be back before the next TDMA frame anyway).
My suggestion would be: Have a fixed SACCH queue depth of 1 or 2 in
L1CTL, and every time we actually dequeue the frame (i.e. send it to the
DSP), send an indication of the current queue depth up to L23. We
should do this for both the main and the ACCH queue so higher layers can
implement some kind of flow control if they want.
> I need some RACH primitives like:
> - RACH request (tx_ph_rach_req already exists) including value and
> offset of RACH slot from now.
What exactly do you mean with 'value and offset of RACH slot from now'?
As we're operating asynchronously "now" is not defined precisely. I
think if you simply tell the L1 that you want to transmit at a specified
GSM time (modulo 51), we can schedule it that way.
L23 should understand the current CCCH/BCCH layout and determine which
lsots are applicable for RACH burst transmission. They can then either
say "please transmit at this full gsm time (uint32_t of the frame
number)" or "please transmit in next multiframe at fn % 51 == X where X
is something specified by L23"
> - RACH confirm, the RACK has been sent (with timeslot where is was sent)
that should be relatively easy to add, I'll add it during the next days.
Meanwhile we can simply assume that it was sent at the timeslot as
requested.
> Since RACH request must be queued in layer 1 until it the right slot
> is reached, I need to tell L1 to cancel it. Whenever I receive a
> confirm, I schedule the next one until the maximum number has been
> transmitted or until an IMMEDIATE ASSIGNMENT is received on CCCH.
I think we can ignore that for now. In the worst case, we send one more
RACH request than needed. I know this is dangerous if done by many
phones on real networks, but for our current goal of "getting something
working in our own gsm test network" this is the kind of shortcut we can
take.
I know your development style is very different. You seem to be trying
to implement something thats fully compliant with the spec. I usually
try to take a more incremental/iterative approach. Make something work
first, and then iteratively improve/complete it. I hope you can live
with the fact that at least for now, L1 doesn't have this support. If
you want, we can already define the L1CTL message for it but simply
ignore it on L1 until its implemented.
> RACH request on RSL:
> Does it make sense to put RACH request to the set of RSLms primitives?
> (i.e. RSL_MT_CHAN_REQ, not RQD!, RSL_MT_CHAN_CNF, RSL_MT_CHAN_CAN)
> What do you say?
I think we should mark them explicitly as RSLms_MT_* to make it obvious
that it is non-standard RSL. Otherwise, I agree. "CAN" for "CANCEL" is
probably causing misunderstanding, lets just write the full word.
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,
I've added support for the Calypso "non-secure" romloader in my branch
steve-m/osmocon.
This means we now can execute our code on devices like the Motorola
W220, the BenQ A38 (which I've used for development), and the OpenMoko
devices (can anyone try to cross-compile osmocon and see if it works?).
For more information see in the wiki:
http://bb.osmocom.org/trac/wiki/CalypsoRomloader
I also added a new model switch for the C140 (-m c140), which
automatically adds the "1003" string in the uploaded binary.
This is meant for use with proms loader, so now you can upload
loader.ramload.bin on the C139/C140 and J100i, and load the application
itself with osmoload.
Regards,
Steve
Hi Harald,
That's a bright idea for all the developers behind the project as well as
those observers around the project to make a brainstorm with the development
and evolution of the project.
It's a little pity, however, for those people not going to participate
directly in the Developer Meeting at CCC near Berlin. If setting up a "green
pathway" connecting to the live meeting on the internet, so the people
strongly wanna share their ideas with others will be able to join into the
Developer Meeting simultaneously.
If there has difficulty in doing such things, maybe recording and uploading
the live video of the meeting into the public wiki of the project is another
way to share the content and fun of the meeting together with other people
all around the world.
Thanks.
Best Regards,
Samuel
On Mon, Apr 5, 2010 at 6:00 PM, <baseband-devel-request(a)lists.osmocom.org>wrote:
> Send baseband-devel mailing list submissions to
> baseband-devel(a)lists.osmocom.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.osmocom.org/mailman/listinfo/baseband-devel
> or, via email, send a message with subject or body 'help' to
> baseband-devel-request(a)lists.osmocom.org
>
> You can reach the person managing the list at
> baseband-devel-owner(a)lists.osmocom.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of baseband-devel digest..."
>
> Today's Topics:
>
> 1. Developer Meeting in Berlin / 2010-04-10 (Harald Welte)
> 2. Re: noisy cable? (Nathan Fain)
>
>
> ---------- Forwarded message ----------
> From: Harald Welte <laforge(a)gnumonks.org>
> To: baseband-devel(a)lists.osmocom.org
> Date: Mon, 5 Apr 2010 09:24:45 +0800
> Subject: Developer Meeting in Berlin / 2010-04-10
> Hi all!
>
> Since I'm returning from holidays in two days, I think it's a good idea
> (for those who are in/around Berlin) to meet again at CCC Berlin.
>
> This is mainly for me to get an idea where we are (compared to before my
> holidas) and how we proceed. Especially the loader seems to have made
> progress, as far as I can tell from casual reading of the commitlog.
>
> I'm also curious to see what's happening on the battery charger, sim
> card reader (and other) parts of the system.
>
> I'd say we'll meet from 7pm on at the CCC Berlin. Anyone interested in
> joining, feel free to join!
>
> Cheers,
> 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)
>
>
>
>
> ---------- Forwarded message ----------
> From: Nathan Fain <nat(a)fains.com>
> To: baseband-devel(a)lists.osmocom.org
> Date: Sun, 04 Apr 2010 22:17:38 -0700
> Subject: Re: noisy cable?
> fyi, using the /dev/cu.** variant solved my problem of osmocon being
> unable to write CMD1 to the port. At least, it worked with an FTDI
> cable I built. I imagine it will solve the issue with the prolific
> cable as well (will try later).
>
>
>
> On 29/03/2010 03:39, willem wrote:
> > i managed to get hello_world working on my c121, connected through a
> > pl2303 usb/serial cable to my macbookpro.
> >
> > but found that the connection is extremely noisy.
> > often the movement of me putting down the phone on the table is enough
> > to break the upload.
> > is that a common problem with these headphone/serial cable plugs?
> >
> >
> > for the serial device i can use /dev/cu.PL2303-0000201A
> > or /dev/tty.PL2303-0000201A
> >
> > but when using the '/dev/tty...' variant, i have to add this to
> osmocon.c
> >
> > diff --git a/src/host/osmocon/osmocon.c b/src/host/osmocon/osmocon.c
> > index f934dd7..b361eb1 100644
> > --- a/src/host/osmocon/osmocon.c
> > +++ b/src/host/osmocon/osmocon.c
> > @@ -128,6 +128,9 @@ static int serial_init(const char *serial_dev)
> > /* hardware flow control off */
> > options.c_cflag &= ~CRTSCTS;
> >
> > + /* ignore modem status lines */
> > + options.c_cflag |= CLOCAL;
> > +
> > /* software flow control off */
> > options.c_iflag &= ~(IXON | IXOFF | IXANY);
> >
> > =============================
> >
> > willem
> >
> >
> >
> >
>
>
>
>
> _______________________________________________
> baseband-devel mailing list
> baseband-devel(a)lists.osmocom.org
> https://lists.osmocom.org/mailman/listinfo/baseband-devel
>
>
hi harald,
i would like to participate (and others maybe too). what if we have somethink like a conference for all the people not in berlin?
in our company we do it this way:
- a conference number is dialed by all members.
- a phone with hands free option can be used on one place where multiple members are.
- netmeeting is used for presentation. this can also be via VNC remote desktop.
is it possible for you in berlin to establish a VNC server with multiple access, or at least something like a "screen" command?
my PRI test machine in my company can be used as conference server for up to 30 parties. it has a german dial-up number.
regrads,
andreas
-----Ursprüngliche Nachricht-----
Von: baseband-devel-bounces(a)lists.osmocom.org [mailto:baseband-devel-bounces@lists.osmocom.org] Im Auftrag von Harald Welte
Gesendet: Montag, 5. April 2010 03:25
An: baseband-devel(a)lists.osmocom.org
Betreff: Developer Meeting in Berlin / 2010-04-10
Hi all!
Since I'm returning from holidays in two days, I think it's a good idea (for those who are in/around Berlin) to meet again at CCC Berlin.
This is mainly for me to get an idea where we are (compared to before my
holidas) and how we proceed. Especially the loader seems to have made progress, as far as I can tell from casual reading of the commitlog.
I'm also curious to see what's happening on the battery charger, sim card reader (and other) parts of the system.
I'd say we'll meet from 7pm on at the CCC Berlin. Anyone interested in joining, feel free to join!
Cheers,
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 current state of coding can be seen in the
src/host/gsm48-andreas/README file of GIT. as noted there, the process
of mobility management and call control is completed. this does not mean
that it is compiling and working. als debugging has to be completed. the
next step would be to follow the compiler errors step by step until all
missing and wrong symbols are found and fixed. i will do that later.
also the radio ressource is at a point where i like to start integrating
it into the layer23 application. today i checked out how the system
informations are received and how to send a random access burst. please
check out the issues about that at src/host/gsm48-andreas/issues.txt in
the GIT.
i must note that layer3.c and rslms.c is not needed in my case, since it
is part of gsm48_rr.c
in order to integrate it, i would like to open a new branch, since there
are many other existing files to be expanded. (new structures to header
files... see extra.c and extra.h) there must also be a way to get all
the changes in the master branch merged to the new branch, so i can
react on changes of master branch. i am not that familiar with git, so
is there any advice except cherry-picking all the time? or maybe there
is a better way of doing that?
andreas
i managed to get hello_world working on my c121, connected through a
pl2303 usb/serial cable to my macbookpro.
but found that the connection is extremely noisy.
often the movement of me putting down the phone on the table is enough
to break the upload.
is that a common problem with these headphone/serial cable plugs?
for the serial device i can use /dev/cu.PL2303-0000201A
or /dev/tty.PL2303-0000201A
but when using the '/dev/tty...' variant, i have to add this to osmocon.c
diff --git a/src/host/osmocon/osmocon.c b/src/host/osmocon/osmocon.c
index f934dd7..b361eb1 100644
--- a/src/host/osmocon/osmocon.c
+++ b/src/host/osmocon/osmocon.c
@@ -128,6 +128,9 @@ static int serial_init(const char *serial_dev)
/* hardware flow control off */
options.c_cflag &= ~CRTSCTS;
+ /* ignore modem status lines */
+ options.c_cflag |= CLOCAL;
+
/* software flow control off */
options.c_iflag &= ~(IXON | IXOFF | IXANY);
=============================
willem
Hi all!
Since I'm returning from holidays in two days, I think it's a good idea
(for those who are in/around Berlin) to meet again at CCC Berlin.
This is mainly for me to get an idea where we are (compared to before my
holidas) and how we proceed. Especially the loader seems to have made
progress, as far as I can tell from casual reading of the commitlog.
I'm also curious to see what's happening on the battery charger, sim
card reader (and other) parts of the system.
I'd say we'll meet from 7pm on at the CCC Berlin. Anyone interested in
joining, feel free to join!
Cheers,
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,
today i will finally (begin to) structure the message handling in my
current work on layer 3:
the message handling functions consist of:
- message cration
- message sending
- message en-queueing
- message de-queueing
i deal with interfaces (SAP):
- between application and call control (MNCC-SAP)
- between call controll and mobility management (MMCC-SAP)
- between supplementary services protocol and mobility management
(MMSS-SAP)
- between sms protocol and mobility management (MMSMS-SAP)
- between mobility management and radio ressource (RR-SAP)
- between radio ressource and layer 2 / layer 1 (let's call it
RSLms-SAP)
additionally there are interfaces:
- between application and mobility management
- between application and PLMN search
- to the sim card
- to the application
- ...
here is what i think the messages should look like. please correct me if
i am wrong or if you have suggestions:
MNCC-SAP:
<gsm48_mncc structure>
MMCC-SAP, MMSS-SAP, MMSMS-SAP:
<gsm48_mmxx structure>[<L3 message*>]
RR-SAP:
<gsm48_rr structure>[<L3 message*>]
RSL-SAP:
<abis_rsl_rll_hdr structure>[<L3 message*>]
* the layer 3 message consists of the gsm48_hdr structure + additional
information elements.
if a layer 3 message moves from call control down to RSL and even lower,
the inter-layer headers are pulled and pushed. additionally there are
pointers to the beginning of the headers inside the message:
- l1h
- l2h
- l3h
- layer 4 headers
- layer 5 header
the inter-layer messages (MMxx-SAP and RR-SAP) will have no pointer to
the message structures. i think they also should not have them, since
they have fixed length and are pushed at the time they are sent, and
pulled at the time they are received.
any suggestions?
andreas