Forum: GNU Radio A low-budget SDR - Was: PCIe know-how?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
3b436e190903d3e9b48cad2dfd262a23?d=identicon&s=25 unknown (Guest)
on 2007-03-05 19:12
(Received via mailing list)
On 3/5/07, Brian Padalino <bpadalino@gmail.com> wrote:
> Power over Ethernet (PoE) can supply almost 13W of power (maximum).  I
> am not sure if that is really an option or being considered for the
> next USRP, but it is a potential solution for delivering power to
> remote devices.
>
>   http://en.wikipedia.org/wiki/Power_over_Ethernet
>
> > It's a solution superior to PCIe in every way.
>
> PCIe still has an advantage of much higher speeds and much lower
> latency.  On the flip side, you can't put it 100m away.

Yeah, I thought about PoE too, but I got the impression implementation
isn't that common. Or is it common? If it is, we'd once again save
some complexity and therefore money by using it.

I've set up a blog to begin collecting the ideas. Located here:

http://guerillasdr.blogspot.com/

--
Nos
79723aa1b24981dcec2dbf7fd59403c1?d=identicon&s=25 Brian Padalino (Guest)
on 2007-03-05 19:26
(Received via mailing list)
On 3/5/07, ceriel@gmail.com <ceriel@gmail.com> wrote:
> Yeah, I thought about PoE too, but I got the impression implementation
> isn't that common. Or is it common? If it is, we'd once again save
> some complexity and therefore money by using it.

I don't think it's that common, but you can buy what are called
midspans which are in-line with ethernet cables and supply the power.
Therefore, if the host to the peripheral doesn't have PoE available,
the midspan gets put in there and supplies the power.

One that supports gigabit ethernet can be found here:

    http://www.powerdsine.com/Products/Midspan/PD_3001.asp

As for complexity - it doesn't necessarily get simpler because of
that.  You need to get a chip that will handle all the arbitration of
doing PoE and do the DC/DC conversion for you.  TI has one, and is
cheap ($1.50 I believe) - but it still adds to the BOM and to your PCB
size.

> I've set up a blog to begin collecting the ideas. Located here:
>
> http://guerillasdr.blogspot.com/
>
> --
> Nos
>

Brian
3b436e190903d3e9b48cad2dfd262a23?d=identicon&s=25 unknown (Guest)
on 2007-03-05 21:31
(Received via mailing list)
On 3/5/07, Brian Padalino <bpadalino@gmail.com> wrote:
> One that supports gigabit ethernet can be found here:
>
>     http://www.powerdsine.com/Products/Midspan/PD_3001.asp
>
> As for complexity - it doesn't necessarily get simpler because of
> that.  You need to get a chip that will handle all the arbitration of
> doing PoE and do the DC/DC conversion for you.  TI has one, and is
> cheap ($1.50 I believe) - but it still adds to the BOM and to your PCB
> size.

(Found the Reply to All button!)

A fellow calling himself Kim posted this link in a comment to the blog:
http://tinyurl.com/3dhmb6

Seems there's an option for adjustable voltage on some, but I'm not
sure how useful that is unless we manage getting all components using
the same voltage. I think it's best to defer judgment on the issue for
now.

I suspect the best design method would be to look at the most
expensive issues first, make those cheaper and then design the rest
around that. The FPGA, ADC and PCB seem to be the most expensive parts
right now. I can't say anything about the PCB yet, but the
dimensioning of the ADC and FPGA would be an issue of what we can get
away with and still have an SDR. The dimensioning of the FPGA depends
on the ADC, so the ADC should be the first issue to be dealt with.

A high SINAD and SNR value for the ADC seems to be important at any
rate, regardless of bit-count, but those values still seem to be
proportional to how many bits of accuracy it has. Low jitter is
apparently also important. The LTC1742 seems attractive in that regard
and the price isn't that terrible either, but it's a 14bit device.
The ADC12C065 and ADC12DS065 are 12 bits, but I don't know National's
price on those. They seem to support undersampling up to 1GHz. If we
could use that, we'd have a pretty awesome radio.
Analog Devices' AD9235 is really cheap and seems to support
undersampling to 500MHz, which is pretty cool too. More than I need at
any rate.

There are of course other manufacturers to consider, but I feel this
is a good start at the very least. Gives an idea what we're dealing
with.


I think the step after deciding on the ADC  would be to dimension the
FPGA by deciding what code it needs to run. It will have to deal with
a bit of Ethernet, and stuffing all the data from the ADC into the
frames. Of course that's not all, but right now it seems that will be
its most taxing task, so it should be spec-ed to be able to deal with
that. I have no idea what those specs are. Guess I'll have to learn
Verilog before I can start guesstimating.

Better post this in the blog too...

Thanks for reading! =)

--
Nos
79723aa1b24981dcec2dbf7fd59403c1?d=identicon&s=25 Brian Padalino (Guest)
on 2007-03-05 22:05
(Received via mailing list)
On 3/5/07, ceriel@gmail.com <ceriel@gmail.com> wrote:
> (Found the Reply to All button!)
>
> A fellow calling himself Kim posted this link in a comment to the blog:
> http://tinyurl.com/3dhmb6
>
> Seems there's an option for adjustable voltage on some, but I'm not
> sure how useful that is unless we manage getting all components using
> the same voltage. I think it's best to defer judgment on the issue for
> now.

I believe the standard has -48VDC going out which then gets converted
to whatever voltage your regulators create for you.  The TPS23750 is
what I must have been thinking of - fully isolated 3.3v DC coming out
of the other side with auto negotiation of the PoE interface.

Then if you needed 1.8v or 2.5v - it wouldn't be as efficient but
throwing some regulator on there wouldn't be too bad.

> proportional to how many bits of accuracy it has. Low jitter is
> apparently also important. The LTC1742 seems attractive in that regard
> and the price isn't that terrible either, but it's a 14bit device.
> The ADC12C065 and ADC12DS065 are 12 bits, but I don't know National's
> price on those. They seem to support undersampling up to 1GHz. If we
> could use that, we'd have a pretty awesome radio.
> Analog Devices' AD9235 is really cheap and seems to support
> undersampling to 500MHz, which is pretty cool too. More than I need at
> any rate.

That Analog Devices AD9235-65 looks like it's good if you want to
sample at something like the USRP is doing right now - 64MHz.  So what
you'd be looking at is an oscope with a 500MHz bandwidth and a 64MSPS
sampling rate.  You could possibly double that if you did some
cascading of the ADCs and used the opposite edge of the clock to also
clock into a different ADC - giving you (effectively) double the
samples per second.

Which brings me to another important feature which is the clocking.
To get a good representation of your incoming signal, you should have
a pretty good reference clock with a VCXO or VCTCXO - especially if
you want to do that high IF sampling.  Those signals are moving so
quick, you really need a super stable reference to nab them at the
right time, otherwise your aliased image has a bit more noise.

> that. I have no idea what those specs are. Guess I'll have to learn
> Verilog before I can start guesstimating.

If all you want to do is take the ADC data and shove it off to the PC
to process, you need a really small FPGA that has just a few block
rams in it to store for FIFOs.

If you wanted to do more signal processing within the FPGA, you should
look more towards a mid-sized low-end FPGA (Spartan 3E, Cyclone II,
Lattice Semi) with embedded multipliers.  An XC3S500E should run you
around $20 and have a good amount of resources in there to run your
gigE interface state machine and do some filtering - possibly an FFT
or two as well.

Learning Verilog should take a back seat to understanding your receive
chain and how you want to process your incoming signals.  Are you
going to try to really process everything on the host side of things,
or would you like different FPGA loads to be able to reduce down that
massive data exchange and process less on your host?

Parts are available for all different prices - but be sure to solve
your problem and not just put together something that has a kitchen
sink.  You had wanted an oscope / spectrum analyzer / SDR.  Is 500MHz
bandwidth good enough for you?  Do you want more?  Is 64MSPS the
digitizing rate you want to hit?  What range and resolution bandwidths
do you want for your spectrum analyzer?  0-10MHz at 1kHz RBW?

Listing out your requirements / wish list might be a good idea before
just saying you want to build this generic cheap SDR board.

> Better post this in the blog too...
>
> Thanks for reading! =)
>
> --
> Nos

