Serial commands through Doremi

[Harshitkumar Thakker]

Hello,

Has anyone used serial communication through Doremi?

I have a Doremi Showvault/IMD with a Barco DP2K-10s projector. We have a need for a multiple HDMI input as that auditorium is used for FATHOM events with their DVR, also used by a church every week so they connect an HDMI to their Laptop and occasionally by our DVD player. So I bought a HDMI switcher that can be controlled via simple serial commands like >>HDMI1, >>HDMI2, etc.

I was able to connect it to my windows computer via a USB to serial converter and send commands using command prompt (copy con COM3: and it worked like expected - changing from one input to another.

However, I connected it to the Doremi via it's built in serial port and set up a device using raw serial and selected serial port /dev/ttyS0.
image.png

and setup macro to send text message to this device. But it doesn't seem to work. I have used simply >>HDMI1, I have used >>HDMI1\r\n, I have used >>HDMI1\r, I have used \w>>HDMI1\w, \wHDMI1\r\n\w. Nothing seems to work.

Anyone know how to send proper serial commands through serial port on a doremi?

Thank you in advance for your help.

[Steve Guttag]

Did you try \0A? Also, are you sure it does not need the carriage return? Using commands on one's laptop can fool people as often the program one uses will insert the CR in there. I'd try \0D\0A as well. You can also try moving that stuff up to the Macro itself.

Sometimes, it can be helpful to hook your laptop up to the device serially and see just what the device (Doremi, in this case) is spitting out to see where the issue is.

[Gordon McLeod]

One thing even though the Showvault is supposed to handle ASCI it doesnt do it well if at all one need to enter all commands in hex decimal and a carriage return is needed

[Carsten Kurz]

What Steve says - if you have a windows computer with USB-Serial - connect the Doremi to it with a simple crossen/nullmodem cable, and see what appears in a terminal program.

[Dave Macaulay]

Not having tried serial control from Doremi in years, in your image the "stop byte (in hexadecimal)" entered is OA - and that is definitely not hexadecimal.

[Steve Guttag]

I see it entered as 0A (zero A), which is Hex for 10 a/k/a: LF.

[Marcel Birgelen]

Did you try \0A? Also, are you sure it does not need the carriage return? Using commands on one's laptop can fool people as often the program one uses will insert the CR in there. I'd try \0D\0A as well. You can also try moving that stuff up to the Macro itself.

Sometimes, it can be helpful to hook your laptop up to the device serially and see just what the device (Doremi, in this case) is spitting out to see where the issue is.

In his case, he tried the "new line" \n (Unix style), the "carriage return" \r (Classic Mac style) and the "new line + carriage return" \r\n (DOS and Windows style). I'm not entirely sure if Doremi supports te /w command, but afaik, the /w command is supposed to be followed by a number: the amount of seconds to wait. I'm not aware that /w does have a well-defined default value.

Also, the stop byte has also been set to newline and the message type to end-of-line-byte, so it should send the \n (\0A) after every message already.

My suspicion is that there is a problem with the serial communication itself and not so much the serial commands. I would get rid of any \w though, as I believe it to syntactical incorrect without a parameter.

[Steve Guttag]

Since the graphic he hows specifically said in hexadecimal, I would avoid the shorthand methods of \n and the like. \0A (if it really is just looking for a line feed) or \0D\0A would be the safer commands to issue.

[Harshitkumar Thakker]

Did you try \0A? Also, are you sure it does not need the carriage return? Using commands on one's laptop can fool people as often the program one uses will insert the CR in there. I'd try \0D\0A as well. You can also try moving that stuff up to the Macro itself.

Sometimes, it can be helpful to hook your laptop up to the device serially and see just what the device (Doremi, in this case) is spitting out to see where the issue is.

Thank you Steve. I did try the \0D\0A in the macro itself and it didn't seem to work.

I also tried to convert the entire message into hexadecimal and put it in as binary message but the doremi would not save it - said it was invalid. So I went back and looked at the built in Jnior messages and all of them seem to begin with 01. So I did add the 01 in front of my message and it did save it but did not work either.

I'm going to try tomorrow to connect my computer to the showvault and see what is being sent out the serial port.

[John Thomas]

RealTerm is a good program for listening to RS232.

[Bruce Cloutier]

So I went back and looked at the built in Jnior messages and all of them seem to begin with 01. So I did add the 01 in front of my message and it did save it but did not work either.

With the JNIOR the Doremi uses port 9200 which is our (deprecated) JNIOR Protocol. It is binary and all of the messages start with 0x01. So that's not a serial character-oriented connection. The JNIOR can also handle serial messages depending on how you have it configured but I am not sure it would have helped you figure this out.

And, everyone is correct that the terminator on your string adds a lot of confusion. It seems that different Doremi software versions required different terminators from none to combinations of a space, carriage return, and/or linefeed (newline). Often too the Doremi assumes that an entire command and only one command comes/goes with each packet over the network. Which is incorrect as the packets implement a stream of bytes and commands can often be split across two or more packets. Even worse you can get more than one command in a single packet causing the second to be ignored and the next packet to be completely unintelligible. They eventually realizes they needed to terminate commands with something but, apparently, weren't sure what.

So we hear this a lot and even after experimenting and seemingly getting it to work, it might not always. That's when people get into repeating the same command trying to pound it into the destination. Lot's of high-technology... Um, not impressive programming IMHO.

This is probably an issue with other external devices as well.

[Bruce Cloutier]

I said "deprecated" and in case that raises a flag with you, no problem, we still support the JNIOR Protocol all though it is limited in what you can do with it. We have replaced that with the JMP Protocol (pronounced "Jump" which you old-school assembly programmers can appreciate). JMP uses JSON formatting.

Barco also likes JSON formatting. But along the lines of needing a terminator, the Barco programmers did not foretell the difficulty in receiving JSON. So, assuming they've not gotten lazy, to receive such a message they need to read and buffer the whole thing counting open and close curly braces taking care not to count those that might appear in strings or otherwise be escaped. That is a pain. It also makes it difficult to deal with malformed messages.

JMP uses JSON but encapsulates the entire message providing the size of the JSON object to follow. So you can easily read the message detecting the open bracket '[', reading the integer size, confirming the comma separator (ignoring whitespace), collecting the entire JSON message by byte-count and confirming the trailing bracket ']' (also ignoring whitespace (spaces, tabs, newline). A blank message looks like:

[14,{"Message":""}]

Anyway, JMP lets you do everything with the JNIOR and not just control the relays. You can transfer files and even open command console sessions. Our WebUI uses this exclusively.

Just FYI. It doesn't solve the original poster's question. Just fun info for us geeks here. I couldn't reference the JNIOR Protocol without suggesting that it is old stuff.