Member Avatar for sunshine102030

If we have the following message bits

11010001010001001010

we split this meassage into blocks of 5 bits, then we use two dimensional matrix for error correction to give the sent frame

But what if we have a message with odd bits , for example :

1010010

To how many blocks we can split it? Is there any method to specify the number of bits per block ?

Edited by sunshine102030
  • 2 Contributors
  • 1 Reply
  • 539 Views
  • 9 Hours Discussion Span
  • Latest Post Latest Post by rproffitt

Dani AI

Generated

A single, deterministic rule is required whenever the bit-stream length isn’t a multiple of your chosen block size. For ’s 5‑bit block idea, the practical options are: pad the last block to fill the 2D rectangle, carry an explicit length field in the frame header, or define a "short-frame" type as suggested. Pick one and make sure both sender and receiver implement it exactly.

A simple, implementable workflow:

  • pick block_size B,
  • compute rows = ceil(len(bits)/B),
  • pad to rows*B using a chosen padding rule,
  • form the B×rows matrix, then compute row/column parity (or whatever ECC you use).

Example helper (Python-style pseudocode):

def make_2d_frame(bitstr, B):
    n = len(bitstr)
    rows = (n + B - 1) // B
    pad_len = rows*B - n
    # Choose a padding scheme: zeros, "1 then zeros", or include length header
    padded = bitstr + ('0'*pad_len)
    matrix = [padded[i:i+B] for i in range(0, len(padded), B)]
    return matrix

Padding trade-offs and cautions: zero-padding is cheapest but ambiguous (receiver can’t tell if trailing zeros are data). A length field removes ambiguity with minimal overhead and is the most robust choice for real protocols. If you use a recognizable pad pattern (for example a single 1 followed by zeros), document it and ensure it can’t collide with valid tail data or protect the length/header with its own checksum. Remember parity-only 2D schemes have limited correction ability; for stronger robustness consider byte-oriented ECC (Hamming/Reed–Solomon) and align blocks to whole bytes where possible.

Practical tips: test extreme cases (very short and empty messages), protect the header/length with a small CRC, and update protocol docs so any intermediate device or future implementer knows exactly how padding/short frames are handled.

Member Avatar for rproffitt

Doesn't look odd to me at all. 10 10010 should be 00010 10010 as that's the same value. If you are implementing a protocol, your protocol will implement a short frame message as well. Again, it's your protocol. Add to it if it's coming up short.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.