VC EL cabinet: identify, repair display flicker, then commission

Status on 2026-09-06: photos inspected; physical repair and end-to-end operation not verified. No cabinet is attached to this computer. This guide concerns cabinet label XT-202303207146, not an arbitrary machine in the cloud.

What the eight photos establish

The original service photographs are private. Shared service reports should redact passwords and payment credentials.

The official VC EL support page covers EL10-22C/D/F and links an Android service manual. Its setup/serial sections name TCN140613 and TCN161114 boards. That is evidence for investigating a TCN configuration, not proof that this exact cabinet still runs it. Official service manual.

Silkron/Vendron remains unconfirmed. Confirm the current application in About/licensing information, installed package/version and controller label. Silkron is a software/integration platform and need not be the cabinet manufacturer. Do not install the Reyeah or ZHZN cabinet APK on this machine merely because all three run Android.

First: classify the flicker without changing the machine

Stop customer sales using the existing documented service procedure while diagnosis is in progress. Finish any active purchase before entering service mode. Keep a record of open transactions; a payment authorization is not evidence that the product reached the customer.

Observe the screen in person and record which of these happens, how often, and whether it happens outside the shopper app. A short recording may help, but phone-camera banding alone does not establish real screen flicker.

These branches deliberately do not prescribe a firmware update, arbitrary refresh rate, or replacement part. The photos contain no voltage rating or confirmed display model from which to select one.

On-site hardware isolation

Have a qualified vending/display technician perform work inside the open cabinet. Shut down through the documented process and isolate mains power before reseating cables; do not probe a live supply, hot-plug unknown D-sub connectors, or run motors with hands inside the mechanism.

1. Record the cabinet rating plate, display model/ratings, controller label and existing cable routes before moving anything.
2. Inspect the door-hinge cable path for strain, pinching, loose seating and damage. The photos show the electronics mounted on the door, so the route deserves inspection; this is not a diagnosis of a loose cable.
3. Reseat only positively identified display signal and low-voltage power connectors with power isolated. Preserve their original locations and orientation. Do not change the two white connector assignments based on their appearance.
4. If available, substitute one manufacturer-compatible signal cable or display at a time. Match interface, pinout, voltage, polarity and current rating. A plug that fits is not sufficient.
5. Restore covers/guards, then test again. If flicker tracks refrigeration startup or another load, have the technician check supply regulation and the site circuit under the manufacturer's service procedure.
6. Keep each result with its time and the exact changed part. If a replacement does not resolve the symptom, do not declare the original component faulty.

For the models covered by its page, Vending Concepts advises a dedicated 120 V / 20 A circuit and no extension cord. Have the technician reconcile this with this cabinet's actual rating plate and site installation; do not change electrical service from a photograph. VC EL power guidance.

Collect Android evidence without installing anything

Use only the manufacturer's documented USB device/service connection. The photographed USB sockets may be host ports: do not connect two host ports with an improvised USB-A-to-USB-A cable. If the cabinet provides no supported debugging connection, use its native service log export or an existing authorized remote-access session.

With Android USB debugging enabled through the cabinet's authorized service procedure, accept this computer's debugging prompt. List devices and select the cabinet explicitly when other Android devices are present. Android ADB documentation.

A technician can collect a small read-only Android inventory after identifying the authorized device:

adb devices -l
# Replace this value with the cabinet shown as authorized above.
KIOSK_ADB_SERIAL='SERIAL_FROM_ADB_DEVICES'
adb -s "$KIOSK_ADB_SERIAL" shell getprop ro.product.model
adb -s "$KIOSK_ADB_SERIAL" shell getprop ro.build.version.release
adb -s "$KIOSK_ADB_SERIAL" shell getprop ro.build.version.sdk
adb -s "$KIOSK_ADB_SERIAL" shell getprop ro.product.cpu.abilist
adb -s "$KIOSK_ADB_SERIAL" shell pm list packages -3
adb -s "$KIOSK_ADB_SERIAL" shell wm size
adb -s "$KIOSK_ADB_SERIAL" shell wm density
adb -s "$KIOSK_ADB_SERIAL" shell cat /proc/uptime

