A QR-Enabled Multi-Participant Quiz System for Educational Settings with Configurable Timing

Abstract

An integrated QR-based identification and multi-participant quiz system is developed for classroom and competition scenarios. It reduces the check-in latency, removes fixed buzz-in timing, and lifts hardware-imposed limits on the participant count. On the software side, a MATLAB-R2022b-based module integrates the generation and recognition of linear barcodes and QR Codes, enabling fast, accurate acquisition of contestant information while reducing the latency and error risk of manual entry. On the hardware side, control circuits for compulsory and buzz-in modules are designed and simulated in Multisim-14.3. To accommodate diverse scenarios, the team-versus-team buzz-in mode is extended to support two- or three-member teams. Functional tests demonstrate the stable display of key states—including contestant identity, buzz-in priority group ID, and response duration. Compared with typical MCU-channel-based designs, the proposed system relaxes hardware-channel constraints, decoupling the participant count from fixed input channels. It also overcomes fixed-timing limitations by supporting scenario-dependent configuration. The Participant Information Registration subsystem achieved a mean accuracy of 86.7% and a mean per-sample computation time of 14 ms. The 0–99 s configurable timing aligns with question difficulty and instructional procedures. It enhances fairness, adaptability, and usability in formative assessments and competition-based learning.

1. Introduction

As digital transformation accelerates, Quick Response (QR) Codes—with high information density, built-in error correction [1], robustness to contamination and occlusion [2], and strong extensibility—have been deployed at scale for product traceability [3], e-ticketing, mobile payments, and scholarly resource management [4], forming a mature coding and implementation ecosystem [5]. Additionally, the technology is highly portable and imposes minimal deployment barriers in educational settings [6]. In contrast, competitive events still rely on manual data collection and fixed-function hardware [7], leading to low check-in throughput (≈15–30 s/person) and elevated entry errors (≈3–5%) [8]. In educational settings—such as classroom interactions and course competitions—these bottlenecks undermine instructional efficiency, degrade interaction quality, and compromise the verifiability of adjudication [9,10]. Concurrency is inadequate, and fairness is difficult to quantify or guarantee. For the check-in stage, approaches based on Radio Frequency Identification (RFID)/Near Field Communication (NFC) [11], mobile apps [12,13], and face recognition encounter practical constraints in cost [14], privacy compliance, network/terminal dependencies, and deployment complexity. In school and training settings, attendance/sign-in platforms are often constrained by device heterogeneity and limited network availability. As a result, they provide poor support for offline operation and concurrent instruction across multiple classrooms [15,16]. For in-event interaction (e.g., buzz-in/answering), prevailing systems adopt a Microcontroller Unit (MCU) channel-based architecture of which concurrency is structurally limited by I/O resources and instruction cycles. Coupled with fixed Resistor/Capacitor (RC) timing that lacks configurability and temporal stability [17,18], such designs are ill-suited to diverse question types and rule sets [19,20]. In educational practice, these limitations hinder formative assessments and fair decision-making. They also restrict the adoption of instructional designs such as team-based learning and differentiated instruction [21,22]. Accordingly, a systematic approach is required to balance recognition accuracy, concurrent scalability, configurable timing, and implementation economy.

To address these issues, a robust QR-Code-recognition pipeline is constructed for check-in and identity binding. It comprises image preprocessing (denoising and adaptive thresholding/binarization) [23], Finder-pattern detection under connected-component and geometric-ratio constraints [24,25], perspective rectification aided by a Neighbor-Point Fusion algorithm [26], and error-correcting decoding via Reed–Solomon codes [27]. The pipeline achieves stable recognition under skew, non-uniform illumination, and partial occlusion [28,29], enabling the fast, accurate capture of contestant identity information. This capability directly reduces instructors’ registration workload and improves the organizational efficiency of large classes and school-wide events [30]. A prototype using the MATLAB Image Processing Toolbox the enables modular integration of 1D/2D code generation and recognition and rapid parameter tuning to camera and imaging conditions [31]; the method is platform-decoupled and portable for Python/OpenCV or embedded decoding libraries (e.g., the ZXing/OpenCV stack) [32,33]. As needed, the system can integrate with the university’s academic affairs and learning management systems to synchronize data. Compared with manual entry, the QR-Code solution substantially increases throughput and reduces entry errors, while supporting data traceability and system-level integration.

Building on this foundation, modular digital-logic architecture is adopted in the buzz-in module. Cooperating combinational and sequential logic replace conventional MCU channel-based designs. The system supports real-time interactivity for classroom quizzes and course competitions. Without an MCU, the scheme provides priority arbitration across ten concurrent inputs and a first-hit latching mechanism. At the hardware level, it implements premature-press suppression, time-out determination, time-limited answering, and reset/clear process control. For timing control, a 0–99 s configurable window (with extensible resolution) covers the chain “timed buzz-in → time-limited answer → timeout invalidation,” thereby avoiding the inherent limitations of fixed RC timing in configurability [34], temperature drift [35], and component tolerance [36,37]. Teachers flexibly configure time windows according to question difficulty and instructional objectives, enhancing the relevance and comparability of formative assessments [38,39]. In addition, a cascaded expansion path based on decoders, priority encoders, and counters enables scalable concurrency with deterministic hardware latency and fair arbitration, while keeping the bill-of-materials (BOM) cost under control. This enables scalable instructional organization from small groups to grade-wide and school-wide activities.

At the system level, this paper connects “recognition → identity binding → concurrent arbitration → configurable timing → process logging” into an integrated workflow and validates, via functional and stability tests, that the system stably presents key states—contestant identity, buzz-in priority group Identity document (ID), and response duration. With comparable hardware budgets, relative to MCU channel-based solutions, our design increases concurrent-channel capacity and affords more flexible timing control. In educational practice, this yields greater organizational flexibility and faster session turnover. In the check-in stage, the recognition pipeline maintains a high success rate under common imaging perturbations and markedly reduces manual entry errors. Consequently, it reduces teachers’ workloads and shortens the preparation time for classes and competitions.

At the system level, recognition, identity binding, concurrent arbitration, configurable timing, and process logging are integrated into a single workflow. Functional and stability tests validate stable presentation of key states—contestant identity, buzz-in priority group ID, and response duration. Under comparable hardware budgets, relative to MCU channel-based solutions, the design increases concurrent-channel capacity and affords more flexible timing control. In the check-in stage, the recognition pipeline maintains a high success rate under common imaging perturbations and markedly reduces manual-entry errors. Contributions are as follows:

(1) Robust QR-Code recognition and information acquisition for contest and education scenarios: an engineering pipeline of preprocessing → detection → rectification → error-correcting decoding, with a platform-decoupled, portable implementation.

(2) Scalable, low-cost digital-logic buzz-in module: hardware-level concurrent arbitration and 0–99 s configurable timing, with cascaded expansion and deterministic arbitration latency. It also supports two- or three-person team modes, promoting collaborative learning and peer assessment.

