Hey, In the hdu.cc file there is a function 'apply_rs_correction'. I am interested in finding out how this works. What is confusing me is that I know it works. But I have been looking at this code and to me it seems to do essentially nothing???
// apply a different kind of correction void hdu::apply_rs_correction(bit_vector& frame) { // pre-processor if statement that is *always false* (0 == false) #if 0 *// so this code is not included in the final compiled program static itpp::Reed_Solomon rs(6, 8, true);
const size_t rs_codeword[][6] = { }; const size_t nof_codeword_bits = sizeof(codeword_bits) / sizeof(codeword_bits[0]);
// the end of the pre-processor if statement #endif // and that's it for this function? -- so this function is actually empty in the compiled program??? }
I am putting comments in the code trying to understand it. What am i missing here?
In the hdu.cc file there is a function 'apply_rs_correction'. I am interested in finding out how this works. What is confusing me is that I know it works. But I have been looking at this code and to me it seems to do essentially nothing???
The code is a "stub" and does nothing. A stub is something intended for future development but time has moved on and nothing been added.
In this case the commented out code is declaring a 2D array consisting of the indices of each of the hex bits in the source frame. The actual indices have not been initialized and the RS not implemented.
On 07/14/2013 04:29 PM, Steve Glass wrote:
In the hdu.cc file there is a function 'apply_rs_correction'. I am interested in finding out how this works. What is confusing me is that I know it works. But I have been looking at this code and to me it seems to do essentially nothing???
The code is a "stub" and does nothing. A stub is something intended for future development but time has moved on and nothing been added.
In this case the commented out code is declaring a 2D array consisting of the indices of each of the hex bits in the source frame. The actual indices have not been initialized and the RS not implemented.
Hey, I was under the impression that upon transmission the HDU undergoes both a (36,20,17) Reed-Solomon encoding and a (18,6,8) shortened Golay encoding and therefore would have to be error checked with both of these for decoding. We are getting the data messages out of the HDU. So how is this so if we are not doing the error check? Is it not necessary for extracting the data information?
On Sun, Jul 14, 2013 at 07:13:56PM -0400, Matt D wrote:
We are getting the data messages out of the HDU. So how is this so if we are not doing the error check? Is it not necessary for extracting the data information?
All of the error correcting block codes used in P25 are the sort where the codeword includes the encoded data verbatim; the code appends bits used for error correction, but a receiver can ignore those and just pull out the data bits. This greatly increases the likelihood of post-decoding bit errors, but it works fine when the SNR is good.
All of the error correcting block codes used in P25 are the sort where the codeword includes the encoded data verbatim; the code appends bits used for error correction, but a receiver can ignore those and just pull out the data bits. This greatly increases the likelihood of post-decoding bit errors, but it works fine when the SNR is good.
OK great, so I'll work on the error correction later. My question now is how are the data bits currently extracted, or separated, from the extra parity bits? So, from the bit_vector& frame_body I can extract the 240 bits the LCW information is in; the question is how do I know where the 12, 6-bit symbols (hex bits or codewords) are within this 240 bits? Please excuse me if there is some obvious answer to this, I am asking in interest of time. Thanks!
-
Matt D -
Michael Ossmann -
Steve Glass