RS232 experts? Device able to communicate, but unresponsive to commands

[AndyC_772]

For the last couple of days I've been trying to get a Sony PCM-7040 to respond to commands over RS232, and failed.

The PCM-7040 is a studio grade DAT recorder dating back to the early '90s. It has a 25 way RS232 port on the back, which (according to the service manual) supports a list of commands that allow a PC to query its status, clear error logs and so on.

I've discovered that:

- The Sony will transmit its configuration, fault logs etc without a problem; these are triggered by pressing buttons on the front panel.
- To transmit, the Sony requires RTS connecting to CTS, otherwise it just hangs waiting for CTS to go high. It's also OK to assert CTS from the PC.
- It also requires DSR high, otherwise it displays an error ('---DSR Off---') when attempting to transmit.

None of this is unexpected for an RS232 device using hardware flow control. The problem is that I absolutely cannot get it to respond to any commands from the PC!

The serial port of the Sony is configured as per the recommendations in the service manual ("ISR" protocol, 9600, 7O1). But when I send "*IDN?;" (or any of a number of other commands or slight variations thereof), I get no response at all. Nothing. Nada. B*gger all.

It has an RS232 'status' entry in the service menu, which shows the most recently received character in Hex, and this works OK, so I know the machine is physically receiving characters from the PC and decoding them correctly. The status display also shows the state of the DSR and DCD inputs, and they're working too. The waveforms in both directions look OK on a scope. Communication from the Sony to the PC is fine.

I've even tried a second PCM-7040, in case there's some bizarre hardware fault with one unit... same problem.

I'm at a loss now for things to try. The hardware seems fine, but in the absence of any error messages or debug info, I've no idea why it seems to be ignoring commands from the PC.

Any ideas from the system integration gurus?

[AndersJ]

CR/LF issue?
Are you terminating your command string properly?

[AndyC_772]

I thought that. I've tried terminating the command with every character from 0-31 inclusive, and it makes no difference, sadly.

[AndersJ]

Does your device have a ”tamper protection” feature?
Perhaps it needs ”unlocking”.

[AndyC_772]

There's certainly a 'protect' option on the configuration, and it's turned off. In any event, some commands are purely queries, which I'd expect to work in any event. There's also a 'local/remote' switch on the front panel, and I've tried both positions.

Thanks for the suggestions... please keep them coming

[matseng]

Have you checked with the scope that your serial port *actually* sends 7bits+odd parity? I've seen ports silently fail over to 8N1 sometimes...

[Bicurico]

Take note that some USB RS232 converter don't work properly.
They may TX incompatible signal level, which results in RX working, but not TX.

[AndyC_772]

I've tried both a PC (with a generic USB-serial converter) and one of my own projects which happens to include a CPU and an RS232 interface. I've decoded the signals in both directions with the scope, and they're definitely 7O1 as they should be.

There *is* a small clue, though. The RS232 status display on the Sony shows the last transmitted and the last received characters in Hex, so I know it's receiving the signal OK electrically. It also shows a status byte which is supposed to indicate parity, framing and overrun errors - but even when I deliberately send it incorrectly formatted data, the error byte still shows zero.

I wonder why...?

[xygor]

I am not familiar with the device but some general suggestions:
Did you try other settings? (e.g. 7e1). Documentation could be wrong plus what it sends (7o1) may not be what it wants to receive.
Are you typing the characters?  Maybe the characters all need to be transmitted within a certain period of time.  Try pasting or sending from a file.

[texaspyro]

Try end-of-line squences of <CR>,  <LF>, or <CR><LF>.   Beyond that gets you into the world of <ETX>, etc.

[AndersJ]

Uppger vs lower case in command?
Is a appended checksum needed on each command?
Checksum in ASCII or hex?

[Nusa]

Nearly all the professional solutions for these machines utilized the 9-pin RS422 port, which probably explains why any documentation about the (optional) RS232 port is hard to find.

So it might be worth finding or making an RS232--RS422 adapter and seeing how that works instead.

I do know the local-remote switch is supposed to disable the front panel and hand full control over to the RS422 port. To use any of the other ports, you have to leave it in local mode.

[BrianHG]

Do you have access to a really old PC with a 25 pin serial connector?
Double check all the possible DB25 signals, including the weird ones, like ring indicator...
According to the sony manual you also need to set the DTR, I didn't see these being mentioned in your post.
http://pdf.textfiles.com/manuals/STARINMANUALS/Sony%20Audio/Manuals/Archive/PCM-7040.pdf
Try changing the Sony's RS232 to something like 9600 baud 8 bits No parity and test...

[floobydust]

Sony DAT might want to see DCD asserted, try jumper 6,8,20. 
Some laptops have low voltage RS-232 drivers, barely swing +/-3V which some devices do not work properly with, if they followed the RS-232 standard exactly.

A break-out box to troubleshoot old DB-25 RS-232 issues, you might have to make a single line (dual LED) probe.

edit:

