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 Keith,
it is my understanding that the TA value of osmo-pcu is working as expected,
as the timing offset is established durign TBF establishment. What osmo-pcu
is missing is the PTCCH signalling to continuously adjust the timing advance
as the timing offset evolves during an onging TBF.
So for a subscriber at a [relatively] fixed distance from the BTS (like the population
centre you're describing), it *should* be working.
Please note that Sylvain has just very recently designed an open source
"timing advance generator" under sysmocom contract, ant using that device
(based on the PLUTO-SDR) plus some coaxial wiring/attenuators, it should be
rather easy to simulate both static as well as changing timing advance.
The project is called 'osmo-rfds' (for RF Delay Simulator), see http://git.osmocom.org/osmo-rfds/
If OsmoPCU was just always operating at a static timing advance, I would
agree that a VTY command would be a possible interim hack. But AFAIK, the
PCU is not actually that limited ;)
Please help to clarify, thanks.
--
- 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)