Considerations for new hardware in gnuradio

GNU Radio
1

I heard about gnuradio since a year ago, and well realize the power of
the power o software combined with especific hardware
like URSP could make awesome things in radio astronomy, GSM networks
researh, Ham radio and so on.

But i also discover (may be i’m wrong) that the only avaliable proven
hardware to work with is URSP, wich is a great device but is the only
one out there.

I’m writing here to as about hardware the requirements/steps to a
hardware be considered a posible new device to be integrated in
gnuradio.

But also i want to introduce a copyleft board called SAKC [1], wich in
general terms is a SoC chip plus a spartan3E fpga plus IO,
surely is too short description so here is a block diagram to chek [2].
As you can see there is no ADC DAC modules yet, but may be you can
suggest one,
and review this board as a possible gnuradio new hardware. And in the
ways support copyleft hardware devices. And knows also copyleft gnuradio
ASICS :slight_smile:

I’m not a hardware or sofware developer, i’m just learning from all this
projects so dont blame me if i used a wrong term.
But i’m conviced of the importance of having our own free/libre software
and coplyeft hardware. [3]

Thats all, i’ll waiting for your answers/comments that also will be
forwarded to qi-hardware devel list.

Saludos

Cristian Paul

[1] SIE - Qi-Hardware
[2] Block Diagram - Qi-Hardware
[3] Copyleft Plans - Qi-Hardware

2

Short but sweet response. It would be great to have a SDR hardware
board
that works with GNU Radio that has a very, very, low latency connection
to
the host, like PCI express. Similar to the Microsoft Research SDR
(previously named SORA). That would be great and open up possibilities
of
low latency MAC protocol implementations.

Just sayin’!

  • George
3

On 03/29/2010 11:13 PM, George N. wrote:

Short but sweet response. It would be great to have a SDR hardware
board that works with GNU Radio that has a very, very, low latency
connection to the host, like PCI express. Similar to the Microsoft
Research SDR (previously named SORA). That would be great and open up
possibilities of low latency MAC protocol implementations.

Just sayin’!

  • George
    More bandwidth == definitely_better

But IM(PNS)HO you don’t want receiver cards living inside a PC cabinet.
Which is why I like the
USRP “remote” philosophy.

I’m thinking about doing some hardware myself, for the specific purpose
of radio astronomy:

o integrated LNA/downconverter/sampler
o common LO/sample-clock for all antenna
o 1GiGE, probably using a compact (4-bit) coding to improve channel

bandwidth

This would appeal to only a small fraction of all Gnu Radio users, to be
sure.

But there are some themes that are common to other applications:

o robust phase coherence  (any kind of aperture synthesis requires

this)
o high bandwidth (sometimes at the expense of code bits)

Fit in a tighter cost envelope. :slight_smile:

–

Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

4

The ability to drop bits off in hardware would be a great feature, at
the moment I have three high end digitizers and could double my
bandwidth/ or quadruple if they had this feature.

Most astronomy applications can get away with 2 bits, 4 nice, and 8 is a
waist, I have several applications that our USRP2 would be perfect for
if we could get rid of bits in the FPGA, with out being FPGA
programmers.

From:
discuss-gnuradio-bounces+bruce.stansby=removed_email_address@domain.invalid
[discuss-gnuradio-bounces+bruce.stansby=removed_email_address@domain.invalid]
on behalf of Marcus D. Leech [[email protected]]
Sent: Tuesday, 30 March 2010 1:10 PM
To: [email protected]
Subject: Re: [Discuss-gnuradio] Considerations for new hardware in
gnuradio

On 03/29/2010 11:13 PM, George N. wrote:

Short but sweet response. It would be great to have a SDR hardware
board that works with GNU Radio that has a very, very, low latency
connection to the host, like PCI express. Similar to the Microsoft
Research SDR (previously named SORA). That would be great and open up
possibilities of low latency MAC protocol implementations.

Just sayin’!

  • George
    More bandwidth == definitely_better

But IM(PNS)HO you don’t want receiver cards living inside a PC cabinet.
Which is why I like the
USRP “remote” philosophy.

I’m thinking about doing some hardware myself, for the specific purpose
of radio astronomy:

o integrated LNA/downconverter/sampler
o common LO/sample-clock for all antenna
o 1GiGE, probably using a compact (4-bit) coding to improve channel

bandwidth

This would appeal to only a small fraction of all Gnu Radio users, to be
sure.

But there are some themes that are common to other applications:

o robust phase coherence  (any kind of aperture synthesis requires

this)
o high bandwidth (sometimes at the expense of code bits)

Fit in a tighter cost envelope. :slight_smile:

–

Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

5

Hi All,

If we had an fpga image that allowed us to store samples on the USRP2
that would be very benefitial, at least for me. Then one could test
algorithms with 100MHz sample-rate. Yes, it would not be possible to
use the channel continously. Receiving 1ms of samples would take 4ms to
upload. However, using the time-stamp functionality one can synchronize
nodes to transmit and receive at the same time and thereby enable
testing e.g. interference rejection algorithms.

BR/
Per

Quoting George N. [email protected]:

6

That memory would be enough to capture 2.5ms at 100MHz if I calculate
correctly (1e6/(100e6*4)). I could do with less.

BR/
Per

7

If we had an fpga image that allowed us to store samples on the USRP2
that would be very benefitial, at least for me. Then one could test
algorithms with 100MHz sample-rate. Yes, it would not be possible to
use the channel continously. Receiving 1ms of samples would take 4ms
to upload. However, using the time-stamp functionality one can
synchronize nodes to transmit and receive at the same time and thereby
enable testing e.g. interference rejection algorithms.

We have an FPGA-based platform for channel sounding and signal
reception at 100MHz with requirements similar to the one you’ve
described. We’re willing to release the code (FPGA and host-side) if
there’s interest in porting it over to the USRP hardware and the
gnuradio project.

As a sidenote, we are also in the process of implementing a gnuradio API
anticipated to be working in the next month or so. We’ll be making it
public in the next couple of weeks and would appreciate input.

8

Per-

If we had an fpga image that allowed us to store samples on the USRP2
that would be very benefitial, at least for me. Then one could test
algorithms with 100MHz sample-rate. Yes, it would not be possible to
use the channel continously. Receiving 1ms of samples would take 4ms to
upload. However, using the time-stamp functionality one can synchronize
nodes to transmit and receive at the same time and thereby enable
testing e.g. interference rejection algorithms.

How many samples? I think the USRP2 has a 512k x 16 (1 Mbyte) SRAM
that’s not used in the default FPGA image.

-Jeff