# Dev call tomorrow? + digital mod/demod questions **URL:** \ **Category:** GNU Radio\ **Created:** [November 20, 2014, 12:38am UTC](https://www.ruby-forum.com/t/dev-call-tomorrow-digital-mod-demod-questions/233154 "2014-11-20T00:38:38Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [November 20, 2014, 12:38am UTC](https://www.ruby-forum.com/t/dev-call-tomorrow-digital-mod-demod-questions/233154/1 "2014-11-20T00:38:38Z")
It looks like there’s a dev call tomorrow. Is that 1700 or 1800 UTC? [https://gnuradio.org/redmine/projects/gnuradio/wiki/Call20141120](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 ---
**Author:** ![NowlanS\_Sean](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/f05b48/32.png) [@NowlanS\_Sean](https://www.ruby-forum.com/u/NowlanS_Sean)\ **Post date:** [November 20, 2014, 10:01am UTC](https://www.ruby-forum.com/t/dev-call-tomorrow-digital-mod-demod-questions/233154/2 "2014-11-20T10:01:59Z")
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 🙂 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 ---
**Author:** ![NowlanS\_Sean](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/f05b48/32.png) [@NowlanS\_Sean](https://www.ruby-forum.com/u/NowlanS_Sean)\ **Post date:** [November 20, 2014, 3:39pm UTC](https://www.ruby-forum.com/t/dev-call-tomorrow-digital-mod-demod-questions/233154/3 "2014-11-20T15:39:31Z")
On Thu, Nov 20, 2014 at 4:00 AM, Martin B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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