From: Orkhan B. <orx...@gm...> - 2012-03-24 16:18:58
|
Hello list I am using USRP n210 to run openbts. I used to run it using the internal clock of the device, the ppm value of which was roughly 3ppm based on the results of kalibrate application. I was able to camp a handset from a short distance(about 2m) only, from longer distances it was displaying openbts on the list on operators but was not camping. I tried to change the power, but obviously that was not the issue. My guess was that it was because of the clock. I connected a signal generator as an external clock and ran kalibrate again and this time the ppm value was 0.025. I reinstalled openbts with external clock option, but this time the phone was not camping from even short distance. Has anyone experienced this? Let me note that the device was not locking to the external clock when I connected to the front REF-IN input, it only did lock when I connected to the second external clock input inside the USRP n210(by the way, I did change that jumper from 1-2 to 2-3). Thanks for your consideration. -- Orkhan |
From: Orkhan B. <orx...@gm...> - 2012-03-24 16:23:48
|
I forgot to mention that I am using Openbts 2.8 On Sat, Mar 24, 2012 at 6:18 PM, Orkhan Badirkhanli <orx...@gm...>wrote: > Hello list > > I am using USRP n210 to run openbts. I used to run it using the internal > clock of the device, the ppm value of which was roughly 3ppm based on the > results of kalibrate application. > > I was able to camp a handset from a short distance(about 2m) only, from > longer distances it was displaying openbts on the list on operators but was > not camping. I tried to change the power, but obviously that was not the > issue. My guess was that it was because of the clock. > > I connected a signal generator as an external clock and ran kalibrate > again and this time the ppm value was 0.025. I reinstalled openbts with > external clock option, but this time the phone was not camping from even > short distance. > > Has anyone experienced this? > > Let me note that the device was not locking to the external clock when I > connected to the front REF-IN input, it only did lock when I connected to > the second external clock input inside the USRP n210(by the way, I did > change that jumper from 1-2 to 2-3). > > Thanks for your consideration. > > -- > Orkhan > -- Orkhan |
From: Thomas T. <tt...@vt...> - 2012-03-24 16:52:11
|
On Sat, Mar 24, 2012 at 12:18 PM, Orkhan Badirkhanli <orx...@gm...> wrote: > Hello list > > I am using USRP n210 to run openbts. I used to run it using the internal > clock of the device, the ppm value of which was roughly 3ppm based on the > results of kalibrate application. > > I was able to camp a handset from a short distance(about 2m) only, from > longer distances it was displaying openbts on the list on operators but was > not camping. I tried to change the power, but obviously that was not the > issue. My guess was that it was because of the clock. Distance based issues are almost always gain related. The more typical experience is the opposite of what you described where one side of the connection saturates. Clock issues won't have a significant effect over a 2m distance change. What are your antenna configuration and attenuation / rxgain values? > I connected a signal generator as an external clock and ran kalibrate again > and this time the ppm value was 0.025. I reinstalled openbts with external > clock option, but this time the phone was not camping from even short > distance. What release or git version of uhd do you have installed? The current code uses the uhd-3.3.0 clock setting interface that was deprecated in uhd-3.4.0, which was officially released yesterday. It shouldn't matter, but there have been few reports that kalibrate only worked after changing to the new interfaces. I can push a similar changeset sometime this weekend. > Let me note that the device was not locking to the external clock when I > connected to the front REF-IN input, it only did lock when I connected to > the second external clock input inside the USRP n210(by the way, I did > change that jumper from 1-2 to 2-3). Strange. From an OpenBTS standpoint, the actual clock setting is simply 'uhd::clock_config_t::REF_SMA'. The jumper should allow use of either input. Thomas |
From: Orkhan B. <orx...@gm...> - 2012-03-24 17:07:29
|
Thanks for the reply Thomas About antennas - I am using SBX daughterboard with 2 VERT900s on both TX/RX and RX. The rxgain was typically 10dB, but I also tested with 20dB. The uhd version is 3.4.0 - UHD_003.004.000-299-g2033713d Also, while reinstalling for using with external clock, is there any need to change anything else other than including "--with-extref"? On Sat, Mar 24, 2012 at 6:52 PM, Thomas Tsou <tt...@vt...> wrote: > On Sat, Mar 24, 2012 at 12:18 PM, Orkhan Badirkhanli <orx...@gm...> > wrote: > > Hello list > > > > I am using USRP n210 to run openbts. I used to run it using the internal > > clock of the device, the ppm value of which was roughly 3ppm based on the > > results of kalibrate application. > > > > I was able to camp a handset from a short distance(about 2m) only, from > > longer distances it was displaying openbts on the list on operators but > was > > not camping. I tried to change the power, but obviously that was not the > > issue. My guess was that it was because of the clock. > > Distance based issues are almost always gain related. The more typical > experience is the opposite of what you described where one side of the > connection saturates. Clock issues won't have a significant effect > over a 2m distance change. What are your antenna configuration and > attenuation / rxgain values? > > > I connected a signal generator as an external clock and ran kalibrate > again > > and this time the ppm value was 0.025. I reinstalled openbts with > external > > clock option, but this time the phone was not camping from even short > > distance. > > What release or git version of uhd do you have installed? The current > code uses the uhd-3.3.0 clock setting interface that was deprecated in > uhd-3.4.0, which was officially released yesterday. It shouldn't > matter, but there have been few reports that kalibrate only worked > after changing to the new interfaces. > > I can push a similar changeset sometime this weekend. > > > Let me note that the device was not locking to the external clock when I > > connected to the front REF-IN input, it only did lock when I connected to > > the second external clock input inside the USRP n210(by the way, I did > > change that jumper from 1-2 to 2-3). > > Strange. From an OpenBTS standpoint, the actual clock setting is > simply 'uhd::clock_config_t::REF_SMA'. The jumper should allow use of > either input. > > Thomas > -- Orkhan |
From: Alexander C. <ale...@gm...> - 2012-03-24 17:52:38
|
Thomas, On Sat, Mar 24, 2012 at 20:52, Thomas Tsou <tt...@vt...> wrote: > On Sat, Mar 24, 2012 at 12:18 PM, Orkhan Badirkhanli <orx...@gm...> wrote: >> Hello list >> >> I am using USRP n210 to run openbts. I used to run it using the internal >> clock of the device, the ppm value of which was roughly 3ppm based on the >> results of kalibrate application. >> >> I was able to camp a handset from a short distance(about 2m) only, from >> longer distances it was displaying openbts on the list on operators but was >> not camping. I tried to change the power, but obviously that was not the >> issue. My guess was that it was because of the clock. > > Distance based issues are almost always gain related. The more typical > experience is the opposite of what you described where one side of the > connection saturates. Clock issues won't have a significant effect > over a 2m distance change. What are your antenna configuration and > attenuation / rxgain values? Looks like this becomes a common question. Could you volunteer to write a short how-to about tuning Rx gain and Tx attenuation to improve coverage? So that anyone could do that for his specific configuration. (Ideally - understand how it works as well). That would be very helpful and reduce the number of questions in the mailing list. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru |
From: Thomas T. <tt...@vt...> - 2012-03-26 21:44:37
|
On Sat, Mar 24, 2012 at 1:52 PM, Alexander Chemeris <ale...@gm...> wrote: > Looks like this becomes a common question. Could you volunteer to > write a short how-to about tuning Rx gain and Tx attenuation to > improve coverage? So that anyone could do that for his specific > configuration. (Ideally - understand how it works as well). That would > be very helpful and reduce the number of questions in the mailing > list. Yes, that item on my todo list. One of the downsides of supporting multiple devices and daughterboards is that the gain setting has become more complicated than when we only had a single configuration. I can add some notes for common configuration issues. More complicated questions such as maximum range tuning or use of additional RF equipment are better answered by someone with more experience in those areas. Thomas |
From: Orkhan B. <orx...@gm...> - 2012-03-24 19:28:15
|
Alexander Do you mean that the problem is solely related to adjusting power levels? On Sat, Mar 24, 2012 at 7:52 PM, Alexander Chemeris < ale...@gm...> wrote: > Thomas, > > On Sat, Mar 24, 2012 at 20:52, Thomas Tsou <tt...@vt...> wrote: > > On Sat, Mar 24, 2012 at 12:18 PM, Orkhan Badirkhanli <orx...@gm...> > wrote: > >> Hello list > >> > >> I am using USRP n210 to run openbts. I used to run it using the internal > >> clock of the device, the ppm value of which was roughly 3ppm based on > the > >> results of kalibrate application. > >> > >> I was able to camp a handset from a short distance(about 2m) only, from > >> longer distances it was displaying openbts on the list on operators but > was > >> not camping. I tried to change the power, but obviously that was not the > >> issue. My guess was that it was because of the clock. > > > > Distance based issues are almost always gain related. The more typical > > experience is the opposite of what you described where one side of the > > connection saturates. Clock issues won't have a significant effect > > over a 2m distance change. What are your antenna configuration and > > attenuation / rxgain values? > > Looks like this becomes a common question. Could you volunteer to > write a short how-to about tuning Rx gain and Tx attenuation to > improve coverage? So that anyone could do that for his specific > configuration. (Ideally - understand how it works as well). That would > be very helpful and reduce the number of questions in the mailing > list. > > > -- > Regards, > Alexander Chemeris. > CEO, Fairwaves LLC / ООО УмРадио > http://fairwaves.ru > -- Orkhan |
From: Alexander C. <ale...@gm...> - 2012-03-24 21:00:47
|
I can't say for sure, but most likely they are related to your RF setup and gain/attenuation settings. On Sat, Mar 24, 2012 at 23:28, Orkhan Badirkhanli <orx...@gm...> wrote: > Alexander > > Do you mean that the problem is solely related to adjusting power levels? > > > On Sat, Mar 24, 2012 at 7:52 PM, Alexander Chemeris > <ale...@gm...> wrote: >> >> Thomas, >> >> On Sat, Mar 24, 2012 at 20:52, Thomas Tsou <tt...@vt...> wrote: >> > On Sat, Mar 24, 2012 at 12:18 PM, Orkhan Badirkhanli >> > <orx...@gm...> wrote: >> >> Hello list >> >> >> >> I am using USRP n210 to run openbts. I used to run it using the >> >> internal >> >> clock of the device, the ppm value of which was roughly 3ppm based on >> >> the >> >> results of kalibrate application. >> >> >> >> I was able to camp a handset from a short distance(about 2m) only, from >> >> longer distances it was displaying openbts on the list on operators but >> >> was >> >> not camping. I tried to change the power, but obviously that was not >> >> the >> >> issue. My guess was that it was because of the clock. >> > >> > Distance based issues are almost always gain related. The more typical >> > experience is the opposite of what you described where one side of the >> > connection saturates. Clock issues won't have a significant effect >> > over a 2m distance change. What are your antenna configuration and >> > attenuation / rxgain values? >> >> Looks like this becomes a common question. Could you volunteer to >> write a short how-to about tuning Rx gain and Tx attenuation to >> improve coverage? So that anyone could do that for his specific >> configuration. (Ideally - understand how it works as well). That would >> be very helpful and reduce the number of questions in the mailing >> list. >> >> >> -- >> Regards, >> Alexander Chemeris. >> CEO, Fairwaves LLC / ООО УмРадио >> http://fairwaves.ru > > > > > -- > Orkhan -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru |
From: Orkhan B. <orx...@gm...> - 2012-03-26 21:41:59
|
Given the initial configuration that comes with OpenBTS, are there specific configurations that need to be done in order to have the system working properly from a short distance other than decreasing rxgain? Cheers, On Sun, Mar 25, 2012 at 1:00 AM, Alexander Chemeris < ale...@gm...> wrote: > I can't say for sure, but most likely they are related to your RF > setup and gain/attenuation settings. > > On Sat, Mar 24, 2012 at 23:28, Orkhan Badirkhanli <orx...@gm...> > wrote: > > Alexander > > > > Do you mean that the problem is solely related to adjusting power levels? > > > > > > On Sat, Mar 24, 2012 at 7:52 PM, Alexander Chemeris > > <ale...@gm...> wrote: > >> > >> Thomas, > >> > >> On Sat, Mar 24, 2012 at 20:52, Thomas Tsou <tt...@vt...> wrote: > >> > On Sat, Mar 24, 2012 at 12:18 PM, Orkhan Badirkhanli > >> > <orx...@gm...> wrote: > >> >> Hello list > >> >> > >> >> I am using USRP n210 to run openbts. I used to run it using the > >> >> internal > >> >> clock of the device, the ppm value of which was roughly 3ppm based on > >> >> the > >> >> results of kalibrate application. > >> >> > >> >> I was able to camp a handset from a short distance(about 2m) only, > from > >> >> longer distances it was displaying openbts on the list on operators > but > >> >> was > >> >> not camping. I tried to change the power, but obviously that was not > >> >> the > >> >> issue. My guess was that it was because of the clock. > >> > > >> > Distance based issues are almost always gain related. The more typical > >> > experience is the opposite of what you described where one side of the > >> > connection saturates. Clock issues won't have a significant effect > >> > over a 2m distance change. What are your antenna configuration and > >> > attenuation / rxgain values? > >> > >> Looks like this becomes a common question. Could you volunteer to > >> write a short how-to about tuning Rx gain and Tx attenuation to > >> improve coverage? So that anyone could do that for his specific > >> configuration. (Ideally - understand how it works as well). That would > >> be very helpful and reduce the number of questions in the mailing > >> list. > >> > >> > >> -- > >> Regards, > >> Alexander Chemeris. > >> CEO, Fairwaves LLC / ООО УмРадио > >> http://fairwaves.ru > > > > > > > > > > -- > > Orkhan > > > > -- > Regards, > Alexander Chemeris. > CEO, Fairwaves LLC / ООО УмРадио > http://fairwaves.ru > -- Orkhan |
From: Thomas T. <tt...@vt...> - 2012-03-26 22:04:17
|
2012/3/26 Orkhan Badirkhanli <orx...@gm...>: > Given the initial configuration that comes with OpenBTS, are there specific > configurations that need to be done in order to have the system working > properly from a short distance other than decreasing rxgain? Attenuation (the 'power' setting) and receive gain are the two main adjustments. You should certainly be able to cover more than 2 meters - coverage for a large sized room or more is typically achievable. Is the behaviour consistent? As in the handset can consistently camp at 2m but not larger distances? Thomas |
From: Orkhan B. <orx...@gm...> - 2012-03-26 22:29:39
|
Thomas In the setting where I only decreased the rxgain to 10dBm, the cell phone was sending a channel request message to OpenBTS as I was detecting the packages through wireshark. I noticed that even though the handset was showing OpenBTS in the list of operators from up to 20m with rooms in between, it was not sending a request channel message and was showing "No signal" sign. And yes, also in the room is LOS the handset was not sending request channel signal from longer than 2m. Thank you for your attention On Tue, Mar 27, 2012 at 3:04 AM, Thomas Tsou <tt...@vt...> wrote: > 2012/3/26 Orkhan Badirkhanli <orx...@gm...>: > > Given the initial configuration that comes with OpenBTS, are there > specific > > configurations that need to be done in order to have the system working > > properly from a short distance other than decreasing rxgain? > > Attenuation (the 'power' setting) and receive gain are the two main > adjustments. You should certainly be able to cover more than 2 meters > - coverage for a large sized room or more is typically achievable. > > Is the behaviour consistent? As in the handset can consistently camp > at 2m but not larger distances? > > Thomas > -- Orkhan |
From: Orkhan B. <orx...@gm...> - 2012-03-26 22:31:26
|
I meant from short distance in the first sentence On Tue, Mar 27, 2012 at 3:29 AM, Orkhan Badirkhanli <orx...@gm...>wrote: > Thomas > > In the setting where I only decreased the rxgain to 10dBm, the cell phone > was sending a channel request message to OpenBTS as I was detecting the > packages through wireshark. > > I noticed that even though the handset was showing OpenBTS in the list of > operators from up to 20m with rooms in between, it was not sending a > request channel message and was showing "No signal" sign. > > And yes, also in the room is LOS the handset was not sending request > channel signal from longer than 2m. > > Thank you for your attention > > > On Tue, Mar 27, 2012 at 3:04 AM, Thomas Tsou <tt...@vt...> wrote: > >> 2012/3/26 Orkhan Badirkhanli <orx...@gm...>: >> > Given the initial configuration that comes with OpenBTS, are there >> specific >> > configurations that need to be done in order to have the system working >> > properly from a short distance other than decreasing rxgain? >> >> Attenuation (the 'power' setting) and receive gain are the two main >> adjustments. You should certainly be able to cover more than 2 meters >> - coverage for a large sized room or more is typically achievable. >> >> Is the behaviour consistent? As in the handset can consistently camp >> at 2m but not larger distances? >> >> Thomas >> > > > > -- > Orkhan > -- Orkhan |
From: Ben H. <ben...@et...> - 2012-03-27 01:28:34
|
Orkhan - Are you adjusting the attenuation (power settings) at all while OpenBTS is running? While using a B100 + SBX at short range, I typically set the attenuation relatively high. It is also possible, if you are using very high power and/or very low gain settings, that you are causing the DACs on your USRP to clip, which would certainly cause issues with getting a working basestation. Cheers, Ben ---------------------------- Ben Hilburn <http://goo.gl/5DdZ3> @ Ettus Research, LLC<http://www.ettus.com/> On Mon, Mar 26, 2012 at 3:31 PM, Orkhan Badirkhanli <orx...@gm...>wrote: > I meant from short distance in the first sentence > > > On Tue, Mar 27, 2012 at 3:29 AM, Orkhan Badirkhanli <orx...@gm...>wrote: > >> Thomas >> >> In the setting where I only decreased the rxgain to 10dBm, the cell phone >> was sending a channel request message to OpenBTS as I was detecting the >> packages through wireshark. >> >> I noticed that even though the handset was showing OpenBTS in the list of >> operators from up to 20m with rooms in between, it was not sending a >> request channel message and was showing "No signal" sign. >> >> And yes, also in the room is LOS the handset was not sending request >> channel signal from longer than 2m. >> >> Thank you for your attention >> >> >> On Tue, Mar 27, 2012 at 3:04 AM, Thomas Tsou <tt...@vt...> wrote: >> >>> 2012/3/26 Orkhan Badirkhanli <orx...@gm...>: >>> > Given the initial configuration that comes with OpenBTS, are there >>> specific >>> > configurations that need to be done in order to have the system working >>> > properly from a short distance other than decreasing rxgain? >>> >>> Attenuation (the 'power' setting) and receive gain are the two main >>> adjustments. You should certainly be able to cover more than 2 meters >>> - coverage for a large sized room or more is typically achievable. >>> >>> Is the behaviour consistent? As in the handset can consistently camp >>> at 2m but not larger distances? >>> >>> Thomas >>> >> >> >> >> -- >> Orkhan >> > > > > -- > Orkhan > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Openbts-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-discuss > > |
From: Thomas T. <tt...@vt...> - 2012-03-27 02:15:35
|
On Mon, Mar 26, 2012 at 9:28 PM, Ben Hilburn <ben...@et...> wrote: > Orkhan - > > Are you adjusting the attenuation (power settings) at all while OpenBTS is > running? While using a B100 + SBX at short range, I typically set the > attenuation relatively high. That is the behavior I expect. > It is also possible, if you are using very high power and/or very low gain > settings, that you are causing the DACs on your USRP to clip, which would > certainly cause issues with getting a working basestation. Doubtful. The default setting only uses 30% of available dynamic range at 0 dB attenuation. This (lack of DAC clipping) has been verified with external test equipment. On an unrelated note, this _is_ a current issue with the multi-carrier branch. On the receive side though, the default gain setting is 47 dB regardless of daughterboard, which is a remnant of the original usrp1-rfx1800 configuration. That setting with an appropriate receive antenna is almost always too high for test distances of a few meters. Thomas |
From: Ben H. <ben...@et...> - 2012-03-27 02:26:49
|
Aha - thanks for the clarification, Tom! Cheers, Ben ---------------------------- Ben Hilburn <http://goo.gl/5DdZ3> @ Ettus Research, LLC<http://www.ettus.com/> On Mon, Mar 26, 2012 at 7:15 PM, Thomas Tsou <tt...@vt...> wrote: > On Mon, Mar 26, 2012 at 9:28 PM, Ben Hilburn <ben...@et...> > wrote: > > Orkhan - > > > > Are you adjusting the attenuation (power settings) at all while OpenBTS > is > > running? While using a B100 + SBX at short range, I typically set the > > attenuation relatively high. > > That is the behavior I expect. > > > It is also possible, if you are using very high power and/or very low > gain > > settings, that you are causing the DACs on your USRP to clip, which would > > certainly cause issues with getting a working basestation. > > Doubtful. The default setting only uses 30% of available dynamic range > at 0 dB attenuation. This (lack of DAC clipping) has been verified > with external test equipment. On an unrelated note, this _is_ a > current issue with the multi-carrier branch. > > On the receive side though, the default gain setting is 47 dB > regardless of daughterboard, which is a remnant of the original > usrp1-rfx1800 configuration. That setting with an appropriate receive > antenna is almost always too high for test distances of a few meters. > > Thomas > |
From: Thomas T. <tt...@vt...> - 2012-03-27 02:25:57
|
On Mon, Mar 26, 2012 at 6:29 PM, Orkhan Badirkhanli <orx...@gm...> wrote: > Thomas > > In the setting where I only decreased the rxgain to 10dBm, the cell phone > was sending a channel request message to OpenBTS as I was detecting the > packages through wireshark. Ok. > I noticed that even though the handset was showing OpenBTS in the list of > operators from up to 20m with rooms in between, it was not sending a request > channel message and was showing "No signal" sign. Note that the handset does not need to send a channel request every time it camps if it was connected to the BTS in a previous instance. > And yes, also in the room is LOS the handset was not sending request channel > signal from longer than 2m. Is the handset still camping in these instances? or are getting "No signal" at just a few meters? Thomas |
From: Orkhan B. <orx...@gm...> - 2012-03-28 15:14:55
|
Well, even when the handset was sending channel request message and then connecting, it was first displaying "Network is no longer available" message. Thus I think the problem is in something else. Right now I am testing with external clock(signal generator) connected as opposed to past. As I turned the system on for the first time during the day and testing I experienced the following. I ran the the openbts, sipauthserve(is there a need to run the asterisk explicitly?) and wireshark. I chose the test network in the list of operators and before I got "Network no longer available" message, I fixed a channel request message in wireshark. The response message in the wireshark as displayed was "IMSI not found". Yes I did not register my IMSI in the asterisk and in the log file I saw that the system denied registration. So I am guessing that is the reason for "Network no longer available". Is this right? After trying this for several time and seeing the wireshark packets sent from phone and from the system, I decided to restart my system and try everything again. But this time I saw saw no activity in the wireshark and along with getting network not available messages, I was getting this continuously in the log file: Mar 28 17:52:43 openbts: INFO 3045002096 RadioResource.cpp:148:AccessGrantResponder: RA=0x2 when=0:1376661 age=5 delay=0.683594 RSSI=-23 Mar 28 17:52:43 openbts: INFO 3045002096 RadioResource.cpp:228:AccessGrantResponder: sending PageMode=(0) DedicatedModeOrTBF=(TMA=0 Downlink=0 DMOrTBF=0) ChannelDescription=(typeAndOffset=SDCCH/4-0 TN=0 TSC=2 ARFCN=613) RequestReference=(RA=2 T1'=14 T2=13 T3=18) TimingAdvance=1 Mar 28 17:53:00 transceiver: ERR 3043343216 UHDDevice.cpp:574:check_rx_md_err: An internal receive buffer has filled at 125.99 sec. I was not getting the last message(ERR) everytime, but at some times. Do you have any suggestions? I think adjusting power levels is one step further, so thought I should be all set with being able to successfully connecting Thanks everyone for consideration On Tue, Mar 27, 2012 at 5:25 AM, Thomas Tsou <tt...@vt...> wrote: > On Mon, Mar 26, 2012 at 6:29 PM, Orkhan Badirkhanli <orx...@gm...> > wrote: > > Thomas > > > > In the setting where I only decreased the rxgain to 10dBm, the cell phone > > was sending a channel request message to OpenBTS as I was detecting the > > packages through wireshark. > > Ok. > > > I noticed that even though the handset was showing OpenBTS in the list of > > operators from up to 20m with rooms in between, it was not sending a > request > > channel message and was showing "No signal" sign. > > Note that the handset does not need to send a channel request every > time it camps if it was connected to the BTS in a previous instance. > > > And yes, also in the room is LOS the handset was not sending request > channel > > signal from longer than 2m. > > Is the handset still camping in these instances? or are getting "No > signal" at just a few meters? > > Thomas > -- Orkhan |
From: Orkhan B. <orx...@gm...> - 2012-03-28 17:39:55
|
To add, when I just went though the OpenBTS logs when I was seeing packets in wireshark, I saw that the two lines I included in previous mail are followed by ------------------- openbts: INFO 3063905136 MobilityManagement.cpp:145:LocationUpdatingController: MM Location Updating Request LAI=(MCC=xxx MNC=xx LAC=0xfffe) MobileIdentity=(IMSI=286032301208040) classmark=(revision=1 ES-IND=1 A5/1=0 powerCap=3) openbts: INFO 3063905136 MobilityManagement.cpp:247:LocationUpdatingController: registration FAILED: IMSI=xxxxxxxxxxxxxxxx -------------------- On Wed, Mar 28, 2012 at 6:14 PM, Orkhan Badirkhanli <orx...@gm...>wrote: > Well, even when the handset was sending channel request message and then > connecting, it was first displaying "Network is no longer available" > message. Thus I think the problem is in something else. > > Right now I am testing with external clock(signal generator) connected as > opposed to past. > > As I turned the system on for the first time during the day and testing I > experienced the following. I ran the the openbts, sipauthserve(is there a > need to run the asterisk explicitly?) and wireshark. I chose the test > network in the list of operators and before I got "Network no longer > available" message, I fixed a channel request message in wireshark. > > The response message in the wireshark as displayed was "IMSI not found". > Yes I did not register my IMSI in the asterisk and in the log file I saw > that the system denied registration. So I am guessing that is the reason > for "Network no longer available". Is this right? > > After trying this for several time and seeing the wireshark packets sent > from phone and from the system, I decided to restart my system and try > everything again. > > But this time I saw saw no activity in the wireshark and along with > getting network not available messages, I was getting this continuously in > the log file: > > Mar 28 17:52:43 openbts: INFO 3045002096 > RadioResource.cpp:148:AccessGrantResponder: RA=0x2 when=0:1376661 age=5 > delay=0.683594 RSSI=-23 > > Mar 28 17:52:43 openbts: INFO 3045002096 > RadioResource.cpp:228:AccessGrantResponder: sending PageMode=(0) > DedicatedModeOrTBF=(TMA=0 Downlink=0 DMOrTBF=0) > ChannelDescription=(typeAndOffset=SDCCH/4-0 TN=0 TSC=2 ARFCN=613) > RequestReference=(RA=2 T1'=14 T2=13 T3=18) TimingAdvance=1 > > Mar 28 17:53:00 transceiver: ERR 3043343216 > UHDDevice.cpp:574:check_rx_md_err: An internal receive buffer has filled at > 125.99 sec. > > I was not getting the last message(ERR) everytime, but at some times. > > Do you have any suggestions? > > I think adjusting power levels is one step further, so thought I should be > all set with being able to successfully connecting > > Thanks everyone for consideration > > On Tue, Mar 27, 2012 at 5:25 AM, Thomas Tsou <tt...@vt...> wrote: > >> On Mon, Mar 26, 2012 at 6:29 PM, Orkhan Badirkhanli <orx...@gm...> >> wrote: >> > Thomas >> > >> > In the setting where I only decreased the rxgain to 10dBm, the cell >> phone >> > was sending a channel request message to OpenBTS as I was detecting the >> > packages through wireshark. >> >> Ok. >> >> > I noticed that even though the handset was showing OpenBTS in the list >> of >> > operators from up to 20m with rooms in between, it was not sending a >> request >> > channel message and was showing "No signal" sign. >> >> Note that the handset does not need to send a channel request every >> time it camps if it was connected to the BTS in a previous instance. >> >> > And yes, also in the room is LOS the handset was not sending request >> channel >> > signal from longer than 2m. >> >> Is the handset still camping in these instances? or are getting "No >> signal" at just a few meters? >> >> Thomas >> > > > > -- > Orkhan > -- Orkhan |
From: Kurtis H. <khe...@cs...> - 2012-03-28 17:41:17
|
My understanding is that if you don't have open registration turned on, OpenBTS will reject the handset during camping. The handset will remember this and reject any further attempts to camp on that tower explicitly. This seems to be the behavior you are seeing. On Wed, Mar 28, 2012 at 8:14 AM, Orkhan Badirkhanli <orx...@gm...> wrote: > Well, even when the handset was sending channel request message and then > connecting, it was first displaying "Network is no longer available" > message. Thus I think the problem is in something else. > > Right now I am testing with external clock(signal generator) connected as > opposed to past. > > As I turned the system on for the first time during the day and testing I > experienced the following. I ran the the openbts, sipauthserve(is there a > need to run the asterisk explicitly?) and wireshark. I chose the test > network in the list of operators and before I got "Network no longer > available" message, I fixed a channel request message in wireshark. > > The response message in the wireshark as displayed was "IMSI not found". Yes > I did not register my IMSI in the asterisk and in the log file I saw that > the system denied registration. So I am guessing that is the reason for > "Network no longer available". Is this right? > > After trying this for several time and seeing the wireshark packets sent > from phone and from the system, I decided to restart my system and try > everything again. > > But this time I saw saw no activity in the wireshark and along with getting > network not available messages, I was getting this continuously in the log > file: > > Mar 28 17:52:43 openbts: INFO 3045002096 > RadioResource.cpp:148:AccessGrantResponder: RA=0x2 when=0:1376661 age=5 > delay=0.683594 RSSI=-23 > > Mar 28 17:52:43 openbts: INFO 3045002096 > RadioResource.cpp:228:AccessGrantResponder: sending PageMode=(0) > DedicatedModeOrTBF=(TMA=0 Downlink=0 DMOrTBF=0) > ChannelDescription=(typeAndOffset=SDCCH/4-0 TN=0 TSC=2 ARFCN=613) > RequestReference=(RA=2 T1'=14 T2=13 T3=18) TimingAdvance=1 > > Mar 28 17:53:00 transceiver: ERR 3043343216 > UHDDevice.cpp:574:check_rx_md_err: An internal receive buffer has filled at > 125.99 sec. > > I was not getting the last message(ERR) everytime, but at some times. > > Do you have any suggestions? > > I think adjusting power levels is one step further, so thought I should be > all set with being able to successfully connecting > > Thanks everyone for consideration > > On Tue, Mar 27, 2012 at 5:25 AM, Thomas Tsou <tt...@vt...> wrote: >> >> On Mon, Mar 26, 2012 at 6:29 PM, Orkhan Badirkhanli <orx...@gm...> >> wrote: >> > Thomas >> > >> > In the setting where I only decreased the rxgain to 10dBm, the cell >> > phone >> > was sending a channel request message to OpenBTS as I was detecting the >> > packages through wireshark. >> >> Ok. >> >> > I noticed that even though the handset was showing OpenBTS in the list >> > of >> > operators from up to 20m with rooms in between, it was not sending a >> > request >> > channel message and was showing "No signal" sign. >> >> Note that the handset does not need to send a channel request every >> time it camps if it was connected to the BTS in a previous instance. >> >> > And yes, also in the room is LOS the handset was not sending request >> > channel >> > signal from longer than 2m. >> >> Is the handset still camping in these instances? or are getting "No >> signal" at just a few meters? >> >> Thomas > > > > > -- > Orkhan > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Openbts-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-discuss > |
From: Orkhan B. <orx...@gm...> - 2012-03-28 18:03:09
|
Kurtis, Yes, my openregistration is null So there is no way in openbts to not to reject requests when they are not registered in the pbx? There is video in youtube of Chris Paget in DEFCOM, when he is demonstrating IMSI catcher(http://www.youtube.com/watch?v=wjYAAmHvt-g). In that case, there did not have the IMSI value. In fact he way detecting them. So, then do you think he make some changes to openbts, or wrote additional script that registers the IMSI automatically? I appreciate your help On Wed, Mar 28, 2012 at 8:40 PM, Kurtis Heimerl <khe...@cs...>wrote: > My understanding is that if you don't have open registration turned > on, OpenBTS will reject the handset during camping. The handset will > remember this and reject any further attempts to camp on that tower > explicitly. This seems to be the behavior you are seeing. > > On Wed, Mar 28, 2012 at 8:14 AM, Orkhan Badirkhanli <orx...@gm...> > wrote: > > Well, even when the handset was sending channel request message and then > > connecting, it was first displaying "Network is no longer available" > > message. Thus I think the problem is in something else. > > > > Right now I am testing with external clock(signal generator) connected as > > opposed to past. > > > > As I turned the system on for the first time during the day and testing I > > experienced the following. I ran the the openbts, sipauthserve(is there a > > need to run the asterisk explicitly?) and wireshark. I chose the test > > network in the list of operators and before I got "Network no longer > > available" message, I fixed a channel request message in wireshark. > > > > The response message in the wireshark as displayed was "IMSI not found". > Yes > > I did not register my IMSI in the asterisk and in the log file I saw that > > the system denied registration. So I am guessing that is the reason for > > "Network no longer available". Is this right? > > > > After trying this for several time and seeing the wireshark packets sent > > from phone and from the system, I decided to restart my system and try > > everything again. > > > > But this time I saw saw no activity in the wireshark and along with > getting > > network not available messages, I was getting this continuously in the > log > > file: > > > > Mar 28 17:52:43 openbts: INFO 3045002096 > > RadioResource.cpp:148:AccessGrantResponder: RA=0x2 when=0:1376661 age=5 > > delay=0.683594 RSSI=-23 > > > > Mar 28 17:52:43 openbts: INFO 3045002096 > > RadioResource.cpp:228:AccessGrantResponder: sending PageMode=(0) > > DedicatedModeOrTBF=(TMA=0 Downlink=0 DMOrTBF=0) > > ChannelDescription=(typeAndOffset=SDCCH/4-0 TN=0 TSC=2 ARFCN=613) > > RequestReference=(RA=2 T1'=14 T2=13 T3=18) TimingAdvance=1 > > > > Mar 28 17:53:00 transceiver: ERR 3043343216 > > UHDDevice.cpp:574:check_rx_md_err: An internal receive buffer has filled > at > > 125.99 sec. > > > > I was not getting the last message(ERR) everytime, but at some times. > > > > Do you have any suggestions? > > > > I think adjusting power levels is one step further, so thought I should > be > > all set with being able to successfully connecting > > > > Thanks everyone for consideration > > > > On Tue, Mar 27, 2012 at 5:25 AM, Thomas Tsou <tt...@vt...> wrote: > >> > >> On Mon, Mar 26, 2012 at 6:29 PM, Orkhan Badirkhanli <orx...@gm... > > > >> wrote: > >> > Thomas > >> > > >> > In the setting where I only decreased the rxgain to 10dBm, the cell > >> > phone > >> > was sending a channel request message to OpenBTS as I was detecting > the > >> > packages through wireshark. > >> > >> Ok. > >> > >> > I noticed that even though the handset was showing OpenBTS in the list > >> > of > >> > operators from up to 20m with rooms in between, it was not sending a > >> > request > >> > channel message and was showing "No signal" sign. > >> > >> Note that the handset does not need to send a channel request every > >> time it camps if it was connected to the BTS in a previous instance. > >> > >> > And yes, also in the room is LOS the handset was not sending request > >> > channel > >> > signal from longer than 2m. > >> > >> Is the handset still camping in these instances? or are getting "No > >> signal" at just a few meters? > >> > >> Thomas > > > > > > > > > > -- > > Orkhan > > > > > ------------------------------------------------------------------------------ > > This SF email is sponsosred by: > > Try Windows Azure free for 90 days Click Here > > http://p.sf.net/sfu/sfd2d-msazure > > _______________________________________________ > > Openbts-discuss mailing list > > Ope...@li... > > https://lists.sourceforge.net/lists/listinfo/openbts-discuss > > > -- Orkhan |
From: Kurtis H. <khe...@cs...> - 2012-03-28 18:04:39
|
You just need to set OpenRegistration to something not-null. This is in the wiki. On Wed, Mar 28, 2012 at 11:02 AM, Orkhan Badirkhanli <orx...@gm...> wrote: > Kurtis, > > Yes, my openregistration is null > > So there is no way in openbts to not to reject requests when they are not > registered in the pbx? > > There is video in youtube of Chris Paget in DEFCOM, when he is demonstrating > IMSI catcher(http://www.youtube.com/watch?v=wjYAAmHvt-g). In that case, > there did not have the IMSI value. In fact he way detecting them. > > So, then do you think he make some changes to openbts, or wrote additional > script that registers the IMSI automatically? > > I appreciate your help > > On Wed, Mar 28, 2012 at 8:40 PM, Kurtis Heimerl <khe...@cs...> > wrote: >> >> My understanding is that if you don't have open registration turned >> on, OpenBTS will reject the handset during camping. The handset will >> remember this and reject any further attempts to camp on that tower >> explicitly. This seems to be the behavior you are seeing. >> >> On Wed, Mar 28, 2012 at 8:14 AM, Orkhan Badirkhanli <orx...@gm...> >> wrote: >> > Well, even when the handset was sending channel request message and then >> > connecting, it was first displaying "Network is no longer available" >> > message. Thus I think the problem is in something else. >> > >> > Right now I am testing with external clock(signal generator) connected >> > as >> > opposed to past. >> > >> > As I turned the system on for the first time during the day and testing >> > I >> > experienced the following. I ran the the openbts, sipauthserve(is there >> > a >> > need to run the asterisk explicitly?) and wireshark. I chose the test >> > network in the list of operators and before I got "Network no longer >> > available" message, I fixed a channel request message in wireshark. >> > >> > The response message in the wireshark as displayed was "IMSI not found". >> > Yes >> > I did not register my IMSI in the asterisk and in the log file I saw >> > that >> > the system denied registration. So I am guessing that is the reason for >> > "Network no longer available". Is this right? >> > >> > After trying this for several time and seeing the wireshark packets sent >> > from phone and from the system, I decided to restart my system and try >> > everything again. >> > >> > But this time I saw saw no activity in the wireshark and along with >> > getting >> > network not available messages, I was getting this continuously in the >> > log >> > file: >> > >> > Mar 28 17:52:43 openbts: INFO 3045002096 >> > RadioResource.cpp:148:AccessGrantResponder: RA=0x2 when=0:1376661 age=5 >> > delay=0.683594 RSSI=-23 >> > >> > Mar 28 17:52:43 openbts: INFO 3045002096 >> > RadioResource.cpp:228:AccessGrantResponder: sending PageMode=(0) >> > DedicatedModeOrTBF=(TMA=0 Downlink=0 DMOrTBF=0) >> > ChannelDescription=(typeAndOffset=SDCCH/4-0 TN=0 TSC=2 ARFCN=613) >> > RequestReference=(RA=2 T1'=14 T2=13 T3=18) TimingAdvance=1 >> > >> > Mar 28 17:53:00 transceiver: ERR 3043343216 >> > UHDDevice.cpp:574:check_rx_md_err: An internal receive buffer has filled >> > at >> > 125.99 sec. >> > >> > I was not getting the last message(ERR) everytime, but at some times. >> > >> > Do you have any suggestions? >> > >> > I think adjusting power levels is one step further, so thought I should >> > be >> > all set with being able to successfully connecting >> > >> > Thanks everyone for consideration >> > >> > On Tue, Mar 27, 2012 at 5:25 AM, Thomas Tsou <tt...@vt...> wrote: >> >> >> >> On Mon, Mar 26, 2012 at 6:29 PM, Orkhan Badirkhanli >> >> <orx...@gm...> >> >> wrote: >> >> > Thomas >> >> > >> >> > In the setting where I only decreased the rxgain to 10dBm, the cell >> >> > phone >> >> > was sending a channel request message to OpenBTS as I was detecting >> >> > the >> >> > packages through wireshark. >> >> >> >> Ok. >> >> >> >> > I noticed that even though the handset was showing OpenBTS in the >> >> > list >> >> > of >> >> > operators from up to 20m with rooms in between, it was not sending a >> >> > request >> >> > channel message and was showing "No signal" sign. >> >> >> >> Note that the handset does not need to send a channel request every >> >> time it camps if it was connected to the BTS in a previous instance. >> >> >> >> > And yes, also in the room is LOS the handset was not sending request >> >> > channel >> >> > signal from longer than 2m. >> >> >> >> Is the handset still camping in these instances? or are getting "No >> >> signal" at just a few meters? >> >> >> >> Thomas >> > >> > >> > >> > >> > -- >> > Orkhan >> > >> > >> > ------------------------------------------------------------------------------ >> > This SF email is sponsosred by: >> > Try Windows Azure free for 90 days Click Here >> > http://p.sf.net/sfu/sfd2d-msazure >> > _______________________________________________ >> > Openbts-discuss mailing list >> > Ope...@li... >> > https://lists.sourceforge.net/lists/listinfo/openbts-discuss >> > > > > > > -- > Orkhan |