17 Nov
2020
17 Nov
'20
10 p.m.
Hello Harald,
Today I was able to achieve a state similar to your *.pcap file from here:
https://osmocom.org/issues/4645
I see my RBS produces the pcap with the same data. I'm a bit worried about
MO CONN which has DISABLED state and ERROR in RSL after sending 5ter to
RBS. Is it possible to try calls in this state?
I had no time today to connect Spectrum Analyser to RF output and check
signal, and until next visit to the lab I hope that signal exists onAir :)
At least I see that led "RF Off" is switched off now on dTRU.
Regarding clock stability issue that I was describing in previous mail, I
solved it by using CISCO 3640 with E1 card as the root for SYNC. My Digium
card takes clock from CISCO and provides it to RBS. RBS looks happy with it.
All other tricks I planned to try were unsuccessful.
Setting both sides of E1 to get sync from the neighbour did not work as
expected.
When I tried with real BSC DX200, it looked like BSC was un-configured and
was not able to bring E1 link up.
So, my next steps are checking RF signal with analyser and trying to make a
call with real UE. What do you think, is it possible?
Thank you
Babanov Ivan
ср, 11 нояб. 2020 г. в 12:14, Harald Welte <laforge(a)osmocom.org>rg>:
Hi Ivan,
On Wed, Nov 11, 2020 at 01:26:01AM +0300, Ivan Babanov wrote:
After it we tried to use default config from
master branch initially
created for RBS-2308.
It worked pretty fine except RF Power which was configured as 41dBm and
41
- 12 = 29 dBm. Value 29 was not acceptable for
our RBS.
I checked with Ericsson BSC Doc and found that our RBS2206 has max RF
output 47dBm for DCS1800. (btw, RBS2308 has only 34dBm max output
according
to the same document, maybe config needs to be
corrected)
feel free to send a patch.
Looks like internal oscillator is not ready. So,
the question is how to
make internal oscillator synchronized? Could it be an E1 Sync stability
issue caused by Digium cards?
The question is not "could". Any BTS always needs a proper, stable
reference clock. So unless your BTS has a built-in GPS clock refrence
(and that
reference is configured/enabled), your E1 will have to provide a stable
clock
reference.
"stable" means (likely) fulfilling a clock stability that is _at the very
least_ the
stability of what commercial TDM/ISDN networks used to have. It doesn't
hurt to have
better stability.
Any crystal oscillator on any E1/T1 peripheral card (digium or not) is by
far not stable
enough, possibly up to 1000 times worse than required.
1. Set Digium card to get Sync from RBS. Now
Digium is configured for
Internal clocking and acts as master. Maybe in case when both sides will
be
configured to get sync from E1 it will decrease
difference between
internal
clock of RBS and E1 and RBS will get Synced
state.
And what would that get you to? In the end, a BTS that transmits at a
frequency that
will likely be so far off that you have serious problems connecting phones
to it.
2. Theoretically I can try to use Nokia DX200 BSC
as a clock master for
Digium and deliver sync to RBS from Digium. I'm not sure if timing
accuracy
is the same for Nokia and Ericsson HW.
Sure, that should work. You can use any proper clock reference. One
option I'm using
here is to use a SIU-02. It has a 1PPS input for GPS, and it clocks up to
16 E1/T1
interfaces with that clock. You can then feed that clock signal to one
port of your
multi-port Digium card, and configure that as clock source, and the other
ports will
use that clock when talking to your BTSs.
One more question is where can I find some info
about timing accuracy for
BTS and any possible way to check it on the existing E1 line?
You would have to use some kind of test equipment that has a much more
accurate/stable
clock itself, like a rubidium oscillator or a GPS-DO. And then you can
try to measure the Allan deviation/variance. But why do that? It's
obvious that a normal crystal oscillator is way insufficient, no need to
measure it.
--
- Harald Welte <laforge(a)osmocom.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch.
A6)