Menu
▾
▴
Re: [Openbts-discuss] How to set RxGain in GPRS branch?
|
From: oxccoxcc o. <oxc...@ya...> - 2013-07-08 16:33:30
|
I set GSM.Channels.NumC1s to 1. GPRS.TS to 2 3 4 5 6 7. But as i see in gsmtap log, only 2 timeslot is used. May be it needs to make any additional changes to multislot configuration enabling? What is a ping time values to ggsn interface do you see on your equipment? 05.07.2013, 13:56, "Ivan Kluchnikov" <Iva...@fa...>: > Hi, > > If you increase number of GPRS.TS (number of timeslots for gprs), you should also decrease number of GSM.Channels.NumC1s (number of timeslots for gsm). > > 2013/7/4 oxccoxcc oxccoxcc <oxc...@ya...> >> For me HTC HD Mini works better than Sony Xperia and many Nokias. Another interesting point: some phones transmits many uplink dummy control blocks (they didn`t handles by osmo-pcu and displays as unknown control block), but HTC HD Mini didn`t transmit this blocks. >> And another one question: how to change multislot class? When i change GPRS.TS to "5 6 7", transceiver didn`t start. >> >> 04.07.2013, 18:08, "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 >> >> ------------------------------------------------------------------------------ >> 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 |
