Saturday, October 19, 2024

Re: Recovering symbols from burst transmissions with unknown sample rate

Hi Adrian,

interesting system! And with the "1 out of 6 frames only" sync opportunity, the rather
generous 24/132 symbols midamble does seem more reasonable.

Thinking about that, I think one way you can approach this is:

- Instead of the corr_est block, you go ahead and build a simple correlation detector
yourself:
- AGC
- Input signal gets put through PLL Freq Det; that gives us the RRC-shaped 4-ASK (->A)
- (offline, before) use the same RRC to filter [54 zeros, midamble, 54 zeros] to get a
prototype burst; reverse the order (and complex conjugate, but this is real, so
nevermind), call the result "coeffs"
- Filter input signal with a filter whose taps are these "coeffs"
- complex to mag² (-> B)
- requires your own sync_block with 2 inputs, one of them being (A), the other (B):
- set output multiple to 132/2
- copy (all - 132/2) input from (A) to output
- look for value above threshold on B (correlation peaks!) starting at input sample
132/2
- if peak present, add tag to output at position of peak - 132/2
- consume (all - 132/2) input items (inherently from both inputs)

Couple observations:

- If you start by interpolating (say, by a factor of f=4), then you need to multiply 132
by f in all considerations above, but you might no longer need a symbol sync at all.
With an FFT FIR filter, things should still be plenty fast enough
- You could use the peak positions in a block that keeps track whether they are multiples
of the TDMA slot length, you can track the amount by which they deviate from the
"correct" count, and use that (ideally, smoothed a bit, maybe go PID on that) to adjust
a Fractional Resampler block that you put up front of things, to match your receive
chain's sample rate to the transmitter's sample rate
- You could also include the complex phase of the peak in the tag; divide
(phase difference) / (tag distance) to get a fine carrier frequency error estimate


On 18.10.24 21:07, Adrian Musceac wrote:
> On Friday, 18 October 2024 21:07:55 EEST Marcus Müller wrote:
>> Hi Adrian,
>> if you don't know the sample rate, then how can you get a detection by
>> correlating with the midamble? Is the midamble structured to be tolerant
>> against sample frequency offset (SFO)? In that case, therein probably lies
>> an approach to getting your decoding to work.
>
> Hi Marcus,
> I meant unknown sample rate in the sense that the number of received samples
> per symbol can be different in small amounts to the ideal samples per symbol
> value, not in the sense that the sample rate is not coarsely known.
>
> The difference between ideal and actual rate is small enough that a correlation
> peak can easily be extracted from the correlation estimator populated with a
> set of filtered symbols from the right sequence (there are 4 such sequences,
> only two are relevant to me).
>
>>
>> But we'd really need to know more about the signal; I feel at least
>>
>> - burst length compared to midamble length,
>> - pulse shaping if known,
>> - constellation type
>>
>
> The signal is 4-FSK with RRC pulse shaping applied, the burst length is 132
> symbols, and the midamble length is 24 symbols. The sync sequences consist of
> values from the set (-3,+3) where the constellation is defined as
> [-3, -1, 1, 3]. It is the standard air interface for DMR (digital mobile
> radio), direct mode of operation (not BS mediated).
>
>>
>> Furthermore, you say not all bursts have such a known midamble: but then,
>> how do you figure out such a burst started? Sounds like there's *also* some
>> kind of preamble.
>>
>
> Unfortunately not, the standard specifies that a synchronization opportunity is
> provided every 6 voice frames, and also every data frame (the transmission
> headers and terminators).
> My hope is that by estimating a symbol timing offset during a synchronization
> burst, this offset could be used for sampling the next 5 TDMA frames and not
> deviate significantly in such a short time, but this is just a guess.
>
> Thank you,
> Adrian
>
>> Best,
>> Marcus
>>
>
>
>

No comments:

Post a Comment