Hi. I've noticed check for device type around Transceiver52M/UHDDevice.cpp:772 - seems like USRP B200 is not supported for multitrx configurations: sudo chrt 20 ./Transceiver52M/osmo-trx -c 2 sudo chrt 15 ./src/osmo-bts-trx/osmo-bts-trx -c ~/.config/osmocom/osmo-bts-trx.cfg -i 192.168.122.1 -t 2 Where does this limitation comes from? Is it just smth which is not implemented (yet) or it's impossible to implement due to X and Y? -- Max Suraev <msuraev@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
On 16/06/2016 17:00, Max wrote:
Hi.
I've noticed check for device type around Transceiver52M/UHDDevice.cpp:772 - seems like USRP B200 is not supported for multitrx configurations: sudo chrt 20 ./Transceiver52M/osmo-trx -c 2 sudo chrt 15 ./src/osmo-bts-trx/osmo-bts-trx -c ~/.config/osmocom/osmo-bts-trx.cfg -i 192.168.122.1 -t 2
Where does this limitation comes from? Is it just smth which is not implemented (yet) or it's impossible to implement due to X and Y?
Hi Max, multitrx is intended for multi-channel USRPs such as USRP B210 or UmTRX However, you could try Thomas's work on multi-arfcn transceiver which can be found here: https://github.com/ttsou/osmo-trx/tree/mcbts
On Thu, Jun 16, 2016 at 8:21 AM, Pierre Baudry <pierre.baudry@diateam.net> wrote:
On 16/06/2016 17:00, Max wrote:
I've noticed check for device type around Transceiver52M/UHDDevice.cpp:772 - seems like USRP B200 is not supported for multitrx configurations: sudo chrt 20 ./Transceiver52M/osmo-trx -c 2 sudo chrt 15 ./src/osmo-bts-trx/osmo-bts-trx -c ~/.config/osmocom/osmo-bts-trx.cfg -i 192.168.122.1 -t 2
Where does this limitation comes from? Is it just smth which is not implemented (yet) or it's impossible to implement due to X and Y?
B200 is a single RF channel device.
However, you could try Thomas's work on multi-arfcn transceiver which can be found here: https://github.com/ttsou/osmo-trx/tree/mcbts
Now that GPRS is working with osmo-bts-trx and osmo-trx, I will begin merging the multi-carrier transceiver chain in the coming week. The history is that multi-arfcn was initially developed on the single channel USRP2. In later devices, such as the UmTRX and B210, there were advantages in both simplicity and RF performance from separate discrete channels, and that became the preferred multi-channel approach used for later testing. There are still, however, benefits (i.e. cost and higher capacity support) to the multi-carrier approach on a single physical RF channel that make it worthwhile to support in mainline. -TT
Hi Tom, On Thu, Jun 16, 2016 at 10:10:50AM -0700, Tom Tsou wrote:
There are still, however, benefits (i.e. cost and higher capacity support) to the multi-carrier approach on a single physical RF channel that make it worthwhile to support in mainline.
I strongly agree. Multi-TRX is a feature for a single BTS with multiple transceivers (and one of them, per sectors). Having those on separate physical radio ports means you need to use external (expensive/lossy) combiners to combine those signals before amplification and feeding the transmit antenna. -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Hi Harald, On Fri, Jun 17, 2016 at 6:13 PM, Harald Welte <laforge@gnumonks.org> wrote:
On Thu, Jun 16, 2016 at 10:10:50AM -0700, Tom Tsou wrote:
There are still, however, benefits (i.e. cost and higher capacity support) to the multi-carrier approach on a single physical RF channel that make it worthwhile to support in mainline.
I strongly agree. Multi-TRX is a feature for a single BTS with multiple transceivers (and one of them, per sectors). Having those on separate physical radio ports means you need to use external (expensive/lossy) combiners to combine those signals before amplification and feeding the transmit antenna.
I completely agree that multi-arfcn support should be in the master. That said, I don't agree that it's always superior to existing approach we have with UmTRX/UmSITE where we use separate radio paths for different TRX. We couldn't achieve power efficiency and flexibility if we were using multi-arfcn approach. Not to mention that single ARFCN per TRX allows us to use simpler receivers. You also don't need a combiner if you want to route two TRX to a single antenna - X-Pol antennas are very popular and easy to get. And for more powerful BTS's (like 10W per channel) you can get real benefit from diversity receive, which again requires separate radio paths for both channels. -- Regards, Alexander Chemeris. CEO, Fairwaves, Inc. https://fairwaves.co
Thanks for explanation. In case of B210 I've got following error: <000b> trx_if.c:380 transceiver (phy0.1) rejected TRX command with response: 'RSP SETTSC 1 7' What could be causing it? Is there some special setting(s) required for 2nd TRX? On 06/16/2016 07:10 PM, Tom Tsou wrote:
On Thu, Jun 16, 2016 at 8:21 AM, Pierre Baudry <pierre.baudry@diateam.net> wrote:
On 16/06/2016 17:00, Max wrote:
I've noticed check for device type around Transceiver52M/UHDDevice.cpp:772 - seems like USRP B200 is not supported for multitrx configurations: sudo chrt 20 ./Transceiver52M/osmo-trx -c 2 sudo chrt 15 ./src/osmo-bts-trx/osmo-bts-trx -c ~/.config/osmocom/osmo-bts-trx.cfg -i 192.168.122.1 -t 2
Where does this limitation comes from? Is it just smth which is not implemented (yet) or it's impossible to implement due to X and Y? B200 is a single RF channel device.
However, you could try Thomas's work on multi-arfcn transceiver which can be found here: https://github.com/ttsou/osmo-trx/tree/mcbts Now that GPRS is working with osmo-bts-trx and osmo-trx, I will begin merging the multi-carrier transceiver chain in the coming week.
The history is that multi-arfcn was initially developed on the single channel USRP2. In later devices, such as the UmTRX and B210, there were advantages in both simplicity and RF performance from separate discrete channels, and that became the preferred multi-channel approach used for later testing.
There are still, however, benefits (i.e. cost and higher capacity support) to the multi-carrier approach on a single physical RF channel that make it worthwhile to support in mainline.
-TT
-- Max Suraev <msuraev@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
On 16/06/2016 16:00, Max wrote:
Hi. Hi Max.
I've noticed check for device type around Transceiver52M/UHDDevice.cpp:772 - seems like USRP B200 is not supported for multitrx configurations: sudo chrt 20 ./Transceiver52M/osmo-trx -c 2 sudo chrt 15 ./src/osmo-bts-trx/osmo-bts-trx -c ~/.config/osmocom/osmo-bts-trx.cfg -i 192.168.122.1 -t 2 I'm sure Alexander will chime in and confirm, but I'm fairly sure that -c is only for Fairwaves hardware Where does this limitation comes from? Is it just smth which is not implemented (yet) or it's impossible to implement due to X and Y?
I have a feeling that the answer here will be that "multiple TRX is only supported on the UmTRX", however, this sparked a memory and a query: In the distant past Thomas worked on a multiARFCN implementation and I kind of remember a suggestion that this could work on a USRP, although the practical problems with RF amplification made it probably not feasable, or economically viable. https://github.com/ttsou/openbts-multi-arfcn show's updates > 4 years ago. I'm not sure if any of this made it into the Transceiver for osmo-trx I'd love to know. Keith.
participants (6)
-
Alexander Chemeris -
Harald Welte -
Keith -
Max -
Pierre Baudry -
Tom Tsou