Brian
08ef15f7d19f6dd445164f802e6ff091?d=identicon&s=25 Kim Toms (Guest)
on 2007-03-06 02:38
(Received via mailing list)
I for a long time wanted to design a device that was an ethernet jack on
one
side and an RS-232 DB-25 on the other (long story).  These devices
exist,
but they are large - I wanted one that I could screw onto the DB-25
avoiding
the cost of the cabling.  TI made a small board that included the whole
power supply.  A problem was that I needed an isolated supply, which
took
more stuff.  Since the interface here is an antenna, there is no need
for an
isolated supply, making the design simpler.  I was also planning on
using
the Dallas 80C400 8051 like ethernet controller.  See the TI
http://focus.ti.com/docs/prod/folders/print/ptqa420050.html, for the
isolated example.  Unfortunately, it is $35.
3b436e190903d3e9b48cad2dfd262a23?d=identicon&s=25 unknown (Guest)
on 2007-03-06 21:12
(Received via mailing list)
On 3/5/07, Brian Padalino <bpadalino@gmail.com> wrote:
> On 3/5/07, ceriel@gmail.com <ceriel@gmail.com> wrote:
> > (Found the Reply to All button!)

<snip>
> To get a good representation of your incoming signal, you should have
> a pretty good reference clock with a VCXO or VCTCXO - especially if
> you want to do that high IF sampling.  Those signals are moving so
> quick, you really need a super stable reference to nab them at the
> right time, otherwise your aliased image has a bit more noise.

Yeah, that indeed is an important issue that needs a very detailed and
thought-out solution. One thing I'd like to be able to do some day is
have maybe three of these devices all 100 meters from my computer
arranged in a triangle and then triangulate signals using the Time of
Arrival principle. I might be able to eventually construct an antenna
array that isn't just directional, but also aware of distance. 65Msps
wouldn't be enough for useful resolution, but it's a start. :)

I would have to co-ordinate the receivers exactly to do this... Could
it be possible to supply a stable clock over Ethernet? Couple it to
the -48VDC? =)

>
> digitizing rate you want to hit?  What range and resolution bandwidths
> do you want for your spectrum analyzer?  0-10MHz at 1kHz RBW?
>
> Listing out your requirements / wish list might be a good idea before
> just saying you want to build this generic cheap SDR board.

I think that, realistically, I will have to do something with the data
already at the FPGA. Be it pre-processing or decimation I do not know
yet, nor can I guesstimate due to lack of experience. PA3FWM in the
link Henry posted managed to deal with 2.5Msps, but I don't know his
bit rate. I've decided in the past that I would be happy with being
able to see just 1MHz of bandwidth at the time, and PA3FWM seems to
have exceeded that. The benefit of using a high-speed ADC in this case
would not be voided, since we could still do a lot of mojo that one
can't do with a radio that requires a tuner. The lack of tuner in
itself makes the device cheaper too...

And what's "RBW"? =)

--
Nos
79723aa1b24981dcec2dbf7fd59403c1?d=identicon&s=25 Brian Padalino (Guest)
on 2007-03-06 21:25
(Received via mailing list)
On 3/6/07, ceriel@gmail.com <ceriel@gmail.com> wrote:
> the -48VDC? =)
I highly doubt that you can do it over ethernet, but you may be able
to supply a 10MHz reference clock over a coax line that could drive
some sort of PLL that were highly stable?  I am not a clocking expert,
so you're a bit on your own.

>
> And what's "RBW"? =)

Resolution Band Width - how accurate your FFT bins are.

>
> --
> Nos

On a side note - have you thought about trying to figure out what you
want to do in a simulation environment?  It might be worth while to
simulate a channel that has your desired signals in it, and see how
feasible it would be to actually accomplish such a thing.

Moreover, if you plan on having your entire front end open, have you
thought about the consequences of large signals saturating your ADC
and not allowing the rest of your band in?  Without a tuner and
filters, you are going to be a bit more susceptible to saturating your
ADC - possibly with unwanted signals.

Brian
3b436e190903d3e9b48cad2dfd262a23?d=identicon&s=25 unknown (Guest)
on 2007-03-06 21:47
(Received via mailing list)
On 3/6/07, Brian Padalino <bpadalino@gmail.com> wrote:
> > it be possible to supply a stable clock over Ethernet? Couple it to
> > link Henry posted managed to deal with 2.5Msps, but I don't know his
>
> thought about the consequences of large signals saturating your ADC
> and not allowing the rest of your band in?  Without a tuner and
> filters, you are going to be a bit more susceptible to saturating your
> ADC - possibly with unwanted signals.

Yes, I thought about simulations today. Apparently Verilog is designed
to facilitate that aswell.
Should I do these simulations with for example Altera's Quartus II?

