14 Jul
2013
14 Jul
'13
4:44 p.m.
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?
--
Matt D
------------
14 Jul
14 Jul
10:29 p.m.
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.
15 Jul
15 Jul
1:13 a.m.
On 07/14/2013 04:29 PM, Steve Glass wrote:
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?
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.
7:58 a.m.
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.
2:52 p.m.
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!
3947
days inactive
3948
days old
4 comments
3 participants
participants (3)
-
Matt D -
Michael Ossmann -
Steve Glass