Menu
▾
▴
Re: [Openbts-discuss] How to set RxGain in GPRS branch?
|
From: oxccoxcc o. <oxc...@ya...> - 2013-06-28 12:24:05
|
Thank you, Ivan! It is that i need. 27.06.2013, 18:34, "Ivan Kluchnikov" <Iva...@fa...>: > 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 |