Run the uptime read again after an observed screen event. A reset helps distinguish a controller restart from a display-only fault. Package names are identification clues, not manufacturer certification. These reads neither repair the machine nor establish successful operation.

Also record the current shopper application's About/version/license screen, native service machine ID, board selection and existing serial settings. Do not copy passwords, payment credentials or remote-access secrets into shared reports. Preserve configuration and current install/rollback material before an eventual software change.

If the issue is confined to software

• Identify the actual crashing app and version first; preserve vendor logs and configuration. Do not clear app data or factory-reset as a first repair step.
• If it is confined to one ad, use the vendor's supported content controls to temporarily remove that item after saving a copy. Check whether the grid and other media remain stable. Do not delete the entire media/config directory.
• If Android itself restarts, use uptime/boot evidence to investigate the controller, thermal conditions and power path before treating the symptom as an app defect.
• Apply only an update intended for the verified board and installed application, with a confirmed signer and rollback plan. A generic Operator APK is not a replacement for the vending controller software.
• Repeat the same observation after the change, then a sustained idle/advertising cycle and supervised vend cycle. Define and record the observation duration; a brief successful boot is insufficient.

Select the integration after identification

Silkron describes Cloud API as REST/mobile integration and Socket API as local Windows integration. Confirm licensed operations and versions with the vendor before designing the adapter. Vendron API.

The matching VC manual has native service navigation for slot management, product details, serial configuration, program updates and log export. Use those documented menus for the verified installed version while identifying the machine; its existence does not establish Kiosk-X integration. Relevant PDF pages: 10-11 (products/slots), 15 (serial settings), 18 (updates/sales), 22 (log export). Serial settings are factory-specific; preserve them. VC manual.

End-to-end signoff for this cabinet

Complete these checks in order and attach the APK, controller firmware and backend revision used. A failed step keeps the machine out of customer service.

1. Identity: reconcile XT-202303207146, the native application machine ID, backend machine number, operator account, controller, app package/version and payment terminal. Confirm the integration explicitly supports the controller.
2. Display: demonstrate stable image/touch during startup, idle, advertising and supervised operation; record before/after symptom and observation duration.
3. Ownership: sign in to the intended Operator account, register/claim through the supported stack, and verify other accounts cannot operate the machine.
4. Inventory and prices: configure a known lane/product, price and measured stock in Operator. Confirm native cabinet readback and shopper display; an accepted cloud write alone is insufficient.
5. Service vend: with the mechanism closed/clear and a technician present, run one native service test and verify actual delivery and resulting stock. Use the actual card packs/products visible in the shopper catalog, not just a larger test object: confirm their packaging meets the identified elevator's loading and sensing requirements. Do not send repeated cloud commands after a timeout.
6. Purchase: perform a supervised permitted payment, verify exactly the requested physical items arrive, stock updates once, and the correct order, amount and payment reference appear in Operator.
7. Failure/refund: use an approved test arrangement to verify rejected/failed delivery and the payment provider's refund result. Do not create a mechanical jam by hand or count a queued refund as money returned.
8. Recovery: test a planned network interruption and restart with no customer transaction active first. Confirm identity/stock persist, queued operations are understood and nothing dispenses unexpectedly on reconnect. In-flight failure testing requires a controlled test environment.
9. Handover: preserve service contacts, signoff evidence, exact artifacts, recovery procedure and operator training. Only mark the specific tested configuration supported.

Vendor support packet (prepared, not sent)

Use the current support channel linked from VC EL support. Include cabinet ID XT-202303207146, VC EL sticker, actual model/rating and board labels, flicker description, whether it occurs at boot/settings/ads, and software versions. Request the correct display/controller wiring diagram, approved recovery package and rollback instructions, native controller SDK/API availability, and confirmation of whether Vendron is installed/licensed. Supply redacted evidence, not the visible cabinet password.