Menu
▾
▴
Re: [Openbts-discuss] How to set RxGain in GPRS branch?
|
From: Ivan K. <Iva...@fa...> - 2013-07-05 10:00:33
|
Hi Christophe, I have never tried Nexus S, but if you provide pcu and sgsn logs for this phone, it will be very helpful and I will try to fix problem. 2013/7/4 Christophe Devine <dev...@gm...> > Ivan, > > Thanks for the tip. Which phones do you use for testing the GPRS branch? I > have a Nexus S which has a lot of trouble connecting (based on an X-GOLD > 616 baseband), but on the other hand a Huawei G300 (MSM7227A) works > extremely well with almost no packet loss, on the same OpenBTS setup. > > > On Thu, Jun 27, 2013 at 4:34 PM, Ivan Kluchnikov < > Iva...@fa...> wrote: > >> 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 >> >> >> ------------------------------------------------------------------------------ >> 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 |
