Forum: GNU Radio OOK reception

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.
1a83f91809fca8823d094b7ec85575c9?d=identicon&s=25 Dan (Guest)
on 2008-10-09 17:40
(Received via mailing list)
Hi, I am working on an OOK receiver but am having some problems with the
squelch.

I wrote a script with the following flow graph:

USRP.source_c -> complex_to_mag -> add_const_ff( -const ) ->
binary_slicer_fb -> file_sink

This works fine, but I would like to have some sort of discrimination
for
when there is no signal.  I looked into adding a pwr_squelch_cc block
after
the source but this led to a lot of buffer overruns as the processing
increased.  I am attempting to receive a bandwidth of 16 MHz using 8-bit
samples so any more processing I add can make a difference.  The
bandwidth
is important as I am trying to maximize the data rates it can handle.

There is also the option of checking after the fact and counting the
number
of samples that are zero.  i.e. if there are x number of 0's then stop
writing to file and wait for another 1 to come through.  Is there
anything
implemented for this or would I have to write my own block?

If you have any ideas or suggestions of what I should take into account
(i.e. alpha and ramp for squelch) then please let me know.  My goal is
to
basically have a variable dwell time after a valid signal that will turn
off
after a certain delay.

Thanks,

Dan
3dfb724cefc1eddbade1e8bd1ee6131f?d=identicon&s=25 Dan Halperin (Guest)
on 2008-10-09 18:21
(Received via mailing list)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Oct 9, 2008, at 8:39 AM, Dan wrote:

> pwr_squelch_cc block after the source but this led to a lot of
> buffer overruns as the processing increased.  I am attempting to
> receive a bandwidth of 16 MHz using 8-bit samples so any more
> processing I add can make a difference.  The bandwidth is important
> as I am trying to maximize the data rates it can handle.
>

If you're doing complex_to_mag anyway, why not use that output for
squelching instead of a pwr_squelch_cc ? The squelch algorithm is
pretty simple.

Also, complex_to_mag has a sqrt in it which it looks like your flow
graph doesn't need. All the following blocks would work just as well
in the mag^2 domain. So maybe you should do that too.

- -Dan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkjuLmIACgkQy9GYuuMoUJ5O5wCfYiDrzSWzZtNZiqkDmXkPN14x
v3MAn2c8phlTZ4jAnmlyj7a96891DAo0
=PjRd
-----END PGP SIGNATURE-----
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2008-10-09 19:46
(Received via mailing list)
On Thu, Oct 09, 2008 at 11:39:29AM -0400, Dan wrote:
> the source but this led to a lot of buffer overruns as the processing
> (i.e. alpha and ramp for squelch) then please let me know.  My goal is to
> basically have a variable dwell time after a valid signal that will turn off
> after a certain delay.
>
> Thanks,
> Dan

complex_to_mag_squared is many many times faster than complex_to_mag.
Using it would reduce your CPU consumption.

Eric
1a83f91809fca8823d094b7ec85575c9?d=identicon&s=25 Dan (Guest)
on 2008-10-09 22:29
(Received via mailing list)
>
>  complex_to_mag_squared is many many times faster than complex_to_mag.
> Using it would reduce your CPU consumption.
>

Okay, I changed the block from complex_to_mag to mag_squared and it
seems to
work well, thanks.

However, I am still looking for a way to prevent writing to file when a
signal is not being received.  That is what drew me to the
pwr_squelch_cc as
it has a gating feature.  I would like some sort of gating feature for
the
receive chain but it could always be done after the OOK demodulation.

It seems the simplest way would be to count the zeroes coming through
and
gate the output when a certain number are reached.  The device could
then
wake up and write when a 1 (or several) are received.  Here is an
example:

usrp.source_c -> complex_to_mag_squared -> add_const_ff( -const ) ->
binary_slicer_fb -> ??? gate of some sort -> file_sink

This would reduce the amount of data stored when signals are few and far
between.  I am just dealing with raw data so there would be no pattern
to
watch for besides signal strength past a threshold.

Is there any sort of block I could use to do this?  Or maybe it should
be
approached from another angle?  I can always write a block if necessary,
just trying to simplify if possible.

Thanks,

Dan
This topic is locked and can not be replied to.