[USRP-users] Loading USRP X3x0 by baseband processing functions

Marcus Müller marcus.mueller at ettus.com
Wed Oct 15 04:56:23 EDT 2014


Hi Birhane,

sorry, I can't tell you what your host must look like for your specific
application, because that is a crucial part of your job as an
application designer, and I don't know how much processing power you'll
need for that task. Simply go for workstation as fast as you can afford[1].

Greetings,
Marcus

[1] Assuming you don't want to wait days on your X3x0 FPGA image to be
generated, you'll have workstation around that has a vast amounts of RAM
and quite possibly a high-performance RAID, and that will be a good
starter for beginning your development on. Upgrade later if necessary.

On 15.10.2014 10:38, Birhane Alemayoh wrote:
> Dear Marcus,
>
>
>
> On Tue, Oct 14, 2014 at 9:15 AM, Birhane Alemayoh <birhanea at gmail.com>
> wrote:
>
>> Dear Marcus,
>> Thank you so much, Your ideas and links are very helpful1
>>
>> On Thu, Oct 9, 2014 at 8:19 PM, Marcus Müller <marcus.mueller at ettus.com>
>> wrote:
>>
>>> Hi Birhane,
>>>
>>> On 09.10.2014 19:04, Birhane Alemayoh wrote:
>>>>> However, a complete GSM stack is a big thing, and I don't see much use
>>> in
>>>>> implementing it in FPGA rather than host code, especially since
>>> working GSM
>>>>> base stations already exist (openBTS).
>>>>>
>>>> My system is supposed to capture and process downlink and uplink GSM
>>>> signals in real time from the air using this X310 device.
>>> OpenBTS [0] does that with USRPs on a host.
>>>>  My system is
>>>> shall work under frequency hopping environment which requires strict
>>> real
>>>> time requirement.
>>> Works.
>>>> We believe that this requirement is difficult to handle
>>>> by processing the signal in the host.
>>> It is. But it has been done :)
>>>> This is the reason why we prefer to
>>>> write FPGA code.
>>> Wow, that's dedication. I'd *definitely* spend more time making sure
>>> things can't be done in host code than spending manyears of development
>>> on FPGA hardware.
>>> Since you're asking us for advice, I'd expect you / your company to be
>>> not very experienced in the implementation of communication standards on
>>> FPGAs -- deciding early you want to do *everything* in the FPGA this
>>> early into your development doesn't sound very wise. Re-inventing the
>>> wheel actually sounds bad. And not looking up the capabilities of
>>> openBTS with USRPs instead of believing requirements are hard to meet
>>> with software sounds like a mistake, but one that is easily corrected ;)
>>>
>>>> So what do you comment/recommend for this?
>>> Doing what all the industry has been doing for 20 years: Doing only the
>>> really necessary part of processing in hardware, and moving higher level
>>> functionality to general purpose processors.
>>
> One more question please!
> You told me that implementing most of the signal processing is preferred in
> the host PC. However, my requirement is to capture and process multiple
> simultaneous GSM conversations (uplink and downlink) from the air. This
> could be up to 8 different ARFCN channels in which each channel has 8 time
> slots according to the GSM standard.  Basically what we are doing is
> implementing GSM interception using the open software and hardware
> technologies.  So what should be the performance or specification of the
> host PC?
> Thank you again!
>
>
>> Seriously, look at the
>>> Osmocom BB project [1]: Even the Motorola C115 [2] brick of a cheap
>>> consumer mobile phone does its baseband processing in software.
>>> Seriously, I think it will be easier to instantiate a general purpose
>>> CPU in the FPGA and just run the baseband processing software on there
>>> rather than doing everything in real FPGA hardware.
>>>> Thank you
>>> Hope you find the links I share helpful!
>>>
>>> Greetings,
>>> Marcus
>>> [0]http://openbts.org/
>>> [1]http://bb.osmocom.org/trac/
>>> [2]http://www.gsmarena.com/motorola_c115-876.php
>>>
>>
>>
>> --
>>
>>
>>





More information about the USRP-users mailing list