The Devices and Triggers Section

The Devices and Triggers section allows you to define how the player interacts with RS232 devices, e.g., attached screens or barcode scanners, and Broadsign Player API.

 

The Devices tab of Configuration Profile Properties

In the Devices tab, you can toggle between basic or advanced mode:

    • Basic mode: Presents a graphical user interface.
    • Advanced mode: Can be useful if you want to copy and paste a complicated configuration into another without having to recreate it through the interface. See Configuration Profiles – Players – Advanced Mode.
Devices

In this tab, you can configure the serial or TCP port configurations required to control RS232-attached devices:

    • Name: Name the Device.
    • Type: Serial or TCP (see images)
    • COM Port: Select the correct COM port, speed, byte size, parity, read timeout, flow control, and stop bits for your device. The exact settings depend on the capabilities of your serial or TCP port, and the attached device. Default settings work for most devices. Consult the user manuals of your devices for further details.
    • Drain Bytes: Drains the specified number of bytes from the serial port before executing any RS232 command, making sure it is clean. Some screens periodically fill the RS232 command buffer with garbage data, preventing the Player from correctly identifying the expected response for a given command.
    • Endian: Interprets routines related to Query Temperature and Query Brightness commands.

Serial

TCP

Actions

Once your devices have been configured, you must add the RS232 actions you would like to perform.

When dealing with RS232 screen control, by far the most commonly used actions are:

    • Set Power On: Ensures that a screen is correctly powered on at the beginning of a day.
    • Assert Power On: Verifies, throughout the day, that a screen is on.
    • Set Power Off: Ensures that a screen is powered off at the end of the day.

In order for the player to issue such commands, hex or ASCII codes need to be defined for each possible action.

  1. Start by consulting your device’s user manual.
      • The commands and their expected responses are usually supplied in ASCII or HEX format.
  2. Click on “Convert to Hex” or “Convert to Ascii” to enter the command codes in the desired format.
      • The expected response can be left blank if need be.
      • If specified, the player will use it in order to ensure the command has executed successfully. If it fails, the player will open an incident.
      • Query Temperature and Query Brightness fetch values from sensors, i.e., the expected responses have portions that are variables. See “Auto-Brightness” and “Temperature Monitoring” in Edit a Screen Control.

Add an action to a device

 

In the Triggers tab, you can toggle basic or advanced mode:

    • Basic mode: Presents a graphical user interface.
    • Advanced mode: Can be useful if you want to copy and paste a complicated configuration into another without having to recreate it through the interface. See Configuration Profiles – Players – Advanced Mode.

The triggers tab allows you to configure the player to receive and respond to triggers issued by RS232 devices such as barcode scanners or switches. In order to activate this functionality, you must first enable the trigger monitor in the Core tab, then configure your serial port similar to how serial ports are configured for devices.

Once done, you can add trigger actions. A trigger action can either match a specific ASCII or HEX string or match everything by clicking “Match All”. The duration of the trigger indicates for how long the triggered Ad Copies should play, if left 0, the triggered Ad Copies will play for their entire length. Lastly, you must choose the trigger category to issue in order to match the correct bundles.

For more information about triggers, see Frame Synchronization.

 

The Core tab of the Devices and Triggers section

    • Network Triggers: The Network Triggers section allows you to enable the trigger monitor and configure how it should behave with regards to network triggers. Network triggers permit you to synchronize multiple players on the same network segment by defining one as the Master and the others as Slaves. (See Frame Synchronization).
        • Network Synchronization Types:
            • None: The player will not issue or respond to network triggers.
            • Master: The player will issue network triggers.
            • Slave: The player will respond to network triggers.
            • Master-Slave: The player will both issue and respond to network triggers.
        • Port: This is the port that the UDP or TCP packets will be sent and/or received on.
        • Routing Scheme: The Routing Scheme determines how synchronization packets are propagated.
            • UDP Broadcast: The Broadcast option is the simplest. In this case, UDP packets are sent on the IPV4 broadcast address (255.255.255.255). In order for a Slave to receive broadcast triggers issued by the Master, they should be on the same network segment.
            • UDP Multicast: Multicast is preferred for some networks to reduce network congestion. You must specify a multicast group address for both the Slave and Master players to join using IGMP and be sure the correct routing equipment is in place.
            • TCP: In networks with high packet error rates, such as Wi-Fi, TCP packets are preferred. This method is advantageous because the sender will retransmit if a TCP packet is lost. When the Master is configured to use a TCP Routing Scheme, it will open a TCP socket server on the specified port and wait for client connections to be established. Whenever a trigger needs to be issued it is sent individually to each client connection.
    • External Triggers: See Triggers Action – Use Master Frame Triggers.
    • Video Synchronization: Video synchronization permits Master and Slave videos to synchronize their playback so that the videos start at the same time and play back at the same frame rate. This feature allows for multiple frames of video within the same display unit to be synchronized, as well as several videos to play across networked players.
 

From this tab, it is possible to add security and encryption to Broadsign Player’s remote control functions. You can access them via the remote_action command line tool, as well as JavaScript, ActionScript, and other programming languages.

    • Enable Remote Control:
        • Port: For the remote_action tool, use Port 2324. For more information, see Player API – Overview.
        • Accept connections only from localhost: By default, it is unencrypted and we protect the service by allowing connections from localhost only.
        • Use SSL/TLSv1: When remote control functions are exposed via a public IP and port, it is possible to implement security and encryption with SSL/TLSv1.
        • Require password: When remote control functions are exposed via a public IP and port, it is possible to implement security and encryption by requesting a password.
    • Enable Web Sockets:
        • Port: When connecting to the WebSocket server, use Port 2326. For more information, see Player API – Overview.
        • Accept connections only from localhost: By default, it is unencrypted and we protect the service by allowing connections from localhost only.
        • Require password: When remote control functions are exposed via a public IP and port, it is possible to implement security and encryption by requesting a password.

Notes:

    • When an SSL connection is required, an SSL connection on the sending end needs to be implemented as non-encrypted connections will no longer be allowed.
    • The certificate of the remote control service is self-signed using Broadsign’s certificate authority. Any software used must be able to catch this warning and allow the connection to proceed.
    • When a password is used, the client must send a password string matching the one specified.
    • A client software sending its own XML documents must send the password as an additional XML attribute as shown in the sample ActionScript 2.0 below:
      // Start ActionScript 2.0
      var theSocket:XMLSocket = new XMLSocket();
      theSocket.onConnect = function(myStatus) {
        if (myStatus) {
          var myString:String = "<rc version=\"1\" id=\"1\" password=\”OCTOSHAPE” action=\"trigger\" trigger_category_id=\"xxxxxx\" duration=\"yyyyyy\"/>\r\n\r\n";
          theSocket.send(myString);
        }
      };
      theSocket.connect("localhost", 2324);
    • When using the remote_action command line tool, the following arguments should be used:
        • -S [ --ssl ]: to use SSL/TLSv1
        • -w [ --password ] arg: to use the password specified