(3) A system-level verification framework is established to enable comprehensive functional validation, covering key metrics such as recognition accuracy and fairness in concurrent arbitration. This framework provides a reference for scalable, replicable deployment in event operations.

The remainder of the paper is organized as follows: Section 2 presents the system architecture and functional design. Section 3 details the participant registration workflow—code-type selection and sourcing, image preprocessing, and decoding. Section 4 describes the buzz-in and answering phase, covering the host module, timing module, violation-detection/alert module, and team-mode control. Section 5 reports system integration and performance evaluation, including registration simulations and scenario-based validation of rapid response, answering, violation, and time-out events. Section 6 presents conclusions and limitations and outlines future directions.

2. System Overview

The system comprises three components—Participant Information Registration and the Answering Stage—with the overall block diagram shown in Figure 1. On the software side, MATLAB is used to implement intelligent participant information registration and barcode management. On the hardware side, reliable digital circuits are constructed on the Multisim platform to support independent scoring for the compulsory round and rapid arbitration for the multi-participant (group) buzz-in module, forming a function-complete and workflow-transparent electronic competition platform.

(1) Participant Information Registration

This stage serves as the entry point of the contest and is responsible for identity verification and information entry for each contestant. Using MATLAB as the core tool and according to practical requirements (e.g., contestant ID and name), the system can generate a unique 1D barcode or QR Code for each contestant [40,41,42]. It also provides recognition capability to scan and decode the barcode supplied by the contestant, extract the complete registration profile, and supply identity evidence for subsequent stages.

(2) Answering Stage

Compulsory module. This round assesses contestants’ mastery of foundational knowledge in an independent-answering mode. The system supports flexible configuration, and its Multisim-based digital circuitry enables assigning up to nine questions per round. The circuit’s core function is to receive and process contestants’ answer signals and to update, in real time on a seven-segment display, the cumulative count of correctly answered questions.

Buzz-in module. This round emphasizes reaction speed and knowledge proficiency and supports simultaneous competition among multiple contestants. It also includes a team-versus-team mode supporting two- and three-person teams and is designed and implemented on the Multisim platform [43,44,45]. It comprises several functional modules, including a buzz-in input module, priority arbitration and latching circuitry, a timing module, a display module, a violation alarm module, and control logic. Its key capability is the efficient handling of simultaneous buzz-in requests from ten contestants. Once a contestant successfully buzzes in, the system enters a locked state, suppresses subsequent buzz-in signals, and explicitly indicates the successful contestant.

Participant-registration (QR-Code recognition) and hardware arbitration are decoupled. The arbitration module performs priority encoding/arbitration, first-trigger latching, configurable timing, and violation alerts entirely in hardware, without reliance on real-time communication with the host computer. When identity data must be synchronized with the event-management system, the registration terminal offers optional short-range serial links (RS-232 or USB–UART) to transmit small packets (≤32–64 bytes, with a simple checksum) carrying internal IDs, group assignments, and timestamps to the logging terminal. At 57.6–115.2 kbps, serial-link latency is typically <10 ms and does not affect arbitration timing or display. By default, arbitration bypasses the communication link.

3. Participant Information Registration

Design rationale of this stage.

(1) Determination of the recognition target. Based on the provided input (non-Chinese characters), the system can algorithmically generate a 1D barcode or a QR Code; alternatively, an existing barcode image can be imported.

(2) Real-world scenario simulation. Add common Gaussian and salt-and-pepper noise; then, apply five classes of degradations to the QR Code: smudging; shadowing/occlusion with uneven illumination; arbitrary-shape missing regions (e.g., torn edges); perspective-induced skew from tilted capture; and surface creasing.

(3) Denoising → binarization → localization → decoding. Perform denoising (Mean Filtering, Median Filtering, and Wiener Filtering) and compare the consistency of results across the three paths; then, conduct binarization, extract the symbology contour, identify Finder Patterns (positioning points), and decode the content.

3.1. Symbology Selection and Sources

3.1.1. Symbology Selection

Enter the symbology selection interface and provide two options via the listdlg function: 1D barcode and QR Code; 1D barcodes offer high accuracy, low cost, and fast input, and thus dominate many automatic identification applications. However, their information-bearing dimension is limited, as encoding typically occurs only along the horizontal axis with no vertical expressivity; therefore, the subsequent discussion focuses on QR Codes.

3.1.2. QR Code Sources

QR Codes can be obtained via camera capture and transmission or generated automatically by the system.

(1) External import. Design the GUI with GUIDE (MATLAB-R2022b), and use uigetfile to select and load an image file. The return values of uigetfile include the file name (filename), path (pathname), and filter index (filterindex), which together indicate whether the user has successfully selected a file. Then, save the image path and call imread to load the image; create an axes object with axes and finally display the QR Code image within the axes using imshow.

(2) System generation. Let the original data comprise k codewords and append 2t parity symbols (where t is the error-correction capability).

The data polynomial is denoted as follows:

$$D\left(x\right)=d_{k-1}{x}^{k-1}+d_{k-2}{x}^{k-2}+\cdots +d_0$$

(1)

The generator polynomial is denoted as follows:

$$g(x)=\prod _{i=0}^{2t-1}(x-{\alpha }^i)=(x-{\alpha }^0)(x-{\alpha }^1)\cdots (x-{\alpha }^{2t-1})$$

(2)

Expanding Equation (2) yields the following:

$$g\left(x\right)=g_{2t}{x}^{2t}+g_{2t-1}{x}^{2t-1}+\cdots +g_0$$

(3)

Parity symbols are then computed. Multiply D(x) by x^2t to obtain

$$M\left(x\right)=D\left(x\right)\cdot x^{2t}$$

(4)

Take the remainder of Equation (4) to obtain

$$R\left(x\right)=M\left(x\right)\mathrm{mod}g\left(x\right)$$

(5)

Therefore, the complete codeword is

$$C\left(x\right)=M\left(x\right)-R\left(x\right)$$

(6)

Its coefficients constitute the final codeword sequence and can be expressed as “original data + parity.”

In implementation, the Java classpath must be configured, and the ZXing open-source library is used to call the encode_qr function to generate the QR Code. QRCodeWriter and BarcodeFormat both belong to the com.google.zxing package and are utility classes required for QR Code generation. After importing them, create a QRCodeWriter object, perform the necessary data-type conversions, and use getHeight and getWidth to obtain the height and width of the drawing region. A zero matrix is then generated (rows mapped to height, columns to width) to control the output QR Code’s size specifications.

3.2. Image Preprocessing

3.2.1. Binarization

Grayscale values measure pixel luminance; grayscale conversion transforms a color image into a grayscale image, typically by combining the R (red), G (green), and B (blue) channels with weighted coefficients to form a luminance component. In this design, rgb2gray is first used to convert the color image to grayscale, preserving luminance and removing chroma; thresholding (e.g., Adaptive Thresholding (Otsu)) is then applied to complete binarization; finally, colormap (gray) is used to set the display colormap.

Converting an RGB image to a grayscale image reduces computational complexity:

$$I_{gray}=0.299\mathrm{R}+0.587\mathrm{G}+0.114\mathrm{B}$$

(7)

Here, R, G, and B denote the pixel values of the three-color channels. When Adaptive Thresholding (Otsu) is adopted, this paper follows Otsu’s method. Let the grayscale image have L levels (typically L is 256) and let p_i be the proportion of pixels at gray level i. For a candidate threshold t, pixels are partitioned into background C₀ ([0, t]) and foreground C₁ ([t + 1, L − 1]). The class probabilities and means are

$$\begin{gathered} {\sigma }_b^2\left(t\right)={\omega }_0\left(t\right)\cdot {\omega }_1\left(t\right)\cdot {\left[{\mu }_0\left(t\right)-{\mu }_1\left(t\right)\right]}^2, {\omega }_0\left(t\right)=\sum _{i=0}^t{p}_i,{\omega }_1\left(t\right)=\sum _{i=t+1}^{L-1}{p}_i, \\ {\mu }_0\left(t\right)={\displaystyle \frac{{\sum }_{i=0}^{t}i\cdot p_i}{{\omega }_0\left(t\right)}}, {\mu }_1(t)={\displaystyle \frac{{\sum }_{i=t+1}^{L-1}i\cdot p_i}{{\omega }_1\left(t\right)}} \end{gathered}$$

(8)

where ${\omega }_0$ represents the pixel-accumulation probability for C₀, ${\omega }_1$ represents the pixel-accumulation probability for C₁, ${\mu }_0$ denotes the mean grayscale value for C₀, and ${\mu }_1$ denotes the mean grayscale value for C₁. The optimal threshold is

$$T=\underset{t\in \left[0,L-1\right]}{\mathrm{a}\mathrm{r}\mathrm{g}\mathrm{m}\mathrm{a}\mathrm{x}}{\sigma }_b^2\left(t\right)$$

(9)

When ${\sigma }_b^2\left(t\right)$ is maximized, T yields the clearest separation between foreground (QR Code black modules) and background (white regions). Under uniform illumination, a fixed-thresholding scheme can be used: choose a scalar threshold and set

