NEC NC1201L-A, service mode, and RS232 automation

[Leo Enticknap]

The integrators working on programming Crestron automation for an NC1201L-A I recently installed are reporting to me that when the projector is in service mode (or "serviceman mode," as NEC's politically incorrect Jinglish manual calls it!), it will not process incoming commands via RS232. When it's put back into user mode, it will.

Has anyone else come across this? I can't find any mention of this behavior in the service manual. This is only the second NEC I've tangled with that uses RS232 automation, and the first (an NC900) played silly buggers as well. Specifically, DCC kept freezing and losing communication with the projector, until the RS232 was disconnected. This NC1201L-A isn't doing that: DCC works fine via IP while the Crestron is talking to it via RS232, and updates itself after an RS232 command is executed. But apparently, if the projector is put into service mode, this has the effect of disconnecting the RS232, until it's put back into user mode.

The projector has firmware version 1.018 (current), in case that's relevant.

[Steve Guttag]

Leo...I've had strange behaviors with AMX talking with Christie projectors via RS232. For instance, a CP2000ZX won't boot up if the RS232 cable is connected. I wonder if the speed at which things are being polled have any effect on the various projector behaviors. Naturally, I'd suggest giving NEC a call for this one as they should know their product better than anyone.

I've found NEC's Ethernet communication the "weakest" of the DLP companies. That is, it has seemingly zero buffer on its input so if it is in a "wait a moment" state, it can ignore the next command so things have to be spaced out or "double-hit" to ensure they take. And that is on Ethernet commands, not RS232.

[Leo Enticknap]

The Crestron programmer we work with most freqently "double hits" NEC commands, spaced a second apart, for precisely the reason you give. The reason RS232 was used in this project rather than IP for automation commands is that it is an upgrade from an existing projector, that was commanded by RS232, and using RS232 for this one too prevented the need for extra hours of billable Crestron programming time.

We knocked the baud rate down to 9600 on this one, but it didn't fix the "serviceman mode" glitch. It's not a huge deal, except for the fact that when we're doing remote troubleshooting via our Teamviewer remote access PC, or downloading a log in preparation for a maintenance visit, we'll have to remember not to put the projector into service mode while the system is being used, as that could potentially bugger up the automation.

[Bruce Cloutier]

Really... It is an inexcusable software defect. I am not sure what is worse: the defect or the fact that it remains uncorrected. It drives me nuts when large companies with seemingly unlimited resources fail to address the simplest things.

[Steve Guttag]

Well, you've dealt with Doremi (Dolby). How long on the password thing? Why do we need \w commands to so many devices to ensure that the cues fire. Why do they make the command set seem like such a burden to provide when so many people would use it?

On the other side, working with A/V projectors and equipment, they'll have an incredible amount of minutia in their command set. I have wondered how many of those commands EVER get used (things like color calibrations via a 3rd party control system). I'm not saying it doesn't happen but I can't believe it is so popular that it is worth the expense of keeping up with it.

[Bruce Cloutier]

Even when something is so obviously broken, it is amazing to me that in this day and age it takes forever for it to be corrected (if at all). You can take that statement way out of this context too.

If you could measure that metric somehow my bet is that the length of time is seriously on the increase year after year. Technology is not improving things in this sense.

All I can say is that if you find an issue with something within my responsibility, I will lose sleep over it until a solution is provided. Then, of course, the frustration is that after supplying the fix (maybe the same day) you find out weeks later that the customer hasn't tried it yet.

Still a solution to the NEC issue isn't "double hits". That is masking the symptom and not addressing the problem. But since the problem is NEC, all we can do is mask the symptom.

This serial communications reliability issue is basic. You need a process always running and buffering the communications independent of the foreground product logic. The hardware buffers just two characters. I would like to think that any computer science major would understand that... but no.

Although, Leo's initial post just mentions that the external RS-232 commands are not accepted during some "serviceman mode". That I suppose is the designer's prerogative.

Another one is the misconception that one packet equals one message over TCP/IP. While timing makes that true 99% of the time, a message on the wire can be split between two packets and sometimes a packet can contain more than one message. So in the code one fread() doesn't always get you the next message/command. Rookie programming mistakes.

[Steve Guttag]

The simplest way to put it is that NEC's communication doesn't like to multitask. If it is doing something, it will often ignore everything else.

[Leo Enticknap]

Although, Leo's initial post just mentions that the external RS-232 commands are not accepted during some "serviceman mode". That I suppose is the designer's prerogative.

I was actually wondering if this behavior is accidental rather than designed, especially given that I've encountered another NEC projector that exhibits different, but equally strange, misbehavior related to automation via RS232. While communicating with the projector via IP, Digital Cinema Communicator running on a PC randomly freezes, and the projector refuses to accept commands or output status information via IP. As soon as you disconnect the RS232 (as in, physically pull the DB9 plug out of the projector), it's happy again.

I don't know why the references to "serviceman mode" in NEC manuals make me giggle so much. It could be because whenever I see them, it evokes the image of an animated figure in a boiler suit, holding a large crescent wrench, from a 1980s Japanese video game.

[Carsten Kurz]

Well, we know that missing automation cues has a long history on NEC DCI projectors. I remember having to place cues as far apart as 15s in playlists for their series-1 machines for them to properly execute (lost dowser cues, remember?). And it seems they never improved it.

[Bruce Cloutier]

Hmm. There is another possibility that sometimes causes RS-232 communications issues. Obviously we are quick to blame software but it could be a common mode voltage issue. If the difference in ground potential between transmitter and receiver is sufficient the receiver doesn't see the signal zero crossing and drops bits or receives none at all. It has been quite a while since i have looked into transceivers at that low a level to reliably quote the workings. But, I have encountered the issue in communicating from one room to another only several feet away. The two rooms were on completely different legs of building power. After powering both ends from the same room's outlets communications were restored. NEC missing commands and requiring "double hits" might be a symptom of this. Perhaps in serviceman mode there are different circuits active and the common mode potential difference is made even worse.

The RS-232 connections are not isolated and the GND pin can set a reference for the entire product and not just the RS-232 communications. Ground loops can result and noise levels increased. If cables are used where the shield is not wired properly there can be other issues.

Perhaps the NEC RS-232 communications work flawlessly in all modes in their labs? They might then think these issues are our fault.

Um, that 2-room RS-232 issue was about 35 years ago by the way. Damn I am old! One could hope that the transceivers are of better design these days... well... you'd hope anyway.

[Carsten Kurz]

Those NECs even miss cues over ethernet. It just seems a general weakness with their main controller and communication software. A lot of series-1 and series-2 projector electronics is OEM from TI - but the main controller is manufacturer specific, so, in that case NEC is solely responsible.

[Mark Gulbrandsen]

My experience with NEC cues is that while the lamp is lighting and stabilizing the projector will ignore any other cues. Once that 30 seconds has passed the other cues will work as they should. I assume this is the same for laser models in order to allow the laser time to stabilize normally.

[Gordon McLeod]

If it is doing a lens change position it will also ignore cues

[Dave Macaulay]

I have seen them be single minded. Receive a command, and execute it... but ignore subsequdnt commands until that one is complete. This is obvious in DCC /DCCS as it locks while indicating what it's doing and you can't do anything, but serial and TCP/IP seem the same. I don't remember server cues failing while in service mode though, and it would be somewhat normal to be there in testing.

[Steve Guttag]

As I said, it doesn't multi-task nor does it have a buffer that takes in cues and executes them in-turn. This affects how I have automations send cues and how much time I place between cues if multiple things are happening. Format changes take the longest and one should allow 15-seconds before making the request for doing something else. Dowser movements are mere 5-second requests. I try to make the first cue to the projector the format change since that takes the most amount of time and you don't know what format was on the previous show. I also try to avoid closing the dowser...ever (there isn't a countdown leader to worry about and one can stuff a show with black clips to avoid anyone seeing format changes.

There is no question, the NEC DCinema projectors are just extremely weak in the area of external commands. They'll do them but they do them on their terms and will do them one at a time.