Quick and dirty solution: split the ciphertext to be transmitted into blocks with par2 and encode each block using codegroup. Join the blocks together with some unambiguous and easily identifiable separator.
For this specific combination you could use e.g. ----- as the separator when encoding (and maybe accept any sequence of dashes as the separator when decoding).
When decoding, split the message into blocks, decode each block into bytes using codegroup (discarding any blocks that fail to decode) and them combine them using par2 to (hopefully) recover the original ciphertext.
The reason for this particular combination is the way that par2 and codegroup work:
Par2 apparently implements an erasure code that splits the input data into a sequence of blocks (of some arbitrary number of bytes, which I believe is configurable but typically on the order of kilobytes) and adds a number of redundant extra blocks that allow the original data to be recovered even if some blocks are lost. Being an erasure code, it doesn't even attempt to correct errors within blocks — rather, it assumes that all blocks are received either correctly or not at all.
Codegroup apparently adds its own CRC checksum to the encoded message to detect errors, and refuses to decode it if the checksum does not match. Thus, even partial message corruption will generally result in full decoding failure.
Thus, there's no point in trying to do error correction within a single codegroup-encoded message — the CRC ensures that, with very high probability, a message either decodes correctly or not at all. (A CRC is not a cryptographic checksum, and it's possible and even quite easy for a deliberate attacker to modify a message in a way that it won't detect. But against random message corruption it's quite effective.)
However, codegroup and par2 actually pair up pretty well, as long as you encode each par2 block separately. Par2 wants corrupted blocks to be discarded, and that's exactly what codegroup does. You just need to make sure that the encoded blocks are combined in a way that lets any intact blocks be reliably separated from each other and from corrupted ones.
The resulting combined scheme may not be optimal in terms of error resistance vs. length expansion, but it should work fairly well at least against rare and/or bursty errors (which, if the message isn't entirely garbled, are likely to leave enough whole blocks intact to allow decoding). If you expect having to deal with a high rate of non-bursty errors (e.g. single bit flips), you may need to tweak the scheme (e.g. by modifying codegroup to apply a convolutional error-correcting code instead of just a CRC to the data).
Anyway, your question doesn't really deal with encryption, so its topicality here seems marginal at best. If you do want to also encrypt your data (which you briefly allude to in your question), the general consensus seems to be that you should do encryption and error correction in separate layers: first encrypt, then apply error correction to the ciphertext.
While error-correcting codes do share some underlying mathematical similarities with some encryption schemes, in practice their goals are different enough that trying to make a single scheme do both at once seems futile. Separating the encryption and the error correction into independent layers simplifies the design and analysis of both components and allows you to use well tested and optimized standard designs for each purpose.
(FWIW, I tried to find a good existing canonical question on that, but the closest I got was Encryption-then-encode or encode-then-encryption?, which isn't really as definitive in its conclusions as I perceive the overall consensus to be. But it'll do for now.)
