Dev call tomorrow? + digital mod/demod questions

GNU Radio
1

It looks like there’s a dev call tomorrow. Is that 1700 or 1800 UTC?
https://gnuradio.org/redmine/projects/gnuradio/wiki/Call20141120

As for input to the digital mod and packet structure discussion, I have
a few questions, or at least food-for-thought for tomorrow:

  •      It looks like the correlate_and_sync work is promising for

allowing carrier and timing recovery loops to adjust more quickly when
dealing with bursty, packetized traffic. However, most of the GR modem
applications I’ve seen use the correlate_access_code block without the
time and phase estimates being done on the preamble. I know the paradigm
is slightly different, i.e. matched-filter preamble correlator vs.
counting access code bit errors after MF and slicing, but is the intent
to eventually merge the two approaches together?

  •      What's the best way to handle the sudden ramp in power at the

start of a burst? Use squelch to detect power above a threshold? Use
AGC? This may be a fundamental radio receiver design question but I
think it makes sense to ask it in the context of how these blocks are
implemented. In gr-air-modes it looks like the preamble detector scans
for a rapid change in sample “voltage” before initiating a preamble
search. This seems more efficient if packet traffic is expected to be
low, otherwise all you’re doing is correlating against noise
(correlate_and_sync) or junk bit decisions (correlate_access_code). If
I’ve misunderstood anything here, please advise.

Thanks,
Sean

2

On 11/20/2014 12:37 AM, Nowlan, Sean wrote:

It looks like theres a dev call tomorrow. Is that 1700 or 1800 UTC?

1800 UTC. I recommend letting Google do the time zone math by joining
the G+ group and adding yourself to the event there.

As for input to the digital mod and packet structure discussion, I have
a few questions, or at least food-for-thought for tomorrow:

As you’ve seen on the agenda, this will be one of our focal points for
today’s call. People interested in this should definitely tune in!

  •      It looks like the correlate_and_sync work is promising for

allowing carrier and timing recovery loops to adjust more quickly when
dealing with bursty, packetized traffic. However, most of the GR modem
applications Ive seen use the correlate_access_code block without the
time and phase estimates being done on the preamble. I know the paradigm
is slightly different, i.e. matched-filter preamble correlator vs.
counting access code bit errors after MF and slicing, but is the intent
to eventually merge the two approaches together?

Can’t state facts on this, but one thing to remember is that
correlate_and_sync is way younger than the other correlators, which
predate the tag system.

  •      Whats the best way to handle the sudden ramp in power at the

start of a burst? Use squelch to detect power above a threshold? Use
AGC? This may be a fundamental radio receiver design question but I
think it makes sense to ask it in the context of how these blocks are
implemented. In gr-air-modes it looks like the preamble detector scans
for a rapid change in sample voltage before initiating a preamble
search. This seems more efficient if packet traffic is expected to be
low, otherwise all youre doing is correlating against noise
(correlate_and_sync) or junk bit decisions (correlate_access_code). If
Ive misunderstood anything here, please advise.

You’re right, it’s a fundamental radio rx design question :slight_smile:
You’re right, though, and if you check out some bursty standards, you’ll
usually find ramp-up times at the beginning of bursts for AGC init
and/or power detection. Imagine your phone would correlate for wifi
headers all the time the way the ofdm_rx does, it would soon run out of
juice.

Cheers,
M

3

On Thu, Nov 20, 2014 at 4:00 AM, Martin B. [email protected]
wrote:

today’s call. People interested in this should definitely tune in!
Can’t state facts on this, but one thing to remember is that

low, otherwise all you’re doing is correlating against noise
Cheers,
M

Indeed, we’ll be talking about this stuff today. I’ve been working on a
number of these issues lately and wanted to both share what I’ve been
doing
and get some feedback on things. Once I’ve finished with what I want to
do
here, I’m hoping I can work with Martin and Tim O. to figure out the
right
path to normalize all of this for the next release. As you’ve pointed
out,
there’s been a good evolution in the capabilities of the blocks here and
support for burst communications. But with the block structure in GNU
Radio, there’s a lot of duplication and yet no real concept of what the
“right” thing to do it. What I’d like to do (for 3.8 since we’ll be
deprecating stuff and changing behavior) is remove the duplication by
combining some concepts, tossing some out, and making what’s left more
generically useful in real modems.

Tom