| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The SIs are kept per ARFCN and for the current cell the
cs->si alias will be assigned[1]. On mobile_exit all SIs
will be freed but the alias will not be set to NULL.
This is a speculative fix but it doesn't seem to make
things worse.
Related: OS#2690
[1] cs->si = cs->list[cs->arfci].sysinfo;
Change-Id: Icf20f9aa03dd26d4bee78772b7f3da034bb34b99
|
|
Add a mobile application logging category and replace printf with
a LOGP. The code is sadly still using exit in the middle of handling.
Change-Id: I71e7f6e6375a485b45bad76ada2be17b0901577d
|
|
Change-Id: Ic12587a6c6456b8663e5357cf68a22c6d1927a07
|
|
This change prevents a possibility of calling memset()
with constant zero length parameter, and the corresponding
compiler warning.
Change-Id: I2d8d78474614939659a7f24d5007b1c890776b1a
|
|
As we use talloc, it's absurdly not to use the main feature of
the library - hierarchical memory management. This change sets
talloc context of all sub-allocated objects to related osmocom_ms
instance. So, as soon as osmocom_ms instance is destroyed, all
sub-allocated chunks are getting destroyed too.
Change-Id: I6e3467ff739f3e6dc8dd60cc6d1fcd3f8e490ce9
|
|
The approach of talloc memory management reduces memory usage,
and prevents some buffer overflows, which were possible before.
Change-Id: Icd6706117fdd7f1b3481b0e3817bbb3b31f12f60
|
|
Change-Id: I4a3aaa0465598b17ccd30ec4cbeb90429216540e
|
|
Change-Id: I74ad6e540c98ab4914e7a2ea725dd23f5a2fd034
|
|
All levels in range of 0..63 are now uint8_t and use "rxlev" as
variable name. All levels in range of -110..-47 are now int8_t and use
"rxlev_dbm" as variable name.
|
|
As andreas points out, there are structure members that are called
'rxlev' but which don't use the scaling (0..63) of the GSM specs, but
which are already a signed type and in dBm. So they need to be
converted.
TODO: Rename those structure members to rxlev_dbm or something that
explicitly states it is _not_ an 'RXLEV' value in terms of GSM.
|
|
As Dieter points out, this drastically improves the resiliance to high
receive levels on the C155. We cannot blindly assume a received signal
level of -85 dBm if the BTS is 2m away and we actually receive -40 dBm.
This patch extends the L1CTL_FBSB_REQ data structure in layer 1 with the
respective field, as well as the l1ctl_tx_fbsb_req() API function called
from the various layer23 apps.
"mobile" and "bcch_scan" already did a PM request and thus know the
expected signal power. "ccch_scan" and "cbch_sniff" apparently don't
do, so the -85 dBm constant is now hardcoded into the host-side source
code there, and should probably be fixed in a follow-up patch.
|
|
log message
|
|
If you enable PCS, you'll never make it out of power-measurement without
this patch.
|
|
Basically, there were two commands in an "else" block without brackets,
causing the
"end = 1023+299"
command to execute regardless of the state of index.
Signed-off-by: Andreas Eversberg <jolly@eversberg.eu>
|
|
Test showed that loosing the signal in dedicated mode caused a complete
rescann of all cells. By keeping the cell selected, the process can use
the neighbour cell informations to do a quick search for the best cell
afterwards.
|
|
|
|
This patch introduces cell re-relection. When camping on a cell, it
scanns neighbour cells. If a 'better' cell is found, the cell is selected.
If the cell is in a different location area, a location upating is
performed under certain conditions.
The 'better' cell depends on various informations that are broadcasted on
the BCCH of a neihbour cell and of course the RX level. Most operators
don't set these informations, so the 'better' cell depend on a better
RX level for the same location area, or a much better RX level (6 dBm)
at a different location area.
There were many issues at the idle mode process that has been fixed.
Expecially when moving, the state machines got stuck, so no more cell search
was possible, or no further calls / location updating was possible.
In order to see the process of cell selection, enter the VTY interface and
enable the network monitor:
enable
monitor network 1 (where '1' is the instance of the MS)
In order to see the current state of the processes, enter:
show ms
|
|
this is apparently a result of no longer including it indirectly via lapdm.h
|
|
This makes it possible to use GSM 850 and PCS 1900 bands, as used in the
US. The support relies on the phone hardware.
Each band (900, DCS, 850, PCS, 480 and 450) can be enabled and
disabled individually for each setting.
|
|
Summary of changes:
s/struct timer_list/struct osmo_timer_list/g
s/bsc_add_timer/osmo_timer_add/g
s/bsc_schedule_timer/osmo_timer_schedule/g
s/bsc_del_timer/osmo_timer_del/g
s/bsc_timer_pending/osmo_timer_pending/g
s/bsc_nearest_timer/osmo_timers_nearest/g
s/bsc_prepare_timers/osmo_timers_prepare/g
s/bsc_update_timers/osmo_timers_update/g
s/bsc_timer_check/osmo_timers_check/g
|
|
This patch changes include paths to get osmocom-bb working with
the current libosmocore tree.
Among all these renames, you can notice several tweaks that I
added on purpose, and that require some explanation, they are:
* hexdump() in osmocon.c and osmoload.c has been renamed to avoid
clashing with hexdump() defined in libosmocore.
* gsmmap now depends on libosmogsm. Actually I had to cleanup
Makefile.am because I was experiencing weird linking problems,
probably due to a bug in the autotools. With the change included
in this patch, I got it compiled and linked here correctly.
This patch has been tested with the phone Motorola C123 and the
following images files:
* firmware/board/compal_e88/hello_world.compalram.bin
* firmware/board/compal_e88/layer1.compalram.bin
Using the osmocon, bcch_scan and mobile tools.
Signed-off-by: Pablo Neira Ayuso <pablo@gnumonks.org>
|
|
This should remove the last dependency to hard-coded system-wide /etc/osmocom
|
|
All functions for handling mobile instances and mobile relevant parts are
moved to mobile/app_mobile.c, the mobile/main.c and mobile/mncc.c become a
simple out-of-the-box mobile application. (making calls)
The mobile/main.c can be replaced easily by a different application now.
this application may have it's own call control implementation (layer 4).
Full configurations via VTY is still possible and required in this case.
|
|
To create another instance: 'ms <name> create'
To remove an instance: 'no ms <name>'
If no instance exists, 'ms 1' is created automatically on startup.
Each instance can be enabled / disabled by using 'shutdown' or
'no shutdown'. Multiple instances may share the same layer2 socket (same
phone hardware), but in this case only one instance can be enabled at the
same time. This makes it much easier to select different settings without
modifying them.
A 'shutdown' initiates the IMSI detach procedure before shutdown is
completed. A 'shutdown force' will immidiately shutdown.
There is no need to restart the software anymore, if fundamental settings
are changed. In this case, a 'shutdown' followed by a 'no shutdown' will
do the job.
If you already have an old osmocom.cfg, you need to "no shutdown" it.
Everything else behaves as before.
|
|
|
|
|
|
|
|
The cell must be kept "selected" in case of loosing radio link. It is
required to perform reselection of that cell or of the given neighbor
cells.
|
|
|
|
There are two criterions for lossing a signal, idle mode and dedicated mode.
A counter counts down when a frame is dropped, and counts up when a valid
frame is received on certain channel. The loss criterion is reached, if the
counter reaches 0. The values added to / removed from the counter and the
limits depend on the process.
|
|
The default (if config not yet created/updated), is still taken from
settings.c.
|
|
|
|
This way the SYSINFO is logged once and not three times.
|
|
|
|
This way all frequencies are scanned, in case they meat the minimum
receive level.
|
|
This way the syncing and cell selection can be reviewed much better.
|
|
|
|
The cell provides SYSTEM INFORMATION 5* and 6. These are used to create a
list of neighbor cells to monitor. Because there is no neighbor cell
monitoring supported by layer1, the list has no valid results yet.
Currently the average RX level of received frames are used to generate a new
report every second. The report is transmitted to layer1 and used there
whenever a measurement report has to be transmitted.
The timing advance and the current transmit power (as requested by network),
is included with every report.
|
|
The SIM client is now complete. Because it usefull for multiple
applications, i moved it to the layer23/src/common directory.
The SIM reader works together with mobile process. Fixes were made.
Thanx to all for testing, finding bugs, and making it work as it is
supposed to do.
The current version uses special L1CTL messages to send and receive APDUs.
This will change in the future, when BTSAP interface is completed.
Please note that this client will not work until the layer1 SIM reader
fixes and extensions are committed.
|
|
The SIM reader can be selected via VTY, but because it is not yet
implemented in layer1, nothing happens when selecting it.
|
|
This split the headers and adapt the source.
We use osmocom/bb as a prefix because libosomore also
uses osmocom and generic names such as misc & common could
conflict in the future.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
We split into :
- common: Everything that can be shared
- mobile: The real spec compliant mobile phones
- misc: Different test stuff
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
