On Thu, Nov 20, 2014 at 4:00 AM, Martin Braun <martin.br...@ettus.com> wrote:
> 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 > 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
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
