Friday, October 18, 2024

Re: Recovering symbols from burst transmissions with unknown sample rate

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