Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092023-01-30T00:06:12ZOpen Source Mobile Communications
Redmine OCTOI - Osmocom Community TDM over IP - Bug #5883 (New): GPS sync sometimes goes to hold overhttps://osmocom.org/issues/58832023-01-30T00:06:12Ztnt
<p>Last occurrences :</p>
<p>Sun Nov 27th 01:00<br />Thu Dec 6th 21:46 <br />Sun Dec 18th 01:00 <br />Wed Dec 28th 13:36<br />Sun Jan 29th 01:00</p>
<p>So at least 3 of them happened on Sundays, at 1 am local time (so 00:00 UTC), which also seems to correspond to the moment the GPS resets its 'ppr` messages counter to 0 ...</p> E1/T1 Hardware Interface (including icE1usb) - Feature #5710 (New): rs422: Merge as much of the g...https://osmocom.org/issues/57102022-10-13T18:53:21Ztnt
<p>Currently the gateware for the RS422 mode is another branch. It's just too big to have dual channel + hw support for it in the same build.</p>
<p>Either try to make it a build option, or reduce size of the gateware to make it fit.<br />ATM we create a whole different UART but technically we could just use the GPS uart and re-route the IO since the on-board GPS isn't used when rs422 mode is used.</p>
<p>This wouldn't support a possible future GPS 02/03 emulation mode but that's a problem for the future. (Although thinking about it, it could actually since after init we never TX to the onboard GPS and we never RX anything on the rs422 ... so we could have the same uart split: rx from onboard gps and tx to the RBS ... we just need to keep the onboard gps at 9600 or support different tx/rx baudrates)</p> E1/T1 Hardware Interface (including icE1usb) - Feature #5709 (New): rs422: Merge as much of the f...https://osmocom.org/issues/57092022-10-13T18:49:19Ztnt
<p>"Pluggable" GPS implementation should be possible.</p>
<p>The extensions boards have an EEPROM to allow run-time discovery and the firmware code size is not an issue, we have 64k and we're using 20.5k ATM so having the GPS03 code in there isn't going to make much of a difference.</p> E1/T1 Hardware Interface (including icE1usb) - Bug #5708 (New): rs422: Support runtime re-init of...https://osmocom.org/issues/57082022-10-13T18:46:17Ztnt
<p>Currently if the GPS receiver side doesn't have power, init will fail and never recover without a reboot.</p>
<p>This is because without power on that side, we can't talk to the I2C IO expander on the isolated side to initialize it and set up the RS422 transceiver ...</p>
<p>Solution is that if we haven't seen NMEA messages in a few seconds, try to re-init the I2C IO expander (default state on reset/power loss is everything disabled to be safe).</p>
<p>One thing to pay attention to is that I2C is slow. And the current I2C driver code is blocking, so we'd need to check the init sequence isn't too long and doesn't block the main loop processing for too long which would cause USB over/underflows ...</p> E1/T1 Hardware Interface (including icE1usb) - Bug #5664 (Resolved): icE1usb GPS module I2C conne...https://osmocom.org/issues/56642022-08-26T12:37:12Ztnt
<p>The GPS has an I2C connection that is currently un-used. I thought that this was to talk to the GPS module as a slave. And indeed that's the case for the uBlox M8W modules (alternate part).</p>
<p>But on the chinese ATGM336H modules, this is not the case. That interface can be used by the module to connect an external EEPROM (although I really can't find much doc about that either) just like it was the case on older (6-series) uBlox modules and so the side effect is that this creates a conflict on the SCL line because the GPS module is actively driving it and not in open-drain mode.</p>
<p>In use in "normal" firmware, this has no impact whatsoever because we don't use the I2C bus (the GPS module is the only thing there by default), and the FPGA drives it in open drain mode.<br />But when trying the rs422 interface (which uses the i2c bus with some io expander for some 'config' signals), this doesn't work out.</p>
<p>Holding the GPS module in reset actually does release the lines so that's the work around I will use for the OCTOI datacenter deployment.<br />But obviously if we wanted to use the rs422 modules for the "other direction", emulating a GPS-02/03, then we need the on-board GPS to be running and not be held in reset ...</p>
<p>I think the best solution is to just disconnect those lines by default. They are routed and go through an area with plenty of free space, so I'd put a couple of "normally-open" solder bridges (or DNP 0402 footprints) in case there is ever a use-case.</p> E1/T1 Hardware Interface (including icE1usb) - Bug #5402 (New): no2e1 gateware improvementshttps://osmocom.org/issues/54022022-01-13T12:00:56Ztnt
<p>The gateware needs some improvements to provide all functions required by upper layer :</p>
<ul>
<li>Need some way to detect we have no signal (for instance, no pulse at all)</li>
<li>Need some way to detect incoming AIS (all ones)</li>
<li>The RX generated tick should still be generated even if no signal was ever received. ATM it's off until we get a signal and then it continues even if we loose the signal, but it'd be better to have it from the start so that in a 'remote tick' confix, the tx side runs directly. Its phase will obviously be off for when we get a signal but that's not different from the caser where we loose signal and re-acquire ...</li>
</ul>
<p>Put all in one issue because the hw changes will most likely be interlinked and have to be implemented/designed at once since they interact with the same part of the circuit (RX clock recovery mostly).</p> osmo-e1d - Bug #5400 (Resolved): Allow enabling/disabling of interfaces in config fileshttps://osmocom.org/issues/54002022-01-11T22:39:05Ztnt
<p>Because some USB controllers don't support running both interfaces at once, or some CPU starved host don't have the performance to, it'd be good to be able to selectively disable some interfaces so that you only run port 0 or port 1.</p> Misc Hardware Projects - Bug #5375 (Resolved): amr breakout : Silk screen errorhttps://osmocom.org/issues/53752021-12-26T15:54:48Ztnt
<p>There are two "IN1" on the top silk screen.</p> Misc Hardware Projects - Feature #5369 (Resolved): amr breakout : Add pull-upshttps://osmocom.org/issues/53692021-12-22T20:21:13Ztnt
<p>Having pull-ups for <code>ac97_reset#</code> and <code>primary_dn#</code> would be useful I think.</p> OsmoBSC - Feature #4536 (New): Multi BTS support within a single physical devicehttps://osmocom.org/issues/45362020-05-06T10:35:51Ztnt
<p>So OpenBSC supports multiple BTSs (obviously). But sometime you want several "logical" BTS inside a single "physical" BTS.</p>
That means that :
<ul>
<li>You only get 1 physical link and possibly a single OML link to that physical BTS (so same/shared e1inp_sign_link *oml_link ...)</li>
<li>Some OML objects needs only to be brought up once for all the "logical" BTS in the same physical one.</li>
<li>In the 12.21 fields, the bts_nr field will not match the gsm_bts->bts_nr field since it starts at 0 for each physical BTS.</li>
<li>... probably other things ...</li>
</ul>
<p>We need a way to represent that in the code and in the config.</p>
Some thoughts:
<ul>
<li>We could introduce another hierarchy level (bts/trx/ts -> phys_bts/virt_bts/trx/ts) but that looks like extensive changes in the code and config format</li>
<li>We could have a "parent" link in bts object and so if a bts has a parent then it's not in charge of the "shared" stuff ... and the config would just have way to specify which bts is a parent. And if we restrict to having contiguous bts_nr for the child, then finding the OML 12.21 bts number for a bts is trivial (bts->nr - bts->parent->nr)</li>
<li>...</li>
</ul> OsmoBSC - Bug #4526 (Closed): Spurious message about channel load sample when running NokiaInsitehttps://osmocom.org/issues/45262020-05-04T09:28:12Ztnt
<p>I have not dug into the cause, but running a Nokia InSite, I get this message every second or so :</p>
<p><0000> chan_alloc.c:128 (bts=0) bogus channel load sample (used=0 / total=0)</p>
<p>I only tested Registering and SMS which seem to work fine. Just logging this so it's not forgotten.</p> libosmocore - Bug #4508 (Resolved): Viterbi Conv decoder performance https://osmocom.org/issues/45082020-04-21T09:32:12Ztnt
<p>There seems to be some evidence that the viterbi decoder might not be performing as well as it should (vis-as-vis its ability to correct errors).</p>
<p>The tested code was a very short packet encoded with this code in tail-biting mode :</p>
<pre><code class="python syntaxhl"><span class="n">code</span> <span class="o">=</span> <span class="n">conv_gen</span><span class="p">.</span><span class="n">ConvolutionalCode</span><span class="p">(</span><span class="mi">20</span><span class="p">,</span>
<span class="p">[</span>
<span class="p">(</span> <span class="n">conv_gen</span><span class="p">.</span><span class="n">poly</span><span class="p">(</span><span class="mi">0</span><span class="p">,</span><span class="mi">2</span><span class="p">,</span><span class="mi">3</span><span class="p">,</span><span class="mi">5</span><span class="p">,</span><span class="mi">6</span><span class="p">),</span> <span class="mi">1</span> <span class="p">),</span>
<span class="p">(</span> <span class="n">conv_gen</span><span class="p">.</span><span class="n">poly</span><span class="p">(</span><span class="mi">0</span><span class="p">,</span><span class="mi">1</span><span class="p">,</span><span class="mi">2</span><span class="p">,</span><span class="mi">3</span><span class="p">,</span><span class="mi">6</span><span class="p">),</span> <span class="mi">1</span> <span class="p">),</span>
<span class="p">(</span> <span class="n">conv_gen</span><span class="p">.</span><span class="n">poly</span><span class="p">(</span><span class="mi">0</span><span class="p">,</span><span class="mi">1</span><span class="p">,</span><span class="mi">2</span><span class="p">,</span><span class="mi">4</span><span class="p">,</span><span class="mi">6</span><span class="p">),</span> <span class="mi">1</span> <span class="p">),</span>
<span class="p">],</span>
<span class="n">name</span><span class="o">=</span><span class="s">'lte'</span>
<span class="p">)</span>
</code></pre>
<p>Decoding results with each time # of bit erasure, % failed packet, % of bit errors.</p>
<pre>
libosmocore:
0 0.00 0.00
5 0.00 0.00
10 0.00 0.00
15 1.33 0.13
20 1.33 0.13
25 3.33 0.37
30 14.00 1.83
35 40.00 8.10
40 89.33 40.30
HW decoder:
0 0.00 0.00
5 0.00 0.00
10 0.00 0.00
15 0.00 0.00
20 0.00 0.00
25 0.00 0.00
30 0.00 0.00
35 2.67 1.43
40 56.67 24.90
</pre> OsmoBSC - Bug #4002 (Resolved): AMR defaults to bandwidth-efficient modehttps://osmocom.org/issues/40022019-05-15T12:48:38Ztnt
<p>0d9a1a7583842203cbbd60517a2c4d63247db954 introduced a new vty option to select between bandwidth efficient and octet-aligned mode.</p>
<p>Previously it would basically always be octet align since that's what all the BTS use natively, but now, with this option the default has changed which can break existing setup that are not aware of this.</p> OsmoBSC - Bug #3975 (Closed): osmo-bsc crash during startup with nokia insitehttps://osmocom.org/issues/39752019-05-04T11:14:10Ztnt
<p>After issuing the reset of the BTS, something goes wrong.</p>
<p>Relevant end of the log :</p>
<pre>
<0004> bts_nokia_site.c:1693 ABIS_OM_MDISC_FOM
<0004> bts_nokia_site.c:1521 (0x81) NOKIA_BTS_ACK
<0004> bts_nokia_site.c:1553 ACK = 1
<0014> input/lapd.c:541 LAPD DL-RELEASE request TEI=1 SAPI=62
<0014> lapd_core.c:2243 Message DL-RELEASE-REQUEST received in state LAPD_STATE_MF_EST (dl=0x91171c8)
<0014> lapd_core.c:2083 perform local release (dl=0x91171c8)
<0014> lapd_core.c:237 new state LAPD_STATE_MF_EST -> LAPD_STATE_IDLE (dl=0x91171c8)
<0014> lapd_core.c:230 stop T203 (dl=0x91171c8)
<0014> input/lapd.c:656 LAPD DL-RELEASE confirm TEI=1 SAPI=62
<0014> input/lapd.c:274 LAPD Freeing SAP for SAPI=62 / TEI=1 (dl=0x91171c8, sap=0x91171b8)
<0014> lapd_core.c:310 Resetting LAPDm instance
<0014> lapd_core.c:237 new state LAPD_STATE_IDLE -> LAPD_STATE_IDLE (dl=0x91171c8)
<0014> lapd_core.c:237 new state LAPD_STATE_IDLE -> LAPD_STATE_NULL (dl=0x91171c8)
<0014> lapd_core.c:1681 we are busy, send RNR (dl=0x91171c8)
Segmentation fault
</pre>
<p>So right after freeing the SAP, we try to send a RNR on the dl that was <em>just</em> freed so obviously this doesn't workout ...</p>
<p>I couldn't really generate a backtrace, gdb didn't give anything meaningful even on a binary with debug symbols.</p> OsmoMSC - Bug #3829 (New): osmo-msc expects aoip TLV in Assignement Complete messages from BSChttps://osmocom.org/issues/38292019-03-07T17:50:59Ztnt
<p>That TLV shouldn't be expected if the channel is signaling only.</p> OsmoBSC - Bug #3784 (Resolved): osmo-bsc ignores requested channel type in ASSIGNEMENT REQUESTS f...https://osmocom.org/issues/37842019-02-06T18:16:36Ztnt
<p>In bssmap_handle_assignm_req , if channel type is of GSM0808_CHAN_SIGN it just creates an a request for a signaling channel but never looks at the ct.ch_rate_type fields to see what kind of channel is really requested. Instead in the assignement fsm and throuh lchan_select_by_chan_mode, it will always assume a signalling channel is a SDCCH.</p>
<p>Also in the assignement fsm, if it sees the current channel mode supports the requested mode (and independently of the channel type requests in ct.ch_rate_type), it will ignore it and not do anything.</p>
<pre><code class="c syntaxhl"> <span class="k">struct</span> <span class="n">gsm0808_channel_type</span> <span class="n">ct</span><span class="p">;</span>
<span class="n">ct</span><span class="p">.</span><span class="n">ch_indctr</span> <span class="o">=</span> <span class="n">GSM0808_CHAN_SIGN</span><span class="p">;</span>
<span class="n">ct</span><span class="p">.</span><span class="n">ch_rate_type</span> <span class="o">=</span> <span class="n">GSM0808_SPEECH_FULL_BM</span><span class="p">;</span> <span class="cm">/* libosmocore doesn't actually define constants for signalling mode channels but this one is compatible in value */</span>
<span class="n">ct</span><span class="p">.</span><span class="n">perm_spch</span><span class="p">[</span><span class="mi">0</span><span class="p">]</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span> <span class="cm">/* spare but must be present ! */</span>
<span class="n">ct</span><span class="p">.</span><span class="n">perm_spch_len</span> <span class="o">=</span> <span class="mi">1</span><span class="p">;</span>
<span class="n">msg</span> <span class="o">=</span> <span class="n">gsm0808_create_ass</span><span class="p">(</span><span class="o">&</span><span class="n">ct</span><span class="p">,</span> <span class="nb">NULL</span><span class="p">,</span> <span class="nb">NULL</span><span class="p">,</span> <span class="nb">NULL</span><span class="p">,</span> <span class="nb">NULL</span><span class="p">);</span>
<span class="n">osmo_sccp_tx_data_msg</span><span class="p">(</span><span class="n">conn</span><span class="o">-></span><span class="n">a</span><span class="p">.</span><span class="n">scu</span><span class="p">,</span> <span class="n">conn</span><span class="o">-></span><span class="n">a</span><span class="p">.</span><span class="n">conn_id</span><span class="p">,</span> <span class="n">msg</span><span class="p">);</span>
</code></pre> E1/T1 Hardware Interface (including icE1usb) - Bug #3269 (Resolved): osmo-e1-xcvr has magnetics n...https://osmocom.org/issues/32692018-05-15T20:10:05Ztnt
<p>It seems the footprint for the T1094NL transformer in the library is wrong.</p>
<p>The pads in the schematics are correct but their position on the footprint is wrong. P$16 is where P$1 should be, P$15 is where P$2 should be and so on and so forth.<br />Also pads have the default P$nn which is probably a clue as to what happened :p</p>
<p>The result is that there is no orientation of the transformer that will give the right result because one side is 1:1 and the other is 1:2.</p>
<p>Currently for the RX path, this has no effect. Primary and secondary are swapped but it's a 1:1 turn ratio.<br />For TX however, the '2' turn ratio should be on the line side and instead it's on the LIU side, so the pulses will end up being 1/4 amplitude of what they should be.</p> Mobile (in)Security - Bug #1482 (New): Sending the TMSI of the old/previous networkhttps://osmocom.org/issues/14822016-02-19T22:51:58Ztnt
<p>On LOCATION UPDATING REQUEST some handsets do not clear their TMSI and send a TMSI of a foreign network to us. This means we know IMSI, IMEI and TMSI from the previous network.</p>
<p>( from <a class="external" href="http://openbsc.osmocom.org/trac/wiki/HandsetBugs">http://openbsc.osmocom.org/trac/wiki/HandsetBugs</a> )</p>