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-driver... 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
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
Hi all,
Hi,
What are the plans to expand support for new SDR devices?
I don't think there is any.
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.
Cheers,
Sylvain
With best regards
Ralph.
Hi,
What are the plans to expand support for new SDR devices?
I don't think there is any.
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.
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
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
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@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@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
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.
On Mon, Aug 17, 2020 at 11:01:38AM +0200, Pau Espin Pedrol wrote:
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.
I've granted wiki write privileges now.
-
Harald Welte -
Pau Espin Pedrol -
Ralph A. Schmid, dk5ras -
Sylvain Munaut -
Xaver Zu