Menu
▾
▴
Re: [Openbts-discuss] How to set RxGain in GPRS branch?
|
From: Ivan K. <Iva...@fa...> - 2013-06-27 14:34:12
|
Hi, For GPRS now we have no implementation of closed loop power control, so the MS should use open-loop power control. In this mode MS should use MS_TXPWR_MAX_CCH parameter (the maximum allowed output power in the cell) for setting transmit power. You can find this parameter in OpenBTS configuration and by default MS_TXPWR_MAX_CCH has maximum value. 2013/6/26 oxccoxcc oxccoxcc <oxc...@ya...> > As i understand, L1 layer is the same in GSM and GPRS. > When i use openbts-master branch, bursts quality is some better because of > MS power control messages is implemented. > About "wavy process": signal quality can be very different with same > bursts RSSI. > Downlink signal quality looks good. I checked it with osmocom-bb sniffer > and airpobe. > Uhfortunatelly airprobe didn`t support uplink sniffing and i didn`t have a > phone with filter reworked to try it with osmocom-bb uplink sniffer. > Receive gain adjustment is implemented in grps branch, as is see. But it > is not enough to downgrade uplink signal to 80-90 dB. > Yes, the problem can be related to ADC or amplifier, but i didn`t check it > and don`t know how it can be done, yet. > I tried to connect USRP with own DC power supply and change usb cable, > nothing good. > Now i try to change gr-uhd and USRP image version. > May be it needs to connect usrp with sinus signal generator and check the > output PCM. > > 25.06.2013, 18:46, "Gullik Webjörn" <gul...@co...>: > > Sorry if my answer was a little hasty. Given my experience, the gain in > > the link is essential to > > good operation, and getting within the linear range of the ADC's. > > Possibly the same is true > > for the downlink, i.e. not overloading the phone. > > > > When you first wrote this I had a look at the various posts, and I could > > see as Alexander says, that > > power control is not implemented (yet). > > > > This could explain the "wavy process", i.e. alternating between loop > > regulated power for some signalling, > > and then no power control when source is GPRS. > > > > Anyway, if you are running wireshark, and getting 60-70% throught, it > > should be possible to determine > > if it is the pings ( to phone) or replies (to BTS) that are lost, to > > clarify if it is up or down link related. > > > > Do you mean there is something within GPRS that prevents integration > > with voice/SMS, or do you > > mean it "may not be so easy to do"? > > > > Should not the layer 1, be independent of what we are running un top, > > (excluding control plane just > > to ensure L1 reliability such as power control algo) ? > > > > From my view, and I am a newbe at this, it seems like there should be a > > common power control > > since operating conditions for a phone would be same for > > voice/SMS/Packet/IP. > > > > If I understand correctly the L1 is exactly the same, it is only with > > EDGE it changes (modulation etc). > > Or, are there other considerationes? > > > > Another Q: Are there no gain adjustments in the GPRS code? (since it is > > not integrated) > > > > Gullik > > On 06/25/2013 02:50 PM, oxccoxcc oxccoxcc wrote: > > > >> I didn`t find anything helpful in other grps or osmocom-pcu threads. > >> As i inderstand, Alexander says about MS power control loop setting, > that transmits in GPRS on other channel than in GSM. It can`t be unioned > with GSM MS power control algorithm. > >> RxGain using is identical in both master and gprs branches, as i see. > But in GPRS the phone is using full transmit power. > >> I tried to set small wifi antenna instead of vert900, set RxGain to 1, > and go away from usrp. After that RSSI of bursts became -70 - -80. May be > bursts quality became some better, but still not normal. > >> For example, when i make ping, 60-70% of packets are lost. And most of > tcp sessions are broken, as i see in wireshark. > >> > >> 25.06.2013, 16:10, "Gullik Webjörn" <gul...@co...>: > >>> Hah, I'm getting better in "guessing", in fact a lot of this > >>> is documented in the pcu / gprs threads.... > >>> > >>> It seems to me that the power algorithm maybe should be > >>> located somewhere where ALL modes of communication > >>> converge, i.e. before multiplexer / demultiplexing. > >>> > >>> Gullik > >>> > >>> On 06/25/2013 08:42 AM, Alexander Chemeris wrote: > >>>> GPRS has it's own power control, independent of the CS (circuit > >>>> switched aka voice/sms) service. Ivan could comment more, but IIRC > >>>> power control is not implemented in the current code yet. So you > >>>> mobile could easily transmit with too much or too small power. > >>>> > >>>> Patches to implement power control control are welcome. :) > >>>> > >>>> On Tue, Jun 25, 2013 at 1:30 AM, Gullik Webjörn > >>>> <gul...@co...> wrote: > >>>>> Hmm, can you see the MS tx power in chans command? > >>>>> > >>>>> I had to experiment quite some before i got the phones to adjust > down, > >>>>> but at > >>>>> that time I was more ignorant :-) > >>>>> > >>>>> What happens if you move the phones away? When I was trying to > >>>>> understand my problems > >>>>> I would call the "echo service" from different places. For your > case > >>>>> that would be a "packet" > >>>>> connection? Where in the stack does GPRS interface itself? > >>>>> > >>>>> Gullik > >>>>> On 06/24/2013 05:10 PM, oxccoxcc oxccoxcc wrote: > >>>>>> I tried to set GSM.MS.Power.Max to 1 and GSM.MS.Power.Min to 1. > But RSSI value is still high (about -25 for WBX, -15 for SBX). > >>>>>> Tried to change WBX daughterboard to SBX. Receive burst quality > is also bad and not all of them can be resolved. It looks like a wavy > process. > >>>>>> At some time bursts have an ideal quality. At another time they > are broken. Periodically they are broken partially, for eaxample: > (10100...11100110010100--------------...--) > >>>>>> I also tried to change ARFCN, but it didn`t help. Before i > checked this arfcn with uhd_fft. > >>>>>> One thing, that looks some strange is a timing value=2.00391. > This value is constantly at all sessions for PDTCH channel and 2 symbols > offset is looks too high for phone, that places near USRP. > >>>>>> > >>>>>> 24.06.2013, 17:00, "Gullik Webjörn" <gul...@co... > >: > >>>>>>> Maybe a moot point, but I think it is not a B100 problem if > >>>>>>> exactness is the issue, but rather a WBX issue. > >>>>>>> > >>>>>>> The same thing should happen on another USRP equipped with WBX, > >>>>>>> if RxGain is left at +47 dB. > >>>>>>> > >>>>>>> Regards, > >>>>>>> > >>>>>>> Gullik > >>>>>>> > >>>>>>> On 06/24/2013 12:59 PM, oxccoxcc oxccoxcc wrote: > >>>>>>>> According to USRP B100 RxGain problem, i set > GSM.Radio.RxGain to 7dB. After that not RACH bursts have an RSSI value > about -80 - -87 and normal quality. > >>>>>>>> But when i starting GPRS and connect to web page, receive > bursts RSSI grow to -10 - -15. And, because of that, receive bursts have a > bad quality and most of them can`t be resolved. > >>>>>>>> > >>>>>>>> > ------------------------------------------------------------------------------ > >>>>>>>> This SF.net email is sponsored by Windows: > >>>>>>>> > >>>>>>>> Build for Windows Store. > >>>>>>>> > >>>>>>>> http://p.sf.net/sfu/windows-dev2dev > >>>>>>>> _______________________________________________ > >>>>>>>> Openbts-discuss mailing list > >>>>>>>> Ope...@li... > >>>>>>>> > https://lists.sourceforge.net/lists/listinfo/openbts-discuss > >>>>> > ------------------------------------------------------------------------------ > >>>>> This SF.net email is sponsored by Windows: > >>>>> > >>>>> Build for Windows Store. > >>>>> > >>>>> http://p.sf.net/sfu/windows-dev2dev > >>>>> _______________________________________________ > >>>>> Openbts-discuss mailing list > >>>>> Ope...@li... > >>>>> https://lists.sourceforge.net/lists/listinfo/openbts-discuss > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Openbts-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-discuss > -- Regards, Ivan Kluchnikov. http://fairwaves.ru |
