osmo-trx with USRP1 - libusrp vs. UHD
Hi! I played with osmo-trx today and tried to run it with a USRP1 that I have laying around, though to no avail. osmo-trx supports two kinds of devices, USRP1 via libusrp and UHD. libusrp was last included in gnuradio 3.4.2[1] from Dec 2013, it unsurprisingly does not build on a recent Linux distribution, due to API incompatibilities with boost. The USRP1 would theoretically be supported by UHD, though the device initialization code in osmo-trx explicitly treats it differently, see [2,3]. I found an old ML post[4] from 2015 that pretty much asks the same question but did not get an answer. Supposedly there is a simple reason why USRP1 is not driven via UHD in osmo-trx, but I don't know. Can somebody please enlighten me? Tom, maybe you? I would like to understand whether it is feasible to use an USRP1 with UHD for osmo-trx or one would have to go down the rabbit hole to build libusrp on a modern system. Kind regards, -Alex [1] https://gnuradio.org/releases/gnuradio/ [2] https://git.osmocom.org/osmo-trx/tree/Transceiver52M/UHDDevice.cpp#n512 [3] https://git.osmocom.org/osmo-trx/tree/Transceiver52M/USRPDevice.cpp [4] https://lists.osmocom.org/pipermail/openbsc/2015-January/000058.html
Hi Alexander, On Thu, Dec 21, 2017 at 07:57:24PM +0100, Alexander Huemer wrote:
I played with osmo-trx today and tried to run it with a USRP1 that I have laying around, though to no avail.
I also still have two USRP1 here that don't have a purpose anymore. My offer is: If you (or the community in general) works out how to make USRP1 work with current-day osmo-trx (either via UHD or via a ported libusrp) on a system like Debian9, I will make sure that a USRP1 becomes part of the osmo-gsm-tester setup[1] to ensure support for this board will not bit-rot again. Regards, Harald [1] https://osmocom.org/projects/osmo-gsm-tester/wiki/Wiki -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Hi, osmo-trx needs devices that support hardware timestamping of packets (TX/RX). The URSP1 UHD driver doesn't support that. All the timestamps are 'faked' in software. That's because the FPGA image for USRP1 doesn't support hardware timestamps. OpenBTS used a custom FPGA image where hardware timestamping support was added and they used libusrp (and not UHD) because it was a lower layer API and that let them access the raw content of the data packets sent by the USRP. That's needed because with that new FPGA image, the content of those packets is no longer just samples, but it now has a header with the timestamps and some flags that needs to be intepreted to generate the timestamping and removed before converting the samples. A long time ago I wanted to implement support for that FPGA image into UHD ... and then when I looked into UHD work, I gave up ... (basically I could never figure out _HOW_ UHD works). Cheers, Sylvain
Hi! On Wed, Dec 27, 2017 at 07:00:44AM +0100, Sylvain Munaut wrote:
osmo-trx needs devices that support hardware timestamping of packets (TX/RX).
The URSP1 UHD driver doesn't support that. All the timestamps are 'faked' in software. That's because the FPGA image for USRP1 doesn't support hardware timestamps.
OpenBTS used a custom FPGA image where hardware timestamping support was added and they used libusrp (and not UHD) because it was a lower layer API and that let them access the raw content of the data packets sent by the USRP. That's needed because with that new FPGA image, the content of those packets is no longer just samples, but it now has a header with the timestamps and some flags that needs to be intepreted to generate the timestamping and removed before converting the samples.
A long time ago I wanted to implement support for that FPGA image into UHD ... and then when I looked into UHD work, I gave up ... (basically I could never figure out _HOW_ UHD works).
Thanks for the great explanation! So, in theory it would be possible to make osmo-trx work with a USRP1 via UHD, though nobody has done (yet) what you described above. Kind regards, -Alex
Hi! On Thu, Dec 21, 2017 at 09:55:12PM +0100, Harald Welte wrote:
On Thu, Dec 21, 2017 at 07:57:24PM +0100, Alexander Huemer wrote:
I played with osmo-trx today and tried to run it with a USRP1 that I have laying around, though to no avail.
I also still have two USRP1 here that don't have a purpose anymore.
My offer is: If you (or the community in general) works out how to make USRP1 work with current-day osmo-trx (either via UHD or via a ported libusrp) on a system like Debian9, I will make sure that a USRP1 becomes part of the osmo-gsm-tester setup[1] to ensure support for this board will not bit-rot again.
Fair enough. What I did so far is: * Extract libusrp from gnuradio 3.4.2, using git filter-branch to preserve history * Craft custom configure.ac * Update m4 macros * Small fixes here and there libusrp builds without warnings now and can be installed with `make install` as expected. After a trivial fix of osmo-trx with `configure --with-usrp1` it starts without complaining. -- Transceiver active with 1 channel(s) Still, when I try to run a full network with osmo-{stp,hlr,msc,bsc,bts-trx}, osmo-bts-trx aborts with: <000b> trx_if.c:413 transceiver (phy0.0) rejected TRX command with response: 'RSP RXTUNE 1 1763200' <0001> bts.c:210 Shutting down BTS 0, Reason TRX-CTRL-MSG: CRITICAL Shutdown timer expired osmo-trx emits: ALERT 140296268797696 00:38:04.3 USRPDevice.cpp:590:setRxFreq: set RX: 1.7632e+09failed baseband freq: 1.75825e+09 DDC freq: -4.95e+06 residual freq: -0.00447035 ALERT 140296268797696 00:38:04.3 USRPDevice.cpp:590:setRxFreq: set RX: 1.7632e+09failed baseband freq: 1.75825e+09 DDC freq: -4.95e+06 residual freq: -0.00447035 ALERT 140296268797696 00:38:04.3 Transceiver.cpp:766:driveControl: RX failed to tune ALERT 140296268797696 00:38:04.3 Transceiver.cpp:766:driveControl: RX failed to tune I don't think that my clock is too far off, I am using a freshly calibrated clocktamer to feed 52MHz into the USRP. Why the USRP would not be able to tune to ARFCN 777 is not clear to me. E.g. kalibreate has no problem with receiving all ARFCNs in DCS. Should anybody have an idea what to look into, suggestions would be appreciated. Kind regards, -Alex
Hi. Just a little side note. On 18.01.2018 01:12, Alexander Huemer wrote:
After a trivial fix of osmo-trx with `configure --with-usrp1` it starts without complaining.
Might make sense to push this to gerrit to make it easier for people to follow your steps. -- - Max Suraev <msuraev@sysmocom.de> http://www.sysmocom.de/ =========================================== * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Harald Welte
Can I use a USRP1 without clock modification? Rafael Diniz On 01/18/2018 07:57 AM, Max wrote:
Hi.
Just a little side note.
On 18.01.2018 01:12, Alexander Huemer wrote:
After a trivial fix of osmo-trx with `configure --with-usrp1` it starts without complaining.
Might make sense to push this to gerrit to make it easier for people to follow your steps.
On Thu, Jan 18, 2018 at 10:57:52AM +0100, Max wrote:
On 18.01.2018 01:12, Alexander Huemer wrote:
After a trivial fix of osmo-trx with `configure --with-usrp1` it starts without complaining.
Might make sense to push this to gerrit to make it easier for people to follow your steps.
I will. Kind regards, -Alex
On Thu, Jan 18, 2018 at 05:51:54PM +0100, Alexander Huemer wrote:
On Thu, Jan 18, 2018 at 10:57:52AM +0100, Max wrote:
On 18.01.2018 01:12, Alexander Huemer wrote:
After a trivial fix of osmo-trx with `configure --with-usrp1` it starts without complaining.
Might make sense to push this to gerrit to make it easier for people to follow your steps.
I will.
https://gerrit.osmocom.org/#/c/5938/ Kind regards, -Alex
Hi Alexander, On Thu, Jan 18, 2018 at 01:12:32AM +0100, Alexander Huemer wrote:
What I did so far is: * Extract libusrp from gnuradio 3.4.2, using git filter-branch to preserve history * Craft custom configure.ac * Update m4 macros * Small fixes here and there
It might make sense to push the results into a git repository. I've created a libusrp.git on git.osmocom.org and gerrit. You should be able to push into it like any other osmocom project on gerrit. Regards, Harald -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
On Thu, Jan 18, 2018 at 02:59:34PM +0100, Harald Welte wrote:
On Thu, Jan 18, 2018 at 01:12:32AM +0100, Alexander Huemer wrote:
What I did so far is: * Extract libusrp from gnuradio 3.4.2, using git filter-branch to preserve history * Craft custom configure.ac * Update m4 macros * Small fixes here and there
It might make sense to push the results into a git repository.
Agreed.
I've created a libusrp.git on git.osmocom.org and gerrit.
Thanks.
You should be able to push into it like any other osmocom project on gerrit.
Given that what I have locally is a git repository with history (from former gnuradio.git, after filter-branch) and the repository on git.osmocom.org is currently empty, I believe pushing into gerrit is not yet the right thing to do, since the remote repository needs a base content first. I can of course discard the history, but I don't think that is beneficial. What about first pushing directly into git and then continuing via gerrit? Kind regards, -Alex
Hi Alexander, On Sun, Jan 21, 2018 at 01:53:06AM +0100, Alexander Huemer wrote:
I can of course discard the history, but I don't think that is beneficial.
No, let's keep history.
What about first pushing directly into git and then continuing via gerrit?
Yes, makes sense. As I don't seem to have a key of yours on record, and to avoid various other manual configuration steps: Is it possible for you to simply push it somewhere public, so I can fetch it from there, and use that as initial state for the osmocom.org repo? Thanks. -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
On Sun, Jan 21, 2018 at 01:31:17PM +0100, Harald Welte wrote:
On Sun, Jan 21, 2018 at 01:53:06AM +0100, Alexander Huemer wrote:
I can of course discard the history, but I don't think that is beneficial.
No, let's keep history.
What about first pushing directly into git and then continuing via gerrit?
Yes, makes sense. As I don't seem to have a key of yours on record, and to avoid various other manual configuration steps: Is it possible for you to simply push it somewhere public, so I can fetch it from there, and use that as initial state for the osmocom.org repo? Thanks.
There should be an ssh key of mine in gerrit, though the other way around isn't a problem either. $ git clone git://yade.xx.vu/libusrp Kind regards, -Alex
Hi Alexander, libusrp is now at http://git.osmocom.org/libusrp/ and I've just merged the first patch via gerrit. The build verification job (https://jenkins.osmocom.org/jenkins/job/gerrit-libusrp/) and the regular 'master' build job (https://jenkins.osmocom.org/jenkins/job/master-libusrp/) are working as expected. In case one would want debian/ubuntu packages, one would have to add a debian/{rules,control,...} to it. Not sure if somebody wants to work on this. I created https://osmocom.org/issues/2849 to not forget about it. What should be done is to add an axis to osmo-trx to build both --with-usrp1 and without it, to make sure our osmo-trx gerrit + master builds are always building in both configurations. Any volunteers here? Maybe dr.blobb? I created https://osmocom.org/issues/2848 to not forget about it Regards, Harald -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
On Sun, Jan 21, 2018 at 06:44:16PM +0100, Harald Welte wrote:
libusrp is now at http://git.osmocom.org/libusrp/ and I've just merged the first patch via gerrit. The build verification job (https://jenkins.osmocom.org/jenkins/job/gerrit-libusrp/) and the regular 'master' build job (https://jenkins.osmocom.org/jenkins/job/master-libusrp/) are working as expected.
Nice, thanks.
In case one would want debian/ubuntu packages, one would have to add a debian/{rules,control,...} to it. Not sure if somebody wants to work on this. I created https://osmocom.org/issues/2849 to not forget about it.
That would indeed be useful, though only if it can be proven that it is indeed possible to successfully run osmo-trx with it, which is not the case (yet). It would be great if someone besides me could give the combination USRP1 + libusrp + osmo-trx a try to see if it behaves similar to what I have reported. After all it is possible that something about my setup is weird and the same combination just works for other people. If it does not and the problem is reproducible, maybe somebody has a clue how to fix it. Also, what is now in git is not exactly perfect, please see the commit message of [1]. Somehow the right m4 macros are not adhered that the build environments of the firmware etc. depend on, so those parts don't build at the moment. Even though the currently broken parts are not required for osmo-trx that is not exactly pretty. Maybe somebody here on the list is in the mood to harvest those low hanging fruits? Kind regards, -Alex [1] http://git.osmocom.org/libusrp/commit/?id=ec6adccbbdda1a4614089aaf52f9e1bab7...
participants (5)
-
Alexander Huemer -
Harald Welte -
Max -
Rafael Diniz -
Sylvain Munaut