Open Source Mobile Communications: Issueshttps://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092024-01-26T22:03:21ZOpen Source Mobile Communications
Redmine OsmocomBB - Feature #6348 (New): virtphy: add Circuit Switched Data (CSD) supporthttps://projects.osmocom.org/issues/63482024-01-26T22:03:21Zfixeria
<p>Since recently, Calypso PHY and trxcon support data traffic channels needed for CSD:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmocom-bb/+/34694">https://gerrit.osmocom.org/c/osmocom-bb/+/34694</a> firmware/layer1: handle CSD related channel modes<br /><a class="external" href="https://gerrit.osmocom.org/c/osmocom-bb/+/32922">https://gerrit.osmocom.org/c/osmocom-bb/+/32922</a> trxcon/l1sched: implement CSD scheduling support</p>
<p>For the sake of completeness, let's add data traffic channel support to virtphy.</p> OsmocomBB - Feature #6347 (New): mobile: support data calls @ 300 bps and 1200/75 bps (TCH/[FH]2.4)https://projects.osmocom.org/issues/63472024-01-26T21:54:56Zfixeria
<p>Currently we implement data rates starting from <code>2400 bps</code> and higher, but not <code>300 bps</code> and <code>1200/75 bps</code>.<br />The problem is that those rates are not specified in ITU-T Rec. V.110, which defines <code>600 bps</code> as the minimum synchronous data rate.</p>
<p>According to 3GPP TS 44.021, section 4.1, the <code>300 bps</code> user data signalling rate shall be adapted to a synchronous <code>600 bps</code> stream.<br />Also, "Incoming asynchronous data is padded by the addition of stop elements" -- this means that we pad bits after stop bit(s):</p>
<pre>
pad bits = ((600 / 300) - 1) * (start + data + parity + stop)
</pre>
<p>This logic most likely needs to be implemented in the soft-UART module of libosmocore.git.</p> OsmocomBB - Feature #6346 (New): mobile: support data calls @ 14400 bps (TCH/F14.4)https://projects.osmocom.org/issues/63462024-01-26T21:44:42Zfixeria
<p>Currently we implement <code>TCH/[FH]2.4</code>, <code>TCH/[FH]4.8</code>, and <code>TCH/F9.6</code>, but not <code>TCH/F14.4</code>. Calypso PHY should be capable of doing <code>TCH/F14.4</code>, as well as trxcon. However, the rate adaptation functions for <code>TCH/F14.4</code> are different from those we implemented so far. According to 3GPP TS 48.020, chapter 10, we would need to implement <code>RA1'/RAA'</code> and <code>RA1'/RAA"</code>. Other relevant specs: 3GPP TS 44.021 and 3GPP TS 48.060.</p> libosmocore - Feature #6344 (New): New TS 24.008 Bearer Capability codec APIhttps://projects.osmocom.org/issues/63442024-01-24T23:17:59Zfixeria
<p>The current implementation of <code>gsm48_{en,de}code_bearer_cap()</code> lacks support for:</p>
<ul>
<li>encoding/decoding V.34 modem type (octet 6d);</li>
<li>encoding/decoding data rates higher than 9600 bps, like 14400 bps (octets 6d, 6e);</li>
<li>encoding/decoding of other B-channel protocols like V.120 (octets 5a, 5b; see also <a class="issue tracker-1 status-1 priority-2 priority-default" title="Bug: Incorrect handling of V.120 data calls (New)" href="https://projects.osmocom.org/issues/6330">#6330</a>);</li>
<li>encoding/decoding fields of octet 4 (hard-coded to 0x88).</li>
</ul>
<p>Unfortunately, adding new fields to <code>struct gsm_mncc_bearer_cap</code> (on which these functions operate) is not an option.<br />This struct is part of the MNCC PDU, so changing it would result in modifying the protocol and thus problems with backwards compatibility.</p>
<p>This means that we need the new API, which would depend on the MNCC protocol definitions.</p> OsmoBTS - Feature #6167 (New): csd_v110: implement rate adaptation for TCH/F14.4https://projects.osmocom.org/issues/61672023-09-01T11:58:07Zfixeria
<p>We do implement scheduling of TCH/F14.4 in osmo-bts-trx, however the rare adaptation is missing. This is why current osmo-bts-trx would NACK CHANnel ACTIVation attempts for this data rate. The rate adaptation functions for TCH/F14.4 are different from the ones employed for TCH/F9.6, TCH/F4.8, and TCH/F2.4. According to 3GPP TS 48.020, chapter 10, we would need to implement RA1'/RAA' and RA1'/RAA". Other relevant specs: 3GPP TS 44.021 and 3GPP TS 48.060.</p> OsmocomBB - Feature #5815 (New): mobile: compose Bearer Capability IE depending on PHY capabiliti...https://projects.osmocom.org/issues/58152022-12-06T19:38:37Zfixeria
<p>This was originally proposed as a checklist item in <a class="issue tracker-2 status-3 priority-2 priority-default closed" title="Feature: mobile: implement GAPK based audio capture / playback (via ALSA) (Resolved)" href="https://projects.osmocom.org/issues/3400">#3400</a>. The idea is to compose the <code>Bearer Capability IE</code> in Uplink <code>(CC) Setup</code> messages not only based on the VTY configuration (see below), but also based on the PHY capabilities (see <a class="issue tracker-2 status-7 priority-3 priority-high3" title="Feature: include some version information / negotiation in the L1CTL protocol (Stalled)" href="https://projects.osmocom.org/issues/1461">#1461</a>) and GAPK codec support (see <a class="issue tracker-2 status-3 priority-2 priority-default closed" title="Feature: mobile: implement GAPK based audio capture / playback (via ALSA) (Resolved)" href="https://projects.osmocom.org/issues/3400">#3400</a>). The respective function <code>mncc_set_bearer()</code> can be found in <a class="external" href="https://cgit.osmocom.org/osmocom-bb/tree/src/host/layer23/src/mobile/mnccms.c">https://cgit.osmocom.org/osmocom-bb/tree/src/host/layer23/src/mobile/mnccms.c</a>.</p> OsmocomBB - Feature #5812 (New): mobile: missing AMR supporthttps://projects.osmocom.org/issues/58122022-12-06T15:07:50Zfixeria
<p>This was originally a checklist item in <a class="issue tracker-2 status-3 priority-2 priority-default closed" title="Feature: mobile: implement GAPK based audio capture / playback (via ALSA) (Resolved)" href="https://projects.osmocom.org/issues/3400#note-15">#3400#note-15</a>:</p>
<pre>
The non-adaptive codecs (HR, FR, EFR) are all confirmed to work. AMR implementation is
currently incomplete in trxcon, and is completely missing in the layer1 firmware (needs DSP patches).
</pre>
<p>Initial AMR support was recently added to trxcon by <a class="user active" href="https://projects.osmocom.org/users/30187">pespin</a>:</p>
<pre>
commit a53e93fe9c81136b512697e169c5cf5ecd319163
Author: Pau Espin Pedrol <pespin@sysmocom.de>
Date: Fri Sep 2 17:02:17 2022 +0200
trxcon: Initial support for forwarding AMR
This allows TTCN3 L1CTL module (used in BTS_Tests) to transmit and
receive AMR payloads towards osmo-bts-trx.
Related: SYS#5987
Change-Id: Ia20bc96e39726a919a556c83c8be48cb31af7331
</pre>
<p>We need to investigate what needs to be done in order to support AMR calls, at least for trxcon.</p>
<p>One missing part is forwarding the AMR parameters to the L1 via L1CTL:</p>
<pre><code class="diff syntaxhl"><span class="gh">diff --git a/src/host/layer23/src/common/l1ctl.c b/src/host/layer23/src/common/l1ctl.c
index e33074af..d5204034 100644
</span><span class="gd">--- a/src/host/layer23/src/common/l1ctl.c
</span><span class="gi">+++ b/src/host/layer23/src/common/l1ctl.c
</span><span class="p">@@ -472,6 +472,7 @@</span> int l1ctl_tx_tch_mode_req(struct osmocom_ms *ms, uint8_t tch_mode,
req->tch_mode = tch_mode;
req->audio_mode = audio_mode;
req->tch_loop_mode = tch_loop_mode;
<span class="gi">+ /* TODO: Set AMR codec in req if req->tch_mode==GSM48_CMODE_SPEECH_AMR */
</span>
return osmo_send_l1(ms, msg);
}
</code></pre> OsmoTRX - Feature #5283 (New): Implement TRXDv2 supporthttps://projects.osmocom.org/issues/52832021-10-27T22:35:37Zfixeria
<p>At the moment, only TRXDv0 and TRXDv1 are supported. Given that osmo-bts-trx does support TRXDv2, it would be nice to have it in osmo-trx too.</p> OsmoBTS - Feature #5025 (New): Missing TTCN-3 coverage for the Timing Advance loophttps://projects.osmocom.org/issues/50252021-02-15T16:36:08Zfixeria
<p>As we figured out in <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: Timing Advance loop is broken for SDCCH channels (Resolved)" href="https://projects.osmocom.org/issues/5024">#5024</a>, there seems to be no TTCN-3 test case(s) for continuous Timing Advance control:</p>
<p>Harald Welte wrote:</p>
<blockquote>
<p>Regarding TTCN3 tests: We also only test the correct TA usage on initial channel establishment (BTS_Tests.TC_rsl_chan_initial_ta) and no tests yet for the TA loop during an active channel.</p>
</blockquote> pySim - Feature #4384 (Stalled): Jenkins program-read verification on daily (or weekly) basishttps://projects.osmocom.org/issues/43842020-01-29T08:49:07Zfixeria
<p>We already have build verification for some projects running once per day:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/master/">https://jenkins.osmocom.org/jenkins/view/master/</a></p>
<p>It would be nice to have daily or at least weekly (given the low amount of contributions) master build verification for pySim too.</p> Cellular Network Infrastructure - Feature #4006 (Stalled): TRX protocol: wind of changehttps://projects.osmocom.org/issues/40062019-05-16T19:54:33Zfixeria
<p>We are using TRX protocol in <a class="wiki-page" href="https://projects.osmocom.org/projects/osmobts/wiki">OsmoBTS</a> in order to "speak" with transceiver (e.g. <a class="wiki-page" href="https://projects.osmocom.org/projects/osmotrx/wiki">OsmoTRX</a>, FakeTRX). Basically it defines three interfaces: clock for TDMA frame clock indications, control (we agreed to call it TRXC) for transceiver management, and data (TRXD) for exchanging Rx/Tx bursts. It was first introduced in <a href="http://openbts.org/" class="external">OpenBTS</a> project, from which we forked <a class="wiki-page" href="https://projects.osmocom.org/projects/osmotrx/wiki">OsmoTRX</a>. For more information, please see: <a class="external" href="https://github.com/RangeNetworks/openbts/blob/master/TRXManager/README.TRXManager">https://github.com/RangeNetworks/openbts/blob/master/TRXManager/README.TRXManager</a>.</p>
<p>The protocol is being used for years, and it still serves us for good. However, it is extremely inflexible. For example, there is no way to send more information about received bursts on TRXD interface, than the fixed-size header already has (TDMA frame number, timeslot number, RSSI, ToA256). On TRXC interface, which is working over UDP as the other ones, there is no way to distinguish command retransmission, which may happen due to timeout, from a regular command. There is no way to notify the L1 (i.e. <a class="wiki-page" href="https://projects.osmocom.org/projects/osmobts/wiki">OsmoBTS</a>) about some events (e.g. device has been disconnected), no way to indicate transceiver version, and so on...</p>
<p>During <a class="wiki-page" href="https://projects.osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2019">OsmoDevCon2019</a> (and before too) we have been discussing the idea of introducing the new version of TRX protocol, which would allow us to solve the mentioned problems. In order to keep backwards compatibility, both L1 and transceiver would initially use the old TRX protocol, while the new version can be optionally enabled by sending a command on TRXC interface. If the transceiver does support the new protocol, it would acknowledge the command. Otherwise, the command is rejected, so L1 would continue to work in "backwards compatibility" mode.</p>
<p>Finally, we need to write a proper protocol description like we already have for GSUP in <a class="external" href="https://git.osmocom.org/osmo-gsm-manuals/">https://git.osmocom.org/osmo-gsm-manuals/</a>. But before starting to work on this, let's create some kind of a wish list - what would you like to see in the new version of TRX protocol?</p> OsmocomBB - Feature #3761 (Resolved): Separate TDMA scheduler into a library (libtdmasched)https://projects.osmocom.org/issues/37612019-01-20T17:03:50Zfixeria
<p>The current TDMA scheduler implementation is tightly integrated with both L1CTL and TRX interfaces, i.e. Downlink frames are being passed to the L1CTL handler, and Uplink bursts are being sent to the TRX interface handler. This is one of the reasons why we don't have even basic unit test coverage.</p>
<p>As the primary solution, I suggest to abstract the scheduler from both interfaces (by extending the existing prim API), and create a separate library (libtdmasched, libgsmsched?), so trxcon application could be linked against it, as well as the further unit tests.</p> OsmocomBB - Feature #3667 (Resolved): Multiple transceiver connectionshttps://projects.osmocom.org/issues/36672018-10-24T12:39:25Zfixeria
<p>It would be great to have a possibility to connect multiple trxcon instances,<br />and multiple osmo-bts-trx instances using a single fake_trx.py process.</p> OsmocomBB - Feature #3666 (New): trxcon: Introduce VTY interfacehttps://projects.osmocom.org/issues/36662018-10-24T12:16:08Zfixeria
<p>Having the VTY interface would allow one to configure various logging<br />parameters, observe some statistics, and moreover to configure<br />multiple L23 <-> TRX connections.</p>
<pre>
log stderr
logging filter all 1
logging print category 1
...
! One transceiver connection
trxcon foo
! TRX interface configuration
trx ip local 127.0.0.1
trx base-port local 5800
trx ip remote 127.0.0.1
trx base-port remote 5700
trx fn-advance 20
...
! L23 interface configuration
layer2-socket /tmp/osmocom_l2.foo
...
! Another transceiver connection
trxcon bar
...
! Another transceiver connection
trxcon zoo
...
</pre> OsmoTRX - Feature #3664 (Resolved): Optimize EDGE burst detectionhttps://projects.osmocom.org/issues/36642018-10-22T16:22:31Zfixeria
<p>In the current code, when EDGE demodulator is enabled, OsmoTRX is trying to detect<br />each normal burst as EDGE burst first, and fall-backs to GSM if detection is failed.</p>
<pre>
Transceiver::pullRadioVector():
...
/* Set time and determine correlation type */
GSM::Time time = radio_burst->getTime();
CorrType type = expectedCorrType(time, chan);
/* Enable 8-PSK burst detection if EDGE is enabled */
if (mEdge && (type == TSC))
type = EDGE;
...
</pre>
<p>Detection of EDGE bursts only makes sense on PDCH channel combinations,<br />and (probably, to be clarified) on TCH combinations that can be combined<br />with PDCH, i.e. dynamic time-slots.</p> OsmoMSC - Feature #3655 (Resolved): Introduce self-destruction timer for SS/USSD connectionshttps://projects.osmocom.org/issues/36552018-10-15T19:25:19Zfixeria
<p>Just like we do in <a class="wiki-page" href="https://projects.osmocom.org/projects/osmo-hlr/wiki">OsmoHLR</a>, it would be great to have a "fail-safe" timer also on the MSC side that would release a transaction in case if the HLR becomes unresponsive.</p> Cellular Network Infrastructure - Feature #3587 (Resolved): Possibility to route SMS messages ove...https://projects.osmocom.org/issues/35872018-09-24T21:21:35Zfixeria
<p>At the moment there is only one way to route short messages between an Osmocom-based<br />network and some external entity (e.g. SMSC) - SMPP interface. It's implemented in<br />both <a class="wiki-page" href="https://projects.osmocom.org/projects/openbsc/wiki">OpenBSC</a> and <a class="wiki-page" href="https://projects.osmocom.org/projects/osmomsc/wiki">OsmoMSC</a>, and can be optionally enabled during<br />the build configuration (using --enable-smpp).</p>
<p>The fundamental problem of SMPP is the need of transcoding between its primitives and<br />pretty complex SMS protocol. Moreover, in some cases this transcoding is not desired.</p>
<p>In commercial networks MAP (Mobile Application Part, see 3GPP TS 29.002) protocol is<br />used for forwarding MO/MT short messages between different network entities. There is<br />a special group of short message management services defined in MAP, see section 12.</p>
<p>The problem of MAP comes from the protocol stack it belongs to - SS7, its complexity.<br />Instead of SS7/MAP, Generic Subscriber Update Protocol (GSUP) is used in Osmocom CNI.<br />Basically GSUP is an Osmocom-specific non-standard protocol designed around the same<br />architecture as the MAP messages/operations, but without the complexity of SS7, and<br />without the need for ASN.1 encoding.</p>
<p>Implementing a possibility to route SMS messages over GSUP would facilitate the<br />integration of Osmocom CNI with third-party networks and components. In general,<br />this task would require us to replicate the SM-related messages and IEs in GSUP,<br />and to implement proper message forwarding in <a class="wiki-page" href="https://projects.osmocom.org/projects/osmomsc/wiki">OsmoMSC</a>.</p>
<p>Draft message sequence charts can be found here: <a class="external" href="https://gerrit.osmocom.org/10604/">https://gerrit.osmocom.org/10604/</a></p> OsmocomBB - Feature #3581 (Resolved): Merge FCDEV3B board supporthttps://projects.osmocom.org/issues/35812018-09-20T17:50:41Zfixeria
<p><a href="https://www.freecalypso.org/fcdev3b.html" class="external">FCDEV3B</a> (stands for "FreeCalypso development board, triband") is a GSM mobile station development board based on legendary TI Calypso chipset. In 2017 Mychaela Falconia has <a href="http://lists.osmocom.org/pipermail/baseband-devel/2017-November/005417.html" class="external">announced</a> that the firmware part of OsmocomBB was extended with support of this board, but the code so far was not merged to the upstream.</p>
<p>The modified source code archive can be downloaded from: <a class="external" href="ftp://ftp.freecalypso.org/pub/GSM/FreeCalypso/obb-fcmods-r1.tar.bz2">ftp://ftp.freecalypso.org/pub/GSM/FreeCalypso/obb-fcmods-r1.tar.bz2</a></p> OsmocomBB - Feature #3558 (Resolved): trxcon/scheduler: implement CBCH supporthttps://projects.osmocom.org/issues/35582018-09-16T14:09:01Zfixeria
<p>Initial work can be found in <a class="external" href="https://git.osmocom.org/osmocom-bb/log/?h=laforge/cbch">https://git.osmocom.org/osmocom-bb/log/?h=laforge/cbch</a></p> libosmocore - Feature #3522 (New): libosmocoding: move TCH ordering functions to libosmocodec and...https://projects.osmocom.org/issues/35222018-09-04T20:49:08Zfixeria
<p>The GSM 05.03 implementation present in libosmocoding is using the RTP speech frame format for TCH coding functions. It is implemented in a way of performing 'canonical -> RTP' bit reordering in decoding functions, and 'RTP -> canonical' bit reordering in encoding functions. At the moment, the RTP format bit reordering implementation is not exposed.</p>
<p>This API could be used by some other projects (at least by osmo-gapk), moreover libosmocoding is already being linked against libosmocodec.</p> libosmocore - Feature #3521 (New): core/utils: engineering notation helpershttps://projects.osmocom.org/issues/35212018-09-04T20:32:52Zfixeria
<p>It would be great to have some auxiliary API to parse numbers written in the engineering notation (e.g. 945.6M, -33k) to the regular numbers (float?), and, vice versa, the regular numbers to engineering notation. This is useful in the cases where a user should provide some input, such as frequency (e.g. in osmo-arfcn) or sample rate.</p>
<p>Inspired by GNU Radio: <a class="external" href="https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/python/gnuradio/eng_notation.py">https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/python/gnuradio/eng_notation.py</a></p>
<p>If this feature also looks useful for others, I would implement it.</p> gr-gsm - Feature #3520 (Resolved): apps/grgsm_trx: implement a possibility to shift both RX and T...https://projects.osmocom.org/issues/35202018-09-04T18:12:32Zfixeria
<p>This feature would allow <a class="wiki-page" href="https://projects.osmocom.org/projects/baseband/wiki">OsmocomBB</a> working on <a class="wiki-page" href="https://projects.osmocom.org/projects/baseband/wiki/SDR_PHY">SDR PHY</a> to interact with a BTS running in some shifted frequency band (e.g. 2.4 GHz).<br />Please see <a class="external" href="https://osmocom.org/versions/136">https://osmocom.org/versions/136</a> for a bit more detailed description.</p> Cellular Network Infrastructure - Feature #3455 (Rejected): docker-playground/debian-jessie-build...https://projects.osmocom.org/issues/34552018-08-08T15:46:44Zfixeria
<p>While building the recent 'debian-jessie-build' Docker image, I noticed that there<br />are some packages which are not common for all projects, in particular:</p>
<ul>
<li>libdbd-sqlite3</li>
<li>libdbi-dev</li>
<li>libfftw3-dev</li>
<li>libgps-dev</li>
<li>libgsm1-dev</li>
<li>libncurses5-dev</li>
<li>libortp-dev</li>
<li>lbfftw3-devibsctp-dev</li>
<li>libsofia-sip-ua-glib-dev</li>
<li>libsqlite3-dev</li>
<li>libusb-dev</li>
<li>libusb-1.0-0-dev</li>
<li>sqlite3</li>
</ul>
<p>I think they should not be common for all other images based on this one,<br />and it makes sense to specify them in the individual Dockerfiles...</p> OsmoMSC - Feature #3445 (Stalled): SS/USSD: clean up the local GSM 04.80 APIhttps://projects.osmocom.org/issues/34452018-08-03T09:43:56Zfixeria
<p>Since the SS/USSD related changes have been merged, OsmoMSC doen't process the<br />SS/USSD requests internally. This is why some part of the local GSM 04.80 API<br />has become useless. Would be great to clean it up, and keep only the most<br />important functions there...</p> OsmoBTS - Feature #3428 (Resolved): Implement handling of NOPE / IDLE indications from Transceiverhttps://projects.osmocom.org/issues/34282018-07-27T20:44:06Zfixeria
<p>The following output can be observed with trxcon and FakeTRX:</p>
<pre>
Too many contiguous elapsed fn, dropping 80375
<0000> ../../../src/common/rsl.c:741 (bts=0,trx=0,ts=1,pchan=SDCCH8) (ss=0) SDCCH Tx CHAN ACT ACK
Too many contiguous elapsed fn, dropping 79538
Too many contiguous elapsed fn, dropping 16
<0011> lapd_core.c:920 Store content res. (dl=0x7f9793b90d68)
Too many contiguous elapsed fn, dropping 48
Too many contiguous elapsed fn, dropping 29
Too many contiguous elapsed fn, dropping 16
Too many contiguous elapsed fn, dropping 48
Too many contiguous elapsed fn, dropping 29
Too many contiguous elapsed fn, dropping 16
Too many contiguous elapsed fn, dropping 48
Too many contiguous elapsed fn, dropping 29
Too many contiguous elapsed fn, dropping 16
Too many contiguous elapsed fn, dropping 48
Too many contiguous elapsed fn, dropping 29
Too many contiguous elapsed fn, dropping 16
Too many contiguous elapsed fn, dropping 48
Too many contiguous elapsed fn, dropping 29
Too many contiguous elapsed fn, dropping 16
Too many contiguous elapsed fn, dropping 48
Too many contiguous elapsed fn, dropping 29
Too many contiguous elapsed fn, dropping 16
Too many contiguous elapsed fn, dropping 48
Too many contiguous elapsed fn, dropping 29
Too many contiguous elapsed fn, dropping 16
Too many contiguous elapsed fn, dropping 48
Too many contiguous elapsed fn, dropping 29
Too many contiguous elapsed fn, dropping 16
<0000> ../../../src/common/rsl.c:720 (bts=0,trx=0,ts=1,pchan=SDCCH8) (ss=0) SDCCH Tx CHAN REL ACK
</pre>
<p>It can be also observed with OsmoTRX, but the most of such messages<br />in this case caused by false-positive detection of bursts (i.e. noise).</p> OsmocomBB SDR PHY - Feature #3424 (Stalled): Transceiver: implement automatic TX delay measurementhttps://projects.osmocom.org/issues/34242018-07-26T20:22:05Zfixeria
<p>As we all know, the world is not perfect, and there is some delay on the TX path of SDR devices.<br />At the moment, we know that for USRP B2X0 this delay is constant, so we take it into account.</p>
<p>But since we are going to extend the hardware compatibility, it makes sense to implement<br />some automatic measurement of delay for a particular device.</p> OsmocomBB SDR PHY - Feature #3423 (Stalled): Receiver: hard-coded GSM 05.02 channel configurationhttps://projects.osmocom.org/issues/34232018-07-26T20:15:46Zfixeria
<p>Unlike <a class="wiki-page" href="https://projects.osmocom.org/projects/osmotrx/wiki">OsmoTRX</a>, it's impossible to configure the desired channel configuration.<br />Please see GSM 05.02, section 6.4 "Permitted channel combinations".</p>
<p>In order to reduce the recourse consumption, it makes sense to implement some API,<br />which would allow both initial and dynamic timeslot configuration...</p> OsmoBTS - Support #3023 (Resolved): src/common/pcu_sock.c/pcu_sock_close(): The array 'ts->lchan'...https://projects.osmocom.org/issues/30232018-03-01T18:48:52Zfixeria
<p>The gsm_bts_trx_ts struct has array of lchans:</p>
<blockquote>
<p>struct gsm_lchan lchan[TS_MAX_LCHAN];</p>
</blockquote>
<p>However, in the pcu_sock_close() it's utilized as a pointer to single object:</p>
<pre>
for (j = 0; j < 8; j++) {
ts = &trx->ts[j];
if (ts->mo.nm_state.operational == NM_OPSTATE_ENABLED
&& ts->pchan == GSM_PCHAN_PDCH) {
ts->lchan->rel_act_kind = LCHAN_REL_ACT_PCU;
l1sap_chan_rel(trx, gsm_lchan2chan_nr(ts->lchan));
}
}
</pre>
<p>Is it intended?</p> OsmocomBB - Support #1639 (Closed): BCCH at TS1-7 supporthttps://projects.osmocom.org/issues/16392016-03-09T15:02:23Zfixeria
<p>The specs says it's possible to have paging channels on other time slots than 0.<br />But support for it is not implemented in Osmocom-bb...</p> OsmocomBB - Support #1627 (Stalled): DCS_8BIT and DCS_UCS2 encoding supprothttps://projects.osmocom.org/issues/16272016-02-29T03:46:52Zfixeria
<p>Currently it is impossible to send/receive SMS messages and USSD encoded in 8-bit or 16-bit alphabet.</p>