From: Adam A. <ara...@gm...> - 2009-04-17 01:04:40
|
All, I searched online, the mailing list (I can't access the archives?), and analyzed the code and I'm still a little confused about how time is kept in OpenBTS. The way I currently understand it, OpenBTS utilizes a system call to get the time. Some of the documentation referred to using a counter or the time stamping on the USRP but, I could not find any code which did this. This seems like it would be better since there would be a more accurate clock 64MHz It is mentioned in the documentation that it would be better if instead of a 64MHz clock the USRP was running at a multiple of 13MHz. If I use an external reference at one of these frequencies what code would I need to change? Would I need to remove the PolyphaseResampler (I'm not exactly sure how it handles all the magic)? I notice that quite often the TOA on any RACHs is actually negative. Is this a timing issue or am I not understanding how the whole peakDetect determines the offset? Also, does OpenBTS use the inband_signaling of the USRP? I've seen the rbf file, but the USRPDevice class only refers to usrp_standard.h. If OpenBTS uses the inband signalling couldn't you use the rx timestamp mechanism? Sorry for all of the questions, I just find this to be a fascinating project and I want to understand it better! -- Adam A. |
From: David A. B. <dbu...@jc...> - 2009-04-17 17:15:01
|
Adam - The clock in OpenBTS derived from the sample clock in the USRP. Here's the chain: * The sample clock is communicated to the transceiver over USB though inband signaling. * The transceiver calculates a GSM symbol clock from the sample clock. It calculates a frame clock from the symbol clock. * The transceiver communicates the frame clock to OpenBTS through occasional UDP messages on port 5700. * Inside OpenBTS, we calculate the current frame clock from the system clock using a GSM::Clock object, gBTS.mClock, based on the receipt time of the last clock message on part 5700 and knowledge of the constant GSM frame rate. This clock is recalibrated whenever OpenBTS receives a clock message from the transceiver. The inside of OpenBTS is asynchronous above L1. The gBTS.mClock does not need to be more accurate than about +/- 1/4 a GSM multiframe. If you run the USRP at a multiple of 13 MHz, you can get rid of the polyphase resampler. That would save a lot of computation. (BTW, we got a little bag of 52 MHz clocks from Elciptek last week and intend to try this soon.) The negative TOA on RACH bursts is probably due to the fact that the RACH correlator search window is very wide and unless your handset is a few km from the receiver you will be on the "early" end of the window. The transceiver uses in-band signaling, but pre-dates the standard in- band signaling interface in GNU Radio's libusrp. Harvind wrote his own based on a pre-release RBF file we got from Eric Blossom back in late 2007. The underlying timestamping mechanism in the USRP is the same, but the implementation on the host side is different. We've been waiting for someone to volunteer to update that in the GNU distribution, but that hasn't happened yet. We will eventually get around to it, but it is not yet a priority. No problem answering questions. One of these days, we'll start writing documentation again. -- David On Apr 16, 2009, at 6:04 PM, Adam Audino wrote: > All, > I searched online, the mailing list (I can't access the > archives?), and analyzed the code and I'm still a little confused > about how time is kept in OpenBTS. The way I currently understand > it, OpenBTS utilizes a system call to get the time. Some of the > documentation referred to using a counter or the time stamping on > the USRP but, I could not find any code which did this. This seems > like it would be better since there would be a more accurate clock > 64MHz > > It is mentioned in the documentation that it would be better if > instead of a 64MHz clock the USRP was running at a multiple of > 13MHz. If I use an external reference at one of these frequencies > what code would I need to change? Would I need to remove the > PolyphaseResampler (I'm not exactly sure how it handles all the > magic)? > > > I notice that quite often the TOA on any RACHs is actually > negative. Is this a timing issue or am I not understanding how the > whole peakDetect determines the offset? > > Also, does OpenBTS use the inband_signaling of the USRP? I've seen > the rbf file, but the USRPDevice class only refers to > usrp_standard.h. If OpenBTS uses the inband signalling couldn't > you use the rx timestamp mechanism? > > Sorry for all of the questions, I just find this to be a > fascinating project and I want to understand it better! > > -- > Adam A. > ---------------------------------------------------------------------- > -------- > Stay on top of everything new and different, both inside and > around Java (TM) technology - register by April 22, and save > $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. > 300 plus technical and hands-on sessions. Register today. > Use priority code J9JMT32. http://p.sf.net/sfu/ > p_______________________________________________ > Openbts-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-discuss David A. Burgess Kestrel Signal Processing, Inc. |
From: Adam A. <ara...@gm...> - 2009-05-08 13:24:54
|
David, Just another quick question. What is the part number of the clocks you received from Elciptek? On Fri, Apr 17, 2009 at 1:09 PM, David A. Burgess <dbu...@jc...> wrote: > Adam - > The clock in OpenBTS derived from the sample clock in the USRP. Here's the > chain: > > * The sample clock is communicated to the transceiver over USB though > inband signaling. > > * The transceiver calculates a GSM symbol clock from the sample clock. It > calculates a frame clock from the symbol clock. > > * The transceiver communicates the frame clock to OpenBTS through > occasional UDP messages on port 5700. > > * Inside OpenBTS, we calculate the current frame clock from the system > clock using a GSM::Clock object, gBTS.mClock, based on the receipt time of > the last clock message on part 5700 and knowledge of the constant GSM frame > rate. This clock is recalibrated whenever OpenBTS receives a clock message > from the transceiver. > > The inside of OpenBTS is asynchronous above L1. The gBTS.mClock does not > need to be more accurate than about +/- 1/4 a GSM multiframe. > > If you run the USRP at a multiple of 13 MHz, you can get rid of the > polyphase resampler. That would save a lot of computation. (BTW, we got a > little bag of 52 MHz clocks from Elciptek last week and intend to try this > soon.) > > The negative TOA on RACH bursts is probably due to the fact that the RACH > correlator search window is very wide and unless your handset is a few km > from the receiver you will be on the "early" end of the window. > > The transceiver uses in-band signaling, but pre-dates the standard in-band > signaling interface in GNU Radio's libusrp. Harvind wrote his own based on > a pre-release RBF file we got from Eric Blossom back in late 2007. The > underlying timestamping mechanism in the USRP is the same, but the > implementation on the host side is different. We've been waiting for > someone to volunteer to update that in the GNU distribution, but that hasn't > happened yet. We will eventually get around to it, but it is not yet a > priority. > > No problem answering questions. One of these days, we'll start writing > documentation again. > > -- David > > > On Apr 16, 2009, at 6:04 PM, Adam Audino wrote: > > All, I searched online, the mailing list (I can't access the archives?), > and analyzed the code and I'm still a little confused about how time is kept > in OpenBTS. The way I currently understand it, OpenBTS utilizes a system > call to get the time. Some of the documentation referred to using a counter > or the time stamping on the USRP but, I could not find any code which did > this. This seems like it would be better since there would be a more > accurate clock 64MHz > > It is mentioned in the documentation that it would be better if instead of > a 64MHz clock the USRP was running at a multiple of 13MHz. If I use an > external reference at one of these frequencies what code would I need to > change? Would I need to remove the PolyphaseResampler (I'm not exactly sure > how it handles all the magic)? > > > I notice that quite often the TOA on any RACHs is actually negative. Is > this a timing issue or am I not understanding how the whole peakDetect > determines the offset? > > Also, does OpenBTS use the inband_signaling of the USRP? I've seen the rbf > file, but the USRPDevice class only refers to usrp_standard.h. If OpenBTS > uses the inband signalling couldn't you use the rx timestamp mechanism? > > Sorry for all of the questions, I just find this to be a fascinating > project and I want to understand it better! > > -- > Adam A. > > ------------------------------------------------------------------------------ > Stay on top of everything new and different, both inside and > around Java (TM) technology - register by April 22, and save > $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. > 300 plus technical and hands-on sessions. Register today. > Use priority code J9JMT32. > http://p.sf.net/sfu/p_______________________________________________ > Openbts-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-discuss > > > > David A. Burgess > Kestrel Signal Processing, Inc. > > > > > -- Adam A. |
From: Adam A. <ara...@gm...> - 2009-05-01 14:04:26
|
I forgot to reply to all to get this on the mailing list David, Thanks for the response! I have a few more questions. Do all your answers above apply to the GnuRadio distribution of OpenBTS? You said, "The negative TOA on RACH bursts is probably due to the fact that the RACH correlator search window is very wide and unless your handset is a few km from the receiver you will be on the "early" end of the window." What exactly is the RACH correlator search window? Is it just the different values that the signal is convolved against? I would naively think that a wide search window is good because it would search over many of the possible values where as a narrower window would only be accurate within it's search area. So, how would one go about adjusting this window to be more accurate? Also, I notice that there is a large standard deviation of the TOA even when the phone is sitting on the desk and not moving. The way I currently understand that OpenBTS works is that it takes a generated RACH sequence (the ideal sequence), reverses it, convolves it with the received signal, and then finds the largest interpolated value in the convolved array. This largest value is supposed to represent the number of 1/256 bits that the signal is "off by". This is the part where I get confused. ~line 900 is sigProcLib.cpp *TOA = (*TOA) - gRACHSequence->TOA - 8 * samplesPerSymbol;//samplesPerSymbol is 1 I believe gRACHSequence->TOA == 19.998047 (which kind of confuses me since I would at least think that 2 identical signals would correlate on the 0th index). Or, is this in the spec that the RACH synced up should arrive at ~20/256 bits into the timeslot? Also, I thought we were in 1/256 of a symbol so why are we multiplying by 8? Lastly, I have gotten my hands on a 52MHz reference clock too and I was wondering what changes I would need to make to the code to utilize it. Would it really be as simple as getting rid of the polyphase resampler in the code? I may give it a go, it would just be nice to know if something goes wrong, if it is the clock, the usrp, or my changes :) Thanks! On Fri, Apr 17, 2009 at 1:09 PM, David A. Burgess <dbu...@jc...> wrote: > Adam - > The clock in OpenBTS derived from the sample clock in the USRP. Here's the > chain: > > * The sample clock is communicated to the transceiver over USB though > inband signaling. > > * The transceiver calculates a GSM symbol clock from the sample clock. It > calculates a frame clock from the symbol clock. > > * The transceiver communicates the frame clock to OpenBTS through > occasional UDP messages on port 5700. > > * Inside OpenBTS, we calculate the current frame clock from the system > clock using a GSM::Clock object, gBTS.mClock, based on the receipt time of > the last clock message on part 5700 and knowledge of the constant GSM frame > rate. This clock is recalibrated whenever OpenBTS receives a clock message > from the transceiver. > > The inside of OpenBTS is asynchronous above L1. The gBTS.mClock does not > need to be more accurate than about +/- 1/4 a GSM multiframe. > > If you run the USRP at a multiple of 13 MHz, you can get rid of the > polyphase resampler. That would save a lot of computation. (BTW, we got a > little bag of 52 MHz clocks from Elciptek last week and intend to try this > soon.) > > The negative TOA on RACH bursts is probably due to the fact that the RACH > correlator search window is very wide and unless your handset is a few km > from the receiver you will be on the "early" end of the window. > > The transceiver uses in-band signaling, but pre-dates the standard in-band > signaling interface in GNU Radio's libusrp. Harvind wrote his own based on > a pre-release RBF file we got from Eric Blossom back in late 2007. The > underlying timestamping mechanism in the USRP is the same, but the > implementation on the host side is different. We've been waiting for > someone to volunteer to update that in the GNU distribution, but that hasn't > happened yet. We will eventually get around to it, but it is not yet a > priority. > > No problem answering questions. One of these days, we'll start writing > documentation again. > > -- David > > > On Apr 16, 2009, at 6:04 PM, Adam Audino wrote: > > All, I searched online, the mailing list (I can't access the archives?), > and analyzed the code and I'm still a little confused about how time is kept > in OpenBTS. The way I currently understand it, OpenBTS utilizes a system > call to get the time. Some of the documentation referred to using a counter > or the time stamping on the USRP but, I could not find any code which did > this. This seems like it would be better since there would be a more > accurate clock 64MHz > > It is mentioned in the documentation that it would be better if instead of > a 64MHz clock the USRP was running at a multiple of 13MHz. If I use an > external reference at one of these frequencies what code would I need to > change? Would I need to remove the PolyphaseResampler (I'm not exactly sure > how it handles all the magic)? > > > I notice that quite often the TOA on any RACHs is actually negative. Is > this a timing issue or am I not understanding how the whole peakDetect > determines the offset? > > Also, does OpenBTS use the inband_signaling of the USRP? I've seen the rbf > file, but the USRPDevice class only refers to usrp_standard.h. If OpenBTS > uses the inband signalling couldn't you use the rx timestamp mechanism? > > Sorry for all of the questions, I just find this to be a fascinating > project and I want to understand it better! > > -- > Adam A. > > ------------------------------------------------------------------------------ > Stay on top of everything new and different, both inside and > around Java (TM) technology - register by April 22, and save > $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. > 300 plus technical and hands-on sessions. Register today. > Use priority code J9JMT32. > http://p.sf.net/sfu/p_______________________________________________ > Openbts-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-discuss > > > > David A. Burgess > Kestrel Signal Processing, Inc. > > > > > -- Adam A. -- Adam A. |