Re: [Discuss-gnuradio] Dev call tomorrow? + digital mod/demod questions

[Martin Braun]

On 11/20/2014 12:37 AM, Nowlan, Sean wrote:
> It looks like there’s 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 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?

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.

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

You're right, it's a fundamental radio rx design question :)
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