16 Apr 2024

Concept

The "Aggressive Retry" feature is a functionality designed for electronic labels that ensures reliability and responsiveness in communication protocols. When an electronic label fails an image transmission , the Aggressive Retry mechanism automatically intervenes to enforce the command.

This feature attempts to re-establish connection and resend the transissions multiple times at short intervals, thereby increasing the probability of successful communication.

Be aware that the 'Aggressive Retry' function is only applicable to online labels and does not operate with labels that are offline.

Benefits

• Enhanced Reliability: Ensures that all electronic labels receive and display the correct information even in cases of initial communication failures.

• Improved Accuracy: Maintains the accuracy of displayed information,

• Reduced Manual Effort: Minimizes the need for manual updates or checks

• Increased Efficiency: Streamlines operations by automating the re-sending of commands, thus keeping systems running smoothly without interruptions.

Conditions

"The 'Aggressive Retry' feature in VUSION Cloud is designed to enhance the reliability of image transmission to electronic labels. Initially, the system tries to deliver the image, and if the first attempt fails, it automatically proceeds to make up to five additional retries, totaling six attempts.

Previously, the Aggressive Retry feature operated on a less frequent retry mechanism. If a transmission failed, the system would retry 5 times. If the transmissions was still not accepted by the label, the system would pause for six hours before restarting the entire cycle. This included another set of five retries followed by another six-hour wait, if necessary.

The updated version of the Aggressive Retry feature introduces a more aggressive and dynamic approach to handling command failures. In this version, when a transmission fails, the system still attempts five retries.

However, the significant change is in the timing between these retries; they are now spaced 15 minutes apart, rather than being almost immediate. If after these spaced retries the command is still not successfully delivered, the waiting period before restarting the retry sequence is now dynamically adjusted. Instead of a static six-hour delay, the system would restart after 15 minutes, and if necessary, continues with additional sets of five retries at increasing intervals: 30 minutes, 45 minutes, and so on.

This approach aims to adapt more responsively to varying network conditions and label responsiveness, potentially reducing the overall downtime and enhancing the probability of successful command delivery.