$$BW(x,y)=\left\{\begin{array}{c}1,\mathrm{i}\mathrm{f} I_{gray}(x,y)>T\\ 0,\mathrm{o}\mathrm{t}\mathrm{h}\mathrm{e}\mathrm{r}\mathrm{w}\mathrm{i}\mathrm{s}\mathrm{e}\end{array}\right.$$

(10)

3.2.2. Real-World Scenario Simulation

In practical applications, differences between the processed image and the ground-truth scene—caused by imaging devices and environmental factors—can be regarded as noise. This factor is considered in our simulations, especially for system-generated QR Codes. To validate algorithmic effectiveness, this paper uses imnoise to add Gaussian noise (‘gaussian’) and salt-and-pepper noise (‘salt & pepper’); three denoising schemes are evaluated: Mean Filtering (imfilter), Median Filtering (medfilt2), and Wiener Filtering (wiener2). For the same QR target, all three paths are applied, and their output consistency is compared. In general, Wiener Filtering is more effective against Gaussian noise, whereas Median Filtering is superior for salt-and-pepper noise. The mathematical formulations of the three filters are provided in Appendix A.1.

3.3. Decoding

3.3.1. Localization

(1) Finder-Pattern Recognition.

A QR Code contains three Finder Patterns, which enable localization by scanning [46]. Along any direction, each Finder Pattern satisfies the black–white ratio 1:1:3:1:1 (see Figure 2). This paper denotes the corresponding module spans as A is 3-module, B is 5-module, and C is 7-module. In ZXing, QR Code processing comprises encoder (encoding), detector (localization), and decoder (decoding). This paper first encapsulates the Detector to perform QR localization. The Reader interface is a general-purpose decoder that takes a BinaryBitmap and returns a result; if only localization is required, one can call Detector.detect (operating on a BitMatrix) to obtain a DetectorResult.

Recognition workflow. Import the relevant ZXing packages; load the image as a BufferedImage, and, if needed, perform scale normalization and grayscale conversion. Wrap the image with a LuminanceSource (MATLAB-R2022b) (e.g., BufferedImageLuminanceSource), then generate a BinaryBitmap via HybridBinarizer (MATLAB-R2022b), and finally obtain its BitMatrix for use by the Detector/Reader. (If using OpenCV, contour extraction can be performed with findContours; in ZXing, the internal FinderPatternFinder handles this implicitly, so no explicit contour call is required.)

(2) Neighbor-Point Fusion Algorithm

First, neighboring candidate points are merged: for a point p_i, take the mean of all points within radius r as the new location,

$$p_{new}={\displaystyle \frac{1}{\left|S_r\right|}}{\sum }_{p_j\in S_r}{p}_j, S_r=\left\{p_j:‖p_j-p_i‖<r\right\}$$

(11)

Next, iterative shrinking is performed to remove isolated points. The iteration terminates when the number of iterations exceeds 10 or the remaining point count falls below 20. Finally, the homograph is estimated from the three localized Finder-Pattern corners to rectify perspective distortion [47]. The estimation procedure for the homography (perspective-transformation) matrix H is detailed in Appendix A.2.

3.3.2. Error Correction

(1) Finder-Pattern Recognition.

In QR Code recognition, error control is based primarily on Reed–Solomon (RS) coding, which is the standard error-correction mechanism for QR Codes. The workflow typically includes data block partitioning, parity generation, Galois-field (GF) operations, error localization, and error correction [48]. The theoretical derivations underpinning RS error correction are provided in Appendix A.3.

In practical acquisition, background surrounding the QR Code is often captured along with the code and introduces unnecessary interference. A morphological pipeline combining erosion and dilation is used to remove it. Specifically, fspecial (‘gaussian’) is used to build a Gaussian filter and, together with imfilter, to perform preliminary smoothing; graythresh selects an appropriate threshold; morphological dilation (imdilate) and erosion (imerode)—optionally with a structuring element defined by strel—are then applied. Dilation expands the foreground, whereas erosion contracts it, removes small speckles, and smooths boundaries. The result facilitates cleaner separation of individual graphical elements.

In addition, QR decoding leverages block-wise RS coding. Data codewords are segmented according to the QR version and error-correction level. Parities are generated using the Reed–Solomon procedure, and each segment is processed through polynomial long division. The long-division process consists of three steps: (1) choose a term to multiply the divisor so that the product’s leading term matches the dividend’s leading term; (2) subtract this product from the dividend to obtain a new remainder; and (3) repeat until elimination can no longer proceed, yielding the final remainder. For example, dividing 3x² + x − 1 by x + 1 yields the quotient 3x − 2 with remainder 1.

Once the generator polynomial is fixed, data codewords correspond to the coefficients of the data polynomial ordered by decreasing degree, and the final remainder corresponds to the parity codewords, likewise ordered by degree. When parts of a QR Code are occluded or smudged, the parity symbols often still enable correct decoding. Incorporating RS decoding markedly improves robustness and accuracy.

3.3.3. Information Extraction

To realize QR Code recognition, BufferedImage, LuminanceSource, and BinaryBitmap are used, and the key recognition class is QRCodeReader, which decodes the input QR image according to the encoding rules to obtain the content [49]. The overall encapsulated workflow is shown in Figure 3. The information-extraction stage follows the upstream pipeline described earlier—image preprocessing → localization → neighboring-point fusion → perspective correction → RS error correction. Before constructing the LuminanceSource or HybridBinarizer, lightweight denoising is applied to the BufferedImage—or to the Region of Interest (ROI) identified by the Finder Pattern—to stabilize thresholding and corner detection. The processed image then enters ZXing’s binarization and decoding workflow. For reproducibility and learning analytics, per-decode metadata—timestamps, corner coordinates, RS error-correction level, and processing time—are logged. A typical ZXing decoding pipeline proceeds as follows:

(1) Import ZXing classes and convert the raw image to a Java BufferedImage (scale normalization and grayscale conversion may be applied at this stage to improve stability).

(1a) Luminance-Domain Denoising. After scale normalization and conversion to grayscale—but before constructing the LuminanceSource—apply small-kernel denoising to suppress random noise and preserve local contrast (e.g., mean-, median-, or Wiener filtering). The selection principle is to apply the minimal necessary smoothing to avoid blunting the Finder-Pattern edges due to over-smoothing. For an ROI workflow, first pad the ROI boundary by 5–10% to accommodate perspective-correction error; then denoise within the ROI before binarization. The filtering can be implemented on the Java side, or denoised outputs from upstream modules can be reused.

(2) Use BufferedImage/LuminanceSource to extract luminance and determine image size; apply HybridBinarizer to obtain a binarized representation and construct a BinaryBitmap. For low-contrast or shadow-dominated inputs, apply lightweight denoising per Step (1a) before constructing the BinaryBitmap. If decoding remains unsuccessful, switch to the GlobalHistogramBinarizer as a fallback binarization path.

(3) Invoke QRCodeReader to decode the BinaryBitmap, returning a Result object from which the text and metadata (e.g., format, version, and localization corners) are obtained. To mitigate privacy risks, the decoding stage logs only essential fields by default—internal identifiers and event timestamps and durations. Raw camera frames do not persist to the disk by default. Any retention for fault reproduction requires authorization from the course administrator and must comply with course policies.

(4) In engineering practice, decoder hints can be set to enhance robustness, such as CHARACTER_SET = UTF-8, enabling TRY_HARDER, and constraining POSSIBLE_FORMATS = QR_CODE. Scene-adaptive configuration recommendations (hints): POSSIBLE_FORMATS = {QR_CODE}. Limit candidate formats to reduce the search space and latency. CHARACTER_SET = UTF-8. This ensures the robust decoding of multilingual participant information. TRY_HARDER = true (for low-contrast or weak-texture scenes). The enables a more exhaustive search at the cost of additional latency. PURE_BARCODE = true only when the ROI tightly contains the QR Code with a clean quiet zone. This skips localization and decodes directly, reducing latency; otherwise, leave it false to avoid failures. RESULT_POINT_CALLBACK = <callback>. Logs detected result points (Finder corners and the alignment point) for visualization, debugging, and error localization.

(5) Failure–Fallback and Consistency Strategy. When a single decoding attempt fails or multi-path outputs are inconsistent, retries proceed in the following fixed order: (i) Binarizer swap: HybridBinarizer ↔ GlobalHistogramBinarizer; (ii) Multi-scale: 0.75×, 1.0×, 1.5×; (iii) Rotation: 0°, 90°, 180°, 270°; (iv) Progressive denoising: none → light (3 × 3) → moderate (5 × 5; only if necessary); (v) ROI policy: attempt the ROI first; fall back to the full image on failure. If multiple alternative decodes are returned, apply a majority-vote rule (≥2 identical decoded strings) and log all attempted parameter combinations—including failures—together with image hashes to ensure reproducibility.

4. Answering Stage

This stage can be configured in either compulsory or buzz-in mode, as shown in Figure 4a. The system comprises the Moderator Switch Module, Buzz-In Timing Module, Answer Timing Module, and Violation Alarm Module and supports up to 10 contestants simultaneously. Each contestant is assigned an independent push button; the moderator’s master switch starts/resets the buzz-in process. The system performs buzz-in signal discrimination, first-hit latching, and result display: when any contestant presses first, the corresponding LED indicator turns on with an audible prompt, and the system immediately enters a locked state so that subsequent presses are ignored. Additional extended functions include the following:

(1) Violation alarm: if a contestant presses prematurely, the alarm indicator illuminates, and an audio prompt is issued via the loudspeaker;

(2) Timed buzz-in: the buzz-in window is configurable up to 99 s according to task requirements; each buzz-in module is triggered by the moderator, and an indicator light signals activation;

(3) Answer-time limit: beyond the buzz-in countdown, an answering time limit is enforced; the remaining time and buzz-in moment are shown on the seven-segment display and retained until moderator reset;

(4) Timeout invalidation: if no one buzzes in before the window closes, the round is declared invalid; the system locks out input channels, forbids late answers, the countdown shows “00,” and an audible prompt is issued.

Primary components and their functional roles.

(i) Priority encoding and first-trigger latching. 74LS148×N (8 → 3 priority encoder, active-low; channels expandable via EI/EO cascading) and 74LS175 (quad D flip-flops) latch the first-trigger channel and synchronize it to the system clock.

(ii) Indication and display. 74LS138 (3 → 8 decoder; cascade via enable pins to expand indicator lines) and CD4511 (BCD-to-7-segment latch/decoder/driver) drive seven-segment displays (channel number and remaining time), LEDs, and the buzzer.

(iii) Mode/team selection. 74LS145 (BCD-to-decimal 10-line decoder, active-low) works with 74LS148 and enables it to realize solo/team mode switching. Same-team buttons are combined via diode-OR (wired-OR in active-low logic) into one 74LS148 input so any member press pulls the line low.

(iv) Timing and time base. Two 74LS192 synchronous up/down decade counters (with preset) form a 0–99 s timing chain; a 555 provides a 1 Hz time base; glue logic (AND/OR/NOR/inverters) handles polarity and gating.

(v) Synchronization. A two-stage JK/D flip-flop chain performs reset/latch gating.

4.1. Moderator Module

4.1.1. Moderator Main Switch

Figure 4b provides a brief overview; the detailed structure is shown in Section 5.1.1. The module orchestrates overall control of the circuit. (1) An 8-to-3 priority encoder and a D flip-flop generate the buzzer-mode control signals S21 (single-player), S22 (two-person team), and S23 (three-person team). (2) A dual JK flip-flop generates a start pulse to initiate buzz-in timing; after processing in the Buzz-In Timing Module and the Answer Timing Module, the signal is delivered to the stop-timing/alarm unit to terminate the sequence. (3) A D flip-flop generates the buzz-in start command and injects it at the entry of the buzz-in circuit; after the Buzz-In Timing Module, the signal passes through a decade counter and combinational logic and is then fed to the Violation Alarm Module. Two indicator lights are provided to intuitively show whether the buzz-in module has started and whether any premature press has been detected.

Timing is configured via hardware buttons: a ten-setting key and a unit-setting key write the corresponding digits to the synchronous programmable counter, while the LED display updates the setting in real time. Setting rule: press the key n times to set digit n (1–9); press it 10 times to set 0. After configuration, the host initiates the countdown by engaging the main control switch. The settings are latched and cannot be modified during the countdown. The reset button clears both the stored value and the display. The interface is independent of GUIs and software-controlled registers, enabling offline, low-cost deployment.

4.1.2. Moderator Counting

This independent unit provides counting switches for the moderator to record the number of correct answers. Figure 5a shows the seven-segment display for a single contestant. In total, nine moderator-controlled switches are connected to the display through a decoder/driver. Initially, the display shows 0; when the contestant answers one question correctly, pressing switch S1 updates the display to 1; when three are correct, pressing S3_1 and S3_2 (driven by the same control command and switchable simultaneously) updates the display accordingly; other counts proceed analogously.

4.2. Timing Module

4.2.1. Buzz-In Timing

The buzz-in function requires the following: each contestant has a dedicated buzz-in button (pressing asserts a buzz-in signal); the moderator has a control button to reset and to announce the start of the round. Once the contest begins, the first press is declared successful; the system then locks the remaining nine input channels to prevent further buzz-ins, and the corresponding LED indicator lights up.

(1) Scheme One

As shown in Figure 5b, the circuit comprises ten 74LS74 dual D flip-flops, 74LS32 OR gates, and a multi-stage network implementing a ten-input NAND gate. Two functions are achieved: (i) determine press order, latch and display the first-pressed channel; (ii) invalidate all other contestants’ buttons. This is accomplished by feeding back a latch-control signal from the ten-input NAND to the inputs, thereby forming a self-latching loop. When the moderator presses control switch S, the D flip-flops are asynchronously reset low (active-low reset), giving Q is 0 and Q′ is 1; the ten-input NAND output is therefore low. With S₁–S₁₀ unpressed, all OR-gate inputs are high, and the D flip-flops remain in the armed state (S′ is 1, R′ is 0); thus, Q₁–Q₁₀ are 0 and the indicator LEDs are off. After the moderator releases S, the buzz-in module starts. If the first team presses (S₁ is 0), then Q₁ is set to 1 and the corresponding indicator turns on; simultaneously, the complement output Q₁′ is 0 drives the NAND-gate network to a high level, generating a high-level latch-control signal that is fed back to each channel’s OR-gate input, forcing S′ high and thereby masking subsequent key-press signals on all remaining channels.

(2) Scheme Two

The CD4511 (hereafter “4511”) is a BCD–seven-segment latch/decoder/driver for common-cathode displays. It provides BCD conversion, blanking, latch enable (LE), seven-segment decoding, and segment driving and can directly drive LED seven-segment displays. Pins 1, 2, 6, and 7 serve as BCD inputs and are therefore connected to the encoded outputs of the contestants’ buttons. Pins 9–15 are the segment outputs (a–g), wired one-to-one to the display to show the ID of the first contestant who presses. Pin 3 (LT, Lamp Test) is the test input; when LT is 0, all segment outputs go high (all segments on), enabling the display test. Pin 5 (LE) is the latch-enable input; when LE transitions from low to high, the current display state is latched and held.

As shown in Figure 5c, S₁–S₁₀ form the ten buzz-in buttons; pressing any button is encoded by a diode network into a BCD code, which is then applied as a high level to the corresponding inputs of the CD4511. From the pin functions, pins 6, 2, 1, and 7 correspond to BCD bits D, C, B, and A, respectively (with D the Most Significant Bit (MSB) and A the Least Significant Bit (LSB), i.e., weights 8, 4, 2, and 1). For example, when contestant 8 presses, a high is applied to pin 6 of the CD4511, while pins 2, 1, 7 remain low, so the input BCD is “1000.”

To satisfy the buzz-in requirement, a priority-latch network determines the first event, latches that code for display, and suppresses subsequent presses. This is realized by using the CD4511 internal latch/decoder together with a control network built from transistor Q₁, resistor R₂₁, and diodes D₁₂/D₁₃. When no one has pressed, all BCD inputs of the CD4511 are pulled down by 1 kΩ resistors, giving “0000.” In this state, segment outputs a–f are high and g is low (displaying “0”). After the buzz-in period starts, pressing any button causes either segment d to go low or segment g to go high (at least one condition holds). The Q₁–R₂₁–D₁₂/D₁₃ network then drives LE from 0 to 1, latching the current BCD input so that a–g hold the displayed value until reset.

(3) Scheme Three

As shown in Figure 5d, a 74LS148 is used as an 8-input priority encoder. To support ten contestants, two devices are cascaded by connecting the EO (enable-out) of the first to the EI (enable-in) of the second, forming a 16-to-4 priority encoder; unused inputs are tied high. Initially, the moderator’s switch is in reset, so the outputs Q₁–Q₄ of the 74LS175 quad D flip-flop are low and the latch path is inactive. When the moderator starts the round, the priority encoder and the latch are enabled and the system enters a waiting state. When a contestant presses, the corresponding channel line is pulled low and presented to the encoder. The 74LS148 performs 8-to-3 priority encoding on active-low inputs I₀–I₇ (priority I₇ highest, I₀ lowest). Because its outputs are active-low, they are passed through NAND/inverter stages to obtain positive logic before being applied to the 74LS175; the GS (group-select, active-low) output is also routed as the fourth bit or as an enable/control input. After being latched by the D flip-flops, the code is passed to a 74LS138 3-to-8-line decoder. Among the four D inputs, D₁–D₃ carry the contestant channel code; thus, Q₁–Q₃ are fed to the 74LS138, and, together with GS/enable signals, a 10-channel mapping is realized. Since the 74LS138 outputs are active-low, they are inverted to drive the LED indicators.

The latching behavior is completed in conjunction with a 74LS160 synchronous decade counter and feedback gating. If contestant A presses S₁, the output Q₁ of the 74LS175 goes low-to-high and the corresponding indicator turns on. In parallel, the four latch outputs are ORed and fed back to the control/enable network, forcing the relevant paths into a high-level mask state so that subsequent presses on other channels are rendered invalid.

By comparison, Scheme One requires a larger number of flip-flops; Scheme Two relies on a back-and-forth toggle action, which is less convenient than a microswitch and less suitable for repeated operation. Scheme Three is therefore adopted, and the resulting design is as follows.

Figure 6 illustrates the workflows of the system’s three functional modules. The left-hand module is the buzz-in timing module. It handles “mode selection → host sets 0–99 s → counter presetting → initiate buzz-in → first-trigger latch/LED indication → start answer timing or, on time-out, lock inputs.” The center module is the answer-timing module. After the first buzz-in, a 1 Hz clock drives the countdown, which is shown in real time on the seven-segment display. On time-out, audible/visual alarms assert, and the lockout persists until a host resets. The right-hand module is the violation-alarm module for early buzz-in detection. On a level change, it lights the alarm LED and generates a 1 Hz pulse train. Pulses are counted in decimals; the tenth pulse issues a carry that silences the buzzer. The left-hand buzz-in timing module comprises mode decoding/gating and programmable counting (e.g., mode gating via 74LS145/74LS148, synchronous programmable decimal counters, and latch/mask logic). Hardware details appear in Section 5.1.1. The countdown is shown on a seven-segment display. Ten push buttons and corresponding indicator LEDs—one set per contestant—are arranged in parallel and, together with the moderator’s control switch, constitute the inputs. If any contestant presses prematurely, the Violation Alarm Module is triggered and a red indicator on the moderator side illuminates. When the round begins, the moderator presses the control switch, and a D flip-flop drives a green “round active” indicator. At the same moment, the digital timer display begins counting down. When the first participant presses the buzz-in button, the first-trigger latch asserts and activates the corresponding LED indicator. Concurrently, the timer module stops and latches the displayed time at the press instant. The latch maintains this state and invalidates all subsequent presses. Simultaneously, the countdown displays lights and begin timing the answer window.

Two violation-alarm modes are implemented. (i) Early buzz-in: if a participant presses before the host engages the start switch, the alarm triggers. The red conflict indicator illuminates and the buzzer sounds. (ii) Time-out: if the countdown expires without a buzz-in, the orange time-out indicator illuminates and the buzzer sounds.

Simultaneous buzz-ins and protection window. The front-end shaping and synchronous-latch circuitry yield a minimum resolvable inter-press interval of 10 ms. If the inter-press difference between two participants is <10 ms, adjudication may be ambiguous; the priority encoder may resolve the tie by channel precedence. The system uses first-trigger latching with a 10 ms protection window: immediately after the first latch, all other channels are masked. The contention event is logged for review and adjudication records. The system uses a local offline architecture; arbitration and timing are independent of networking, so core functionality is unaffected by network interruptions.

To accommodate diverse scenarios, the team-versus-team buzz-in mode is extended to support two- or three-member teams, as shown in Figure 5e. In conjunction with Section A of the main schematic, when the moderator selects a mode, the associated buzz-in enable is activated, whereas the enable lines for other modes remain disabled. A press by any team member within the configured time window registers a successful team buzz-in. The signal propagates through a flip-flop to the LED indicator, illuminating the member’s channel LED. The latch holds this state until the moderator resets, preventing subsequent presses from other teams.

The buzzer system provides a configurable response window of up to 99 s, adjustable per question requirements. Each response round is initiated by the host (via the main control switch). Timing is configured via two hardware keys (tens-setting and units-setting), which write the digits to their respective counters; the LED display updates in real time. The host main control switch initiates the countdown, and a green indicator shows the active state. During the countdown, the setting is latched and cannot be modified; it can be cleared only after the cycle completes or via manual reset. Push buttons are used in place of Dual Inline Package (DIP) switches to reduce size, enable flexible adjustments, lower the risk of mis-operation, and improve usability.

If the countdown expires with no contestant buzzing in, the round is declared invalid. The countdown shows “00”; a logic path composed of OR/NOT stages drives the buzzer to issue a stop-timing alert; simultaneously, contestant inputs are controlled so that the input channels are locked out, preventing late answers.

4.2.2. Answer Timing

As shown in Figure 6, this module follows principles like the previous one. The buzz-in event generates an input that is combined by a synchronous programmable counter to drive the seven-segment display corresponding to the answer time; the answering window is limited to 60 s. Two synchronous counters are cascaded to extend the bit width; a BCD decoder/driver then feeds the displays for the ones and tens digits of the answering countdown. The counting clock is provided by an oscillator built from a timer; the remaining answer time is displayed on the seven-segment display and held until moderator reset.

4.3. Violation Alarm Module

As shown in Figure 6, a ten-input AND network is formed at the contestants’ button inputs. When a contestant presses prematurely, the corresponding input goes low; after inversion, the signal drives the alarm LED. Because push buttons are used and no latching is involved in the alarm path, the output remains high only briefly before returning low, producing a blinking alarm indication.

An audible indication is also provided: a decade counter is clocked by a 1 Hz pulse from the pulse-generation circuit. When the count reaches the 10th second, the carry-out toggles from low to high and, after inversion, is fed to the buzzer input to stop the tone. Consequently, if a contestant presses before the moderator announces the start, the alarm is triggered: the alarm LED blinks, and the buzzer emits a 9 s tone that stops automatically at 9 s.

For both the countdown and the 9 s alarm, a 1 Hz pulse generator is required to produce a rectangular wave with a stable amplitude and accurate period (target period, 1 s, i.e., 1 Hz). As shown in Figure 7a, the implementation employs a 555 Timer Astable Oscillator (Texas Instruments, headquartered in Dallas, Texas, USA.) with external resistors and a capacitor. The supply Vcc charges the capacitor through R₄₂ and R₄₃, raising the capacitor voltage. When the capacitor voltage reaches the upper threshold (2/3 Vcc), the output Uo goes low and the internal discharge switch turns on; the capacitor discharges through R₄₃, causing the voltage to fall. When the capacitor voltage drops to the trigger threshold (1/3 Vcc), Uo goes high and the discharge switch turns off. Repeating this process yields a stable oscillation that provides the 1 Hz time base for the system.

In a 555 Timer astable configuration, the charge time T_H (from 1/3 Vcc to 2/3 Vcc) and discharge time T_L (from 2/3 Vcc to 1/3 Vcc) are

$$T_H=0.693\left({\mathrm{R}}_{42}+{\mathrm{R}}_{43}\right){\mathrm{C}}_1,T_L={0.693\mathrm{R}}_{43}{\mathrm{C}}_1$$

(12)

Hence, the period and oscillation frequency are

$$T=T_H+T_L=0.693\left({\mathrm{R}}_{42}+2{\mathrm{R}}_{43}\right){\mathrm{C}}_1, f={\displaystyle \frac{1}{T}}$$

(13)

Substituting into T (cf. Equation (13)) gives 0.998 s, so f is 1.00 Hz.

$${\mathrm{R}}_{42}=20 \mathrm{k}\mathsf{\Omega }, {\mathrm{R}}_{43}=62 \mathrm{k}\mathsf{\Omega },{\mathrm{C}}_1=10 \mathsf{\mu }\mathrm{F},$$

(14)

The astable output is shown in Figure 7b. With an oscilloscope attached to the pulse-generator output, the waveform period is observable; moving the oscilloscope cursors yields a single-cycle duration of 1 s, confirming the practicality of the design.

5. System Integration and Performance Testing

5.1. System-Level Evaluation

5.1.1. Functional Testing Results

The simulation-and-verification workflow for the system’s three-layer robustness chain—pixel level (filtering + Otsu), geometric level (Neighbor-Point Fusion + Perspective Rectification), and codeword level (Reed–Solomon error correction)—is shown in Figure 8a. The figure provides a systematic, end-to-end protocol and stress setup for the Participant Information Registration subsystem: Construct Participant QR Code Repository generates and manages a unique QR Code per contestant; after Symbology Selection, the input source is the on-site Real-World Image Input. To emulate real contest conditions, seven representative perturbations are injected on the input side (green modules): Salt-and-Pepper Noise, Gaussian Noise, Shadowing, Skew, Surface Creasing, Missing Regions, and Smudging, thereby testing robustness under both random noise and structural distortions. The pipeline then enters Image Preprocessing (purple modules): Grayscale Conversion followed by Adaptive Thresholding (Otsu) for stable binarization; three denoising branches—Mean Filtering (imfilter), Median Filtering (medfilt2), and Wiener Filtering (wiener2)—are run in parallel and Assess Result Consistency compares the decoded outputs of the three paths on the same QR target as a pixel-level robustness criterion. In Decoding (blue backbone), two key reinforcements (yellow modules) are included: Neighbor-Point Fusion averages candidate key points within radius r and iteratively shrinks to remove outliers, stabilizing the three Finder-Pattern coordinates; Perspective Rectification estimates the homograph H from the three corners, removing tilt-induced trapezoidal distortion. The geometrically rectified bitstream is then passed to Reed–Solomon Error Correction for syndrome computation, error localization, and correction, maintaining decodability even under occlusion or damage. Recognition Results output the contestant identity and related metadata and transition seamlessly to Awaiting Answer, linking to the hardware chain of concurrent arbitration, configurable timing, and violation alarm.

The above reproducible criteria—agreement across multiple preprocessing/decoding paths and successful localization → rectification → RS-based recovery under diverse perturbations—are consistent with the portable implementation (MATLAB/ZXing), recognition-accuracy goals, and system-level integration objectives, thereby providing clear experimental evidence for scalable deployment. As an illustrative example, Figure 8b shows the 1D barcode, QR Code, and recognition output for contestant Zhang San from the Shu Guang team (ID 01).

To further assess the robustness of the registration process, identification success-rate tests were conducted under seven representative disturbances. Gaussian and salt-and-pepper noise were synthesized with MATLAB imnoise; the remaining disturbances were applied manually in 60 groups at graded intensities. Each group used a random subset of source QR Codes to reduce selection bias. In addition to recognition accuracy (Acc), the metrics included a consistency ratio (Consis—the fraction of correct cases whose three-path denoising decodes yielded identical text) and per-sample processing time (Time).

Table 1. Test results under different perturbations.

Perturbations	Acc (%)	Consis (%)	Time (ms)
Salt-and-Pepper Noise	90.0	72.2	14
Gaussian Noise	90.0	77.8	14
Shadowing	83.3	68.0	14
Skew	93.3	86.0	12
Surface Creasing	86.7	74.0	14
Missing Regions	78.3	61.7	15
Smudging	85.0	72.5	14
Average	86.7	73.6	14

reports results across the evaluated perturbations. After neighboring-point fusion and perspective correction, skew/perspective distortion retains high Accuracy (93.3%) and Consistency (86.0%). Local low contrast from shadows or smudges reduces Consistency, whereas Accuracy remains at 83–85% with TRY_HARDER, with moderate ROI relaxation and mild denoising. With missing-pixel occlusion, Acc is 78.3%, mainly because occlusion induces codeword-field loss beyond the correction capability of RS codes. The computation time varies little across perturbations, indicating a limited and controllable impact on system latency. Overall, the system achieves a mean Acc of 86.7%, mean Consis of 73.6%, and mean per-sample computation time of 14 ms across perturbations.

Answering the stage simulation workflow is shown in Figure 8c. After the moderator sets the countdown and presses the control switch, the green indicator lights to denote the start of the buzz-in module; contestant #6 then presses first at 31 s, the corresponding blue indicator turns on, other buttons are immediately disabled, and the answer timer starts from 60 s. Figure 9a shows the answering countdown at 58 s. The violation-alarm simulation in Figure 9b indicates a red light and an active buzzer upon premature buzz-in. The timeout-no-buzz simulation in Figure 9c shows that when the moderator’s buzz-in window ends with no contestant response, the timeout buzzer activates and the timeout indicator lights; pressing the reset switch returns the system to its initial state.

Participant scalability is realized through two components: single-user expansion and team expansion.

(1) Single-user expansion. The prototype employs two 74LS148 priority encoders for single-user buzz-in detection, providing up to 16 independent buttons. For larger channel counts (e.g., 24 or 32), additional 74LS148 devices can be cascaded per the datasheet. To display the first-to-press channel, the encoded output is latched (e.g., 74LS175) before being decoded by the 74LS138. When more than eight channels are required, indicator lines are expanded by cascading 74LS138 decoders via their enable pins. Button inputs follow an active-low convention, and jitter/retriggers are suppressed by the existing shaping and first-trigger latching.

(2) Team expansion. The system supports team-based modes for pairs and trios. Buttons from the same team are combined through diode-OR wiring (wired-OR for active-low) into a single active-low input of the 74LS148; this prevents cross-channel back feed and interference. Unselected team lines are held high. Mode switching uses the 74LS145’s active-low selection outputs together with the enable/gating pins of the 74LS148: only the selected team’s network is enabled, and other modes are gated off. Thus, in two- or three-person modes, pressing any button within the team asserts that channel. Subsequent processing follows the “first-trigger latch → display indication” sequence, while unselected paths remain disabled.

5.1.2. Performance Comparison

Table 2. Performance comparison of different technical schemes.

Technical Schemes	System-Level Power Consumption (W)	Cost ($)	Deployment Complexity
FPGA	5–10	80–200	Challenging
STM32	0.7–1.5	30–50	Difficult
Arduino Mega 2560	0.7–1.2	23–40	Moderate
ESP32	0.6–1.0	16–30	Moderate
This system	1.5–3.0	25–40	Moderate

compares the power, cost, and deployment complexity across the technical solutions. Comparisons assume identical peripherals and loads: 5 V supply; a two-digit seven-segment display (10 mA per segment, 1/2 multiplexing); 10 indicator LEDs (two lit on average, 5–10 mA each); and a buzzer with a ≈10% duty cycle. System-level power equals board power plus peripheral-driver power. With identical peripherals, system-level power for the discrete 74-series design is dominated by LED/seven-segment drivers and falls in the ≈1.5–3.0 W range. Comparable MCU/ESP32/STM32 designs with the same peripherals show similar or slightly lower system-level power. The small-batch prototype BOM (74xx/4000 + seven-segment/LED/buzzer + PCB/connectors) is ≈$25–$40; MCU/ESP32 solutions with equivalent peripherals are comparable; FPGA dev-board solutions are substantially higher. Deployment complexity is graded as follows: this system—no firmware, plug-and-play, but extensive wiring (Moderate); Arduino/ESP32—mature Integrated Development Environment (IDEs)/libraries (Moderate; basic firmware and wiring required); STM32—substantial peripheral/middleware configuration (Difficult); FPGA—HDL development, timing closure, and power planning (Challenging). Overall, the system compares favorably in power, cost, and deployment complexity.

The engineering focus is determinism, fairness, and offline usability rather than aggressive reductions in power or the BOM cost. Priority encoding and first-trigger latching are realized at the gate level; worst-case delay is set by logic-propagation and the time base and is immune to firmware scheduling, interruptions, and load variation. The 0–99 s timing is loaded via the 74LS192 preset (synchronous-load) pins. Answer-timing presets are fixed, improving usability and reducing the error risk. Participant expansion is realized by cascading 74LS148 priority encoders and 74LS138 decoders, keeping timing/priority effects transparent. This facilitates debugging and auditing in educational and examination settings. These conclusions apply only to prototype-level implementations under the stated assumptions. Commercial products are excluded because the integration level and drive strategy vary widely, yielding non-comparable power and cost.

5.2. Usability and Ethical Considerations

This system operates offline and provides a compact interface comprising a main control switch, indicator lights, and a digital display. It supports single-user and two- or three-person team modes, with configurable 0–99 s timing and one-touch reset. A first-trigger latch and audible/visual alerts for violations and time-outs make decisions auditable and immediately perceivable. These features facilitate on-site orchestration for classroom and school-wide events.

Data processing follows data-minimization and purpose-limitation principles: QR Codes encode only an internal identifier (optionally, a group identifier) and no facial or other biometric data; camera frames are processed in memory and are not stored by default; persistent records comprise structured event-level metadata (timestamps, channel/group selection, buzz-in/response durations, violation/time-out events, internal identifier) for classroom statistics and post-event analysis. By default, logs are stored locally on the competition terminal; data are not uploaded to third-party services. Exports are local files (e.g., CSV) to enable integration with campus teaching platforms.

For educational deployments, randomized internal identifiers are recommended, with local mapping tables maintained by course administrators. Retention should comply with course or school privacy policies; detailed data should be purged periodically, retaining only the aggregated statistics necessary for pedagogical evaluation.

5.3. Portability and Runtime Performance

The system’s information-extraction and decoding pipeline comprises platform-agnostic pixel/geometric operations and a standard decoding library, supporting portability. Grayscale conversion and lightweight denoising used in the prototype can be realized with equivalent operators on mobile/embedded devices. Perspective correction uses a single-view planar homography estimated from the three Finder-Pattern references, and the decoding stage reuses the ZXing implementation consistent with the prototype. To balance latency and compute on mobile/embedded platforms without compromising correctness, the system adopts ROI-first decoding with fallback to the full image, short-edge normalization, and on-demand retries (HybridBinarizer → GlobalHistogramBinarizer; multi-scale/rotation triggered only on failure). POSSIBLE_FORMATS = {QR_CODE} constrains the search space; TRY_HARDER is enabled only in low-contrast scenarios; PURE_BARCODE is attempted only for near-pure ROIs (tight crops with a clean quiet zone). Based on desktop phase-wise measurements (Table 1), the mean per-sample time for information extraction is ≈14 ms, with limited variation across perturbations. These measurements serve as scale references; platform-specific real-time performance and power consumption on target mobile/embedded devices will be reported in subsequent prototype tests.

6. Conclusions

An integrated information-recognition and multi-participant quiz system tailored to educational competitions has been proposed and validated, encompassing participant registration, team formation, and buzz-in adjudication. For registration, a portable barcode pipeline (MATLAB/ZXing) integrates 1D/2D code generation and recognition, coupled with grayscale conversion → Adaptive Thresholding (Otsu) → Neighbor-Point Fusion → Perspective Rectification → Reed–Solomon error correction, which markedly increases throughput and reduces manual-entry errors. The Multisim-based compulsory-round circuitry, together with seven-segment displays, supports up to nine questions with independent scoring for accurate recording and cross-checking. To enrich the buzz-in experience, the team-versus-team mode has been extended to support two- or three-person teams. For the buzz-in module, a priority-encoding with first-hit latching digital-logic scheme enables deterministic arbitration across 10 concurrent inputs; a 0–99 s configurable buzz-in window and a 60 s answering countdown are provided, along with violation alarms for early presses, overcoming limitations of fixed timing and channel-bound designs.

Functional and stability simulations indicate the stable presentation of identity/group/time states, reliable first-buzz latching with effective masking of subsequent channels, and suitability for rapid deployment in small- to mid-scale contests, improving the registration accuracy and adjudication/recording efficiency. A 1 Hz time base derived from a 555 Timer astable oscillator ensures timing accuracy and repeatability. Relative to MCU channel-based architectures, the proposed digital-logic design relaxes hardware-channel constraints, delivers predictable arbitration latency, and offers flexible timing configuration, while preserving cascadability and cost controllability. The integrated workflow—recognition → identity binding → concurrent arbitration → configurable timing → process logging—facilitates replicable deployment and end-to-end traceability across the contest lifecycle. The Participant Information Registration subsystem achieved a mean accuracy of 86.7% and a mean per-sample computation time of 14 ms.

The primary limitations stem from the verification approach, which is dominated by simulation and functional testing. The prototype verifies logic correctness and latch/register robustness under ten concurrent channels. Further participant scaling is constrained by the propagation delay, fan-out, and routing complexity introduced by cascading 74LS148/138 devices. Timing accuracy is limited by the 555-timer RC tolerances and temperature drift. Timing distributions for input-side key bounce and asynchronous arrivals have not yet been measured on physical hardware. QR-Code recognition remains borderline under large-area occlusions that exceed RS correction capability or under extreme shadowing/perspective. Future work will evaluate physical prototypes for high-concurrency cascading and system stability. Planned measurements include arbitration-delay and jitter distributions and timing-error statistics under uniform conditions at full load. Mitigations will include Schmitt-trigger shaping, hardware de-jittering, synchronous clocking, and an XO/TCXO-derived time base via frequency division. The end-to-end recognition accuracy and processing time under field perturbations will be reported; cross-platform porting (e.g., Python/OpenCV) and mobile-acquisition integration will be advanced. Ultimately, comparative data on scalability and stability will be provided against representative systems, and circuit-/parameter-level optimizations will be performed based on prototype results.

Future cross-platform deployment roadmap. Implement grayscale conversion, lightweight denoising, binarization, Finder-pattern localization, and homography-based perspective correction with Python/OpenCV; use ZXing-cpp for decoding to preserve workflow equivalence. Optimize latency on ARM-based single-board computers (SBCs) and mobile devices using ROI-first decoding, short-edge normalization, and on-demand fallbacks (HybridBinarizer → GlobalHistogramBinarizer; multi-scale/rotation triggered only on failure). Measure end-to-end latency and power consumption and perform bottleneck analysis (per-step timings for image reading, binarization, and decoding); then, conduct parameter restriction/tuning and lightweight optimizations based on the findings. After ethical approval, conduct small-scale classroom pilots and present side-by-side comparisons against an MCU channel–based buzzer system.