This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi 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 <laforge at gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)