Hi.
While testing latest osmo-trx in multi-trx mode I've noticed following errors:
sudo chrt -r 99 ./Transceiver52M/osmo-trx -c 2 -x -m
linux; GNU C++ version 6.2.0 20161005; Boost_106100; UHD_003.009.006-release
opening configuration table from path :memory: Info: SSE3 support compiled in and supported by CPU Info: SSE4.1 support compiled in and supported by CPU
Config Settings Log Level............... NOTICE Device args............. TRX Base Port........... 5700 TRX Address............. 127.0.0.1 Channels................ 2 Tx Samples-per-Symbol... 4 Rx Samples-per-Symbol... 4 EDGE support............ Disabled Reference............... External C0 Filler Table......... Disabled Multi-Carrier........... Enabled Tuning offset........... 0 RSSI to dBm offset...... 0 Swap channels........... 0
-- Detected Device: B210 -- Operating over USB 2. -- Initialize CODEC control... -- Initialize Radio control... -- Performing register loopback test... pass -- Performing register loopback test... pass -- Performing CODEC loopback test... pass -- Performing CODEC loopback test... pass -- Asking for clock rate 16.000000 MHz... -- Actually got clock rate 16.000000 MHz. -- Performing timer loopback test... pass -- Performing timer loopback test... pass -- Setting master clock rate selection to 'automatic'. -- Asking for clock rate 51.200000 MHz... -- Actually got clock rate 51.200000 MHz. -- Performing timer loopback test... pass -- Performing timer loopback test... pass -- Setting B200/B210 4 SPS Multi-ARFCN -- Transceiver active with 2 channel(s) NOTICE 139729930782464 12:59:47.8 Transceiver.cpp:794:driveControl: Changing TSC from 0 to 7 NOTICE 139729930782464 12:59:47.8 Transceiver.cpp:243:start: Starting the transceiver NOTICE 139729930749696 12:59:48.0 Transceiver.cpp:794:driveControl: Changing TSC from 7 to 7
ALERT 139729930749696 12:59:48.0 UHDDevice.cpp:611:setRxGain: Requested non-existent channel 1 ALERT 139729930749696 12:59:48.0 UHDDevice.cpp:611:setRxGain: Requested non-existent channel 1
...
This doesn't seem to have any visible effect but still makes me wonder what's going on here? If this is indeed critical error than what exactly is broken and how to test it? If it's smth which could be safely ignored than why it's reported with alert priority?
Any help clarifying it would be appreciated.
On Wed, May 31, 2017 at 4:06 AM, Max msuraev@sysmocom.de wrote:
ALERT 139729930749696 12:59:48.0 UHDDevice.cpp:611:setRxGain: Requested non-existent channel 1
The error comes up because in MCBTS there is only one physical channel - as in one hardware RF gain element. So the receive gain on channel 0 is effectively a global setting for all ARFCN channels; gain on each ARFCN cannot be set independently.
Note that the transmit side behaves differently. The same gain effect exists for all channels, but there is no warning. Instead, the gain control command is sent to the device regardless of which ARFCN is selected.
Perhaps we should make the Tx and Rx gain behavior consistent. I'm open to suggestions.
-TT
Hi Tom,
In osmo-bts, we have the notion of a "phy link" and a "phy instance".
A PHY Link defines some kind of logical or physical interfae to a given PHY layer implementation. This can be some kind of shared memory device (sysmobts, litecell15), or a ethernet device (octbts).
The PHY Instance is a logical instance serving one ARFCN within the PHY Link.
AFAIR, for osmo-bts-trx, we moved the attenuation/gain parameters at some point into the "instance" so that there can be separate parameters for each of the two TRX.
If I understand you correctly, osmo-trx has two modes of multi-trx operation:
a) two soft ARFCN in one RF dac/adc-rx/tx chain in the SDR b) two sets of single-TRX, each on a separate dac/adc-rx/tx chain in the SDR
Correct?
In that case, the problem is that 'a' and 'b' would differ in terms of where the parameters should be put. In 'a' it should be global parameters for the entire 'PHY Link', in 'b' it shold be per 'PHY Instance'.
The only obvious logical way to resolve this would be to move the parameters to the 'PHY Link'. 'a' would then have one PHY link with two PHY instances (shared params), and 'b' would have two PHY links which one instance each (separate params).
The question is then how the separate TRX are exposed on the UDP-protocol between osmo-trx and osmo-bts-trx. I haven't yet looked at that part of the code [or forgot, sorry].
Regards, Harald
-
Harald Welte -
Max -
Tom Tsou