From: Axelle <aaf...@gm...> - 2010-10-11 09:46:52
|
On Sun, Oct 10, 2010 at 1:41 AM, Konrad Meier < me...@in...> wrote: > Am 09.10.2010 23:33, schrieb Sylvain Munaut: > > My transceiver fails to tune, and although there are several messages >>> about >>> this, I haven't found any solution in my case. >>> >> >> If you're trying to use the 64Mhz version of the tranceuver in the >> 1.8GHz band, it won't work without small mod to the code. >> You need to set : >> >> DIV2 = 0; >> freq_mult = 1; >> >> somewhere in USRPDevice.h >> > > Attached is a patch for this. I don't know if it still works but for me it > did work some time ago. > Thanks guys, I did the modifications in the code & compiled, and great :) now it doesn't complain any longer about not tuning ! :) ... However, my phone does not register yet :( - I am using GSM.Band 1800 with GSM.ARFCN 880. Is this okay? When I use ./usrp_fft.py I see a peek for 1800Mhz, this means the frequency is being used, no? could that be a problem? I also tried GSM.Band 1900 with GSM.ARFCN 801, unsuccessful to register too. I have a RFX 1800 daughterboard, of course. - The OpenBTS logs tell me seem ok. Looks like the first initial command failed but then next ones seem to be ok: 1286790026.9604 INFO 3074414272 TRXManager.cpp:254:sendCommandPacket: command CMD POWEROFF 1286790028.0097 WARNING 3074414272 TRXManager.cpp:271:sendCommandPacket: retrying transceiver command after response timeout 1286790028.0140 INFO 3074414272 TRXManager.cpp:254:sendCommandPacket: command CMD SETTSC 0 1286790028.0182 INFO 3074414272 TRXManager.cpp:254:sendCommandPacket: command CMD RXTUNE 1908000 1286790028.0305 INFO 3074414272 TRXManager.cpp:254:sendCommandPacket: command CMD TXTUNE 1988000 1286790028.0427 INFO 3074414272 TRXManager.cpp:254:sendCommandPacket: command CMD SETSLOT 0 5 1286790028.0469 INFO 3074414272 TRXManager.cpp:254:sendCommandPacket: command CMD POWERON 1286790028.0753 INFO 3074414272 TRXManager.cpp:254:sendCommandPacket: command CMD SETPOWER 0 ... 1286790028.1606 INFO 3074414272 TRXManager.cpp:254:sendCommandPacket: command CMD SETSLOT 1 7 ... 1286790028.4505 INFO 3074414272 OpenBTS.cpp:221:main: system ready - I set up my phone for manual network detection. It searches for networks, but it only catches the 3 main French operators, not my OpenBTS. Finally, would another French OpenBTS user know if and where I need to report/get a test license for 1800Mhz? Best regards Axelle. |
From: Axelle <aaf...@gm...> - 2010-10-11 10:14:12
|
> > could that be a problem? I also tried GSM.Band 1900 with >> GSM.ARFCN 801, unsuccessful to register too. >> I have a RFX 1800 daughterboard, of course. >> > > In your previus e-Mail you wrote that you are using a "RAW" USRP. I think > you problem is caused by the frequency offset of the standart USRP > oscillator. > Please read this: > http://gnuradio.org/redmine/wiki/gnuradio/OpenBTSClocks > Hi Konrad, Ok... I just want to make sure this is the real problem before buying some new equipment. In some other answer I got, somebody was saying a raw USRP - standard clock - should be okay for a few tests... Regards Axelle. > > Regards > Konrad > |
From: Konrad M. <me...@in...> - 2010-10-11 10:31:02
|
Am 11.10.2010 12:14, schrieb Axelle: > could that be a problem? I also tried GSM.Band 1900 with > GSM.ARFCN 801, unsuccessful to register too. > I have a RFX 1800 daughterboard, of course. > > > In your previus e-Mail you wrote that you are using a "RAW" USRP. I > think you problem is caused by the frequency offset of the standart > USRP oscillator. > Please read this: > http://gnuradio.org/redmine/wiki/gnuradio/OpenBTSClocks > > > Hi Konrad, > > Ok... I just want to make sure this is the real problem before buying > some new equipment. > > In some other answer I got, somebody was saying a raw USRP - standard > clock - should be okay for a few tests... My experience is that it might work in the GSM900 or 850 frequency band but not in DCS1800 with the standard clock. I am using the FA-SY 1 calibrated with "Kal" and it works great. But the output voltage of the FA-SY 1 is to high. Maybe try the new FA-SY 2: http://www.box73.de/catalog/product_info.php?products_id=1870 I did not test the FA-SY 2 so I can't guarantee that it works. Regards Konrad |
From: Sylvain M. <24...@gm...> - 2010-10-11 11:32:27
|
Hi, > - I set up my phone for manual network detection. It searches for networks, > but it only catches the 3 main French operators, not my OpenBTS. Your clock is just probably too misaligned ... As Konrad saif, for GSM900 the default clock sometimes work, but for 1800 it's less likely. Try the kal 0.3 software to see how off your clock is. Either pickup a lab frequency generator, or wait for the ClockTamer to be back in stock. (should be by the end of the month according to their web site). > Finally, would another French OpenBTS user know if and where I need to > report/get a test license for 1800Mhz? Contact the ANFR I'd guess ... Cheers, Sylvain |
From: Joshua L. <jl...@th...> - 2010-10-11 16:30:11
|
Quoting Sylvain Munaut (24...@gm...): [...] > Try the kal 0.3 software to see how off your clock is. Use 0.4.1 instead: http://thre.at/kalibrate/kal-v0.4.1.tar.bz2 . It should be more accurate. |
From: David A. B. <dbu...@jc...> - 2010-10-11 16:36:24
|
This is why I would prefer to remove support for 64 MHz clocks from the public distribution of OpenBTS. I've had this discussion privately with a few people but will point out this example publicly. We put information about clock accuracy in the wiki (http://gnuradio.org/redmine/wiki/gnuradio/OpenBTSClocks), we have these discussions on the list on a regular basis, and still people keep trying to run OpenBTS on stock USRP hardware, even in the 1800/1900 bands, where it is almost certain to fail due to the crazy thermal clock drift. On Oct 11, 2010, at 4:32 AM, Sylvain Munaut wrote: > Hi, > >> - I set up my phone for manual network detection. It searches for >> networks, >> but it only catches the 3 main French operators, not my OpenBTS. > > Your clock is just probably too misaligned ... As Konrad saif, for > GSM900 the default clock sometimes work, but for 1800 it's less > likely. > > Try the kal 0.3 software to see how off your clock is. > > Either pickup a lab frequency generator, or wait for the ClockTamer to > be back in stock. (should be by the end of the month according to > their web site). > >> Finally, would another French OpenBTS user know if and where I >> need to >> report/get a test license for 1800Mhz? > > Contact the ANFR I'd guess ... > > > Cheers, > > Sylvain > > ---------------------------------------------------------------------- > -------- > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating > great > experiences on the web. Be a part of the beta today. > http://p.sf.net/sfu/beautyoftheweb > _______________________________________________ > Openbts-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-discuss David A. Burgess Kestrel Signal Processing, Inc. |
From: Axelle <aaf...@gm...> - 2010-10-12 07:54:52
|
On Mon, Oct 11, 2010 at 6:36 PM, David A. Burgess <dbu...@jc...> wrote: > > > This is why I would prefer to remove support for 64 MHz clocks from the public distribution of OpenBTS. I've had this discussion privately with a few people but will point out this example publicly. We put information about clock accuracy in the wiki (http://gnuradio.org/redmine/wiki/gnuradio/OpenBTSClocks), we have these discussions on the list on a regular basis, and still people keep trying to run OpenBTS on stock USRP hardware, even in the 1800/1900 bands, where it is almost certain to fail due to the crazy thermal clock drift. Hi David, I just want to point out I had read that wiki page, but did not understand whether having a better clock was a 'nice recommendation' or a 'strong requirement'. And as my budget is pretty tight, it's important to me ;) I have tested my clock with kal 0.3 (v0.4 does not support gnuradio 3.2.2 I think) and got "fcch not detected in 20 frames". I intend to test with v0.4 - to make see if I get better info. And, then, well probably, I'll end up buying a clock... Thanks for your help Regards Axelle. |
From: Axelle <aaf...@gm...> - 2010-10-14 08:21:10
|
On Mon, Oct 11, 2010 at 1:32 PM, Sylvain Munaut <24...@gm...> wrote: > Your clock is just probably too misaligned ... As Konrad saif, for > GSM900 the default clock sometimes work, but for 1800 it's less > likely. > > Try the kal 0.3 software to see how off your clock is. How do I know how much the clock is off ? I tried kal 0.3, but it complained about fcch errors. Then, I tried kal v0.4.1, but looks like this one only works with gnuradio 3.3. I compiled that version and tried ./kal -s DCS kal: Scanning for DCS-1800 base stations. DCS-1800: I don't get anything more... Final question, even if I find out by how much my clock is off, I can't do anything about it to re-align it (apart from buying another clock) can I? Regards Axelle... off to reading about which clock I should buy ;) |
From: Sylvain M. <24...@gm...> - 2010-10-14 08:39:06
|
Hi, > Then, I tried kal v0.4.1, but looks like this one only works with > gnuradio 3.3. Well you should really be using gnuradio 3.3 anyway ... Also some version of cal have the default clock configuration set to 52MHz, so make sure you use the proper argument to set the frequency to 64000000 Hz if you're using the default clock. > Final question, even if I find out by how much my clock is off, I > can't do anything about it to re-align it (apart from buying another > clock) can I? Nope. Sylvain |
From: Axelle <aaf...@gm...> - 2010-10-14 09:03:58
|
Hello, On Thu, Oct 14, 2010 at 10:39 AM, Sylvain Munaut <24...@gm...> wrote: > Hi, > >> Then, I tried kal v0.4.1, but looks like this one only works with >> gnuradio 3.3. > > Well you should really be using gnuradio 3.3 anyway ... But then, I have to use OpenBTS 2.6 Mamou. Why not. I currently have an error when doing so: 1287043984.8295 ALARM 3075208896 TRXManager.cpp:447:setMaxDelay: SETMAXDLY failed with status -1 1287043984.8303 ALARM 3075208896 TRXManager.cpp:458:setRxGain: SETRXGAIN failed with status -1 etc > > Also some version of cal have the default clock configuration set to > 52MHz, so make sure you use the proper argument to set the frequency > to 64000000 Hz if you're using the default clock. Yes, you're right indeed. Although I do not get much more: ./kal -F 64000000 -s DCS -v kal: Scanning for DCS-1800 base stations. channel detect threshold: 93.186335 DCS-1800: that's all... -- Axelle |
From: Sylvain M. <24...@gm...> - 2010-10-14 09:18:10
|
> But then, I have to use OpenBTS 2.6 Mamou. Why not. > I currently have an error when doing so: > 1287043984.8295 ALARM 3075208896 TRXManager.cpp:447:setMaxDelay: > SETMAXDLY failed with status -1 > 1287043984.8303 ALARM 3075208896 TRXManager.cpp:458:setRxGain: > SETRXGAIN failed with status -1 Those two are normal, that's for features not supported in 64M mode. They don't prevent proper functions. But make sure you use the git version or have this patch applied : http://openbts.git.sourceforge.net/git/gitweb.cgi?p=openbts/openbts;a=commitdiff;h=5a969569c59c729d5a4c5b806438558c60c05b0b > Yes, you're right indeed. > Although I do not get much more: > ./kal -F 64000000 -s DCS -v > kal: Scanning for DCS-1800 base stations. > channel detect threshold: 93.186335 > DCS-1800: Try to explicitely tune to a known DCS1800 station. Use a phone with a netmonitor mode / field test mode to find some. Because it might just be that there are _no_ DCS1800 station where you are ... That's the case where I am for example, I can only see GSM900 station and there are none in DCS1800. Sylvain |
From: Axelle <aaf...@gm...> - 2010-10-14 13:38:53
|
>> Yes, you're right indeed. >> Although I do not get much more: >> ./kal -F 64000000 -s DCS -v >> kal: Scanning for DCS-1800 base stations. >> channel detect threshold: 93.186335 >> DCS-1800: > > Try to explicitely tune to a known DCS1800 station. Use a phone with a > netmonitor mode / field test mode to find some. > > Because it might just be that there are _no_ DCS1800 station where you > are ... That's the case where I am for example, I can only see GSM900 > station and there are none in DCS1800. Ok. I'm sorry to sound so idiot, but I can't see where to retrieve any info about a DCS1800 station. I installed a field test mode application. I get all those menus 1.1, 8.1 etc but I can't see where I should find the info I need... And then, to tune to that frequency, you mean do: ./kal -f <THEFREQUENCY> ? Regards Axelle. |
From: Axelle <aaf...@gm...> - 2010-10-14 14:54:26
|
Hi Andy, On Thu, Oct 14, 2010 at 10:41 AM, Andy Fung <and...@gm...> wrote: > I came across similar problem as you are now. I finally made it worked. If > you want, I can share the process with you. Google Talk? That's cool of you, but I have asked about so many problems :( I don't know which one you are referring to... All in all, it looks like I need to buy a better clock. Axelle |