No, really, I wouldn't squelch at all, but simply integrate the "is this high enough"
logic into a block at the output of your moving average, which only sends a *message* only
on detection of the burst to a Qt compass sink (and anything else that cares).
That is, unless your mental physical model of what you're simulating here says the nature
of it matches well to the nature of our Squelches (which, tbh, are rather um, strange).
Best regards,
Marcus
On 2026-03-02 10:25 AM, Marcus Müller wrote:
> Hi Robert, my thoughts:
>
> You really need to describe where these signals are coming from and what they physically
> are! I'd, for example, argue you would in general need frequency recovery first – but that
> might be a given (or not a problem) in your specific system.
>
> Generally, yes, the argument of the signal is the phase. I'd frankly do the squelching, if
> at all, only after the moving average that reduces the noise variance.
>
> Best regards,
> Marcus
>
> On 2026-03-02 7:41 AM, Robert Heerekop wrote:
>> The objective is to measure the phase difference between a noisy burst of 200ms
>> containing 500Hz and a reference 500Hz.
>> Attached grc runs without hardware, contains the signal sources and works as follows:
>>
>> 1. A noisy 200ms burst signal of 500Hz is generated based on a 500Hz sine.
>> 2. A squelch block its sob-Tag triggers a python block which diverts the stream (during
>> the active pulse) from the default null sink to a detector.
>> 3. The detector is a conjugate multiplication which transfers the difference of both
>> signals to DC.
>> The noise is averaged out and the resulting phase difference is extracted.
>> 4. A compass and constallation sink show the phase difference
>>
>> 20260302.png
>> Thanks for sharing your thoughts what to improve in the phase shift detection of this
>> simulation.
>>
>> Robert
>>
>>
https://github.com/rrrRbert360/GR_Burst_PHdetection <
https://github.com/rrrRbert360/
>> GR_Burst_PHdetection>
>
