OOK reception

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

-----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-----

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

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