Menu
▾
▴
Re: [Openbts-discuss] How to set RxGain in GPRS branch?
|
From: oxccoxcc o. <oxc...@ya...> - 2013-06-25 12:50:28
|
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 |
