JVS Troubleshooting: RS-485, SENSE, Packet Errors and Recovery (JVS-004)

Start with the failure layer, not a replacement PCB

A JVS communication failure can originate at the physical bus, SENSE and address assignment, packet framing, command handling or host/game integration. An I/O board that replies to command 10 is not necessarily capable of running the intended cabinet controls.

Follow the last verified transition: did the host send F0? Did SENSE indicate an unaddressed node? Did F1 receive a valid acknowledgement? Did commands 11–14 complete? Did periodic input requests then succeed? Record that boundary before replacing parts.

Except where a third-party author is credited, example byte traces in this document are synthetic diagnostic fixtures, not oscilloscope captures from Atelier Rocky.

Prepare an electrically safe capture

Identify the host, cabinet, exact I/O PCB revision and power domains. Power off for any rewiring. JVS ports can resemble USB connectors but are not ordinary USB. Only use probes rated for the relevant voltage and common-mode arrangement; never attach a grounded oscilloscope clip blindly to an unknown powered bus conductor.

Record RS-485 A−B differentially where possible, UART RX/TX on the correctly referenced logic side, driver-enable DE, receiver-enable /RE when accessible, and SENSE using an appropriate analog input. A/B vendor polarity conventions vary: check the transceiver datasheet instead of guessing.

Check termination with the power removed and the complete bus topology known. A fixed resistor on every chained JVS board is not a general repair. Keep the capture point, instrument settings and sampling rate with the trace.

Log one entire request and response

A usable trace contains host/game name, board part number, actual power condition, synchronized direction control, SENSE, complete physical encoded frames and independently decoded logical frames. A lone screenshot of an ID string cannot explain where discovery failed.

At the conventional 115200 baud and 8N1 format, one UART character occupies about 86.8 microseconds (ten bits), not including optional stuffed characters. This serialization time is not a universal JVS reply deadline.

Label every log as measured by us, captured by a third party, firmware-derived, or synthetic. Software timestamps alone cannot establish RS-485 physical release.

HOST/GAME:     <name, revision>
I/O BOARD:      <part number, firmware, node position>
CAPTURE:       <probe type, rate, A/B polarity, logic voltage>
TIME:          <last host stop bit> <node DE high> <node first start>
SENSE:         <before reset> <unassigned> <after F1>
HOST TX:       <raw physical bytes>
NODE RX/TX:    <raw physical bytes>
DE / /RE:      <assert and release edge times>
DECODED:       <logical E0, address, LEN, payload, SUM>
VALIDATION:    <checksum, length, reports, destination>
RESULT:        <repeatable failure and recovery observation>
PROVENANCE:    MEASURED / THIRD PARTY / SOURCE / SYNTHETIC

Establish a known-good discovery sequence

On a conventional single-node bus the host broadcasts reset F0 D9 and ordinarily receives no reply, then broadcasts F1 with node address 01 and expects a normal acknowledgement. Only after that should it issue identification, version and capability queries.

The following independent checksum-verified sequence assumes a hypothetical node that reports command-format revision 1.1. It illustrates packet fields, not live timing measurements or a universal manufacturer profile.

HOST -> ALL   E0 FF 03 F0 D9 CB       F0 D9 reset; no ordinary reply
HOST -> NODE  E0 FF 03 F1 01 F4       broadcast F1, assign 01
NODE -> HOST  E0 00 03 01 01 05       status 01, report 01
HOST -> NODE  E0 01 02 11 14          request command revision
NODE -> HOST  E0 00 04 01 01 11 17    status 01, report 01, BCD 11

These five frames are calculated teaching vectors, not captures.

Decode LEN and escaping before declaring packet corruption

Each conventional packet starts with SYNC E0. LEN counts decoded logical bytes after LEN including the final additive checksum. SUM is the low eight bits of destination + LEN + decoded payload, without the initial E0 sync.

After initial sync, logical E0 is encoded D0 DF and logical D0 as D0 CF. An unescaped body D0 E0 therefore adds two extra physical wire bytes; logical LEN remains unchanged. A trailing D0 without a second byte is an incomplete escape, not proof of an unknown command.

The example is intentionally artificial codec data, not a valid JVS command and not something to send blindly to original arcade hardware.

DECODED: E0 01 03 D0 E0 B4
            |  |  |-----|  +-- SUM B4
            |  |  +-- artificial data D0, E0
            |  +----- LEN 03: two data bytes + SUM
            +-------- destination 01

