Somehow osmo-hlr is no longer building in OBS for a variety of targets
--
- 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 noticed the MSC test that wants osmo-msc to repeat a Paging to the BSC and
hNodeB.
After fixing the Iu tests, I wanted to get this last ttcn3-msc-test working, so
I was about to implement repeated Paging from osmo-msc, but the more I think
about it, the less it makes sense to me.
The commit log in osmo-ttcn3-hacks says:
Repeating will improve the reachability of MS when a Paging is lost
or not received because the MS is moving between states.
This reasoning seems flawed to me, because the BSC / hNodeB is between the MSC
and the MS, and the BSC *does* repeat Paging. That should cover MS moving
between states.
The link between MSC and {BSC,hNodeB} is considered reliable, and AFAICT
nothing really gets better when repeating a Paging request to the BSS.
It could make sense to maybe repeat Paging with a larger/more general Cell
Identifier List? But why not send the full list in the first place?
Also 3GPP TS 48.008 3.1.10 Paging says:
A single PAGING message across the MSC to BSS interface contains information
on the cells in which the page shall be broadcast.
I interpret the "A single" as: there is no repetition of Paging requests toward
the BSS, and that's also what makes most sense to me infrastructurally.
Is there any spec indicating repeated Paging from the MSC?
I would actually remove the test TC_lu_and_mt_sms_paging_repeated.
If that's the wrong call, we should specify how osmo-msc should repeat Paging.
Before that, having the test makes little sense...
What do you guys think?
~N
Hi all,
I wrote a script and am wondering whether it makes sense to publish it in
libosmocore/contrib/.
For codec negotiation patches, I was writing ladder diagrams manually in the
mscgen format, and it was so annoying to type "[label=]" all the time, that I
decided to write a script that parses a leaner ladder diagram format and
converts it to mscgen format.
I was going to use this format in osmo-msc.git, but actually, after I wrote the
first osmo-msc codec ladder diagram, I went a step further and automated the
process by transcribing an osmo-msc log output directly to a ladder diagram.
That script can output to mscgen format, so in the end there is no dependency
on that simpler ladder format from my osmo-msc patches.
When writing ladder diagrams manually in the future, I'll probably choose my
simpler ladder format. I could always submit the converted format instead of
that, i.e. keep the simpler format to myself entirely.
I could publish the script privately...
Any opinions? Does it make sense to put this in libosmocore/contrib/ before any
Osmocom git trees actually depend on it?
See branch neels/contrib
http://git.osmocom.org/libosmocore/commit/?h=neels/contrib&id=f1ec9483de0f9…
~N
Dear Osmocom developers,
please see the attached messages. I'm getting dozens of these since yesterday,
it appears likely some regression was merged? Any help is appreciated.
Regards,
Harald
--
- 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)
Hi all,
during the past couple of days, there have been a high number of build
failures due to 'illegal instruction'. I checked about a handful of
them, and they all happened on build2.osmocom.org.
On the machine nothing strange could be observed, i.e. no oopses or the like.
Also, debsums didn't report any broken compiler binaries.
I've taken the builds slaves offline and asked for the machine to be replaced
(disks will be moved so no data loss expected).
Let's hope that fixes it. If not, I guess a full re-install of OS +
lxc's (via ansible) is up next.
--
- 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)
On Mon, Oct 21, 2019 at 05:37:51PM +0100, ah med wrote:
> well,for the osmo-all.sh script,it can be found here under Running
> examples :
>
> https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_I…
Ha, completely forgot about that. I tweaked that wiki page a bit to be less of
a pitfall to newcomers (hopefully).
BTW, off-list, ah med wrote to us that he figured out to use osmo-trx and
osmo-bts-trx but still struggles with the BladeRF. We asked him to come back
on-list or visit IRC for further questions.
~N
after setting the osmo-bts-trx and osmo-trx-uhd and with a BLADERF X40 ,i
just got this when running my network !
every other services like HLR,MSC...work perfectly and just the
osmo-trx-uhd have some problems with the bladerf !
osmo-trx-uhd.service - Osmocom SDR BTS L1 Transceiver (UHD Backend)
Loaded: loaded (/lib/systemd/system/osmo-trx-uhd.service; disabled;
vendor preset: enabled)
Active: failed (Result: exit-code) since Mon 2019-10-21 20:04:25 CET;
5min ago
Process: 20384 ExecStart=/usr/bin/osmo-trx-uhd -C
/etc/osmocom/osmo-trx-uhd.cfg (code=exited, status=1/FAILURE)
Main PID: 20384 (code=exited, status=1/FAILURE)
Oct 21 20:04:24 osmo-trx-uhd[20384]: -- setSampleRate(Rx, 0, 4.000000
MHz), actual = 4.000000 MHz
Oct 21 20:04:24 osmo-trx-uhd[20384]: -- setSampleRate(Tx, 0, 4.000000
MHz), actual = 4.000000 MHz
Oct 21 20:04:24 osmo-trx-uhd[20384]: Mon Oct 21 20:04:24 2019 DDEV <0002>
UHDDevice.cpp:355 [tid=140004723987136] Unsupported device bladeRF
Oct 21 20:04:24 osmo-trx-uhd[20384]: Mon Oct 21 20:04:24 2019 DMAIN <0000>
osmo-trx.cpp:514 [tid=140004723987136] Failed to create radio device
Oct 21 20:04:24 osmo-trx-uhd[20384]: Mon Oct 21 20:04:24 2019 DMAIN <0000>
osmo-trx.cpp:485 [tid=140004723987136] Shutting down transceiver...
Oct 21 20:04:24 osmo-trx-uhd[20384]: -- bladerf_close()
Oct 21 20:04:25 systemd[1]: Stopping Osmocom SDR BTS L1 Transceiver (UHD
Backend)...
Oct 21 20:04:25 systemd[1]: osmo-trx-uhd.service: Main process exited,
code=exited, status=1/FAILURE
Oct 21 20:04:25 systemd[1]: osmo-trx-uhd.service: Failed with result
'exit-code'.
Oct 21 20:04:25 systemd[1]: Stopped Osmocom SDR BTS L1 Transceiver (UHD
Backend).
I am using the systemd service file .all parts are installed using apt-get
install via the latest builds!.
by the way,the uhd_find_devices give the correct output!
uhd_find_devices
linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.000-0-unknown
[INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501;
UHD_3.14.1.1-release
--------------------------------------------------
-- UHD Device 0
--------------------------------------------------
Device Address:
serial: 9e52d2c864bc9b191e8a3327a4b2a216
backend: libusb
device: 0x01:0x0E
driver: bladerf
instance: 0
label: BladeRF #0 [9e52d2c8..a4b2a216]
type: soapy
bladeRF-cli -p
Description: Nuand bladeRF
Backend: libusb
Serial: 9e52d2c864bc9b191e8a3327a4b2a216
USB Bus: 1
USB Address: 17
bladeRF> version
bladeRF-cli version: 1.7.1-2018.12-rc3-2-ppabionic
libbladeRF version: 2.2.0-2018.12-rc3-2-ppabionic
Firmware version: 1.9.1
FPGA version: 0.10.2
SoapySDRUtil --probe="driver=bladerf"
######################################################
## Soapy SDR -- the SDR abstraction library ##
######################################################
Probe device driver=bladerf
[INFO] bladerf_open_with_devinfo()
[WARNING @ host/libraries/libbladeRF/src/board/bladerf1/bladerf1.c:1705] RX
DC calibration table not found. Manual gain control will be used instead.
[INFO @ host/libraries/libbladeRF/src/board/bladerf1/bladerf1.c:1706] To
enable AGC, see "Generating a DC offset table" at
https://github.com/Nuand/bladeRF/wiki/DC-offset-and-IQ-Imbalance-Correction
[INFO] bladerf_get_serial() = 9e52d2c864bc9b191e8a3327a4b2a216
[INFO] setSampleRate(Rx, 0, 4.000000 MHz), actual = 4.000000 MHz
[INFO] setSampleRate(Tx, 0, 4.000000 MHz), actual = 4.000000 MHz
[WARNING @ host/libraries/libbladeRF/src/board/bladerf1/bladerf1.c:1705] RX
DC calibration table not found. Manual gain control will be used instead.
[INFO @ host/libraries/libbladeRF/src/board/bladerf1/bladerf1.c:1706] To
enable AGC, see "Generating a DC offset table" at
https://github.com/Nuand/bladeRF/wiki/DC-offset-and-IQ-Imbalance-Correction
----------------------------------------------------
-- Device identification
----------------------------------------------------
driver=bladeRF
hardware=bladerf1
fpga_size=40
fpga_version=0.10.2
fw_version=1.9.1
serial=9e52d2c864bc9b191e8a3327a4b2a216
----------------------------------------------------
-- Peripheral summary
----------------------------------------------------
Channels: 1 Rx, 1 Tx
Timestamps: YES
Registers: LMS
Other Settings:
* XB200 Transverter - bladeRF XB200 Transverter Board
[key=xb200, default=disabled, type=string, options=(disabled, 50M,
144M, 222M, auto1db, auto3db, auto, custom)]
* Sampling Mode - Internal = Via RX/TX connectors, External = Direct
sampling from J60/J61 connectors
[key=sampling_mode, default=internal, type=string,
options=(internal, external)]
* Loopback Mode - Enable/disable internal loopback
[key=loopback, default=none, type=string, options=(none, firmware,
bb_txlpf_rxvga2, bb_txlpf_rxlpf, bb_txvga1_rxvga2, bb_txvga1_rxlpf,
rf_lna1, rf_lna2, rf_lna3)]
* Reset Device - Reset the device, causing it to reload its firmware
from flash.
[key=reset, default=false, type=bool, options=(true, false)]
* Erase the FPGA region of flash - Erase the FPGA region of SPI flash,
effectively disabling FPGA autoloading.
[key=erase_stored_fpga, default=false, type=bool, options=(true,
false)]
* Write FX3 firmware to flash - Write FX3 firmware to the bladeRF's
SPI flash from the provided file path. This will require a power cycle to
take effect.
[key=flash_firmware, type=string]
* Write to the FPGA region of flash - Write FPGA image to the
bladeRF's SPI flash from the provided file path and enable FPGA loading
from SPI flash at power on.
[key=flash_fpga, type=string]
* Clear out a firmware signature word in flash and jump to FX3
bootloader - The device will continue to boot into the FX3 bootloader
across power cycles until new firmware is written to the device.
[key=jump_to_bootloader, default=false, type=bool, options=(true,
false)]
* Load device's FPGA - Load device's FPGA from the provided file path.
Note that this FPGA configuration will be reset at the next power cycle.
[key=load_fpga, type=string]
GPIOs: CONFIG, EXPANSION
----------------------------------------------------
-- RX Channel 0
----------------------------------------------------
Full-duplex: YES
Supports AGC: NO
Stream formats: CS16, CF32
Native format: CS16 [full-scale=2048]
Stream args:
* Buffer Count - Number of async USB buffers.
[key=buffers, units=buffers, default=32, type=int]
* Buffer Length - Number of bytes per USB buffer, the number must be a
multiple of 1024.
[key=buflen, units=bytes, default=4096, type=int]
* Num Transfers - Number of async USB transfers. Use 0 for automatic
[key=transfers, units=bytes, default=0, type=int, range=[0, 32]]
Antennas: RX
Corrections: DC offset, IQ balance
Full gain range: [-1, 60, 1] dB
lna gain range: [0, 6, 3] dB
rxvga1 gain range: [5, 30, 1] dB
rxvga2 gain range: [0, 30, 3] dB
Full freq range: [237.5, 3800] MHz
RF freq range: [237.5, 3800] MHz
Sample rates: [0.08, 10], [10, 20], [20, 40] MSps
Filter bandwidths: [1.5, 28] MHz
----------------------------------------------------
-- TX Channel 0
----------------------------------------------------
Full-duplex: YES
Supports AGC: NO
Stream formats: CS16, CF32
Native format: CS16 [full-scale=2048]
Stream args:
* Buffer Count - Number of async USB buffers.
[key=buffers, units=buffers, default=32, type=int]
* Buffer Length - Number of bytes per USB buffer, the number must be a
multiple of 1024.
[key=buflen, units=bytes, default=4096, type=int]
* Num Transfers - Number of async USB transfers. Use 0 for automatic
[key=transfers, units=bytes, default=0, type=int, range=[0, 32]]
Antennas: TX
Corrections: DC offset, IQ balance
Full gain range: [17, 73, 1] dB
txvga1 gain range: [-35, -4, 1] dB
txvga2 gain range: [0, 25, 1] dB
Full freq range: [237.5, 3800] MHz
RF freq range: [237.5, 3800] MHz
Sample rates: [0.08, 10], [10, 20], [20, 40] MSps
Filter bandwidths: [1.5, 28] MHz
[INFO] bladerf_close()
HI
Hope that you are doing well!
system :
Ubuntu 18.04.3 LTS
when trying to start the osmocom CNI using the osmo-all script i will get :
./osmo-all.sh restart
> + systemctl restart osmo-hlr osmo-msc osmo-mgw osmo-ggsn osmo-sgsn
> osmo-stp osmo-bsc osmo-hnbgw osmo-bts-sysmo osmo-pcu
> Failed to restart osmo-bts-sysmo.service: Unit osmo-bts-sysmo.service not
> found.
>
so seems that osmo-bts it's not installed,wjen i try to install it will get
:
sudo apt-get install osmo-bts
>
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
>
> The following packages have unmet dependencies:
> osmo-bts : Depends: libosmoabis5 (>= 0.3.2+20151106git86fc3c8) but it is
> not going to be installed
> E: Unable to correct problems, you have held broken packages.
and when trying to install libosmoabis5 i will get :
sudo apt-get install libosmoabis5
> The following packages will be REMOVED:
> libosmo-gsup-client0 libosmoabis6 osmo-bsc osmo-bts-trx osmo-bts-virtual
> osmo-hlr osmo-msc osmo-sgsn
> The following NEW packages will be installed:
> libosmoabis5
> 0 upgraded, 1 newly installed, 8 to remove and 0 not upgraded.
>
thanks in advnace!
Hi,
> libosmocore.so.4 -> libosmocore.so.4.0.0
> libosmovty.so.0 -> libosmovty.so.0.0.0
it looks like you have installed a very old libosmocore.
You need to remove it (make uninstall) and install the
recent one from the upstream (not from OsmocomBB).
With best regards,
Vadim Yanitskiy.
Hello,
Unfortunately I have come up to the problem that I can't google myself and
my friends can't help with either. Maybe it has something to do with readme
saying that libsomocore in the git I pulled isn't for system wide
installation but when I make the osmocombb src then it spits out this:
configure: error: Package requirements (libosmovty >= 0.10.0) were not met:
Requested 'libosmovty >= 0.10.0' but version of Osmocom VTY Interface
Library is UNKNOWN
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables LIBOSMOVTY_CFLAGS
and LIBOSMOVTY_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
Makefile:94: recipe for target 'host/layer23/Makefile' failed
make: *** [host/layer23/Makefile] Error 1
If I need to get a different libosmocore could you provide it to me?
Thank you
