From: Rad <ra...@mo...> - 2009-11-18 01:11:12
|
Hi, Has anyone tried using OpenBTS with a single RFX daughter board? I understand that there are likely to be RX/TX crosstalk issues, but if those issues could be addressed with RF shielding between the TX and RX areas on the board, maybe close range performance would be acceptable? What software changes would need to be made to accommodate using just the one board? Thanks in advance, Rad. |
From: Harvind S. <hs...@ke...> - 2009-11-18 01:22:35
|
Rad, You can use it with a single RFX daughterboard. You probably just need to change configuration code in USRPDevice.cpp to use the Rx2 port on daughterboard A instead of B. --- Harvind On Wed, 2009-11-18 at 00:36 +0000, Rad wrote: > Hi, > > Has anyone tried using OpenBTS with a single RFX daughter board? I > understand that there are likely to be RX/TX crosstalk issues, but if > those issues could be addressed with RF shielding between the TX and RX > areas on the board, maybe close range performance would be acceptable? > What software changes would need to be made to accommodate using just > the one board? > > Thanks in advance, > Rad. > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Openbts-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-discuss |
From: Sylvain M. <24...@gm...> - 2009-11-18 07:36:32
|
Hi, > Has anyone tried using OpenBTS with a single RFX daughter board? Yes, I use it with one RFX900. > I understand that there are likely to be RX/TX crosstalk issues, but if > those issues could be addressed with RF shielding between the TX and RX > areas on the board, maybe close range performance would be acceptable? >From what I observed, the TX leak in RX coming from having the two antenna close to each other is much more important than the leak on the board itself. > What software changes would need to be made to accommodate using just > the one board? I posted a patch on this list to do just that a month back or so, see the archive on source forge. Sylvain |
From: Rad <ra...@mo...> - 2009-12-10 10:11:54
|
Hi, Now that there is a 52M version as well as the 64M, has anyone removed the non-integer polyphase decimator in that version with the aim of reducing CPU (and power) consumption? Or is it already in the testing branch? Perhaps the GumStix Overo package will be adequate to run a minimal version of OpenBTS with the potentially reduced CPU loading that the 52M setup creates. This question is aimed at David really, but if anyone has got a GumStix going with OpenBTS, please can you share the code/setup. I see http://www.close-haul.com/ are developing their GAPFiller to do just this, but it would be good to have a non-commercial alternative using GumStix. Thanks in advance, Rad. |
From: David A. B. <dbu...@jc...> - 2009-12-10 20:27:21
|
Rad - The 52M version does not have the polyphase decimator and has a much lower computational load than the 64M version. We run release 2.5 on the Gumstix under Ubuntu 9.04. We do not use OE. The Gumstix can support two active timeslots, but not more. So you have the BCCH+CCCH +SDCCH4 (C-V) beacon on T0 and either TCH/F (C-I) or SDCCH/8 (C-VII) on T1. -- David On Dec 10, 2009, at 2:11 AM, Rad wrote: > Hi, > > Now that there is a 52M version as well as the 64M, has anyone removed > the non-integer polyphase decimator in that version with the aim of > reducing CPU (and power) consumption? Or is it already in the testing > branch? > > Perhaps the GumStix Overo package will be adequate to run a minimal > version of OpenBTS with the potentially reduced CPU loading that > the 52M > setup creates. This question is aimed at David really, but if > anyone has > got a GumStix going with OpenBTS, please can you share the code/ > setup. I > see http://www.close-haul.com/ are developing their GAPFiller to do > just > this, but it would be good to have a non-commercial alternative using > GumStix. > > Thanks in advance, > Rad. > > > ---------------------------------------------------------------------- > -------- > Return on Information: > Google Enterprise Search pays you back > Get the facts. > http://p.sf.net/sfu/google-dev2dev > _______________________________________________ > Openbts-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-discuss David A. Burgess Kestrel Signal Processing, Inc. |
From: Alexander C. <ale...@gm...> - 2009-12-10 20:45:39
|
Hi David, What is the biggest CPU hog on Gumstix? GMSK demodulator? On Thu, Dec 10, 2009 at 23:25, David A. Burgess <dbu...@jc...> wrote: > Rad - > > The 52M version does not have the polyphase decimator and has a much > lower computational load than the 64M version. We run release 2.5 on > the Gumstix under Ubuntu 9.04. We do not use OE. The Gumstix can > support two active timeslots, but not more. So you have the BCCH+CCCH > +SDCCH4 (C-V) beacon on T0 and either TCH/F (C-I) or SDCCH/8 (C-VII) > on T1. > > -- David > > > > On Dec 10, 2009, at 2:11 AM, Rad wrote: > >> Hi, >> >> Now that there is a 52M version as well as the 64M, has anyone removed >> the non-integer polyphase decimator in that version with the aim of >> reducing CPU (and power) consumption? Or is it already in the testing >> branch? >> >> Perhaps the GumStix Overo package will be adequate to run a minimal >> version of OpenBTS with the potentially reduced CPU loading that >> the 52M >> setup creates. This question is aimed at David really, but if >> anyone has >> got a GumStix going with OpenBTS, please can you share the code/ >> setup. I >> see http://www.close-haul.com/ are developing their GAPFiller to do >> just >> this, but it would be good to have a non-commercial alternative using >> GumStix. >> >> Thanks in advance, >> Rad. >> >> >> ---------------------------------------------------------------------- >> -------- >> Return on Information: >> Google Enterprise Search pays you back >> Get the facts. >> http://p.sf.net/sfu/google-dev2dev >> _______________________________________________ >> Openbts-discuss mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/openbts-discuss > > > David A. Burgess > Kestrel Signal Processing, Inc. > > > > > > ------------------------------------------------------------------------------ > Return on Information: > Google Enterprise Search pays you back > Get the facts. > http://p.sf.net/sfu/google-dev2dev > _______________________________________________ > Openbts-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-discuss > -- Regards, Alexander Chemeris. |
From: David A. B. <dbu...@jc...> - 2009-12-10 21:17:29
|
The biggest problem appears to be memory bandwidth, not CPU loading. We made a lot of changes to reduce the cache footprint and copy operations in the transceiver, but memory delays still appear to dominate. On Dec 10, 2009, at 12:45 PM, Alexander Chemeris wrote: > Hi David, > > What is the biggest CPU hog on Gumstix? GMSK demodulator? David A. Burgess Kestrel Signal Processing, Inc. |
From: Alexander C. <ale...@gm...> - 2009-12-10 21:22:07
|
That's interesting to know. Have you estimated which component consumes the most bandwidth? I wonder what tool have you used to estimate memory bandwidth? On Fri, Dec 11, 2009 at 00:12, David A. Burgess <dbu...@jc...> wrote: > > The biggest problem appears to be memory bandwidth, not CPU loading. > We made a lot of changes to reduce the cache footprint and copy > operations in the transceiver, but memory delays still appear to > dominate. > > On Dec 10, 2009, at 12:45 PM, Alexander Chemeris wrote: > >> Hi David, >> >> What is the biggest CPU hog on Gumstix? GMSK demodulator? > > > David A. Burgess > Kestrel Signal Processing, Inc. > > > > > > ------------------------------------------------------------------------------ > Return on Information: > Google Enterprise Search pays you back > Get the facts. > http://p.sf.net/sfu/google-dev2dev > _______________________________________________ > Openbts-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-discuss > -- Regards, Alexander Chemeris. |
From: Rad <ra...@mo...> - 2009-12-10 21:43:16
|
Hi, > if anyone has got a GumStix going with OpenBTS, please > can you share the code/setup. I see http://www.close-haul.com/ > are developing their GAPFiller to do just this, but it would be > good to have a non-commercial alternative using GumStix. > >Sorry, could you elaborate what do you mean by "this" here? Doing what? > > Using Gumstix or reducing power consumption? 'This' was referring to getting GumStix going with OpenBTS, but only as a means of reducing power - so both! Using the Atom Z530 uses ~7W, whereas the Overo would be just 1 or 2W. If the system is to be solar/wind powered, this power saving becomes significant. Thanks for your help, Rad. |
From: Alexander C. <ale...@gm...> - 2009-12-10 21:51:51
|
Hi Rad, On Fri, Dec 11, 2009 at 00:43, Rad <ra...@mo...> wrote: > > if anyone has got a GumStix going with OpenBTS, please > > can you share the code/setup. I see http://www.close-haul.com/ > > are developing their GAPFiller to do just this, but it would be > > good to have a non-commercial alternative using GumStix. > > > >Sorry, could you elaborate what do you mean by "this" here? Doing what? > > > Using Gumstix or reducing power consumption? > > 'This' was referring to getting GumStix going with OpenBTS, but only as > a means of reducing power - so both! Using the Atom Z530 uses ~7W, > whereas the Overo would be just 1 or 2W. If the system is to be > solar/wind powered, this power saving becomes significant. While I agree with this, isn't it PA and other analog stuff which consumes the most of the power? -- Regards, Alexander Chemeris. |
From: Rad <ra...@mo...> - 2009-12-10 22:01:09
|
Alexander Chemeris wrote: >> 'This' was referring to getting GumStix going with OpenBTS, but only as >> a means of reducing power - so both! Using the Atom Z530 uses ~7W, >> whereas the Overo would be just 1 or 2W. If the system is to be >> solar/wind powered, this power saving becomes significant. >> > While I agree with this, isn't it PA and other analog stuff which consumes > the most of the power? > The USRP and two RFX boards use around 15W, but this could be halved with some redesign effort. One look at the multiple linear regulators shows that the USRP wasn't designed for low power consumption. Regards, Rad. |
From: Harvind S. <hs...@ke...> - 2009-12-10 22:02:31
|
Depending on the physical range of the network, the PA will be the dominant power drain. And I suspect that the larger the network, the more subscribers you will have to support, and the Gumstix won't cut it anyways. For smaller-range systems, where a power amp isn't necessary, then the savings are significant. On Fri, 2009-12-11 at 00:51 +0300, Alexander Chemeris wrote: > Hi Rad, > > On Fri, Dec 11, 2009 at 00:43, Rad <ra...@mo...> wrote: > > > if anyone has got a GumStix going with OpenBTS, please > > > can you share the code/setup. I see http://www.close-haul.com/ > > > are developing their GAPFiller to do just this, but it would be > > > good to have a non-commercial alternative using GumStix. > > > > > >Sorry, could you elaborate what do you mean by "this" here? Doing what? > > > > Using Gumstix or reducing power consumption? > > > > 'This' was referring to getting GumStix going with OpenBTS, but only as > > a means of reducing power - so both! Using the Atom Z530 uses ~7W, > > whereas the Overo would be just 1 or 2W. If the system is to be > > solar/wind powered, this power saving becomes significant. > > While I agree with this, isn't it PA and other analog stuff which consumes > the most of the power? > |
From: Alexander C. <ale...@gm...> - 2009-12-10 22:22:56
|
Hum, what is a use case for battery-powered BS with a small range? Only thing I can imagine is a femtocell use in Africa, but I don't think that's something viable today. All other uses (excluding intelligence) I can imagine are either high-power or on-grid. On Fri, Dec 11, 2009 at 01:02, Harvind Samra <hs...@ke...> wrote: > Depending on the physical range of the network, the PA will be the > dominant power drain. And I suspect that the larger the network, the > more subscribers you will have to support, and the Gumstix won't cut it > anyways. > > For smaller-range systems, where a power amp isn't necessary, then the > savings are significant. > > On Fri, 2009-12-11 at 00:51 +0300, Alexander Chemeris wrote: >> Hi Rad, >> >> On Fri, Dec 11, 2009 at 00:43, Rad <ra...@mo...> wrote: >> > > if anyone has got a GumStix going with OpenBTS, please >> > > can you share the code/setup. I see http://www.close-haul.com/ >> > > are developing their GAPFiller to do just this, but it would be >> > > good to have a non-commercial alternative using GumStix. >> > >> > > >Sorry, could you elaborate what do you mean by "this" here? Doing what? >> > > > Using Gumstix or reducing power consumption? >> > >> > 'This' was referring to getting GumStix going with OpenBTS, but only as >> > a means of reducing power - so both! Using the Atom Z530 uses ~7W, >> > whereas the Overo would be just 1 or 2W. If the system is to be >> > solar/wind powered, this power saving becomes significant. >> >> While I agree with this, isn't it PA and other analog stuff which consumes >> the most of the power? >> > > > > ------------------------------------------------------------------------------ > Return on Information: > Google Enterprise Search pays you back > Get the facts. > http://p.sf.net/sfu/google-dev2dev > _______________________________________________ > Openbts-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-discuss > -- Regards, Alexander Chemeris. |
From: Rad <ra...@mo...> - 2009-12-10 22:06:23
|
David A. Burgess wrote: > Rad - > > The 52M version does not have the polyphase decimator and has a much > lower computational load than the 64M version. We run release 2.5 on > the Gumstix under Ubuntu 9.04. We do not use OE. The Gumstix can > support two active timeslots, but not more. So you have the > BCCH+CCCH+SDCCH4 (C-V) beacon on T0 and either TCH/F (C-I) or SDCCH/8 > (C-VII) on T1. > > -- David David, Are you likely to be publishing Wiki build instructions for 2.5 on GumStix any time soon? Regards, Rad. |
From: David A. B. <dbu...@jc...> - 2009-12-10 22:42:27
|
The build instructions are the same. You put Ubuntu on the Gumstix and then treat it like any other Ubuntu system. On Dec 10, 2009, at 2:06 PM, Rad wrote: > David A. Burgess wrote: >> Rad - >> >> The 52M version does not have the polyphase decimator and has a >> much lower computational load than the 64M version. We run >> release 2.5 on the Gumstix under Ubuntu 9.04. We do not use OE. >> The Gumstix can support two active timeslots, but not more. So >> you have the BCCH+CCCH+SDCCH4 (C-V) beacon on T0 and either TCH/F >> (C-I) or SDCCH/8 (C-VII) on T1. >> >> -- David > David, > > Are you likely to be publishing Wiki build instructions for 2.5 on > GumStix any time soon? > > Regards, > Rad. David A. Burgess Kestrel Signal Processing, Inc. |
From: Harvind S. <hs...@ke...> - 2009-12-10 22:08:21
|
We use oprofile to estimate the computational load. The report from oprofile suggested that a lot of the CPU usage was in the kernel, not actual math (like the GMSK demod). Thus, our "guess" is that our memory usage is significantly greater than the 32K cache in the Overo Earth. We'll take a closer look in the near future. Our main goal was supporting SMS-only, and it does that with plenty of CPU to spare. --- Harvind On Fri, 2009-12-11 at 00:21 +0300, Alexander Chemeris wrote: > That's interesting to know. Have you estimated which component > consumes the most bandwidth? > > I wonder what tool have you used to estimate memory bandwidth? > > On Fri, Dec 11, 2009 at 00:12, David A. Burgess <dbu...@jc...> wrote: > > > > The biggest problem appears to be memory bandwidth, not CPU loading. > > We made a lot of changes to reduce the cache footprint and copy > > operations in the transceiver, but memory delays still appear to > > dominate. > > > > On Dec 10, 2009, at 12:45 PM, Alexander Chemeris wrote: > > > >> Hi David, > >> > >> What is the biggest CPU hog on Gumstix? GMSK demodulator? > > > > > > David A. Burgess > > Kestrel Signal Processing, Inc. > > > > > > > > > > > > ------------------------------------------------------------------------------ > > Return on Information: > > Google Enterprise Search pays you back > > Get the facts. > > http://p.sf.net/sfu/google-dev2dev > > _______________________________________________ > > Openbts-discuss mailing list > > Ope...@li... > > https://lists.sourceforge.net/lists/listinfo/openbts-discuss > > > > > |
From: Alexander C. <ale...@gm...> - 2009-12-10 22:25:48
|
Ah, I recall you mentioned oprofile before. It would be great if you post your progress here. At least I'm very interested in it and may be willing to help with some issues. On Fri, Dec 11, 2009 at 00:54, Harvind Samra <hs...@ke...> wrote: > We use oprofile to estimate the computational load. The report from > oprofile suggested that a lot of the CPU usage was in the kernel, not > actual math (like the GMSK demod). Thus, our "guess" is that our memory > usage is significantly greater than the 32K cache in the Overo Earth. > > We'll take a closer look in the near future. Our main goal was > supporting SMS-only, and it does that with plenty of CPU to spare. > > --- Harvind > > On Fri, 2009-12-11 at 00:21 +0300, Alexander Chemeris wrote: >> That's interesting to know. Have you estimated which component >> consumes the most bandwidth? >> >> I wonder what tool have you used to estimate memory bandwidth? >> >> On Fri, Dec 11, 2009 at 00:12, David A. Burgess <dbu...@jc...> wrote: >> > >> > The biggest problem appears to be memory bandwidth, not CPU loading. >> > We made a lot of changes to reduce the cache footprint and copy >> > operations in the transceiver, but memory delays still appear to >> > dominate. >> > >> > On Dec 10, 2009, at 12:45 PM, Alexander Chemeris wrote: >> > >> >> Hi David, >> >> >> >> What is the biggest CPU hog on Gumstix? GMSK demodulator? >> > >> > >> > David A. Burgess >> > Kestrel Signal Processing, Inc. >> > >> > >> > >> > >> > >> > ------------------------------------------------------------------------------ >> > Return on Information: >> > Google Enterprise Search pays you back >> > Get the facts. >> > http://p.sf.net/sfu/google-dev2dev >> > _______________________________________________ >> > Openbts-discuss mailing list >> > Ope...@li... >> > https://lists.sourceforge.net/lists/listinfo/openbts-discuss >> > >> >> >> > > > > ------------------------------------------------------------------------------ > Return on Information: > Google Enterprise Search pays you back > Get the facts. > http://p.sf.net/sfu/google-dev2dev > _______________________________________________ > Openbts-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-discuss > -- Regards, Alexander Chemeris. |
From: David A. B. <dbu...@jc...> - 2009-12-10 22:52:16
|
The Burning Man units pulled 60 W each: PA 20 W. USRP 15 W. mini-ITX single-core 1.6 GHz Atom 12 W. LNA 10 W. other misc. stuff 3 W. Part of the problem is that we used an oversized class A PA with very low efficiency. That PA power load should probably be cut in half. The problem with the Gumstix is that it just can't support any real capacity. It would be OK for some femtocell applications, but that's about it. On Dec 10, 2009, at 1:51 PM, Alexander Chemeris wrote: > > While I agree with this, isn't it PA and other analog stuff which > consumes > the most of the power? > > -- > Regards, > Alexander Chemeris. David A. Burgess Kestrel Signal Processing, Inc. |
From: Alexander C. <ale...@gm...> - 2009-12-12 19:56:18
|
Hi David, On Fri, Dec 11, 2009 at 01:50, David A. Burgess <dbu...@jc...> wrote: > The Burning Man units pulled 60 W each: > > PA 20 W. > USRP 15 W. > mini-ITX single-core 1.6 GHz Atom 12 W. > LNA 10 W. > other misc. stuff 3 W. > > Part of the problem is that we used an oversized class A PA with very > low efficiency. That PA power load should probably be cut in half. I put this info on the wiki: http://gnuradio.org/trac/wiki/OpenBTS/BM2009RF > The problem with the Gumstix is that it just can't support any real > capacity. It would be OK for some femtocell applications, but that's > about it. With only 2 timeslots - yes. But if we can get full 8 timeslots running, it will be fine for a small-village use case, I think. -- Regards, Alexander Chemeris. |
From: Rad <ra...@mo...> - 2010-03-19 17:40:45
|
Hi, I'd like to be able to generate the "usrp_inband.rbf" file myself from the verilog. Does anyone know exactly which source file was used to create it and where it is? I can see the standard file: "usrp/fpga/toplevel/usrp_std/usrp_std.v" and one that's at least got 'inband' in the name: "usrp/fpga/toplevel/usrp_inband_usb/usrp_inband_usb.v", but I was expecting to find a "usrp_inband.v" file somewhere. Perhaps this is the right one but just renamed? Similarly, any links to documentation on the existing inband signalling used in OpenBTS anyone? I can see http://gnuradio.org/redmine/wiki/gnuradio/InBandSignaling but this seems to be future work rather than what's currently implemented. Thanks Rad. |
From: Rad <ra...@mo...> - 2010-03-23 19:21:28
|
Sorry for replying to my own post, but just to clarify.. although I am able to use Quartus to generate "usrp_std.rbf", which works correctly, my attempts to generate the "usrp_inband.rbf" using the "usrp/fpga/toplevel/usrp_inband_usb/usrp_inband_usb.v" verilog have failed so far. The resulting rbf loads OK, but OpenBTS on the USRP does not generate any RF. It is also different in size to the one provided with GNURadio/OpenBTS which leads me to this that there is a different verilog file being used. Can anyone provide an answer to whether "usrp_inband_usb.v" is the file used to create the FPGA load used by OpenBTS, and if not, where is the one that is? Thanks, Rad. |
From: David A. B. <dbu...@jc...> - 2010-03-23 22:16:40
|
Rad - As far as I know, GNU Radio can't find the .v files used to generate usrp_inband.rbf. My understanding is that the _usb.v file you name below is the closest match that anyone knows of. Sorry I can't be of more help there. This FPGA image also has some serious bugs related to the handling of the transmission FIFO, so we will eventually replace it entirely. -- David On Mar 23, 2010, at 12:20 PM, Rad wrote: > Sorry for replying to my own post, but just to clarify.. although I am > able to use Quartus to generate "usrp_std.rbf", which works correctly, > my attempts to generate the "usrp_inband.rbf" using the > "usrp/fpga/toplevel/usrp_inband_usb/usrp_inband_usb.v" verilog have > failed so far. The resulting rbf loads OK, but OpenBTS on the USRP > does > not generate any RF. It is also different in size to the one provided > with GNURadio/OpenBTS which leads me to this that there is a different > verilog file being used. > > Can anyone provide an answer to whether "usrp_inband_usb.v" is the > file > used to create the FPGA load used by OpenBTS, and if not, where is the > one that is? > > Thanks, > Rad. > > > ---------------------------------------------------------------------- > -------- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Openbts-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-discuss David A. Burgess Kestrel Signal Processing, Inc. |
From: Rad <ra...@mo...> - 2010-03-23 23:47:33
|
David, > GNU Radio can't find the .v files used to generate usrp_inband.rbf Sorry, not sure what you mean. Is it that the GNU Radio folks did not create the inband verilog, or that somewhere along the way it's been lost? Surely someone must have the original verilog or know who made it..? Replacing it to iron out any bugs is going to be tricky. If this is the case, has anyone got the "_usb.v" file working with OpenBTS ? Thanks, Rad. |
From: David A. B. <dbu...@jc...> - 2010-03-23 23:53:56
|
Rad - They can't find it. Apparently, it was some obscure branch that the developers lost track of. -- David On Mar 23, 2010, at 4:47 PM, Rad wrote: > David, > > > GNU Radio can't find the .v files used to generate usrp_inband.rbf > > Sorry, not sure what you mean. Is it that the GNU Radio folks did > not create the inband verilog, or that somewhere along the way it's > been lost? Surely someone must have the original verilog or know > who made it..? Replacing it to iron out any bugs is going to be > tricky. If this is the case, has anyone got the "_usb.v" file > working with OpenBTS ? > > Thanks, > Rad. David A. Burgess Kestrel Signal Processing, Inc. |