Dolby DSP100 TCP cues

[Jose Angel Velasco]

Hello.
Is possible to add JSD60 TCP cues to a DSP100 server? Maybe adding a CP650 with the CONFIG script and modifying some cues file?
If not possible, how can I add serial cues?

[Steve Guttag]

It is not possible. You could use a serial to Ethernet adapter to give it Ethernet commands.

Note, later DSS systems (DSS200 or DSS220), in one of the version 4.9 software (not available to the DSS100/DSP100) could have ONE Ethernet device where one could make a suitable XML file with the commands.

Dolby was very closed on their Ethernet usage despite, since the DSS100, its ability to talk Ethernet to the NA10, CP650, CP750.

I can tell you, from my work on a CP650 emulator for Q-SYS, the DSS series really expects the responses to be right or it shuts down the service. For instance, while emulating the CP650 within Q-SYS, I was using an Ethernet to serial adapter so I could present the DSS server with the right port number. If I would push a new design, that would cause the DSS server to see the CP650 stop responding yet the port/socket remained open due to the serial to Ethernet adapter...the DSS would shut down CP650 communication and not recover until the server was rebooted. (My solution was for QSYS to energize a relay when the design was running that then turned on the adapter. So, from the DSS' point of view, it behaved like a CP650...if the unit is off, the socket disappears...if the unit is on, it has a finite time to start responding.

[Jose Angel Velasco]

Ok, and serial cues? The JSD60 accepts serial cues too.

[Steve Guttag]

Well, there you go. There is a 9 pin serial connector for serial cues. You define the commands, and the communication parameters.

[Dave Macaulay]

Serial works well. Just experiment a bit with one cue until you get the line terminator correct. I think it's either \0A (line feed) or \0D (carriage return).
If you make the cues "sound" cues they will be available in the GUI otherwise only in a playlist.
If you want to control anything else, serial is a one to one connection so it's all used up with just your JSD60.
I have used a Jnior as a serial to network converter and controlled sound, lights, mag door release, and masking via both the network conversion and relay controls. If you have an NA10, ok it works but is no longer supported at all.
True the recent DSS200 software versions allow network control of non Dolby devices but boy it isn't easy.

[Jose Angel Velasco]

I have a JNIOR, but I only need the cues for the JSD60. Is explained on any manual the creation of serial cues on the DSS100?

[Dave Macaulay]

I think there is a serial to network manual, the integpg.com website has all the manuals. The Junior app has to be loaded and configured but it works great.

[Jose Angel Velasco]

No, I'm searching for a manual of how to configure the serial cues on the DSS100.

[Leo Enticknap]

It's pretty straightforward. Firstly, in system > auditorium, you need to enable "this auditorium uses serial automation." If this box is unchecked, the "serial automation" tab disappears.

image.png

You then enter the RS232 configuration (e.g. 8N1), the termination string, and the actual cues into that tab as so. It's pretty self explanatory:

image.png

This example shows the cues for a MiT IMC2-B automation controller, but the principle is the same for any device that can accept cues as regular ASCII strings.

[Harold Hallikainen]

Note that JSD-60 commands are terminated with carriage return (0x0d).

Also, the JSD-60 has a command that can send strings over TCP to other devices. So, you can use the JSD-60 for RS232 to TCP conversion.

The command is:

jsd60.sys.tcp_send ip3 ip2 ip1 ip0 port StringToSend

The arguments are tab or pipe delimited. So, you can send this to the JSD-60:

jsd60.sys.tcp_send|192|168|1|123|456|Hello world!\r

to send Hello world! to 192.168.1.123:456

Harold

[Steve Guttag]

That is a rather cool feature!

[Jose Angel Velasco]

Thank you!!!!
I see that the only way to test the cues is on a playlist.
The SERIAL-TCP conversion of the JSD60 is fantastic. Is an undocumented command? I haven't seen it in the JSD60 manual.

[Harold Hallikainen]

Thanks! I added tcp_send in version 130513 . The manual never caught up. I added this to the JSD-60 when developing the LSS so I could get a DSS-200 to control the LSS. This was before we added the flash sequence script start to the LSS. The string to send can contain any character (including the field separator pipe). The following escape sequences are supported:

\\ = backslash
\t = tab
\n = newline
\r = carriage return
\a is alarm (bell)
\f is form feed
\v is vertical tab
\b is backspace

[Bruce Cloutier]

All of these commands are nice but... The thing is that there are no acknowledgements. So you do not even know for certain that your command was transmitted or received and that the subsequent TCP command was transmitted or received until someone complains that something didn't happen like it should have.

Naturally stuff works great when you test it. Generally it fails when you go to demo it to management. Finally it works as it should until it doesn't and that will be at the worst possible moment.

I realize that the bidirectional aspect implies a protocol and some kind of programming. Then you have to decide what to do if the command fails or the endpoint refuses to do what you ask. These simple strings are easy peasy. I get it.

Then there is the confusion that will occur in a year when the next guy is asked to get it working again and he has no clue.

I shouldn't mention the lack of login or security. This kind of open remote procedure call (RPC) is in part responsible for the hacker's paradise we have created. But.. oh well.. a little too late on that front.

Come on guys... it's 2025 and here we are still discovering escaped characters?

I'm even more grumpy today than usual. Sorry. There is no hope.