What I find weird is that the gsmmap is using files from layer23,
and vice-versa cell_log from layer23 is using files from this
utility. And somehow they are separate sub-projects.
I see no reason why gsmmap must be in its own sub-project.
Change-Id: I2bc9c8897f3c7ccf207be0146f7b55fc733a6abb
This will be needed for the modem application, and is also used
in a follow-up commit adding support for parsing SI13 Rest Octets.
Change-Id: I8e0f826c9b2a886f94624176e34e7d197e93d25f
Related: OS#5500
Accessing a header file from outside of the sub-project requires
using the relative path ("-I$(top_srcdir)/../layer23/include"),
which does not resolve properly during make distcheck.
The '../layer23/include/l1ctl_proto.h' is actually a symlink too.
Change-Id: Id64ab161a17d53f5e93cdd100e81d4fb8acfb97a
It's not really clear to me how the L1 is supposed to handle the
L1CTL_DM_REL_REQ message, which maps to the TRXCON_EV_DCH_REL_REQ
in our case. Lookig at the layer23 code I see that it's sent along
with the L1CTL_RESET_REQ (maps to the TRXCON_EV_RESET_SCHED_REQ).
The layer1 firmware does reset some parameters on receipt of the
L1CTL_DM_REL_REQ and some more parameters on the L1CTL_RESET_REQ.
It's clear though that we should not switch to the TRXCON_ST_RESET
on receipt of the L1CTL_DM_REL_REQ. The layer23 application
(e.g. mobile) may send L1CTL_DM_EST_REQ right after that, and we
won't be able to transition from the TRXCON_ST_RESET directly to
the TRXCON_ST_DEDICATED. Such transition is neither implemented
nor permitted by 3GPP TS 44.004, Figure 5.1.
Ideally, according to 3GPP TS 44.004, Figure 5.1, we should have
an additional transient state 'TUNING DCH' in the trxcon_fsm and
switch there on reciept of the L1CTL_DM_REL_REQ. But currently
it's not implemented and adding it would require some effort.
As a temporary solution, let's do not change the current state and
stay in the TRXCON_ST_DEDICATED. This workaround is needed to make
mobile terminated calls work in the mobile app.
Change-Id: I5bbe6ca4cc6299f9faf343822c992a6872a45081
Related: OS#5599
Sometimes I am seeing error messages like this:
DCS ERROR Failed to write BA list
The problem is that there can be several BA entries which need to
be written, and for each of them we're calling fwrite() twice.
This function returns number of items written, so the final sum
of returned values would be: len(BA list) * 2. Thus expecting
it to be 2 regardless of len(BA list) is wrong.
Fix this by checking the sum in each iteration, not at the end.
Take a chance to refactor the code and move to a function.
Change-Id: Id8bc216c146127d9c9995379c9e56450d328f46d
The mobile app crashes when using a Calypso phone and specifically
when using its built-in SIM reader. The problem is that msg->l2h
is NULL in rx_l1_sim_conf(), so msg->l1h must be used instead.
Assert failed msgb->l2h /usr/local/include/osmocom/core/msgb.h:162
Change-Id: I7c68a3ad393be5fd0413e00e119a06db59672357
This is needed for SDR based PHYs, because for them it takes longer
to tune, flush the buffers and so on. Add a field to the trxcon_inst
structure and a command line option (-F) for the trxcon app.
Change-Id: Ia68954c5bdacda45fc871ffea0ccdf2460936408
Related: OS#5599
In the upcoming patches I am adding a possibility to enlarge the FBSB
timeout by providing API for that. This is needed for SDR based PHYs,
because for them it takes longer to tune and so on. The L1CTL codec
is not the right place for applying PHY specific quirks, so let's
move the TDMA FNs -> ms conversion to the FSM logic.
Change-Id: I685f48cfed000997b0d7c16073c6387bc05d2bbe
Related: OS#5599
The *cnf param of l1ctl_tx_dt_conf() was already declared as const
in the header file, however it was not in the actual function
definition. Take a chance to fix formatting in the header.
Change-Id: I842ac717a6959830c536cbf91efdbb6a4ee931ce
Includes RF frontend configuration, TIFFS config, keymap.
Currently still using the rf_tables and afcparams from gta0x.
No display driver yet.
Make sure to run osmocon with -m romload -i 10
Change-Id: I711702862b1cec5a8089dac071f8a171ca026003
This is a partial revert of d49a748cbb.
The GAPK based audio I/O implementation of the mobile app is now capable
of handling TI's specific TCH frame format, which can be configured via
the VTY interface ('io-tch-format ti'). Thus there is no need to have
the conversion logic in the firmware anymore.
This patch also fixes the layer1 firmware, so it does not hang on
receipt of Uplink TCH frames anymore when compiled with recent
arm-none-eabi toolchain (v12.2.0 on my machine).
Change-Id: I5afd4e4ddd9c06d32768d01bc1e3e18d476706fb
Related: OS#3400
This is a partial revert of 8f04fa9758.
The GAPK based audio I/O implementation of the mobile app is now capable
of handling TI's specific TCH frame format, which can be configured via
the VTY interface ('io-tch-format ti'). TCH frames in this format are
different from the ones in RTP format and may have different length and
different bit ordering. Remove voice_frame_verify().
Change-Id: I6113ba443e65ddaae091b643af54c873b7da4de8
Related: OS#3400
Do not assert() in gsm_recv_voice(), because channel release does
not happen immediately and the PHY may be still sending TCH frames.
Change-Id: I8943ee9bd46afc96e6d7cfd52c95c34fd311ce11
Related: OS#3400
It may happen that the MS needs to go directly from a PDCH to a TCH
or SDCCH, e.g. in case of a Mobile Terminated call. I don't know
if the opposite transition is needed on practice, but let's simply
allow direct transitions for both TRXCON_ST_{DEDICATED,PACKET_DATA}.
Change-Id: I1a854e4683f102c40f1c174a291b6dc638f49b5c
Related: OS#5599
According to 3GPP TS 44.004, Figure 5.1, it's absolutely legal to
perform loop transitions in state 'DCH' (i.e. from 'DCH' to 'DCH').
This kind of transition is needed in the following cases:
* on reciept of RR FREQUENCY REDEFINITION,
* on reciept of RR ASSIGNMENT REQUEST,
* on reciept of RR HANDOVER REQUEST,
when going back from state 'DCH' to state 'BCH' is not required nor
actually desired. In context of the trxcon_fsm, this applies to
both TRXCON_ST_DEDICATED and TRXCON_ST_PACKET_DATA, as they both
represent what's defined as 'DCH' in the Figure 5.1.
Change-Id: I3b402ec84610a5df744d9b06e5f7dab7a9a3ddad
Related: OS#5599
This new function will be re-used in a follow up patch implementing
handling of TRXCON_EV_DCH_EST_REQ in TRXCON_ST_{DEDICATED,PACKET_DATA}.
Change-Id: I8db93fcdace7aaa8bc3876b14e441304349a36d5
Related: OS#5599
According to 3GPP TS 44.004, Figure 5.1, transitioning from state
'DCH' directly to state 'BCH' is not permitted. Speaking in terms
of the trxcon_fsm, the following state transitions are invalid:
* TRXCON_ST_DEDICATED -> TRXCON_ST_BCCH_CCCH,
* TRXCON_ST_PACKET_DATA -> TRXCON_ST_BCCH_CCCH.
We never do such transitions anyway, so we are good.
Change-Id: I14ebfc5c86d37765ad06fa91321a469dea46e50f
Related: OS#5599
This change introduces a new feature to the mobile application -
audio I/O support, which allows the user to speak right from the
host side running mobile through its ordinary mic and speakers.
The audio I/O is based on libosmogapk [1][2], which in its turn
uses the ALSA sound system for the playback and capture. This
is a new optional dependency of mobile, which is automatically
picked up if available during the build configuration. Whether
to depend on it or not can be controlled using '--with-gapk-io'.
The API offered by libosmogapk implies to use the processing chains,
which generally consist of a source block, several processing blocks,
and a sink block. The mobile app implements the following chains:
- 'pq_audio_source' (voice capture -> frame encoding),
- 'pq_audio_sink' (frame decoding -> voice playback).
both taking/storing TCH frames from/to the following two buffers:
- 'tch_fb_ul' - a buffer for to be played DL TCH frames,
- 'tch_fb_dl' - a buffer for encoded UL TCH frames.
The buffers are served by a new function gapk_io_dequeue().
[1] https://gitea.osmocom.org/osmocom/gapk/
[1] https://osmocom.org/projects/gapk
Change-Id: Ib86b0746606c191573cc773f01172afbb52f33a9
Related: OS#5599
This way we can avoid allocating another msgb and enqueue the given
msgb directly to the write queue of the MNCC socket.
Change-Id: I29305866e61a0bc3bd082108af6a9ba8ff86bcf2
Related: OS#5599
Do not send voice frames to the external MNCC unconditionally.
Add a new I/O handler type for the external MNCC application.
Change-Id: I406b169963e6654110329d741728fa12c8c8eeec
Related: OS#5599
This API is going to be used by osmo-trx-ms for inquiring the l1sched
about an lchan state before attempting to demodulate a Downlink burst.
Change-Id: I9a71b8a59733f4dd908b760c5e23ea3d624afb1a
Related: OS#5599
This API is going to be used by osmo-trx-ms for pulling Uplink bursts
from the scheduler in a synchronous way, without relying on the
timer driven libtrxcon's internal scheduler.
Change-Id: Ic8f74413f5fad277340e007dd4296f890155a2c1
Related: OS#5599
Vadim Yanitskiy
Steve Markgraf
Vadim Yanitskiy