9 Jun
2020
9 Jun
'20
3:50 p.m.
Hi all,
What are the plans to expand support for new SDR devices?
When I check the contents of osmo-trx/Transceiver52M/device/ on the git
master I see the supported lms, uhd and usrp1 devices. For example the XTRX
SDR was presented at OsmoDevCon 2018. I expected it to be included in the
master soon. At this point I see its addition in the fairwaves /
libxtrx-wip branch from 2018. That doesn't give me much encouragement for
my next question.
Would it be possible to add support for PCIe SDR from Amarisoft?
Some information about SDR is here
https://discourse.myriadrf.org/t/amarisoft-sdr-integration-with-oai/2288
Based on the
https://media.ccc.de/v/osmocon2018-82-osmotrx-status-support-for-more-drive…
I tried to create support by myself. I've gotten into a state that some MS
with weak requirements for signal quality and timing can connect. My branch
is here https://github.com/XK1ZU/osmo-trx/tree/PCIeSDR-LMSstyle
gr-osmosdr support is here
https://github.com/XK1ZU/gr-osmosdr/commits/PCIeSDR
This osmo-trx is able to run for a few tens of seconds then it quits and I
have to restart it, so I would need a deeper understanding of the timing
and scheduling of processes within osmo-trx. Who should be a clock master
SW stack or SDR device?
I see a lot of log error messages as
0000> Transceiver.cpp:422 [tid=140137319651072][chan=0] dumping STALE burst
in TRX->SDR interface (1:1408722 vs 7:1408723), retrans=0
<0000> Transceiver.cpp:1122 [tid=140137311258368] ClockInterface: sending
IND CLOCK 1408899
or
0000> Transceiver.cpp:280 [tid=140137328043776] Starting the transceiver
<0000> radioInterface.cpp:181 [tid=140137328043776] Starting radio device
<0000> PCIESDRDevice.cpp:199 [tid=140137328043776] PCIESDRDevice::start
<0000> PCIESDRDevice.cpp:205 [tid=140137328043776] starting PCIeSDR...,
sample rate:1.08333e+06
<0000> PCIESDRDevice.cpp:234 [tid=140137328043776] PCIESDRDevice::flush
<0000> PCIESDRDevice.cpp:219 [tid=140137328043776] msdr_start ok:
<0000> PCIESDRDevice.cpp:532 [tid=140137328043776] Update Alignment
<0000> PCIESDRDevice.cpp:532 [tid=140137328043776] Update Alignment
<0000> radioInterface.cpp:202 [tid=140137328043776] Radio started
<0000> Threads.cpp:119 [tid=140137294472960] Thread 140137294472960 (task
18522) set name: TxLower
<0000> Threads.cpp:119 [tid=140137311258368] Thread 140137311258368 (task
18524) set name: RxUpper0
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
POWERON 0'
<0000> Threads.cpp:119 [tid=140137302865664] Thread 140137302865664 (task
18523) set name: RxLower
<0002> PCIESDRDevice.cpp:363 [tid=140137302865664] rc < 0
<0002> PCIESDRDevice.cpp:364 [tid=140137302865664] Sample buffer: Requested
timestamp is not valid
<0000> Threads.cpp:119 [tid=140137319651072] Thread 140137319651072 (task
18525) set name: TxUpper0
<0002> PCIESDRDevice.cpp:365 [tid=140137302865664] timestamp = 10960,
length = 262144, time_start = 6765960, time_end = 6766960, data_start =
223320, data_end = 224320
<0002> PCIESDRDevice.cpp:482 [tid=140137294472960] tx_underflow_count:3
rx_overflow_count:0
<0002> PCIESDRDevice.cpp:491 [tid=140137294472960] PCIeSDR: tx underrun
ts_tmp:10976 ts:10960 hwts:6762040
<0000> radioInterface.cpp:334 [tid=140137302865664] Receive error 0
<0000> Transceiver.cpp:1162 [tid=140137302865664] Something went wrong in
thread RxLower, requesting stop
<0002> PCIESDRDevice.cpp:482 [tid=140137294472960] tx_underflow_count:4
rx_overflow_count:0
<0002> PCIESDRDevice.cpp:491 [tid=140137294472960] PCIeSDR: tx underrun
ts_tmp:13476 ts:13460 hwts:6762278
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETRXGAIN 40'
<0000> PCIESDRDevice.cpp:318 [tid=140137328043776] Setting RX gain to 40 dB.
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETRXGAIN 0 40'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETPOWER 0'
<0000> PCIESDRDevice.cpp:297 [tid=140137328043776] Setting TX gain to 60
dB. device:0x1f6e0e0 chan:0
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETPOWER 0 0'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETSLOT 0 5'
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETSLOT 0 0 5'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETSLOT 1 7'
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETSLOT 0 1 7'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETSLOT 2 13'
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETSLOT 0 2 13'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETSLOT 3 13'
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETSLOT 0 3 13'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETSLOT 4 13'
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETSLOT 0 4 13'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETSLOT 5 8'
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETSLOT 0 5 8'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETSLOT 6 8'
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETSLOT 0 6 8'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETSLOT 5 13'
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETSLOT 0 5 13'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETSLOT 7 13'
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETSLOT 0 7 13'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETSLOT 6 13'
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETSLOT 0 6 13'
<0000> osmo-trx.cpp:485 [tid=140137400406720] Shutting down transceiver...
<0000> Transceiver.cpp:338 [tid=140137400406720] Stopping the transceiver
<0000> Transceiver.cpp:351 [tid=140137400406720] Stopping the device
<0000> PCIESDRDevice.cpp:254 [tid=140137400406720] PCIESDRDevice::stop
<0000> PCIESDRDevice.cpp:261 [tid=140137400406720] PCIESDR stopped
<0000> Transceiver.cpp:364 [tid=140137400406720] Transceiver stopped
<0000> PCIESDRDevice.cpp:78 [tid=140137400406720] Closing PCIESDR Device
Yours XK1Zu
18 Jul
18 Jul
4:17 p.m.
Hi,
What are the plans to expand support for new SDR
devices?
I don't think there is any.
Support for a given SDR pretty much needs two parts :
- Someone to write initial support for it in good enough shape and
submit it for inclusion.
That can either be the vendor, a user, or someone contracted by
someone else to write it.
USRP1 support comes from the root of OpenBTS code. UHD device
support was AFAIR initially written by Tom Tsou when he was working
for Ettus. Lime Support was a first patch from Fairwaves and then
improved and merged into mainline by Sysmocom. I know Lime themselves
have at least sponsored some hardware to various devs.
- Then someone has to maintain that driver and test it works. Once
merged, it'll probably be auto tested that it builds as part of
regression testing, but it won't be tested that it actually works.
But for testing it works, someone with access to the hardware will
need to continuously test it and make sure it doesn't get broken.
AFAIR Sysmocom has some automated testing with real hardware but
obviously they only do that with hardware that they have and have an
interest in maintaining.
When I check the contents of
osmo-trx/Transceiver52M/device/ on the git master I see the supported lms, uhd and usrp1
devices. For example the XTRX SDR was presented at OsmoDevCon 2018. I expected it to be
included in the master soon. At this point I see its addition in the fairwaves /
libxtrx-wip branch from 2018. That doesn't give me much encouragement for my next
question.
Would it be possible to add support for PCIe SDR from Amarisoft?
Probably ... see above.
If you write a patch that works and can maintain support for it over
time, that'll be a nice inclusion in osmo-trx.
Cheers,
Sylvain
21 Jul
21 Jul
3:07 p.m.
Hi all,
Hi,
What about considering a somehow wider group of SDRs using an additional layer with Soapy?
I am no coder at all and can't help, and maybe I am totally wrong anyway, but a more
universal approach looks interesting to me. A friend is coding at the moment a DMR
interface between MMDVM and soapy and is doing good progress. Also Soapy has proven to be
somehow "cell infrastructure ready" in the srsLTE project.
What are the plans to expand support for new SDR
devices?
I don't think there is any. Cheers,
Sylvain
With best regards
Ralph.
26 Jul
26 Jul
9:31 a.m.
Hi,
What about considering a somehow wider group of SDRs using an additional layer with
Soapy? I am no coder at all and can't help, and maybe I am totally wrong anyway, but a
more universal approach looks interesting to me. A friend is coding at the moment a DMR
interface between MMDVM and soapy and is doing good progress.
What are the plans to expand support for new SDR
devices?
I don't think there is any. Also Soapy has proven to be somehow "cell
infrastructure ready" in the srsLTE project.
Has it ? Is it used for production ready stability level anywhere ?
Last I heard it was a "yeah, it works sort-of sometimes" level of
support, but maybe that's outdated.
Even with UHD which is supposed to be "universal" there is still a
bunch of tweaking "per radio" for things like analog and digital
delays in the hardware itself, gain range, etc etc ... so Soapy would
likely have the same.
But if you want to give it a shot, go ahead.
Cheers,
Sylvain
18 Jul
18 Jul
6:19 p.m.
Hi,
without looking into much detail at your branch, I should suggest:
* Rebase your work on top of current osmo-trx master, the base commit
you use is uite old and the API has changed a bit since then, with some
fixes and improvements.
* Make sure you run both osmo-trx and osmo-bts-trx with RR scheduler
(realtime). For instance, osmo-trx VTY cmd "rt-prio 18", and
osmo-bts-trx cmd line arg "-r 1".
* From what i see in the logs, it looks like you have some issues with
how you are managing the tmestamps inside your device backend, so
something is not being done correctly in there most probably, then 0 is
returned and osmo-trx upper layers decide to stop the process.
Once you have something working acceptably fine (MS can use the network
more or less reliably, and osmo-trx doesn't stop or crash), I'm happy to
review your patch in gerrit.
Regards,
Pau
--
- Pau Espin Pedrol <pespin(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 Director: Harald Welte
8 Aug
8 Aug
3:46 p.m.
Hi,
I updated API and rebased it.
It works more stable with new version of osmo-bts.
What exactly does a "device backend" mean?
Is it content of osmo-trx/Transceiver52M/device/pciesdr/ or lower layers
(libsdr, kernel drivers or HW)?
This crash happen after device stop - start (caused by cmd PWROFF from
osmo-bts).
PCIESDRDevice.cpp:363 [tid=140137302865664] rc < 0
<0002> PCIESDRDevice.cpp:364 [tid=140137302865664] Sample buffer: Requested
I haven't found a working solution yet. Starting the demon again helps.
I managed to reach an uptime of more than 3 hours with one MS connected. So
I decide push it into gerrit for review
https://gerrit.osmocom.org/c/osmo-trx/+/19548
Are you considering adding support for floating format samples to the radio
interface?
The proprietary libsdr.so library (driver from manufacturer) expects
samples in float format. I have to convert short to float again during Rx /
Tx.
I received a feedbak from laforge with a request to complete the PCIeSDR
description. Is it possible to create a page on the wiki for this purpose?
Regards
XK1Zu
so 18. 7. 2020 v 18:19 odesílatel Pau Espin Pedrol <pespin(a)sysmocom.de>
napsal:
Hi,
without looking into much detail at your branch, I should suggest:
* Rebase your work on top of current osmo-trx master, the base commit
you use is uite old and the API has changed a bit since then, with some
fixes and improvements.
* Make sure you run both osmo-trx and osmo-bts-trx with RR scheduler
(realtime). For instance, osmo-trx VTY cmd "rt-prio 18", and
osmo-bts-trx cmd line arg "-r 1".
* From what i see in the logs, it looks like you have some issues with
how you are managing the tmestamps inside your device backend, so
something is not being done correctly in there most probably, then 0 is
returned and osmo-trx upper layers decide to stop the process.
Once you have something working acceptably fine (MS can use the network
more or less reliably, and osmo-trx doesn't stop or crash), I'm happy to
review your patch in gerrit.
Regards,
Pau
--
- Pau Espin Pedrol <pespin(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 Director: Harald Welte
17 Aug
17 Aug
11:01 a.m.
Hi,
On 8/8/20 3:46 PM, Xaver Zu wrote:
What exactly does a "device backend" mean?
Is it content of osmo-trx/Transceiver52M/device/pciesdr/ or lower layers
(libsdr, kernel drivers or HW)?
This crash happen after device stop - start (caused by cmd PWROFF from
osmo-bts).
When I talk about osmo-trx I mean each of osmo-trx-* binaries, which
basically differ on the code being taken from a different directory in
osmo-trx/Transceiver52M/device/ each.
PCIESDRDevice.cpp:363 [tid=140137302865664] rc < 0
<0002> PCIESDRDevice.cpp:364 [tid=140137302865664] Sample buffer: Requested
I haven't found a working solution yet. Starting the demon again helps.
I managed to reach an uptime of more than 3 hours with one MS connected.
So I decide push it into gerrit for review
https://gerrit.osmocom.org/c/osmo-trx/+/19548
Thanks, I'll have a look at some point when I find some time.
Are you considering adding support for floating format samples to the
radio interface?
No one is working or planning to work on that as far as I am concerned.
The proprietary libsdr.so library (driver from
manufacturer) expects
samples in float format. I have to convert short to float again during
Rx / Tx.
I received a feedbak from laforge with a request to complete the PCIeSDR
description. Is it possible to create a page on the wiki for this purpose?
Sure, ask for permissions to edit the wiki here if you don't have them yet.
--
- Pau Espin Pedrol <pespin(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 Director: Harald Welte
12:17 p.m.
On Mon, Aug 17, 2020 at 11:01:38AM +0200, Pau Espin Pedrol wrote:
I've granted wiki write privileges now.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
I received a
feedbak from laforge with a request to complete the PCIeSDR
description. Is it possible to create a page on the wiki for this purpose?
Sure, ask for permissions to edit the wiki here if you don't have them yet.
1356
days inactive
1425
days old
7 comments
5 participants
participants (5)
-
Harald Welte -
Pau Espin Pedrol -
Ralph A. Schmid, dk5ras -
Sylvain Munaut -
Xaver Zu