21 Dec
2017
21 Dec
'17
7:57 p.m.
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
21 Dec
21 Dec
9:55 p.m.
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
27 Dec
27 Dec
7 a.m.
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
18 Jan
18 Jan
1:14 a.m.
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
1:12 a.m.
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:
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
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. 
10:57 a.m.
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(a)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
3:04 p.m.
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.
5:51 p.m.
On Thu, Jan 18, 2018 at 10:57:52AM +0100, Max wrote:
On 18.01.2018 01:12, Alexander Huemer wrote:
I will.
Kind regards,
-Alex
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.
20 Jan
20 Jan
11:44 p.m.
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:
https://gerrit.osmocom.org/#/c/5938/
Kind regards,
-Alex
On 18.01.2018 01:12, Alexander Huemer wrote:
I will.
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.
18 Jan
18 Jan
2:59 p.m.
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
21 Jan
21 Jan
1:53 a.m.
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:
Agreed.
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.
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
1:31 p.m.
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
2:18 p.m.
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:
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
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.
6:44 p.m.
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
7:04 p.m.
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=ec6adccbbdda1a4614089aaf52f9e1bab…
2294
days inactive
2325
days old
14 comments
5 participants
participants (5)
-
Alexander Huemer -
Harald Welte -
Max -
Rafael Diniz -
Sylvain Munaut