On 03/23/2016 10:08 PM, Dan CaJacob wrote:
Derek is spot on. 0 dB into any USRP is screaming loud. Most of the
units are very sensitive, so it's perfectly fine to err on the side of
too much attenuation to start and dial the gain as you need. It
depends on the USRP type, but signals much above -15dB can physically
damage the hardware if you set the gain too high.
I'd actually said most of this to Tom privately, but forgot to copy the
list.
It's instructive to consider what kind of "normal" signals one might
expect to receive on a receiver intended to be connected to an antenna.
Consider your average +70dBm (10kW) FM station. 10km away from the
TX, we expect about 90dB path loss, which means that the
theoretical power seen by your antenna would be about -20dBm. Perhaps
a bit more, since the TX antenna won't be strictly isotropic.
At 50km away, that's 100dB of path loss, giving about -30dBm at your
antenna terminals (ballpark, hand-waving). Now, a signal of
-30dBm is actually considered fairly strong, and your typical FM
receiver will produce a very nice, nearly-noise-free output from
signals entering your antenna at levels of -30dBm.
The RX inputs of most SDRs (Ettus radio are no exception) are designed
for the kinds of signal levels that are typical in "connected to
an antenna" environment. They are less well suited to "connected to
a laboratory signal generator", without significant attenuation.
The RF signal levels floating around in a lab are typically much
"louder" than you might find "on air", so if one is used to lab conditions,
it may not be obvious that a sensitive receiver designed for "from
the air" reception would be unhappy in laboratory signal-level
conditions. So, keep the levels very modest indeed.
On Wed, Mar 23, 2016 at 9:35 PM Derek Kozel <derek.ko...@ettus.com
<mailto:derek.ko...@ettus.com>> wrote:
Hello Tom,
The input power to the USRP daughterboard should not be above
-15dBm. I would recommend putting as much attenuation as you have
available inline and raising the gain until just before a timesink
shows the signal clipping, as Andy says having the maximum
attenuation set will be raising your noise figure.
Regards,
Derek
On Wed, Mar 23, 2016 at 4:28 PM, Andy Walls
<a...@silverblocksystems.net <mailto:a...@silverblocksystems.net>>
wrote:
> From:
> Tom Golden
> Subject:
> Re: [Discuss-gnuradio] Ettus N210
> GMSK 9600
> Date:
> Wed, 23 Mar 2016 13:14:18 -0600
>
>
______________________________________________________________________
> Here's my flow-graph along with a snapshot of the constellation and
> FFT.
>
>
> Thanks!!
> -Tom
Hi Tom,
A couple of things:
a) The polyphase resampler isn't going to work well without a
filter
definition in the taps field.
b) The constellation sink will not display anything meaningful
without
sample timing synchronization; it is not useful at its current
position
in the flowgraph. The constellation sink also doesn't display
anything
useful for an FSK modulation normally; (G)MSK being an
exception, if
treating it like a PSK modulation vs. FSK.
c) You don't have any coarse or fine frequency
synchronization. That
will cause you major problems, if trying to treat GMSK as a PSK
modulation. It will cause you minor problems, if treating
GMSK as an
FSK modulation.
d) Timing recovery blocks usually want a signal that has peaks
(which
you get by putting the signal through a matched filter), and
those peaks
should nominally be scaled to +/- 1.0. You don't have a
matched filter
or an AGC before the Clock Recovery block.
e) The USRP's 0 dB gain setting is actually the USRP inserting the
maximum attenuation it can (e.g. 37 dB of attenuation). That
can kill
your signal to noise ratio. You may want to consider adding
"gain" as
long as the time domain signal doesn't look clipped (sometimes
hard to
tell with FSK).
f) You may wish to look at what Nick Foster's gr-ais does to
demodulate
a 9600 baud GMSK AIS signal. It will probably give you a nice
starting
point; just ignore the stuff about correlating to a preamble.
https://github.com/bistromath/gr-ais
If you share your datafile somewhere, I might be inspired to
whip a
flowgraph that works on it. :) But that could rob you of the
learning
process.
Regards,
Andy
>
> On Wed, Mar 23, 2016 at 1:01 PM, Marcus D. Leech
<address@hidden>
> wrote:
> On 03/23/2016 02:48 PM, Tom Golden wrote:
> Hi,
>
> I'm a novice gnu radio user. I'm using
gnuradio with
> an Ettus N210 cabled to a modem transmitting
GMSK
> 9600bps. This is just for a test to verify
the modem
> transmit bits.
>
> I'm having issues with resampling. The N210
clock
> can't be set to a multiple of 9600, so I'm
attempting
> to resample. I've tried various mechanisms
but the
> output after resampling to 96000 is too noisy to
> successfully decode bits. I've tried the
GMSK demod
> block as well as the combination of Quadrature
> Demod->Clock Recovery MM->Binary Slicer -
and neither
> works.
>
> I've also played with the Polyphase clock
sync but I
> don't see any noticeable difference. Can anyone
> recommend a solution?
>
> Thanks!!
> -Tom
>
> For a first step, it would be useful for you to
share your
> flow-graph with the list.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
Very Respectfully,
Dan CaJacob
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