I took a tour of the PCM-7030 service manual, a 374 page leisurely drive reminding me of repairing hi-fi VCR's...
Assuming the IF-283 option board is similar- But service manual does not include that board's schematic, as I searched 
Anyhow, DCD is not used, only the usual DB-25 pins:2,3,4,5,7,20. No DIP switches to set for the IF-283 installation, it seems to be a RS-232 and UART card. Just two custom ROM's for it.

[BrianHG]

https://forums.ni.com/t5/LabVIEW/DAT-Audio-Driver/td-p/212692
Do you have the service manual?  Sony may be using a funny termination string, or, even an initiation string?

[Tomorokoshi]

Try end-of-line squences of <CR>,  <LF>, or <CR><LF>.   Beyond that gets you into the world of <ETX>, etc.

Also try <LF><CR>.

[Leo Bodnar]

Are you certain you are sending the right data to it?
Sony liked packetised formats like this ftp://ftp.sgi.com/sgi/video/rld/vidpage/s9pinnt.html with flow control and checksummed packets.
Leo

[AndyC_772]

Some great suggestions here folks, thanks for accepting the challenge on my behalf!!

I'm back at work now so it may be a few days before I get to have another session, but in the meantime:

- The wiring I've been testing with does include a link between pins 6, 8 and 20, though I'm pretty sure I've tried every combination of logic levels on the three flow control inputs. I have RTS/CTS connected to the host, and DSR is definitely required to be high. DTR is an output.

- I do have the service manual, including schematics. The RS232 transceiver is an LT1134ACS-E2, which has the curious characteristic that its receiver input thresholds are small and positive, ie. it could actually be driven at logic levels. In any event, I know it's working because of the RS232 status display on the machine's front panel.

- I'm using 7O1 because that's hard wired when the machine is in "ISR" mode.

I'm starting to wonder whether the information in the service manual is incomplete in terms of the command format it's expecting, and that there is some kind of packetisation and formatting required which isn't listed as part of the ISR command set.

Many of the commands look like SCPI, though with an added semicolon, ie. the command to query the device type is "*IDN?;" rather than just "*IDN?". Maybe there are framing characters too, which they've not thought to mention? If that's the case, I could be in for a LOT of trial and error (which, honestly, I just don't have the time or inclination to do, given that all I really want to do with this machine is reset the 'scheduled maintenance' warning that comes up because the heads have done 1000 hours).

[nali]

It's probably using Sony's Interactive Status Reporting, which in turn is based on a SMPTE protocol. Not a whole lot of info on the web about it though

From thevideoguru.com

For complex devices there is SMPTE 269M, the status monitoring and diagnostic protocol (SMDP). SMDP is just a protocol, not a defined language; there's a lot of room for implementation flexibility. In this it resembles IEEE-488 (GPIB), which inspired it. At least one manufacturer implements SMDP (under its own trade name) across a wide range of its products; it began doing so when it got into the systems business and saw how such a reporting system could save it time and money in installing and servicing large systems. 269M is defined using a short, point-to-point serial interface, but nothing prevents it from being carried on a LAN; in fact, it was expected that LANs would be the most common implementation of such systems

[AndyC_772]

I think you're definitely on to something here 

I found this when searching for SMDP:

http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=7240343

This document describes a protocol which looks very, very like the one in the PCM-7040 service manual, but it includes details of a data link layer (section 9) with a defined packet format including special characters for start and end of text - which, of course, I've not been sending.

That would explain why the Sony is ignoring me!

[floobydust]

The service manual oddly mentions a 50msec request time, I have no idea if this the card IRQ or serial data requirement

[AndyC_772]

We have a winner

The answer is, the Sony requires commands to be formatted according to SMPTE 273M, which requires special synchronisation and start/end of command characters. The proper sequence for a simple command (*IDN?) is:

0x16 0x02 *IDN?; 0x03 0x16

With the special characters included, the PCM-7040 sings like a canary 

But...

Clearing the error log doesn't make the 'caution' message at power-up go away.

There is, in fact, no documented command to reset the hour meter 

It looks to be a deliberate omission. The clue is in the procedure for replacing the main board:

• Record the hours meter information
• Make a note of switch settings (etc)
• Check the backup battery on the new board
• Set DIP switch to clear the backup memory
• Power on, check for 'all clear', power off
• Set the serial number (refer to service menu in section 2.6.6 - all documented)
• Set the hours meter information which was recorded in step (1)
• Set the clock, perform various checks and adjustments...

The actual procedure for setting the hours meter is clearly glossed over. Just going into the service menu and trying to change the displayed digits, in the same way as every other parameter, doesn't work. There must be some other magic sequence of buttons to press, which have now undoubtedly been forgotten by the select few people who ever knew.

Unless, of course, anyone here knows otherwise? 

(Resetting the backup memory *does* zero the hours meter, including the 'not resettable' meter which is supposed to show the true number of operating hours. There's a separate 'resettable' meter which is the one I really wanted to reset).