= Refactoring OP25 =

The top-level tasks here are to:
  • Split the classes for a block into an impl/interface and use the new namespace rules.
    This is pretty straightforward and documented [ here].
  • Implement the common P25 functionality within the OP25 library.
    This covers bit interleaving/de-interleaving, forward error-correction and insertion/extraction of audio and other message payload.
  • Expose more of our components at a lower level because we can use GNURadio to schedule execution across multiple threads/CPUs.
    We already have some of the C4FM demod/mod, DQPSK demod/mod, vocoder and so on but we need to expose the bit correlator, framer, forward error correction, vocoder and so on.
  • Ensure that all blocks have unit tests, are properly documented and can be used in GRC.
To make the discussion more concrete we can consider splitting the decoder we use at present into multiple lower-level blocks:
  • Modulator/demodulator blocks for C4FM and pi/4 DQPSK (we already have most of this).
    Modulator should use message-passing for frequency correction where possible. The symbols are two bit and this should be preserved at least until correlation.
    GNURadio now supports DQPSK so we can use the standard block wrappered appropriately.
  • A P25 correlator to detect training sequences (requiring a signal from the framer to reset to the scannning state).
    Again, message passing can be used to trigger scanning.
  • A P25 framer to construct packets from the bit stream (and signal the correlator when to re-start scanning for the FS).
    I'm overloading this term but the idea is that a block that knows how to identify the extent of a frame based on the DUID. We could tag the output stream here or we could make the output a vector of bits or pass a message containing the actual frame. I favour the "vector of bits" approach.
  • Blocks to compute and apply forward error correction.
    Again we need to decide on the data format.
  • A block to do the p25cai encapsulation.
  • A vocoder block modeled on those in the GNURadio core.
    I'm presuming the decoder will need voice codewords (vectors of bits) as input and product PCM output.
    The encoder will take PCM and produce voice codewords.
    This means we need blocks to extract/insert voice codewords from/to a frame stream.

Details need working out.

Updated by zecke over 6 years ago · 1 revisions

Add picture from clipboard (Maximum size: 48.8 MB)