https://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092017-08-10T14:34:25ZOpen Source Mobile CommunicationsOsmoTRX - Feature #2430: osmo-trx support bladerfhttps://projects.osmocom.org/issues/2430?journal_id=49292017-08-10T14:34:25ZVladimir
<ul></ul><p>Vladimir wrote:</p>
<blockquote>
<p>Anyone can add support for a bladerf for osm-trx<br />I found these files, but when build different errors come out</p>
</blockquote> OsmoTRX - Feature #2430: osmo-trx support bladerfhttps://projects.osmocom.org/issues/2430?journal_id=50062017-08-15T17:52:45Zlaforge
<ul><li><strong>Tracker</strong> changed from <i>Support</i> to <i>Feature</i></li><li><strong>Priority</strong> changed from <i>Normal</i> to <i>Low</i></li></ul><p>We'd be more than happy to merge any patches for BladeRF support. However, some of the users/proponents of OsmoTRX on BladeRF would have to develop the related code, test it and submit patches, preferrably via gerrit.osmocom.org.</p> OsmoTRX - Feature #2430: osmo-trx support bladerfhttps://projects.osmocom.org/issues/2430?journal_id=73812018-02-01T20:09:52Zroox
<ul></ul><p>Here are some notes from my research on this topic:</p>
<p>History of the bladeRF compatible transceiver:</p>
<ul>
<li>In <strong>March 2014</strong> @robertghilduta (Robert Ghilduta, Nuand LLC) released the initial transceiver code based on Tranceiver52M<br /> - <a class="external" href="https://github.com/Nuand/YateBTS/commit/d0cb6b2863abb5d0ffadd1cd4770b3df52365317">https://github.com/Nuand/YateBTS/commit/d0cb6b2863abb5d0ffadd1cd4770b3df52365317</a></li>
<li>In <strong>April 2014</strong> @robertghilduta switched to TransceiverRAD1 since he had some problems with Transceiver52M<br /> - <a class="external" href="https://github.com/Nuand/YateBTS/commit/36cb7dd06dcf33647ba3307781ff9cf1a271872a">https://github.com/Nuand/YateBTS/commit/36cb7dd06dcf33647ba3307781ff9cf1a271872a</a></li>
<li>Until <strong>June 2015</strong> the TransceiverRAD1 based transceiver code was used and extended with minor improvements by the yate-people as part of yateBTS<br /> - <a class="external" href="http://yate.null.ro/websvn/revision.php?repname=yatebts&path=%2F&rev=503">http://yate.null.ro/websvn/revision.php?repname=yatebts&path=%2F&rev=503</a> (svn rev503 is the last version before this kind of transceiver was dropped)<br /> - <em>Major changes</em>:<br /> - Drop the openBTS-style reading of the configuration parameters via the sqlite-db. Read those parameters from a file instead.<br /> - Add capability for bladeRF to use USB 2 High Speed mode<br /> - Add some functions for easier troubleshooting bladeRf-RF-related things</li>
<li>Since late <strong>June 2015</strong> the yate-people are using a new transceiver for yateBTS and the TransceiverRAD1 based transceiver was removed from their repository<br /> - TransceiverRAD1 delete commit: <a class="external" href="http://yate.null.ro/websvn/revision.php?repname=yatebts&path=%2F&rev=504">http://yate.null.ro/websvn/revision.php?repname=yatebts&path=%2F&rev=504</a><br /> - New transceiver code: <a class="external" href="http://yate.null.ro/websvn/listing.php?repname=yatebts&path=%2Ftrunk%2Ftransceiver%2F&opt=dir">http://yate.null.ro/websvn/listing.php?repname=yatebts&path=%2Ftrunk%2Ftransceiver%2F&opt=dir</a><br /> - <em>Major changes in the new tranceiver code</em>:<br /> - Most parts were completely rewritten (by David Burgess?)<br /> - The transceiver interface was changed (for some unknown reason) - it's not longer compatible with OsmoBTS or OpenBTS :(</li>
<li>In <strong>December 2017</strong> @robertghilduta (Robert Ghilduta, Nuand LLC) released a transceiver that can be used with OpenBTS-UMTS<br /> - <a class="external" href="https://github.com/Nuand/OpenBTS-UMTS/commit/7cf94d986c2644b81c5fd900219075d034a68c31">https://github.com/Nuand/OpenBTS-UMTS/commit/7cf94d986c2644b81c5fd900219075d034a68c31</a><br /> - It's again based on the code for RAD1-based devices</li>
</ul>
<p>There are some issues with the bladeRF integration:<br />The transceiver code thats actually used in osmo-trx evolved from Tranceiver52M (UHD-based devices) while the available tranceiver code for bladeRF is either based on TransceiverRAD1 or uses an incompatible transceiver interface.</p>
<p>I also did some experiments with the last available TransceiverRAD1-based code from:<br /><a class="external" href="http://yate.null.ro/websvn/revision.php?repname=yatebts&path=%2F&rev=503">http://yate.null.ro/websvn/revision.php?repname=yatebts&path=%2F&rev=503</a></p>
<p>01) Compile yate-bts (rev 503)<br /><pre>
svn checkout -r 503 http://voip.null.ro/svn/yatebts/trunk yatebts
./configure --enable-bladerf
make
cp ybts.conf.sample mbts/TransceiverRAD1/
</pre><br />02) Run the transceiver (it automatically loads FPGA version 0.0.3):<br />(!) Make sure your bladeRF run with FX3 Firmware version v1.9.1 (v2.0.0 is not compatible!!!)<br /><pre>
cd yatebts/mbts/TransceiverRAD1/
export MBTSConfigFile=ybts.conf.sample
./transceiver-bladerf
</pre></p>
<p>03) Run all the other stuff you need for an osmocom-environment<br />At least: osmo-hlr, osmo-stp, osmo-msc, osmo-mgw, osmo-bsc, osmo-bts</p>
04) <strong>The result</strong><br />The transceiver connects to osmo-bts... and RF-stuff will be setup up.<br />So far so good but...
<ul>
<li>Most of the time UEs cannot see the cell</li>
<li>Even if I have a UE that does see the cell it will not camp on that cell</li>
</ul>
<p>Here's the from osmo-bsc when a UE tries to connect:<br /><pre>
<0004> abis_rsl.c:1288 (bts=0,trx=0,ts=0,ss=0) state ACTIVATION REQUESTED -> ACTIVE
<0004> abis_rsl.c:1883 BTS 0 CHAN RQD: reason: answer to paging (ra=0x25, neci=0x00, chreq_reason=0x01)
<0000> chan_alloc.c:412 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Allocating lchan=1 as SDCCH
<0004> abis_rsl.c:1965 (bts=0,trx=0,ts=0,ss=1) Activating ARFCN(870) SS(1) lctype SDCCH r=PAGING ra=0x25 ta=0
<0004> abis_rsl.c:596 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Tx RSL Channel Activate with act_type=INITIAL
<0004> abis_rsl.c:625 (bts=0,trx=0,ts=0,ss=1) state NONE -> ACTIVATION REQUESTED
<0004> abis_rsl.c:1629 (bts=0,trx=0,ts=0,ss=1) CHANNEL ACTIVATE ACK
<0004> abis_rsl.c:1288 (bts=0,trx=0,ts=0,ss=1) state ACTIVATION REQUESTED -> ACTIVE
<0004> abis_rsl.c:1753 (bts=0,trx=0,ts=0,ss=0) T3101 expired: no response to IMMEDIATE ASSIGN
<0004> abis_rsl.c:870 (bts=0,trx=0,ts=0,ss=0) RF Channel Release due to error: 1
<0004> abis_rsl.c:780 (bts=0,trx=0,ts=0,ss=0) DEACTivate SACCH CMD
<0004> abis_rsl.c:901 (bts=0,trx=0,ts=0,ss=0) state ACTIVE -> RELEASE DUE ERROR
<0004> abis_rsl.c:942 (bts=0,trx=0,ts=0,ss=0) RF CHANNEL RELEASE ACK
<0004> abis_rsl.c:1753 (bts=0,trx=0,ts=0,ss=1) T3101 expired: no response to IMMEDIATE ASSIGN
<0004> abis_rsl.c:870 (bts=0,trx=0,ts=0,ss=1) RF Channel Release due to error: 1
<0004> abis_rsl.c:780 (bts=0,trx=0,ts=0,ss=1) DEACTivate SACCH CMD
<0004> abis_rsl.c:901 (bts=0,trx=0,ts=0,ss=1) state ACTIVE -> RELEASE DUE ERROR
<0004> abis_rsl.c:942 (bts=0,trx=0,ts=0,ss=1) RF CHANNEL RELEASE ACK
<0004> abis_rsl.c:829 (bts=0,trx=0,ts=0,ss=0) is back in operation.
<0004> abis_rsl.c:830 (bts=0,trx=0,ts=0,ss=0) state RELEASE DUE ERROR -> NONE
<0004> abis_rsl.c:829 (bts=0,trx=0,ts=0,ss=1) is back in operation.
<0004> abis_rsl.c:830 (bts=0,trx=0,ts=0,ss=1) state RELEASE DUE ERROR -> NONE
</pre></p>
<p>Some years ago others also had no sucess with the original RAD1 devices and osmo-bts and the issues they had were similar to the ones I just described...</p>
<ul>
<li><a class="external" href="http://lists.osmocom.org/pipermail/openbsc/2014-July/007570.html">http://lists.osmocom.org/pipermail/openbsc/2014-July/007570.html</a></li>
<li><a class="external" href="https://github.com/kheimerl/vbts-openbts/commits/osmotrx">https://github.com/kheimerl/vbts-openbts/commits/osmotrx</a></li>
</ul> OsmoTRX - Feature #2430: osmo-trx support bladerfhttps://projects.osmocom.org/issues/2430?journal_id=73852018-02-02T07:50:10Zlaforge
<ul></ul><p>Thanks for your research and for the related summary.</p>
<p>I think it could make sense to simply capture a protocol trace on a working yatebts<br />setup, os one can see the protocol between their "modern" transceiver and yatebts.</p>
<p>This way one could see how the protocol looks like<br />1) for initialization/control (the CMD + timing mechanism in the old protocol)<br />2) for actual traffic bursts</p>
<p>Assuming the functional split is still the same (modulation/demodulation in the transceiver,<br />convolutional coding/decoding in the bts), there would be the option of implementing that<br />same protocol in OsmoBTS in order to be compatible.</p>
<p>One would then have a configuration option on which protocol dialect to use.</p>
<p>The other approach would be to keep the OsmoTRX code base as-is, but only add the interface<br />on the radio side. This has the advantage of having the same (known) code on all SDR platforms.</p>
<p>So I think I generally see the following three options:</p>
<p>1) implement "new" protocol [as an option] in omso-bts-trx<br />2) implement libbladerf based support in osmo-trx<br />3) use soapysdr-module-bladerf, soapysdr and soapy-uhd, similar to how LimeSDR support<br />is currently handled in OsmoTRX</p>
<p>In terms of effort, '3' should be the easiest option. Not elegant, but not really any<br />significant changes to code / architecture / protocols required.</p> OsmoTRX - Feature #2430: osmo-trx support bladerfhttps://projects.osmocom.org/issues/2430?journal_id=77672018-02-22T21:07:54Zroox
<ul><li><strong>File</strong> <a href="/attachments/2969">yate-with-yatebts-debug-cli.txt</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/2969/yate-with-yatebts-debug-cli.txt">yate-with-yatebts-debug-cli.txt</a> added</li><li><strong>File</strong> <a href="/attachments/2970">yatebts-modern-tranceiver.pcap</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/2970/yatebts-modern-tranceiver.pcap">yatebts-modern-tranceiver.pcap</a> added</li></ul><p>Here's some debug output and a pcap trace from a YateBTS session thats using their "modern" transceiver.<br />The trace includes Radio/BTS setup, MS attach and a MO voice call.</p>
Test environment:
<ul>
<li>bladeRF X40 (via USB2)</li>
<li>Yate v6.0.0</li>
<li>YateBTS v6.0.0</li>
</ul>
<p>non-default ybts.conf parameters:<br /><pre>
Radio.Band=1800
Radio.C0=870
Identity.MCC=001
Identity.MNC=01
Identity.LAC=1
Identity.CI=1
Identity.BSIC.BCC=1
Identity.BSIC.NCC=1
Identity.ShortName=YateBTS
Radio.PowerManager.MaxAttenDB=10
Radio.PowerManager.MinAttenDB=0
...
</pre></p> OsmoTRX - Feature #2430: osmo-trx support bladerfhttps://projects.osmocom.org/issues/2430?journal_id=77752018-02-23T15:02:58Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-3 priority-2 priority-default closed" href="/issues/2975">Bug #2975</a>: OsmoBTS doesn't generate measurement indications in absence of uplink bursts</i> added</li></ul> OsmoTRX - Feature #2430: osmo-trx support bladerfhttps://projects.osmocom.org/issues/2430?journal_id=77772018-02-23T15:03:08Zlaforge
<ul><li><strong>Related to</strong> deleted (<i><a class="issue tracker-1 status-3 priority-2 priority-default closed" href="/issues/2975">Bug #2975</a>: OsmoBTS doesn't generate measurement indications in absence of uplink bursts</i>)</li></ul> OsmoTRX - Feature #2430: osmo-trx support bladerfhttps://projects.osmocom.org/issues/2430?journal_id=77852018-02-23T17:14:11Zlaforge
<ul></ul><p>Interesting, thanks for posting. I did a very brief look at the pcap using the new wireshark dissector for "our" old TRX protocol in <a class="external" href="http://git.osmocom.org/wireshark/log/?h=laforge/trx">http://git.osmocom.org/wireshark/log/?h=laforge/trx</a> and it can even still decode some of it.</p>
<p>More research is needed, but it seems that at least fundamentally the concept of ASCII commands in UDP on one port with binary burst data on other UDP ports has remained.</p> OsmoTRX - Feature #2430: osmo-trx support bladerfhttps://projects.osmocom.org/issues/2430?journal_id=235032022-01-26T18:08:45Zfixeria
<ul><li><strong>Has duplicate</strong> <i><a class="issue tracker-2 status-6 priority-1 priority-lowest closed" href="/issues/5420">Feature #5420</a>: osmo-trx not detecing bladerf</i> added</li></ul> OsmoTRX - Feature #2430: osmo-trx support bladerfhttps://projects.osmocom.org/issues/2430?journal_id=235142022-01-27T10:34:27Zfixeria
<ul></ul><p>Hi all,</p>
<p>roox wrote in <a href="#note-5">#note-5</a>:</p>
<blockquote>
<p>Here's some debug output and a pcap trace from a YateBTS session thats using their "modern" transceiver.<br />The trace includes Radio/BTS setup, MS attach and a MO voice call.</p>
</blockquote>
<p>this brought my attention (after being mentioned in <a class="issue tracker-2 status-6 priority-1 priority-lowest closed" title="Feature: osmo-trx not detecing bladerf (Rejected)" href="https://projects.osmocom.org/issues/5420">#5420</a>), so I had a quick look at the attached PCAP file.</p>
<p>laforge wrote in <a href="#note-8">#note-8</a>:</p>
<blockquote>
<p>More research is needed, but it seems that at least fundamentally the concept of ASCII commands in UDP on one port with binary burst data on other UDP ports has remained.</p>
</blockquote>
<p>Please find my observations below:</p>
<ul>
<li>The control plane protocol is pretty much the same as OsmoTRXC, with a few changes / additions:
<ul>
<li>New commands: 'CMD RESET', 'CMD STATISTICS <ON/OFF>', 'CMD READFACTORY',</li>
<li>Tune commands {RX,TX}TUNE indicate the freq. argument in kHz, but the response is in Hz.</li>
<li>The response for tune commands may actually indicate a different frequency?!?
<ul>
<li>'CMD RXTUNE 1781800' (DCS1800, ARFCN 870), 'RSP RXTUNE 1782400000' (DCS1800, ARFCN 873)</li>
<li>'CMD TXTUNE 1876800' (DCS1800, ARFCN 870), 'RSP TXTUNE 1877400000' (DCS1800, ARFCN 873)</li>
</ul>
</li>
<li>The clock indications are sent even before the POWERON command, however the value remains static:
<ul>
<li>'IND CLOCK 2', 'IND CLOCK 2', 'IND CLOCK 2' ...</li>
</ul>
</li>
</ul>
</li>
<li>The user plane protocol is also the same as OsmoTRXDv0
<ul>
<li>See <a class="external" href="http://voip.null.ro/svn/yatebts/trunk/transceiver/gsmutil.cpp">http://voip.null.ro/svn/yatebts/trunk/transceiver/gsmutil.cpp</a>: GSMTxBurst::parse() and GSMRxBurst::fillEstimatesBuffer()</li>
<li>The only difference is that they indicate filler bursts by setting <code>buf[0] & 0x10</code> (we kept this bit reserved)</li>
<li>The flow of Downlink TRXD PDUs looks chaotic, perhaps because their scheduler is multi-thread?</li>
</ul></li>
</ul>
<p>So far so good, no significant changes. The key difference is that they use <strong>different port mapping strategy</strong>.</p>
<p>In Osmocom we simply inherited the old mapping strategy from OpenBTS:</p>
<pre>
Given a base port `B` (5700), and a set of channels `0..N`, the ports related to
a channel `0 <= X <= N` are:
* The Master clock interface is located on port `P=B`.
* The `TRXC` interface for channel `X` is located on port `P=B+2X+1`
* The `TRXD` interface for channel `X` is located on port `P=B+2X+2`.
The corresponding interface for every socket is at `P+100` on the BTS side.
</pre>
<p>while the Yate transceiver follows a more linear approach without doing <code>P+100</code>:</p>
<pre>
Given a base port `B` (5700), the ports are mapped as follows:
* TRXC: commands are sent from `B+1` to `B`; responses go in the opposite direction;
* TRXC: clock indications are sent from `B+2` to `B+3`;
* TRXD: Uplink bursts are sent from `B+4` to `B+5`;
* TRXD: Downlink bursts are sent from `B+5` to `B+4`;
</pre> OsmoTRX - Feature #2430: osmo-trx support bladerfhttps://projects.osmocom.org/issues/2430?journal_id=238762022-04-07T09:21:24Zfixeria
<ul><li><strong>Has duplicate</strong> <i><a class="issue tracker-2 status-2 priority-3 priority-high3" href="/issues/5516">Feature #5516</a>: BladeRF 2.0 Support</i> added</li></ul>