https://osmocom.org/https://osmocom.org/favicon.ico?16647414092018-03-10T05:21:04ZOpen Source Mobile CommunicationsOsmoBTS - Bug #3052: osmo-bts-sysmo fails to detect RACH bursts from osmocom-bbhttps://osmocom.org/issues/3052?journal_id=81202018-03-10T05:21:04Zfixeria
<ul></ul><p>Hi Harald,</p>
<p>I recommend you to try GRGSM-TRX and FakeTRX/burst_gen.py.<br />This would allow you to modulate and send any possible sequences.</p>
<p>Also, what does "Wrong burst type" exactly mean? Is it possible<br />to observe both BER and ToA values?</p>
<p>BTW: I didn't know that there are more than one synch sequences.<br />I've used to refer the 5.1.0, while the latest V14.4.0 (2018-01)<br />defines even more than three sequences...</p> OsmoBTS - Bug #3052: osmo-bts-sysmo fails to detect RACH bursts from osmocom-bbhttps://osmocom.org/issues/3052?journal_id=81212018-03-10T05:25:00Zfixeria
<ul></ul><p>I also have a killed by statical electricity Motorola C118. I don't know which<br />part exactly was damaged: it's still capable to receive GSM signal, but the<br />transmitted signal looks like a noise. OsmoBTS reports 100% BER despite<br />relatively good RSSI values.</p> OsmoBTS - Bug #3052: osmo-bts-sysmo fails to detect RACH bursts from osmocom-bbhttps://osmocom.org/issues/3052?journal_id=81262018-03-10T08:30:16Zlaforge
<ul></ul><p>On Sat, Mar 10, 2018 at 05:25:00AM +0000, fixeria [REDMINE] wrote:</p>
<blockquote>
<p>I also have a killed by statical electricity Motorola C118. I don't know which<br />part exactly was damaged: it's still capable to receive GSM signal, but the<br />transmitted signal looks like a noise. OsmoBTS reports 100% BER despite<br />relatively good RSSI values.</p>
</blockquote>
<p>I've tried it with several phones. Also, I can hear it loud and clear in the speaker<br />I use, depending on the configured transmit power.</p>
<p>I am feeling this is somehow related to timing. It seems that OsmocomBB is sending<br />the first RACH request already with a ToA of 19 bits (!) and this increases with every<br />RACH.</p> OsmoBTS - Bug #3052: osmo-bts-sysmo fails to detect RACH bursts from osmocom-bbhttps://osmocom.org/issues/3052?journal_id=81272018-03-10T08:31:57Zlaforge
<ul></ul><p>I cannot find anything related in the OsmocomBB or TSM30 source code. There's nothing to configure in terms of RACH except the 8-bit RA value, timing and transmit power. No idea yet why the sysmobts PHY doesn't want to detect those access bursts</p> OsmoBTS - Bug #3052: osmo-bts-sysmo fails to detect RACH bursts from osmocom-bbhttps://osmocom.org/issues/3052?journal_id=81282018-03-10T08:40:10Zlaforge
<ul></ul><p>On Sat, Mar 10, 2018 at 05:21:04AM +0000, fixeria [REDMINE] wrote:</p>
<blockquote>
<p>I recommend you to try GRGSM-TRX and FakeTRX/burst_gen.py.<br />This would allow you to modulate and send any possible sequences.</p>
</blockquote>
<p>Thanks. I was trying to avoid adding even more parts to the equation,<br />but maybe I'll try.</p>
<blockquote>
<p>Also, what does "Wrong burst type" exactly mean?</p>
</blockquote>
<p>that's the beauty of a proprietary PHY. I guess the correlator<br />determines that neither of the three training sequences for RACH bursts<br />was detected over the correlation window.</p>
<blockquote>
<p>Is it possible to observe both BER and ToA values?</p>
</blockquote>
<p>BER = 0.16666</p>
<blockquote>
<p>BTW: I didn't know that there are more than one synch sequences.</p>
</blockquote>
<p>I meanwhile figoured out TS1 and TS2 are used for 11bit RACH requests in EGPRS.</p>
<blockquote>
<p>I've used to refer the 5.1.0, while the latest V14.4.0 (2018-01)<br />defines even more than three sequences...</p>
</blockquote>
<p>well, those are probably EGPRS2 related (nobody uses that) or EC-GSM-IoT.</p> OsmoBTS - Bug #3052: osmo-bts-sysmo fails to detect RACH bursts from osmocom-bbhttps://osmocom.org/issues/3052?journal_id=81292018-03-10T10:26:30Zlaforge
<ul></ul><p>the timing is not the problem, at least not when using osmo-bts-trx as reference.</p>
<p>When using L1CTL_PAR_REQ to set TA=0, osmo-bts-trx reports the bursts at toa256 of 7..15, which is as good as it gets. When using TA1, this goes to about toa256=-270, which is expected.</p>
<p>I've also tried older sysmobts firmware versions down to v2.4 with no change in behavior. I've used three different sysmoBTS boards and two different Motorola Phones. No change.</p> OsmoBTS - Bug #3052: osmo-bts-sysmo fails to detect RACH bursts from osmocom-bbhttps://osmocom.org/issues/3052?journal_id=81302018-03-10T10:49:19Zlaforge
<ul></ul><p>I've not only tested current master with old firmware, but also tested osmo-bts version 0.7.0 - no change in behaviour.</p> OsmoBTS - Bug #3052: osmo-bts-sysmo fails to detect RACH bursts from osmocom-bbhttps://osmocom.org/issues/3052?journal_id=81512018-03-11T19:50:27Zlaforge
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>80</i></li></ul> OsmoBTS - Bug #3052: osmo-bts-sysmo fails to detect RACH bursts from osmocom-bbhttps://osmocom.org/issues/3052?journal_id=82132018-03-14T05:42:40Zlaforge
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Stalled</i></li></ul> OsmoBTS - Bug #3052: osmo-bts-sysmo fails to detect RACH bursts from osmocom-bbhttps://osmocom.org/issues/3052?journal_id=201142020-10-25T20:32:35Zlaforge
<ul><li><strong>Status</strong> changed from <i>Stalled</i> to <i>In Progress</i></li></ul> OsmoBTS - Bug #3052: osmo-bts-sysmo fails to detect RACH bursts from osmocom-bbhttps://osmocom.org/issues/3052?journal_id=201162020-10-25T20:43:19Zlaforge
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Rejected</i></li></ul><p>not observed in a long time</p>