Serial Remote Control

PDM II's serial control options permit custom interfaces for on-air or logging systems via a network connection. There is no hardware serial port.

Standard IP-based Connections

Commands and queries can be transmitted as TCP socket connections to the unit's network port 5443 when enabled in the Configuration screen's "Control" section.

Once enabled, port 5443 remains accessible to the entire network until it is specifically closed. There is no password checking. Therefore we recommend the use of a firewall or keeping your PDM II on a dedicated closed network.

Serial Language Structure

PDM II's serial remote control language is designed to be easily implemented from any terminal program, by macros in most automation systems, or by computer programming language.

Requests and responses are standard ASCII characters, based on plain English, using familiar PDM II “front panel” designations whenever possible.

  • Requests - messages from the controller to PDM II - consist of a number of words followed by a Line Feed character <LF> (ASCII 10). Messages are case-sensitive. Note that Carriage Return (ASCII 13) is ignored.

  • Responses - replies from PDM II back to the controller - consist of a single Result character, any appropriate message, and then <LF>. The Result character may be one of the following:

    • ! - Indicates a command has been received and acted upon

    • ? - Indicates a command isn’t understood or can’t be acted upon

    • @ - Indicates an event message that wasn't an immediate response to a command

Output Events can be sent by PDM whenever there’s a change in status, such as memory being filled or buttons being pressed, and are provided to design custom serial interfaces to other equipment. Use the enable command to specify which events generate a message.

Request Syntax

Requests consist of a command (something for PDM II to do), usually followed by arguments (what it should act upon), and then a Line Feed <LF>. Commands include:

  • down - Start the event described by <argument>. Used for level-sensitive inputs

  • up - End the event described by <argument>. Used for level-sensitive inputs.

  • trigger - Momentary activation of <argument>, the same as tapping a button. Used for triggered inputs.

  • get - Returns the status of <variable>

  • help - Returns hints about PDM II's serial language

  • enable - Turns on Output Event reporting for a specific PDM II condition

  • disable - Turns off reporting for a specific condition

Arguments act the same as the identically-named GPIO inputs as described in the GPIO section. You may enable or disable Output Event reporting for just about every PDM II function. Arguments are also case-sensitive. They use internal capital letters and must be sent exactly as shown. Arguments include:

  • Build

  • Exit

  • Cough

  • Dump

  • Bypass

  • Cue 1 - Cue 8

  • Flag 1- Flag 8

Variables include:

  • Depth - Current audio delay length in seconds and tenths

  • PeakInput - Peak input level, both channels, in dBFS

  • PeakOutput - Peak output level, both channels, in dBFS

  • TemperatureC or TemperatureF - Current internal temperature in whole degrees Celcius or Fahrenheit depending upon the request

Output Event messages sent by PDM II are @nameOfEvent.[=1 or =0] followed by <LF>. NameOfEvent can be any event reported by the GPIO. If an event is momentary (such as a button press) the Boolean does not appear.

=1 or =0 appear only if the event is an ongoing state, such as whether the system is currently in Bypass Mode. These numbers do not appear for triggered events such as Cues.

A typical Output Event might look like: @DelaySafe=1<LF>, which translates to "Delay Safe is now on" and PDM II's memory has enough audio buffered to cover at least one complete dump.

Examples

Note 1: Help does not require an <argument>. If you send help<LF> by itself, it returns a list of valid commands. If you specify any command as the argument, it returns a brief explanation along with a list of the command's arguments.

For example, if you send help down<LF>, PDM II replies with !down: send Press signal for one or more space-separated events (None Build Exit Cough Dump Bypass Cue 1... etc. through Flag 8).

Note 2: Output Event Messages (preceded by @) only appear after they have been specifically enabled for a type of event.

Output Event Messages

PDM II's Output Event messages can be used to build elaborate custom remote controls. Any event that can trigger a GPIO output can also be sent serially.

Each type of output event must be specifically enabled before PDM II will report it. This way, you can tell PDM II to report only those events that are important to your installation.

When a socket connection is made to port 5443, a System Active message is sent: @Welcome to PDM. This can be used as a handshake or as a signal to start your own routine for enabling those Output Events you want reported.

Events are enabled or disabled on a per-connection basis. You must send enable messages each time you establish a new connection. Otherwise, each connection to the PDM II defaults to having all of its event messages disabled.

enable Command

This command turns on PDM II's ability to report specific events.

  • Use the form enable EventName<LF>, where EventName is a change in PDM II's current status. For example, enable DumpTrig<LF> tells PDM II to send a message whenever DUMP has been activated.

  • Two or more EventNames can be combined in the same command by separating them with a space. For example, enable DumpTrig Muted<LF> tells PDM II to report any time either DUMP or MUTE has been activated.

  • Use All for EventName as a shortcut when you want to enable messaging for every PDM II event.

  • When PDM II receives any valid enable command, it responds !<LF>.

  • If a function is active when you enable its message, PDM II reports its state immediately and then sends an updated report when the state changes. For example, if you send enable Muted<LF> and the unit is already muted, it will immediately respond with @Muted=1. When Muting is turned off, PDM II will send @Muted=0.

EventNames used in enable commanded include:

  • Building - PDM II is building up a delay

  • BuildTrig - The BUILD button has been pressed

  • Bypass - PDM II is in a bypass state

  • Cue1 ... Cue8 - Cue point n has been reached

  • DelayEmpty - The memory is empty

  • DelayFull - The delay is now full

  • DelaySafe - A Dump increment has been reached in memory

  • DelayUnsafe - The memory contains some audio but not enough to cover a full Dump event

  • DumpTrig - The DUMP button has been pressed

  • EmptyTrig - The memory has just been completely emptied

  • Exiting - PDM II is exiting a delay

  • Flag1 ... Flag8 - Flag point n has been reached

  • FullTrig - The memory has just been completely filled

  • Muted - PDM II's output is muted

  • BuildLamp - The BUILD button is flashing

  • ExitLamp - The EXIT button is flashing

  • DumpLamp - The DUMP button is flashing

  • CoughLamp - The COUGH lamp is flashing

  • All - Enables events for all of the above events

Note - "Lamp" functions mimic the lamp state and report =1 or =0 every time a front panel button flashes on or off.

disable Command

The disable command turns off reporting of one or more output events and follows a similar syntax.

  • disable DumpTrig<LF> tells PDM II to stop reporting that DUMP has been activated.

  • disable DumptTrig Muted<LF> turns off reporting for both functions.

  • disable ALL<LF> turns off any message reporting.

  • PDM II responds to valid disable commands with !<LF>.

Note - The disable command affects only serial messages. Parallel GPIO functions on the DB-15 are not affected and remain as set on the front panel or via the web interface.

Last updated