To prevent damages

hi,
I’ve just been reading the thread about the broken RX board.
some days ago I’ve just denied to one of my fellows the permission to
connect an amplified HF antenna to the LFRX for fear it could overload
the input…we used a passive half-wave (@ band centre) dipole
instead.

just to be sure about what we can or cannot do with our fantastic piece
of hardware, is there anything published detailing exactly what we must
avoid and what we can feel free to do?

thanks

vincenzo

It might not be a bad idea for Ettus R. to also stock some other
items such as SMA cables/adapters/attenuators.

It might also be handy to have some nice block diagrams with max power
recommendations and recommended attentuations for cabled setups as
well as a table in the Wiki with such recommendations.

That might save some of the more software oriented people from burning
out their hardware without intentionally doing so.

On 9/27/06, Brian P. [email protected] wrote:

It might not be a bad idea for Ettus R. to also stock some other
items such as SMA cables/adapters/attenuators.

Attenuators might a good idea. I think a model to match the 100mW
transmitters would be Mini-Circuits’ VAT-15 (50 ohm, SMA, 1W, 15dB,
usable up to 4GHz) if I’ve done my loss calculations correctly
<www.mini-circuits.com>. A 9 or 6 dB for the BasicTX should be usable
if I haven’t messed up my calculations.

It might also be handy to have some nice block diagrams with max power
recommendations and recommended attentuations for cabled setups as
well as a table in the Wiki with such recommendations.

Here is what I think the calculation is:

transmit power converted to dBm (1 dBm == 1 mW) minus the attenuator
loss = output power in dBm.

E.g.
100 mW -> 20dBm
20dBm - 15 db att = 5 dBm
5 dBm -> 3.2 mW

So if the receiver can handle 3.2 mW input, this would be adequate
attenuation. Off hand I don’t know what is acceptable input power
range.

dBm ref: http://en.wikipedia.org/wiki/DBm

That might save some of the more software oriented people from burning
out their hardware without intentionally doing so.

Agreed.

Matt E. wrote:

0 dBm, or 1 mW into a receiver will not damage it.
Matt
Under ordinary conditions, a radio receiver receiving a 0dBm signal
would be close
to overload, but not in “input amplifier damage” territory.

You average FM radio receiver is quite happy receiving a few microwatts
(-30dBm or less), and
producing a quite-acceptable demodulated signal.

In my application, a few microwatts is burning-the-house-down strong :slight_smile:

Vincenzo P. wrote:

hi,
I’ve just been reading the thread about the broken RX board.
some days ago I’ve just denied to one of my fellows the permission to
connect an amplified HF antenna to the LFRX for fear it could overload
the input…we used a passive half-wave (@ band centre) dipole
instead.

That should not be a problem.

just to be sure about what we can or cannot do with our fantastic piece
of hardware, is there anything published detailing exactly what we must
avoid and what we can feel free to do?

0 dBm, or 1 mW into a receiver will not damage it.

Matt

transmit power converted to dBm (1 dBm == 1 mW) minus the attenuator
loss = output power in dBm.

E.g.
100 mW -> 20dBm
20dBm - 15 db att = 5 dBm
5 dBm -> 3.2 mW

Actually, I think 0 dBm = 1 mW.

dB’s are a royal pain in the butt. They eluded me for years because
they required a lot of rote memorization and made no sense. For those
of us not pickled in radio-speak from an early age, but who know basic
algebra, there’s a simple way to deal. Ignore deciBels. Use Bels.

Bels are easy and obvious. They’re a straight logarithmic scale in Base
10.
100 mW is 2 Bm. 10 mW is 1 Bm. 1 mW is 0 Bm. 0.1 mW is -1 Bm.

DeciBels are just tenths of a bel. So if you shift the decimal point
one place, you’re suddenly calculating in an easy to use notation.
Here’s the above calculation in Bels:

100 mW -> 2 Bm
2 Bm - 1.5 B att = 0.5 Bm
0.5 Bm -> 10 to the 0.5 power -> the square root of 10 -> about 3.2 mW

See, now you not only know the answer, but you know WHY “5dBm” is 3.2
mW.

Why the EE universe settled on doing everything in tenths of a
logarithmic unit is way beyond me. It’s as if every carpenter figured
every length in deciInches or decimeters, even if inches, kilometers
or meters would be the more straightforward unit. How often do you
calculate in decivolts, deciwatts, or decimeters per second per
second?

The rumor is that decibels were invented because somebody at Bell Labs
couldn’t cope with decimal points or negative numbers, in the days when
equipment wasn’t capable of dealing with large orders of magnitude
(e.g. the painful-to-someone 0.3 Bel became the friendly-to-someone 3
deciBel). Of course, now that people regularly see 5 to 10 orders of
magnitude (5 to 10 Bels) (50 to 100 deciBels) (factors of 10000 to 10
billion) in ratios, such as in radar, digital signal processing, or
fiber optics, the “deci” has just become a hindrance.

You can do your part to clear up this idiocy by using Bels in most
places where the lemmings use deciBels. You may actually get them to
think (briefly).

John

PS: Don’t even get me started about why dBm’s aren’t referenced to
watts rather than milliwatts! Since a “milli” is 1/1000th and that’s
just 3 orders of magnitude, referencing to ordinary watts would merely
involve subtracting 3 or 30 from the number, e.g. 40 dBm = 4 Bm = 1 BW
= 10 dBW. It reminds me of how we’re still calculating speeds in
5280-foot units per 3600-second units rather than in some sane system
using basic decimal units. Actually using BW notation in your
thinking and writing may overload lemming brains, though.

It don’t see how this makes the calculation of RF power any easier, to
the
contrary it confuses the issue.

cheerio Berndt

