I understand now. It’s not: T symbols of error correction AND 2T symbols of error detection. It’s T symbols of error correction OR 2T symbols of error detection. T symbol errors have unique syndromes where 2T are not unique but are non zero. The uniqueness makes it correctable , the non zero makes it detectable. So you cannot both correct T errors and detect 2T because many (in this case about 4000) of the syndromes for T errors is also the syndrome for 2T, and there is no way to differentiate if you should try and correct for a single error, or if you should flag it as an uncorrectable error.
Thanks everyone.
If by half data are corrupted, you mean that the binary probability of error is equal to $p = 1/2$, then you are in trouble. For a BSC (Binary Symmetric Channel), the channel capacity per symbol is equal to:
$$C_S = 1 + p \, log_2 p + (1-p)\,log_2(1-p)$$
And then the capacity is equal to $C_S = 0$ for $p = 1/2$.
This implies that no code can correct such a randomized channel.
In a comment, you detail that the data are corrupted by blocks (this should have been told in the post itself). For example, one half is highly corrupted, on half is correct. In such an extreme situation, the best if to make a block transmission, with a CRC for each block, to detect which blocks are corrupted, and which are not. Then data blocks detected as corrupted (highly incorrect) must be thrown. To get the whole information, you have to perform some kinds of data block repetition.
The important aspect is that if a given block is highly corrupted, you can use the above capacity analysis to decide that the best thing we can do with it is to throw it.
In a real transmission system, with a return channel, this is managed by retransmitting the erroneous blocks (ARQ process).
Best Answer
The choice most likely depends not only on the expected number of symbol errors but rather on the distribution of those errors. You may need to run a simulation to reach a conclusion (or a recommendation to your boss, whether relevant). The goal is undoubtedly to meet some quality-of-service goal that you didn't specify (and may need feedback from the said boss to determine anyway).
8-bit symbols: Here there is no need to look further than shortened Reed-Solomon codes. Relevant features:
4-bit symbols: Here I want to suggest a few alternatives. Basically because you left it unclear how long your data blocks are, and whether you can split it into several blocks of an error-correcting code on demand or not.
The goto code is still the Reed-Solomon code (suggested in Dilip Sarwate's comment):
The point I want to emphasize is that this Reed-Solomon code will constrain the block length severely. That may or may not be a problem, because you can split a longer block of data into several code blocks. But, for the purposes of meeting a QoS requirement you may (?) then need to estimate the probability of ALL those blocks being able to correct the eventual errors. Therefore I also proffer a few alternatives, just in case their parameters work better in your application (run that sim!). Those alternatives are so called algebraic geometry codes. The amount of math that goes into their theory is significantly more than what is needed for Reed-Solomon codes, but I still suspect you could locate code for using those codes by searching... The advantage they offer over Reed-Solomon codes is that they have longer data blocks. That sometimes helps, but the catch is that they are not MDS-codes. Meaning that to correct $t$ erroneous hexadecimals they need more than $2t$ check symbols. There is an extra parameter called the genus, $g$. When using a code based on a curve of genus $g$, the code needs $2t+g$ check symbols to correct $t$ errors. That is, $8t+4g$ check bits. A few alternatives:
I hope the example number games I described above give you an idea, what you need to know to decide on a code. It is difficult to tell what is best for your application. It may well be that you don't need to optimize it too much, in which case the alternatives don't offer significant enough gains over the familiar 8-bit Reed-Solomon code. If your channel creates errors lumped together rather than scattered hexadecimal errors, you hopefully got the idea that codes with longer blocks may then save the day. An alternative often used in telcomm is to use an interleaver to split errors lumped together between various blocks of the good ole Reed-Solomon code. It seems to me that your application has so short packages that interleavers may not help. Over to you.
A further point:
It is known that a curve of genus $g$ can have at most $n=q+2g\sqrt{q}$ points over the field of $q$ elements (save for one point we need to leave out). Here $q=16$, so the blocks you get with a curve of genus $g$ can contain up $16+8g$ hexadecimal symbols, and needs to use $2t+g$ check symbols to correct $t$ errors. You see that the two curves above with $g=1$ and $g=6$ reach the maximum $16+8g$. Unfortunately that maximal length cannot be achieved for all possible values of $g$. If you need a value of $g$ other $0$ (Reed-Solomon), $1$ (elliptic) or $6$ (Hermitian), do ask, but I won't know the answer right away :-/