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/.
Ivan Babanov ivan.babanov at gmail.comHello 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 at osmocom.org>: > 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 at osmocom.org> > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. > A6) > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20201118/1356be49/attachment.htm>