NEC Projector RS232 Commands: Binary Frames, Checksum and the MultiSync Confusion

NEC Projectors Are Binary — Not Text

This is the first thing to internalise, because it is where most NEC integrations fail.

NEC projector commands are raw hex bytes. Unlike Epson (PWR ON), Sony (power "on") or LG (ka 00 01), there is no readable text involved. Power on is:

02 00 00 00 00 02

Six bytes. Typing the characters 0, 2, space, 0, 0… sends eighteen ASCII characters and will never work.

This trips up nearly everyone once. A documented Arduino case had a developer trying Serial.println("02 00 00 00 00 02") and many variations without success — the fix is to write actual bytes:

byte powerOn[] = {0x02, 0x00, 0x00, 0x00, 0x00, 0x02};
Serial.write(powerOn, 6);

Note also that println appends CR/LF, which adds two bytes the projector did not ask for and corrupts the packet even if the rest was right. Use a write/send-bytes call, not a print-line call. In a terminal program, switch to HEX send mode.

Packet Structure

┌─────┬─────────┬─────────┬──────────────┬──────────┬──────────┐
│ ID1 │  ID2    │ Unit ID │ Unit Address │ Data Len │ Checksum │
│ 02  │ 00/01…  │   00    │      00      │    00    │    XX    │
└─────┴─────────┴─────────┴──────────────┴──────────┴──────────┘

For a single projector, NEC's guidance is to set the unit ID to 0 and the unit address to 00. When the unit ID is set for general notification, the unit address is not checked — which is what makes the all-zeros form work on a standalone install.

The Checksum

Add every preceding byte, keep the low eight bits. NEC's own wording: "CKS: Check Sum — lower eight bits digits of sum total of the first byte to the byte just before the last."

Power on:

02 + 00 + 00 + 00 + 00 = 0x02
Frame: 02 00 00 00 00 02
                      └── checksum

Power off:

02 + 01 + 00 + 00 + 00 = 0x03
Frame: 02 01 00 00 00 03

The power-on frame is a nice coincidence — the checksum equals the first byte — which occasionally makes people think the last byte is a repeat of the first. It is not. Power off makes the rule obvious: the last byte becomes 03 because the sub-command changed to 01.

Once you have the rule, you can validate any NEC frame you find in a table before trusting it, which is worth doing — control code tables get copied between forums for years without anyone recomputing them.

Serial Settings

Baud rate is the model-dependent one. If a projector is silent, trying 9600 and 38400 costs thirty seconds and eliminates a whole branch of the diagnosis. Some models also let you change the rate in the menu, so a unit that came from another site may not be at its factory default.

The MultiSync Confusion

This trips up people who work with both NEC projectors and NEC displays.

NEC MultiSync monitors and displays do not use the projector protocol. They use a completely different ASCII-based scheme with SOH headers, monitor IDs, and hex-encoded fields — the power command appears as the characters C, 2, 0, 3, D, 6 followed by a four-digit power mode (0001 for on).

So "NEC RS232 commands" means two unrelated things depending on whether the device projects or displays. A command table for one is useless for the other, and because both are NEC and both are RS-232, it is easy to spend a while wondering why a perfectly good table produces nothing.

Check which family your device is in before you look for codes.

Timing: The Cooling Period

The projector will not accept other commands during power-off processing, which includes the cooling period.

This produces the standard sequence bug: an operator presses "close hall", the system sends power off, and then someone presses "open hall" a minute later — and the power-on command lands in the middle of cooldown and is discarded. Nothing errors; the projector simply stays off.

Build a delay into your control logic, or better, query the state and act on it rather than firing commands blindly. This is the same discipline that Epson's PWR? status values exist for, and Panasonic's QPW.

Why Your NEC Command Gets No Response

1. You sent text instead of bytes. The dominant cause. "02 00 00..." is not 0x02 0x00 0x00....

2. Your send call appended CR/LF. println and friends corrupt the frame.

3. Wrong baud rate. Try both 9600 and 38400.

4. Checksum wrong. Recompute — it is the low byte of the sum of everything before it.

5. Wrong protocol family. A MultiSync display needs the display protocol, not this one.

6. The projector is cooling down. Wait, or query first.

7. Straight-through cable instead of null modem. See null modem vs straight-through.

8. Unit ID / unit address non-zero on a standalone install where the projector expects the general-notification form.

With SoftControl

SoftControl sends NEC frames as raw serial or TCP bytes with hex entry — so the byte-versus-text problem, which is the main way NEC integrations fail, does not arise. The command tester shows the exact hex transmitted and the raw response, so a checksum rejection looks different from a projector that is not listening.

For the cross-brand view see the projector control guide; if the hall mixes manufacturers, PJLink gives one command set for power, input and mute across all of them and is usually the better default, with NEC's native protocol reserved for the model-specific extras.