25 Jan
2014
25 Jan
'14
7:58 p.m.
On Sat, Jan 25, 2014 at 2:57 AM, Andreas Eversberg <andreas(a)eversberg.eu> wrote:
so when i stop sending the bursts, the filler table
will continue to
transmit bursts. do i understand it correctly: if i send a single idle burst
(frame??) after sending bursts, the filler table is disabled until new
bursts are sent?
Sorry, I misspoke about disabling transmission. The filler table
resends the last burst in the multiframe, so the idle burst is usually
just a dummy burst, which does not actually stop physical
transmission. To fully turn off the downlink signal on a particular
slot requires disabling the slot by the channel combination.
That said, I agree with Alexander that the retransmission portion of
the filler table should be turned off because the behavior is
incorrect. With a few exceptions (e.g. FCCH), bursts should *not* be
retransmitted at L1 and doing so generates an invalid signal.
Note that the filler table cannot be completely disabled because it is
part of the real-time loop that drives the device I/O. If the upper
layer does not send a burst for a particular slot, or that burst
arrives late (stale burst), something still must be transmitted.
Currently, in that case, the burst comes from the filler table if the
slot is active or zeros if the slot is turned off. Again, I do not
think the current implementation is entirely correct, but that depends
on expectations of the upper layers.
-TT
26 Jan
26 Jan
3:32 p.m.
New subject: RF power problems with current master of osmo-trx
Tom Tsou wrote:
That said, I agree with Alexander that the
retransmission portion of
the filler table should be turned off because the behavior is
incorrect.
hi thomas,
this makes sense. repeating any LAPDm frame is definitely something that
might cause problems (SDCCH/FACCH/SACCH). even repeating (interleaved)
TCH bursts in a multiframe does not make much sense in my opinion.
i have just tried your patch. i still get RF power on second TRX.
osmobts-trx configures all 8 channels (SETSLOT to TCH/F), but does not
send any burst data (TRX 1) to osmo-trx.
best regards,
andreas
5:35 p.m.
New subject: RF power problems with current master of osmo-trx
On Sun, Jan 26, 2014 at 9:32 AM, Andreas Eversberg <andreas(a)eversberg.eu> wrote:
i have just tried your patch. i still get RF power on
second TRX.
osmobts-trx configures all 8 channels (SETSLOT to TCH/F), but does not send
any burst data (TRX 1) to osmo-trx.
Yes, that is expected behavior. There will be power output as long as
the slot is enabled. Right now the only way to turn off transmission
is to disable the slot.
-TT
10:12 p.m.
New subject: RF power problems with current master of osmo-trx
Hi Thomas,
On Sun, Jan 26, 2014 at 8:35 PM, Tom Tsou <tom(a)tsou.cc> wrote:
On Sun, Jan 26, 2014 at 9:32 AM, Andreas Eversberg
<andreas(a)eversberg.eu> wrote:
This is an incorrect behavior for TRX1, unlike TRX0.
For TRX1 there are no idle bursts and there should be no transmission
if there is no data sent. I can't check this right now, but I'm pretty
sure that at least some time ago osmo-trx respected this behavior and
didn't transmit on TRX1 until it gets something to transmit.
I would appreciate if you confirm that the current code still respects
this and if you make filler table optional for TRX0 as well.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
i have just tried your patch. i still get RF
power on second TRX.
osmobts-trx configures all 8 channels (SETSLOT to TCH/F), but does not send
any burst data (TRX 1) to osmo-trx.
Yes, that is expected behavior. There will be power output as long as
the slot is enabled. Right now the only way to turn off transmission
is to disable the slot.
27 Jan
27 Jan
2:52 a.m.
New subject: RF power problems with current master of osmo-trx
On Sun, Jan 26, 2014 at 4:12 PM, Alexander Chemeris
<alexander.chemeris(a)gmail.com> wrote:
For TRX1 there are no idle bursts and there should be
no transmission
if there is no data sent. I can't check this right now, but I'm pretty
sure that at least some time ago osmo-trx respected this behavior and
didn't transmit on TRX1 until it gets something to transmit.
Burst selection at a particular time works in the following order of priority.
1. Slot is disabled with channel combination set to NONE (default)
1. Burst exists in priority queue for the current time.
2. Filler table entry is used
This ordering has never changed.
What you are probably thinking of is the multi-ARFCN branch and
derived code, which explicitly separated the beacon carrying channel.
In that codebase, retransmissions were limited to the C0 TRX and the
filler table on non-C0 channels was loaded with zeros. Osmo-TRX does
not make this distinction and treats both channels are possible C0
beacons.
I agree that Independent channel configuration of the filler table is
the correct approach.
-TT
8:05 a.m.
New subject: RF power problems with current master of osmo-trx
On Mon, Jan 27, 2014 at 5:52 AM, Tom Tsou <tom(a)tsou.cc> wrote:
What you are probably thinking of is the multi-ARFCN
branch and
derived code, which explicitly separated the beacon carrying channel.
In that codebase, retransmissions were limited to the C0 TRX and the
filler table on non-C0 channels was loaded with zeros. Osmo-TRX does
not make this distinction and treats both channels are possible C0
beacons.
Yes, I was speaking about the multi-ARFCN branch, as that's what we
tested most deeply and which we used in production.
I agree that Independent channel configuration of the
filler table is
the correct approach.
You mean that it'll be configurable at runtime on per-TRX basis?
That'll be a nice way.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
4:17 a.m.
New subject: RF power problems with current master of osmo-trx
On Sun, Jan 26, 2014 at 11:35 AM, Tom Tsou <tom(a)tsou.cc> wrote:
On Sun, Jan 26, 2014 at 9:32 AM, Andreas Eversberg
<andreas(a)eversberg.eu> wrote:
Hi Andreas,
Please try the filler branch, which zero fills and disables filler
table retransmissions by default. You can re-enable the OpenBTS type
behavior for C0 on the command line.
git://git.osmocom.org/osmo-trx filler
-TT
i have just tried your patch. i still get RF
power on second TRX.
osmobts-trx configures all 8 channels (SETSLOT to TCH/F), but does not send
any burst data (TRX 1) to osmo-trx.
Yes, that is expected behavior. There will be power output as long as
the slot is enabled. Right now the only way to turn off transmission
is to disable the slot.
30 Jan
30 Jan
8:42 a.m.
New subject: RF power problems with current master of osmo-trx
Tom Tsou wrote:
Please try the filler branch, which zero fills and
disables filler
table retransmissions by default. You can re-enable the OpenBTS type
behavior for C0 on the command line.
just tested it. it works, i get no RF power
when not sending a burst.
actually i get some RF power that is 40dB lower than the power of actual
bursts, but this is caused by using ARFCNs that are close. (869 and 872)
8:54 a.m.
New subject: RF power problems with current master of osmo-trx
On Thu, Jan 30, 2014 at 2:42 AM, Andreas Eversberg <andreas(a)eversberg.eu> wrote:
Great. It's just zero's during the non-burst periods so anything else
that still shows up is probably RF related.
-TT
Please try the
filler branch, which zero fills and disables filler table
retransmissions by default. You can re-enable the OpenBTS type behavior for
C0 on the command line.
just tested it. it works, i get no RF power when not sending a burst.
actually i get some RF power that is 40dB lower than the power of actual
bursts, but this is caused by using ARFCNs that are close. (869 and 872)
8:31 a.m.
New subject: RF power problems with current master of osmo-trx
Tom Tsou wrote:
Yes, that is expected behavior. There will be power
output as long as
the slot is enabled. Right now the only way to turn off transmission
is to disable the slot. -TT
hi thomas,
in case of TRX 0, osmo-bts always sends bursts, even on idle bursts. it
sends dummy bursts in this case. i suggest that there is no RF power in
case of TRX>0 for each single burst, that is not sent from osmo-bts. the
reasons are:
- one TCH/H channel of one TS may be in use, so the other channel should
be disabled, to reduce noise on the spectrum.
- DRX (in the future) might be used to reduce noise on the spectrum.
- SACCH is disabled when leaving dedicated mode, so the MS runs into
radio link timeout, if the release message does not go through or some
error occurs.
i think about three solutions to make make osmo-trx send no RF power per
burst:
1. omso-bts does not send any burst to osmo-trx
2. sends a dummy burst with lowest possible power indication (pwr=255)
3. sends a burst with zero length data (only the 6 bytes header)
i prefer the first solution.
best regards,
andreas
8:35 a.m.
New subject: RF power problems with current master of osmo-trx
On Thu, Jan 30, 2014 at 2:31 AM, Andreas Eversberg <andreas(a)eversberg.eu> wrote:
in case of TRX 0, osmo-bts always sends bursts, even
on idle bursts. it
sends dummy bursts in this case. i suggest that there is no RF power in case
of TRX>0 for each single burst, that is not sent from osmo-bts. the reasons
are:
- one TCH/H channel of one TS may be in use, so the other channel should be
disabled, to reduce noise on the spectrum.
- DRX (in the future) might be used to reduce noise on the spectrum.
- SACCH is disabled when leaving dedicated mode, so the MS runs into radio
link timeout, if the release message does not go through or some error
occurs.
i think about three solutions to make make osmo-trx send no RF power per
burst:
1. omso-bts does not send any burst to osmo-trx
Please try out the filler branch I posted earlier. It does exactly that.
-TT
4160
days inactive
4165
days old
10 comments
3 participants
participants (3)
-
Alexander Chemeris -
Andreas Eversberg -
Tom Tsou