And indeed I've thought about saturating the ADC. I first thought
about a varistor for the sole  purpose of protecting it from voltage
spikes, but I realized that it could cause clipping, which would look
like overmodulation and could drown signals in noise.
One of the High Speed Data Transfers videos behind the link I posted
in the blog mentions a circuit I could use to condition the input
before it reaches the ADC, and it also mentions a balun very, very
briefly. I think of all of this as the RF frontend, and a problem I
don't need to solve yet. The RF frontend should be designed to allow
for undersampling too, so it's far from straight-forward. I think I'll
be designing it or looking for existing designs as the last thing,
because it is so important.

--
Nos
79723aa1b24981dcec2dbf7fd59403c1?d=identicon&s=25 Brian Padalino (Guest)
on 2007-03-06 21:51
(Received via mailing list)
On 3/6/07, ceriel@gmail.com <ceriel@gmail.com> wrote:
> Yes, I thought about simulations today. Apparently Verilog is designed
> to facilitate that aswell.
> Should I do these simulations with for example Altera's Quartus II?

If you want to simulate Verilog, there are free tools available along
with an Altera ModelSim version that is also "free" from their
website.

To clarify, I didn't mean FPGA/hardware simulations, but more like a
high level GNU Radio block level simulation.  Taking a bunch of
signals and creating a pseudo channel that you may encounter,
truncating to an ADC value, filtering, etc.  Just to see what kind of
performance you were looking for.

Brian
3b436e190903d3e9b48cad2dfd262a23?d=identicon&s=25 unknown (Guest)
on 2007-03-06 21:57
(Received via mailing list)
On 3/6/07, Brian Padalino <bpadalino@gmail.com> wrote:
> high level GNU Radio block level simulation.  Taking a bunch of
> signals and creating a pseudo channel that you may encounter,
> truncating to an ADC value, filtering, etc.  Just to see what kind of
> performance you were looking for.

Ooh! I didn't know that was possible. =D

I'll install Ubuntu again first thing tomorrow when I get back from
work and give it a try. Now, bedtime. :)

Once again, thank you for your reply.

--
Nos
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2007-03-06 23:07
(Received via mailing list)
On Tue, Mar 06, 2007 at 10:46:49PM +0200, ceriel@gmail.com wrote:
> for undersampling too, so it's far from straight-forward. I think I'll
> be designing it or looking for existing designs as the last thing,
> because it is so important.
>
> --
> Nos

FYI, there's a discussion on front-end protection taking place right
now on the hpsdr list.  Lots of clueful discussion, including parts
selection, etc.

Here's the head of the thread:
http://lists.hpsdr.org/pipermail/hpsdr-hpsdr.org/2...

Eric
1b23ff56ba31369aa63ce2103709143f?d=identicon&s=25 Henry Vredegoor (Guest)
on 2007-03-07 03:31
(Received via mailing list)
Hi All, Nos,

If I remember your initial design goals correctly:

100 Msamples/second (for a receiver bandwidth of 0 - 50 MHz)
16 bits/sample

If my simple, rough, calculation is right this would give you a minimum
bitstream over Gigabit Ethernet of:

16 * 100 M = 1600 Mbit/s or 1.6 Gbit/s !! Excluding protocol overhead.

Well over 1 Gbit/s!
So you have to do something to reduce this I suppose! ;-]

- Reducing the number Bits/sample will cost you dynamic range
- Reducing sample rate will cost you receiver bandwidth) (no
undersampling)

So you have to do DDC or some clever data compression in the remote
device.....

Henry.
Cf1f87de124043f2da6c95cfc293358e?d=identicon&s=25 Eric A. Cottrell (Guest)
on 2007-03-17 17:02
(Received via mailing list)
Brian Padalino wrote:
>> I would have to co-ordinate the receivers exactly to do this... Could
>> it be possible to supply a stable clock over Ethernet? Couple it to
>> the -48VDC? =)
>
> I highly doubt that you can do it over ethernet, but you may be able
> to supply a 10MHz reference clock over a coax line that could drive
> some sort of PLL that were highly stable?  I am not a clocking expert,
> so you're a bit on your own.
Hello,

You may be able to use IEEE 1588 precision time protocol (PTP) over the
Ethernet to provide time stamps for on-board clock synchronization.

73 Eric
This topic is locked and can not be replied to.