Menu
▾
▴
Re: [Openbts-discuss] How to set RxGain in GPRS branch?
|
From: Christophe D. <dev...@gm...> - 2013-07-04 14:06:09
|
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 > > |
