Saturday, October 19, 2024

Re: Recovering symbols from burst transmissions with unknown sample rate

On Saturday, 19 October 2024 17:22:13 EEST Marcus Müller wrote:
> Hi Adrian,

Hi Marcus,
Thank you for the suggestions, I had to think a bit and also translate to what
I already have here - there are two small differences:

1. I use the quadrature demod block instead of the PLL freq detect, but the
outcome should be the same basically
2. I use a raised cosine filter for the known correlation sequence, since a
matched RRC filter is applied right after the quadrature demod. So the block
sequence is: Quad demod -> matching RRC filter -> correlate the sync sequence.
I believe this is needed to have a sync block operate on symbols with ISI
removed.

So if I understood your design correctly, I need to count the distance between
two correlation peaks in samples, and apply this difference between actual
number of samples and ideal number of samples as the second input to the
fractional resampler in a feed forward loop, and this will enable me to sample
at the symbol peak later as the peak correlation tag would be aligned to the
symbol peak and the input sample rate will match the ideal sample rate right?

So if I understood this system correctly, then the earliest aligned symbol
sampling can happen on the third burst, since the first two are necessary to
determine the samples per symbol mismatch? I'm going to give this a try.

Then my questions following from this:
- can rotating the samples achieve the same symbol alignment as the fractional
resampler?
- I wonder if the correlator filter can give me enough information to achieve
this in a single burst. I took a brief look at the code of the correlation
estimator block, and it appears to me that the "time_est" tag gives the offset
between the correlation peak and the optimum actual symbol peak. So I wonder
if this information is enough to adjust the peak symbol sampling in one go (so
even a single burst could be decoded correctly (in a single sync block as
opposed to a loop).

Thanks,
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