ON WIRE: E0 01 03 D0 CF D0 DF B4
                  D0 -> D0 CF
                  E0 -> D0 DF

01 + 03 + D0 + E0 = 01B4 hex => SUM B4
Decoded length remains 03.

No response after F0 versus no response after F1

A reset request is not normally acknowledged. Treating silence after F0 as an error is a host-side diagnostic mistake. But F1 address assignment normally does receive an acknowledgement from the one eligible unaddressed node.

If F1 has no complete reply, examine the request itself, SENSE eligibility, direction handoff and the node's address state before marking that node as discovered. Our SP5001-B firmware refuses F1 once its FF5A address variable is no longer FF; the exact physical meaning of two other P7 eligibility bits is still open.

An already-addressed node should not claim the next downstream address. A multi-node failure therefore needs SENSE-chain evidence, not only successful packets from node one.

A bad SUM is not a missing board

A frame may arrive completely but fail its checksum. For example, a revision reply ending 17 is valid; changing only SUM to 18 makes it invalid without changing the identification, status or reports. A diagnostic tool should report BAD_CHECKSUM, not NO_RESPONSE.

Before blaming cabling, verify logical unescaping and byte boundaries. If errors cluster at the first reply byte, compare host driver-release and node driver-enable timing. A malformed response by itself does not prove electrical contention.

Never treat a partial or corrupted response as a successful discovery step. Save the raw bytes and a separate computed checksum.

VALID: E0 00 04 01 01 11 17
SUM = (00+04+01+01+11) & FF = 17

BAD:   E0 00 04 01 01 11 18
                             ^^ received SUM = 18
         recomputed SUM still = 17

Classify BAD_CHECKSUM; do not treat as an unknown command.
No real node was sent this deliberately corrupted reply.

Separate framing, packet status and command report errors

An otherwise valid checksum does not mean a reply is relevant to the current request. A normal JVS reply addresses host 00; a frame addressed to 02 may be well-formed but invalid as a reply to the master. A zero LEN or a truncated payload is likewise a framing problem.

The first reply payload byte is packet status. Common statuses are 01 normal, 02 unknown command, 03 checksum error and 04 overflow. A successful overall status can still contain a non-success report for an individual command: normal 01, parameter error 02, data-parameter error 03 or busy 04. These layers should be logged separately.

Our Namco WAJVIO Ver2.04 reconstruction maps these distinct outcomes to different negative internal results, corroborating that a disciplined host should not reduce every error to 'JVS disconnected'.

SENSE troubleshooting requires an analog measurement

SENSE is a sideband state, not serialized RS-485 data. Conventional implementations often show high with no eligible node, intermediate with an unaddressed node, and low after successful F1. Those are qualitative regions; source designs and host thresholds differ.

On our identified Sega 838-13683-93 Rev.B board we traced a passive diode route and a separately controlled sink driven from P7.2 after F1 acceptance. The external SENSE contact is not a direct logic pin on the microcontroller. A substitute resistor that produces an intermediate voltage on one host may fail on another with different input loading.

For a chained cabinet, capture SENSE before and after each address assignment. A local low state on node one does not prove that downstream eligibility propagated correctly, and no logic-analyzer screenshot should be called a voltage measurement without a calibrated analog instrument.

RS-485 handoff: diagnose collisions at the first response byte

A conventional JVS transaction is half-duplex. The host transmits the request, releases its driver, and the addressed node enables its own driver for the reply. If a modern node drives before the host has released the pair, the overlapping drivers can damage the first UART character or make an entire reply vanish.

On our original Sega SP5001-B Rev.B path, one MCU signal P3.6 controls both SP485 DE and active-low /RE: low means receive, high means transmit. The firmware waits until the physical UART TX-complete state before returning to receive. DE released at FIFO-empty rather than shift-register-empty may cut off the final stop bit.

Our static timing reconstruction for a combined 20 02 02 + 21 02 request yields 0.378147–0.384386 ms from final received-byte readiness to the first reply byte written into SCBUF. This is NOT a direct wire measurement and excludes UART serialization and transceiver propagation. A 200-µs guard in one newer development implementation is a profile choice, not a JVS-standard minimum.

