Menu
▾
▴
Re: [Openbts-discuss] How to set RxGain in GPRS branch?
|
From: Gullik W. <gul...@co...> - 2013-07-08 21:14:51
|
My dear OpenBTS friends, I just want your confirmation that I am understanding this correctly. Besides running OpenBTS and getting voice calls and SMS through, why would I want to run GPRS? If I manage to make the GPRS stack cooperate with OpenBTS, I will be rewarded with a 15-30 Kbps Internet connection, right? And, what should I use this to? It is barely sufficient in speed to download mail (without attachments). So, can someone please explain why I would want something (internet access) that is already in most phones via Wifi? Is this just for "historical" reasons, or is there som other reason? Best Regards, Gullik On 07/08/2013 06:33 PM, oxccoxcc oxccoxcc wrote: > 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 > ------------------------------------------------------------------------------ > 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 |
