{"id":"68a90f99-f47f-4d87-a3f8-7dff66debe4d","arxiv_id":"2506.23004","paper_version":1,"verdict":"REJECT","confidence":"LOW","novelty_score":4.0,"correctness_risk":"high","formal_verification":"none","parameter_count":5,"one_line_summary":"A lightweight CNN trained on a custom augmented dataset classifies payload, data, and overhead frames in a smartphone screen-to-camera VLC link with about 98.74% accuracy, claimed to improve synchronization.","lead":"The paper trains a small convolutional neural network to tell apart data frames and synchronization overhead frames in screen-to-camera visible light communication on smartphones. It reports about 98.74% classification accuracy, but it does not demonstrate that this actually improves synchronization in a working link.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The 85% synchronization gain rests on an assumed 5 ms CNN time that contradicts the paper's own 237 ms mean-time result for the proposed method in Table IV.","rationale":"The reader's weakest assumption was that the 98.74% classification accuracy does not by itself validate the synchronization benefit because T_cnn = 5 ms is never measured and no end-to-end metrics are provided. My stress test identifies a stronger, more specific problem: the paper itself reports two incompatible timing values for the proposed method. Section IV-B uses T_cnn = 5 ms in Eq. (3) to claim 85% gain, while Table IV lists the proposed method's mean time as 237 ms. These figures cannot both describe the same model on the same hardware, and the paper offers no reconciliation, so the synchronization claim is internally inconsistent, not merely unvalidated. This is the most load-bearing concern because the title, abstract, and conclusion all hinge on the synchronization benefit, not on the classification accuracy per se. I agree with the reader's REJECT verdict, but for a more concrete reason. I also note the architecture description in Section III is internally inconsistent (100x100 input, 3x3 kernel, no padding cannot yield 24x24 feature maps), which undermines reproducibility, and the paper provides no dataset or code. The classification accuracy of 98.74% could still be genuine, and the paper does describe a plausible lightweight CNN pipeline, but the lack of a consistent timing measurement for the actual synchronization loop is fatal to the central claim as currently stated.","tokens_in":8794,"tokens_out":5542,"duration_ms":54017,"concrete_test":"Measure the per-frame inference time of the exact proposed CNN model (as described in Section III) on a Google Pixel 6 Pro, using the same 100x100 QR/ASCII frame images and preprocessing as in Table II, and record the measured T_cnn. Then recompute Eq. (3) with T = 33.33 ms. If the measured T_cnn is not approximately 5 ms, the claimed 85% gain is unsupported; if it is close to 237 ms or above 33.33 ms, the synchronization benefit is refuted by the paper's own Table IV and the central claim fails.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central synchronization claim is the 85% system gain in Section IV-B, computed from Eq. (3): x(t) = (T - T_cnn)/T, with the text stating that computation time is reduced 'from 33.33 ms to 5 ms' by skipping payload processing for sync frames, i.e., T_cnn = 5 ms. However, the only timing reported for the proposed model is in Table IV (Section IV-A), which lists the proposed method's mean time as 237 ms. These two numbers are never reconciled. If the CNN actually takes 237 ms per frame, Eq. (3) yields (33.33 - 237)/33.33 = -6.11, a strongly negative gain, meaning the proposed synchronization would be far slower than simply processing every frame and the claimed benefit is inverted. If the 5 ms figure refers to some other quantity (e.g., classification of a small 100-character overhead frame), that quantity is neither defined nor measured in the paper. No end-to-end timing, packet-error, or throughput measurements are provided, and no measurement of T_cnn on the Google Pixel 6 Pro appears anywhere. Since the abstract and conclusion assert improved synchronization and system performance, and that assertion is supported only by this arithmetic estimate, the contradiction with Table IV is a load-bearing, internally inconsistent step. Resolving it is necessary before any synchronization benefit can be accepted. An additional internal inconsistency is the architecture description: a 100x100 input convolved with a 3x3 kernel without padding produces 98x98 feature maps, not the stated 24x24; this does not by itself invalidate the classification results but further weakens reproducibility.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The manuscript proposes a supervised CNN for frame identification in smartphone screen-to-camera (S2C) visible light communication. The authors build a custom dataset of QR and ASCII frame images, train a small CNN to distinguish data frames from overhead/synchronization frames, and report an overall accuracy of 98.74% across three experiments. They further claim an 85% system gain in synchronization, computed from Eq. (3) as x(t)=(T-T_cnn)/T, by skipping payload processing when overhead frames are detected. A comparison against SVM, LeNet-5, GoogLeNet, and ImageNet is presented in Table IV.","tokens_in":9074,"tokens_out":4879,"duration_ms":48718,"significance":"If the classification result were reproducible and if the synchronization claim were backed by end-to-end measurements, a lightweight CNN that reliably separates overhead frames from data frames would be a useful component for OCC receivers and a positive step toward deep-learning-based synchronization on smartphones. The authors have assembled a custom image set that includes cropping, rotation, and blur, which is a constructive effort. However, the paper does not provide the evidence needed for the main claimed contribution: there are no synchronization metrics, no latency or throughput measurements on the live link, no measurement of the CNN's running time on the target phone, and no dataset or code release. The classification result is plausible but unverifiable under standard reproducibility expectations, and the synchronization gain claim contains an internal contradiction with the paper's own timing table.","major_comments":[{"comment":"The claimed 85% synchronization gain is contradicted by the paper's own timing table. Table IV reports a mean time of 237 ms for the proposed method. Substituting T=33.33 ms and T_cnn=237 ms into Eq. (3) gives (33.33 - 237)/33.33 = -6.11, i.e., a negative gain. The text states that computation time is reduced 'from 33.33 ms to 5 ms,' but no definition or measurement of the 5 ms value is provided, and no measurement of T_cnn on the Google Pixel 6 Pro appears anywhere in the manuscript. This contradiction is load-bearing because the abstract and the conclusion claim improved synchronization and system performance on the basis of this arithmetic estimate. The authors must either reconcile Table IV with Eq. (3) or remove the 85% gain claim until it is supported by direct measurement.","section":"IV-B, Eq. (3), Table IV"},{"comment":"The synchronization benefit is asserted but never measured. The paper reports no packet error rate, frame-sync success rate, throughput, or end-to-end latency on the live S2C link. Classification accuracy on the custom image set is not a synchronization metric, and the assumption that 98.74% accuracy translates to reliable frame-boundary recovery is untested. An end-to-end experiment with explicit synchronization metrics is required before any claim of improved synchronization can be accepted.","section":"IV-B"},{"comment":"The architecture description is internally inconsistent and prevents reproduction. A 100x100 input passed through two 3x3 no-padding convolutional layers and one 2x2 max-pooling layer produces 48x48 feature maps (100 -> 98 -> 96 -> 48), not the stated '24 x 24' feature maps. The text also says convolution is performed 'without striding' but later refers to a 'stride of 12 x 12' in the pooling layer. These contradictions make it impossible to determine the actual network structure and undermine the claimed lightweight comparison.","section":"III"},{"comment":"The baseline comparison is not reproducible. No training or testing protocol is given for the four baselines, including dataset splits, augmentation settings, training epochs, and hardware. No error bars or repeated runs are reported. Two references do not point to the named models: [22] is a LiDAR semantic segmentation network, not LeNet-5, and [24] is a general deep-learning review, not GoogLeNet. 'ImageNet' as a model name is also ambiguous because ImageNet is a dataset. These issues make the superiority claim in Table IV unverifiable.","section":"IV-A, Table IV"}],"minor_comments":[{"comment":"Figure 8's caption duplicates the caption of Figure 7 ('Training and testing accuracy of overhead detection'), but the figure is referenced in Section IV-B as showing frame rate; the caption should be corrected.","section":"Fig. 8"},{"comment":"The accuracies reported as 'less than 0.48%' and '0.444%' appear to be fractions expressed as percentages; as written they are inconsistent with the training curves, which start near 0.5 and 0.45, respectively.","section":"IV-A.1"},{"comment":"The average performance is reported to four decimal places with no confidence intervals; given the small per-class dataset (1,000 images), the variability across runs should be reported.","section":"Table III"},{"comment":"The heading 'SYCHRONIZATION' contains a typo and should read 'SYNCHRONIZATION'.","section":"IV-B heading"},{"comment":"The notation T is used both for the receiver computation time and as the sampling interval base in Eq. (2), which is confusing; a clear separation of symbols is needed.","section":"II-C and IV-B"}],"recommendation":"reject","confidential_remarks":"The classification experiment may be salvageable in a future extended study, but as submitted the synchronization contribution is unsupported, and the internal contradiction between Eq. (3) and Table IV is decisive for the paper's central claim. Repairing this would require new end-to-end measurements, a reproducible baseline protocol, and careful redrafting of the gain claim; I do not see this as a minor or local revision."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The one genuinely new thing here is applying a small CNN to distinguish overhead sync frames from payload frames in screen-to-camera VLC. That specific use is absent from the synchronization literature the authors cite, and the classification experiments themselves look like honest work: a custom dataset with rotation and cropping augmentation, three separate tasks, and a reported 98.74% average accuracy. The baseline comparison, while not fully specified, at least shows the proposed model beating SVM, LeNet, GoogLeNet, and ImageNet on accuracy. If all you need is a lightweight classifier for this one task, the paper gives you a plausible starting point.\n\nThe soft spots are real and one is load-bearing. The 85% system gain in Section IV-B comes from Eq. (3) with Tcnn = 5 ms, but Table IV lists the proposed method's mean time as 237 ms. Those two numbers are never reconciled. If 237 ms is the actual inference time, the gain is negative: (33.33 - 237)/33.33 is about -6.1. The abstract and conclusion claim improved synchronization and system performance, but the only support is this arithmetic estimate. There are no end-to-end sync metrics, no measured CNN inference time on the Google Pixel 6 Pro, no throughput or packet-error results. The synchronization claim is unsupported as written.\n\nThe architecture description is also internally inconsistent: a 100x100 input with a 3x3 kernel and no padding gives 98x98 feature maps, not 24x24. That does not necessarily invalidate the classification results, but it makes the model hard to reproduce. No code or dataset is released, and the accuracy numbers have no error bars, so the classification result is plausible but not verifiable from the paper alone.\n\nI would not cite this in its current form. The classification piece could be salvaged, but the central synchronization claim needs either real end-to-end measurements or a much more modest claim. This is not a desk-reject case in my view: the application is new, the experiments are real, and the flaw is fixable with additional measurements or a revised scope. A serious referee should see it, with the clear expectation of major revision.\n\nFor the record, I think the skeptic's stress-test is correct on the timing contradiction, and the reader's low-confidence reject is proportionate.","headline":"A plausible CNN classification study whose synchronization claim is contradicted by its own timing table, fixable but currently overclaimed.","tokens_in":9681,"tokens_out":2111,"would_cite":false,"duration_ms":24427,"reading_group":"maybe","serious_thinker":"no","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The paper proposes that a lightweight convolutional neural network can identify and synchronize frames in smartphone screen-to-camera visible light communication, reporting 98.74% classification accuracy and an estimated 85% computation…","keywords":["Convolutional neural networks","Screen-to-camera visible light communication","Frame synchronization","Frame identification","Optical camera communication","Smartphone communication","Image classification","Supervised learning"],"falsifier":"Measure the real inference time of the described CNN on the same smartphone model used in the experiments while the receiver is running; if $T_{cnn}$ exceeds the frame interval or 5 ms, the 85% gain in Eq. (3) would not hold. Then transmit a known interleaved sequence of data and overhead frames and count misclassified boundaries under motion and changing light; with a 98.74% reported accuracy, roughly 1.26% of frames are misclassified, so the experiment should check whether that residual error concentrates at frame boundaries and corrupts packet alignment.","tokens_in":8557,"feed_emoji":"📱","tokens_out":10788,"duration_ms":107773,"temperature":0.7,"pith_summary":"This paper seeks to solve one of the hardest practical problems in screen-to-camera visible light communication: the receiver does not know when a displayed frame is payload data and when it is a synchronization marker. The proposed answer is to treat frame identification as an image-classification task. A deliberately small convolutional neural network is trained on QR and ASCII frame images, including cropped and rotated versions, to tell data frames from overhead sync frames; the paper reports 98.74% overall accuracy across three classification experiments. If this works in a live link, the receiver can recognize overhead frames and skip decoding their payload, which the paper estimates as an 85% reduction in computation time per sync frame. That would matter because frame synchronization is a known bottleneck in smartphone-to-smartphone optical links.","feed_headline":"Six-layer CNN spots sync frames in phone light links at 98.74%","feed_subtitle":"Receivers skip decoding sync frames, cutting per-frame compute from 33 ms to 5 ms.","key_machinery":"The load-bearing mechanism is the overhead-frame classifier: a convolutional neural network that converts synchronization into a per-frame label. The architecture is intentionally small, with 32 and 16 filters in the two convolutional layers, each $3\\times3$, followed by $2\\times2$ max pooling and a single 128-neuron dense layer, so that it can run on a smartphone receiver. Its task is to separate the overhead QR sync frames from the large 4,000-character QR data frames, so the receiver knows when a packet starts and can skip expensive decoding of sync frames. The quantitative engine of the claimed gain is Eq. (3), $x(t) = (T - T_{cnn})/T$, which converts the assumed CNN processing time of 5 ms against a 33.33 ms data-frame processing time into the reported 85% system gain.","core_discovery":"The central claim is that a small CNN with two convolutional layers using $3\\times3$ kernels and ReLU, a $2\\times2$ max-pooling layer, a flatten layer, a 128-neuron fully connected layer, and a logistic output can classify $100\\times100$ pixel S2C frames into the right category reliably enough to drive synchronization. Trained on 4,000 custom images (two QR data-frame types, one ASCII frame type, and one QR overhead frame type) with crop and rotation augmentation, the model reaches 98.60% accuracy for payload classification, 99.60% for distinguishing data frames from ASCII interference, and 98.00% for spotting overhead frames, for an average of 98.74%. The paper argues this classification capability is what lets the receiver detect the sync frames that mark packet boundaries, and uses Eq. (3) to estimate the resulting system gain: with a 33.33 ms per-frame computation time and a 5 ms CNN time, skipping payload processing for sync frames saves about 85%.","pith_inferences":["Because the paper's experiments stop at image classification, an end-to-end link test that transmits known data with periodic overhead frames and measures packet error rate or throughput is the direct next step needed to confirm the 85% computation saving reaches the user.","The 85% gain depends on the assumed $T_{cnn}$; without measuring inference latency on the target phone, the saving could be smaller in practice, or the CNN could fall behind the camera frame rate.","A classifier of this kind could be retrained to mark lost or duplicated frames caused by the mismatch between screen refresh and camera frame rates, turning frame-skip recovery into another classification task."],"forward_implications":["A receiver using this CNN can mark the start of each packet by recognizing overhead frames, removing the need for a separate preamble-detection circuit in screen-to-camera links.","Because sync frames are classified before payload decoding, the system can skip the QR-decoding step for those frames, cutting per-frame computation from 33.33 ms to 5 ms under the paper's assumptions.","The reported accuracy of 98.74% on cropped and rotated inputs suggests the classifier tolerates the blur, cropping, and rotation that occur during user mobility.","In the paper's comparison table, the proposed model exceeds the classification accuracy of SVM, LeNet-5, GoogLeNet, and ImageNet while keeping mean processing time at 237 ms, second-fastest of the five.","Frame identification as image classification offers a software-only path to synchronization, avoiding extra hardware on the smartphone receiver."],"supporting_citations":[{"why":"It is an earlier screen-to-camera barcode streaming system whose throughput constraints frame the synchronization problem addressed here.","marker":"[9]"},{"why":"It identifies blur and perspective distortion as open challenges in S2C systems, motivating the paper's augmented training dataset.","marker":"[15]"},{"why":"It is a prior unsynchronized visual communication scheme that the paper cites as the state of the art for lost-frame handling.","marker":"[17]"},{"why":"It demonstrates preamble-based packet synchronization, the traditional approach the CNN-based frame identification is meant to simplify.","marker":"[18]"},{"why":"It supplies the linear SVM baseline used in the comparison of accuracy and mean time.","marker":"[21]"},{"why":"It supplies the LeNet-5 baseline, the lightweight CNN whose mean runtime the proposed method slightly exceeds.","marker":"[22]"},{"why":"It supplies the ImageNet classifier baseline used in the comparison table.","marker":"[23]"},{"why":"It supplies the GoogLeNet baseline used in the comparison table.","marker":"[24]"}],"fun_headline_variants":["CNN spots sync frames in phone VLC with 98.7% accuracy","98.7% accurate CNN syncs frames for smartphone VLC","CNN-based sync for screen-to-camera VLC hits 98.7%","AI syncs frames in phone light links at 98.7% accuracy"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that 98.74% classification accuracy on still images, together with the assumed 5 ms CNN processing time, transfers to a live screen-to-camera link so that the receiver actually finds packet boundaries and realizes the estimated 85% computation saving.","fun_headline_variants_meta":{"raw":{"variants":["CNN spots sync frames in phone VLC with 98.7% accuracy","98.7% accurate CNN syncs frames for smartphone VLC","CNN-based sync for screen-to-camera VLC hits 98.7%","AI syncs frames in phone light links at 98.7% accuracy"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000528,"raw_usage":{"total_tokens":2527,"prompt_tokens":907,"completion_tokens":1620,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":523,"completion_tokens_details":{"reasoning_tokens":1538}},"tokens_in":523,"tokens_out":1620,"duration_ms":11778,"temperature":1.0,"reasoning_tokens":1538,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-06T21:52:37.634670+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Measure the real inference time of the described CNN on the same smartphone model used in the experiments while the receiver is running; if $T_{cnn}$ exceeds the frame interval or 5 ms, the 85% gain in Eq. (3) would not hold. Then transmit a known interleaved sequence of data and overhead frames and count misclassified boundaries under motion and changing light; with a 98.74% reported accuracy, roughly 1.26% of frames are misclassified, so the experiment should check whether that residual error concentrates at frame boundaries and corrupts packet alignment.","supporting_citations":[{"cited_title":"Smartphone to Smartphone Visible Light Communications,","cited_arxiv_id":null,"evidence_quote":"It identifies blur and perspective distortion as open challenges in S2C systems, motivating the paper's augmented training dataset."},{"cited_title":"Lightsync: Unsynchronized visual communication over screen-camera links,","cited_arxiv_id":null,"evidence_quote":"It is a prior unsynchronized visual communication scheme that the paper cites as the state of the art for lost-frame handling."},{"cited_title":"Visual light landmarks for mobile devices,","cited_arxiv_id":null,"evidence_quote":"It demonstrates preamble-based packet synchronization, the traditional approach the CNN-based frame identification is meant to simplify."},{"cited_title":"LENet: Lightweight And Efficient LiDAR Semantic Segmentation Using Multi-Scale Convolution Attention","cited_arxiv_id":"2301.04275","evidence_quote":"It supplies the LeNet-5 baseline, the lightweight CNN whose mean runtime the proposed method slightly exceeds."}],"review_version":1}