I have to say that I like dBs, too. All you have to do is remember two
things: 3dB doubles the power, and 10dB is 10 times the power, and from
that you can SWAG just about anything.

John

Berndt Josef W. said the following on 09/28/2006 07:26 PM:

A spreadsheet could work just the same without all the Tcl/Tk
silliness or input verification problems.

On Friday 29 September 2006 09:21, John Ackermann N8UR wrote:

I have to say that I like dBs, too. All you have to do is remember two
things: 3dB doubles the power, and 10dB is 10 times the power, and from
that you can SWAG just about anything.

A guy at work wrote a handy program in Tcl/Tk for converting power
between
various units (dBm, mW, Volts & Pk-Pk Volts).

Might be worth writing a Python version for GNU Radio - it would be
pretty
simple I think.

You could open Google Spreadsheets in the web browser you’ve probably
already got open. Not only that, but you can share it with your
buddies for collaborative editing so everyone can use it!

Or you could just write a bc script to to handle it. That uses much
less memory, I am sure.

Or we could ask Google to build it into their calculator function so
you can just type “200 dB in mW” and it would do the conversion for
you!

I wasn’t trying to be a jerk, but I have noticed that spreadsheets are
much better at converting data to a visual format as well as extending
a dataset you might be building and doing some visual interpretations.
There’s always more than one way to skin a cat, as GNURadio is all
about.

I guess this is the difference big between RF engineers and academics -
applied versus theory. Spreadsheets can help in doing
conversion/calculations
but doesn’t stop people from using these values out of context as for
this
you need to know what you’re doing.

BTW: I do these calculations in my head - pretty much primary school
stuff
really.

cheerio Berndt

On Friday 29 September 2006 10:13, Brian P. wrote:

A spreadsheet could work just the same without all the Tcl/Tk
silliness or input verification problems.

Yeah, a spreadsheet, so lightweight compared to a memory hungry Tcl/Tk
application.

12623 radar 1 103 0 11972K 6068K select 0:00 3.97%
wish8.4
12643 darius 6 20 0 120M 72048K kserel 0:07 0.00%
soffice.bin

cough

Not sure what you mean about input verification.

On Friday 29 September 2006 11:49, Berndt Josef W. wrote:

BTW: I do these calculations in my head - pretty much primary school stuff
really.

Yeah, depends what level of accuracy you need though :slight_smile:

On Friday 29 September 2006 11:33, Brian P. wrote:

You could open Google Spreadsheets in the web browser you’ve probably
already got open. Not only that, but you can share it with your
buddies for collaborative editing so everyone can use it!

Or write it in javascript…

Or you could just write a bc script to to handle it. That uses much
less memory, I am sure.

Lacks flexibility.

Or we could ask Google to build it into their calculator function so
you can just type “200 dB in mW” and it would do the conversion for
you!

Kind of slow.

I wasn’t trying to be a jerk, but I have noticed that spreadsheets are
much better at converting data to a visual format as well as extending
a dataset you might be building and doing some visual interpretations.
There’s always more than one way to skin a cat, as GNURadio is all
about.

Spreadsheets take too long to load, we already have tcl/tk stuff running because our radar uses it.

Presumably a Python version would be good for GNURadio since you’d
already be
using it :slight_smile:

On Friday 29 September 2006 12:03, Daniel O’Connor wrote:

On Friday 29 September 2006 11:49, Berndt Josef W. wrote:

BTW: I do these calculations in my head - pretty much primary school
stuff really.

Yeah, depends what level of accuracy you need though :slight_smile:

How accurate do you need it… :slight_smile:

cheerio Berndt

On Friday 29 September 2006 12:33, Brian P. wrote:

I am really surprised on how you guys are so anti-spreadsheets.

A lot of the RF engineers where I work like using them when designing
their receive and transmit chains for calculating tolerances and all
sorts of noise figures.

One even modeled the front end amplifier gain stages for which DAC
values should be used at each input power over our 75 dB of gain so
when I wrote the FPGA module to actually do the AGC we could compare
my simulation results with their ideal gain for any given input.

This sort of thing makes perfect sense for a spreadsheet.

Our RF engineer uses them for working out receiver gain distribution and
other
things.

We use the Tcl/Tk program for doing stuff like calculating output power
of a
transmitter as you look at the scope on its sniff port… much faster
than
loading a spreadsheet :slight_smile:

Languages like Tcl are very easy to program even for novice coders
(like our
RF engineer :slight_smile: and are usually very portable as well.

I am really surprised on how you guys are so anti-spreadsheets.

A lot of the RF engineers where I work like using them when designing
their receive and transmit chains for calculating tolerances and all
sorts of noise figures.

One even modeled the front end amplifier gain stages for which DAC
values should be used at each input power over our 75 dB of gain so
when I wrote the FPGA module to actually do the AGC we could compare
my simulation results with their ideal gain for any given input.

Then again, I guess people stick with the tools they know - though I
do implore you to all take a second look at the mighty spreadsheet.
They really are more powerful than what you are giving them credit
for.

Daniel O’Connor wrote:

How about going old school and using a calculator? No memory footprint
on the computer at all.

Dave

Brian P. wrote:

Then again, I guess people stick with the tools they know - though I
do implore you to all take a second look at the mighty spreadsheet.
They really are more powerful than what you are giving them credit
for.

I’m in the process of writing a PLL analysis tool in Excel, located at
http://www.keystoneradio.com/PllDesign.html, probably at the high end of
things you can do with Excel. The other thing to think about is that
spreadsheets are a very common tool, while tkl/python etc require
installation. In a corporate environment, you are pretty guaranteed to
have Excel, but the other stuff may be more difficult to get hold of.

Dave

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs