RefactoringPage » History » Version 1
zecke, 04/22/2017 04:20 PM
1 | 1 | zecke | = Refactoring OP25 = |
---|---|---|---|
2 | |||
3 | The top-level tasks here are to: |
||
4 | * Split the classes for a block into an impl/interface and use the new namespace rules. |
||
5 | This is pretty straightforward and documented [http://gnuradio.org/redmine/projects/gnuradio/wiki/BlocksCodingGuide here]. |
||
6 | * Implement the common P25 functionality within the OP25 library. |
||
7 | This covers bit interleaving/de-interleaving, forward error-correction and insertion/extraction of audio and other message payload. |
||
8 | * Expose more of our components at a lower level because we can use GNURadio to schedule execution across multiple threads/CPUs. |
||
9 | 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. |
||
10 | * Ensure that all blocks have unit tests, are properly documented and can be used in GRC. |
||
11 | |||
12 | To make the discussion more concrete we can consider splitting the decoder we use at present into multiple lower-level blocks: |
||
13 | * Modulator/demodulator blocks for C4FM and pi/4 DQPSK (we already have most of this). |
||
14 | Modulator should use message-passing for frequency correction where possible. The symbols are two bit and this should be preserved at least until correlation. |
||
15 | GNURadio now supports DQPSK so we can use the standard block wrappered appropriately. |
||
16 | * A P25 correlator to detect training sequences (requiring a signal from the framer to reset to the scannning state). |
||
17 | Again, message passing can be used to trigger scanning. |
||
18 | * A P25 framer to construct packets from the bit stream (and signal the correlator when to re-start scanning for the FS). |
||
19 | 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. |
||
20 | * Blocks to compute and apply forward error correction. |
||
21 | Again we need to decide on the data format. |
||
22 | * A block to do the p25cai encapsulation. |
||
23 | * A vocoder block modeled on those in the GNURadio core. |
||
24 | I'm presuming the decoder will need voice codewords (vectors of bits) as input and product PCM output. |
||
25 | The encoder will take PCM and produce voice codewords. |
||
26 | This means we need blocks to extract/insert voice codewords from/to a frame stream. |
||
27 | |||
28 | Details need working out. |