HOST UART:     [ request bytes ][ final STOP ]..................
HOST DRIVER:   ========================DE=0.....................
JVS BUS:       [ HOST A/B symbols ].....idle.....[ NODE symbols ]
NODE DRIVER:   ...........................DE=1==========DE=0...
NODE UART:     ............................[ response + STOP ]...
                              ^              ^                ^
                              |              |                |
                         host releases   node asserts    node releases

Measure four edges: last host stop, host DE off, node DE on,
last node stop / node DE off. This diagram has NO time scale.

Timeouts are host-specific, not interchangeable numbers

The host may enforce an initial-reply delay limit, an inter-byte idle window, a whole-transaction deadline or a frame-time budget. Those quantities are not equal. A source-derived timing value from an original slave should not be presented as the acceptance limit of an unrelated host.

Our research notes describe a Chihiro host activity-gap window of approximately 2.432–2.560 ms and an original Sega slave's 0.236816–0.243056 ms isolated-switch CPU turnaround. These are measurements or calculations from different software roles, not one universal JVS timeout.

An optional fault-injection test build can vary initial reply delay and inter-byte gap separately, but the planned USB2JVS experiment is NOT proof that these delay boundaries have been tested on every original host. Do not introduce diagnostic delays into production firmware.

A surprising Sega parser fault: timeout intent versus executable behaviour

The SP5001-A/B firmware initializes a two-tick, nominally 20-ms whole-packet deadline, and its parser polls a counter that Timer1 should decrement. But our CPU-instruction and interrupt-model study found the parser remains inside the receive interrupt with maskable nesting disabled; Timer1 therefore cannot advance that counter while it is needed.

An earlier unsuffixed SP5001 used a similar monolithic receive-interrupt architecture with Timer3 and the same conceptual defect. The later SP5002-A instead processes one byte per receive interrupt and returns between bytes; a Timer3-driven 10-ms assembly deadline can then run. An earlier 315-6215 Type-1 family also uses byte-state parsing, so this is architectural lineage rather than a simple chronological progression.

This is a strong static firmware/CPU-semantics finding, NOT an assertion that Atelier Rocky physically reproduced an indefinitely hung production board. In troubleshooting, a board that stops responding after an interrupted frame should be tested and reset using manufacturer-safe methods; don't diagnose this exact flaw merely from a vague freeze.

Namco error counters and a practical recovery decision tree

Our Namco WAJVIO Ver2.04 reconstruction distinguishes a public bus restart counter from per-node consecutive receive failures and a separate worker busy counter. A node is deemed unhealthy after 64 consecutive receive failures in this specific DLL; an isolated bad frame is not automatically a public fatal error. Internal -22 means receive timeout, -23 unexpected reply address, -24 zero length, and -25 bad checksum.

Recovery should preserve the exact failed stage and avoid inventing an assigned node or reusing stale input snapshots. After restoring the safe link configuration, let the host's normal reset/reenumeration path run, then revalidate ID and capabilities. Do not create repeated output commands or live malformed-packet injections as an ordinary repair technique.

Use the checklist below to turn a symptom into a reproducible engineering finding. We have not qualified USB2JVS hardware electrically or measured these traces on every Sega, Taito or Namco cabinet.

• Archive exact host/software, board revision, firmware ID and physical configuration.
• Log requested destination, full response, checksum calculation and per-command report.
• Capture SENSE and RS-485 direction when investigating missing first replies.
• Measure initial reply and inter-byte gaps independently if timing matters.
• Reproduce with known-good single-node configuration before testing chains.
• Never infer compatibility or safety from synthetic unit tests alone.

START: link/cabinet state documented; no unsafe rewiring live
   |
   +-- Is host transmitting differential traffic?
   |       NO -> inspect power, connector, host UART/driver
   |       YES
   v
   Is valid F0 reset visible? -> observe SENSE; F0 silence is normal
   |
   +-- Does F1 return a valid ACK?
   |       NO -> inspect SENSE, eligibility, RX and DE timing
   |       YES
   v
   Do ID / versions / features pass LEN, SUM, status, report?
   |       NO -> classify FRAME / STATUS / COMMAND / DEST
   |       YES
   v
   Do switch/coin polls and input changes match capabilities?
   |       NO -> inspect poll count, wiring, game expectations
   |       YES -> baseline established; test recovery carefully

Keep RAW WIRE and DECODED PACKETS as separate evidence.