Calculate serial image refresh rate limits

What serial image refresh rate means

Serial image refresh rate is the rate at which complete image updates can pass through a serial interface. It is not necessarily the panel's refresh rate, the animation rate generated by the application, or the rate at which a function accepts new work.

A panel may repeatedly show the same stored image while the serial connection delivers its replacement. Likewise, a host may queue updates faster than the display can receive them. A growing queue increases image age rather than increasing completed updates.

Keep these measurements separate:

• Requested update rate: how often the application produces a new image.
• Transfer completion rate: how often a complete image reaches the receiving endpoint.
• Visible completion rate: how often a complete new image appears on the display.

For a changing status graphic, visible completion is usually the useful result. For smooth motion, consistent timing matters as well as the average rate. Planning signage animation frame rate addresses that separate content-planning question.

Calculate the full-frame wire limit

Start with the number of bytes actually transmitted, not just the image dimensions. For an uncompressed, tightly packed image:

payload bytes = width × height × bytes per pixel

This assumes there is no row padding, compression or additional image header. If the interface uses packed pixels, encoded text or another representation, use its documented byte count instead.

Next, calculate serial framing. A typical eight-data-bit format with one start bit, no parity and one stop bit uses:

serial bits per byte = 1 + 8 + 0 + 1 = 10

For a binary UART link carrying one bit per symbol, the baud rate is numerically equal to the bit rate. Under that assumption:

payload-only transfer time = payload bytes × serial bits per byte ÷ baud rate

payload-only frame-rate ceiling = baud rate ÷ (serial bits per byte × payload bytes)

These are optimistic limits. They assume back-to-back transmission with no other traffic or processing delays. Check both endpoints' actual data-bit, parity and stop-bit settings rather than assuming ten bits per byte.

Commands and headers consume capacity too. If they use the same framing on the outgoing link:

outgoing wire time = (payload bytes + command and header bytes) × serial bits per byte ÷ baud rate

Add protocol waits separately. A reply on a separate receive wire may not consume outgoing bandwidth, but waiting for that reply can still delay the next transmission.

Work through a three-frame target

Consider an uncompressed 132 × 132 image using two bytes per pixel. Its payload is:

132 × 132 × 2 = 34,848 bytes

At three complete images per second, the payload requirement becomes:

34,848 × 3 = 104,544 bytes per second

With ten serial bits per byte, the payload alone requires a line rate of:

104,544 × 10 = 1,045,440 bits per second

That is the mathematical floor, not a recommended operating setting. At exactly that rate, the payload occupies the entire outgoing link. There is no capacity left for command bytes or idle intervals.

The following rates are calculation examples, not claims that a particular interface supports them.

Under these assumptions, 729,167 baud cannot carry three full images per second. Faster servicing cannot change that result.

You can also work backward from the available budget:

bytes available per update = baud rate ÷ (serial bits per byte × target updates per second)

At 729,167 baud and three updates per second, the outgoing budget is at most 24,305 whole bytes per update, before allowing for pauses. Commands and headers must fit inside that allowance. A 34,848-byte image does not.

Check whether the measured time is possible

A timing measurement is useful only when its boundaries and byte count are known.

For example, an uncompressed 320 × 240 image at two bytes per pixel contains 153,600 bytes. At 115,200 baud with ten serial bits per byte, transmitting that payload alone takes about 13.33 seconds.

If an operation appears to take eight seconds, at least one assumption differs. Possible explanations include:

• The transmitted image uses fewer bytes per pixel.
• Compression reduces the byte count.
• Only part of the image is sent.
• The timing excludes part of the transfer.
• The actual line rate differs from the configured value being assumed.
• The command references an image already stored at the receiving endpoint.

Do not interpret the shorter measurement as unusually efficient scheduling. First reconcile the captured byte count, actual line rate and timing boundaries.

A function returning does not automatically mean that the image is visible. Depending on the interface, it may mean the data was queued, copied into a buffer, transmitted, or acknowledged. Use the interface documentation to establish what completion means.

Separate line time, idle gaps and rendering

Capture one repeatable image transaction with suitable serial measurement equipment. Verify signal levels and use equipment appropriate to the electrical interface. Record the first request byte, payload transmission, any responses and visible completion.

Look for three different causes of delay:

• A nearly solid stream of bytes: the line rate is probably the dominant transfer limit. Raising task priority offers little benefit if there are no gaps to remove.
• Idle periods between bytes or blocks: investigate host servicing, flow control, buffer limits, protocol waits and competing work.
• A pause after the final payload byte: investigate receiver processing, image conversion, drawing or a documented display-update operation.

The stages may overlap. Some receivers draw while bytes arrive; others wait for the complete image. Do not add preparation, transfer and rendering times as if they always occur in sequence. Measure the actual pipeline.

For a broader delay investigation, diagnosing factory screen update delay helps distinguish an old source value from a slow transfer or a late visible update.

Choose changes that address the limiting stage

Increase the baud rate only when both endpoints and the complete physical connection support the proposed setting. Check documented rate choices, achievable clock settings, signal levels and any intervening converters. Matching nominal settings are not enough if transfers become corrupted.

Change settings using the endpoints' documented procedures and retain a documented recovery method. Recheck image integrity and transaction timing after each change.

If idle gaps dominate, investigate buffering and serial servicing. A priority change may reduce delays before the transmitter receives its next block. It does not increase the number of bits the configured line rate can carry. Check that other time-critical tasks still meet their requirements after any scheduling change.

If the wire budget is insufficient, reduce transmitted data or change the architecture:

• Use partial-region updates if the receiving interface supports them.
• Send supported drawing commands instead of complete images where appropriate.
• Reference locally stored graphics when the protocol provides that function.
• Reduce image dimensions or color depth if the application permits it.
• Use compression only when supported, and budget for representative content and decoding time.
• Select a faster interface or relax the update-rate requirement.

Partial updates need particular care. If an image changes everywhere, a small typical update region does not represent the worst case. Budget for the largest update the application must deliver within its deadline.

Check completed updates under normal load

A target of three completed images per second corresponds to a nominal interval of about 333 milliseconds. Decide whether that requirement means an average throughput, a maximum interval between images, or a maximum age for the displayed information. Those are different acceptance conditions.

Run consecutive updates with representative images and normal background work active. Record:

• Actual bytes transmitted per update, including protocol overhead.
• Active transmission time and idle gaps.
• Intervals between visibly completed images.
• Image age if updates can queue.
• Corruption, incomplete drawing, retries and missed deadlines.

Compare the results with the calculated wire-time floor. A result close to that floor points toward a bandwidth limit. A much longer result calls for examining gaps and receiver processing.

A short trial cannot establish every future timing condition. Use the measurements to identify available margin and investigate long intervals rather than relying only on an average. If the payload already exceeds the theoretical budget, change the data volume, interface or requirement before spending more time on scheduler tuning.

Questions