Radio Communications (Mscan.exe)

For background information see LOWIS Server Architecture Overview

In LOWIS, the mscan.exe program is used to communicate with devices that are connected via radios, where the radio transmitter is directly connected (or made to appear as if it is) to the LOWIS server.  For devices where the radio is connected to a TCP/IP device, please see the TCP/IP Communications (mipscan.exe) article which discusses how to configure these.

Radio transmitters are typically connected to a server via a RS-232 connection, and require more tuning than other communication mechanisms before functional.  Part of this is due to the transmitters normally being powered down and requiring a small period of time to become fully functional again once the port has been activated (which signals the transmitter to start powering back up). The RS-232 port was originally meant to be used for direct connections between devices, so the port has no concept of needing to wait for the device on the other end to be ready to receive data.  This can be shown with the following image, where the line indicates the transmitters ability to transmit and and a visualization of the data being transmitted.

In this image the blue background indicates that there is a period after the port is initially activated until it is ready to be able to accurately transmit data.  The yellow tinted section is to indicate when data is being transmitted, and the green tinted section indicates that the transmitter is powering back down to a low power state.

Key On

This powering up period (blue) is configured as the KeyOn period in LOWIS and is meant to specify the amount of time (in milliseconds) until the signal coming off of the transmitter is strong enough to produce a valid signal. The Key On period also should account for how long it may take the receiving device to notice the transmitters signal and switch itself into a receiving mode.  This is why the Key On value is specified in the device configuration in LOWIS instead of just on the COM port.

Key Off

For some transmitters, there might be a small delay between when data is handed to it for transmission before it is actually sent out.  In some cases, once the RS-232 port indicates that it has finished its request the transmitter might start to immediately start powering down, not waiting for the yet to be sent data to be sent first.  To account for this, there is a configuration setting in LOWIS called KeyOff to delay the signaling to the RS-232 port for it to signal that the transmission is complete to allow these extra characters to be transmitted cleanly.  Note that this value is also configured in LOWS on each device instead of just on the COM port.

Read/Write Constant/Multiplier

There are four configuration settings in LOWIS that are used for determining how long the mscan.exe process will wait for the reply to be sent from the device, two for read requests and two for write requests.  For both of these sets there is a base value and a per character value.  For reads, the Read Constant value is the base amount of time to wait and the Read Multiplier is the expected amount of time each character will take to be transmitted.   For writes, these are Write Constant and Write Multiplier. The Read values are used both for the transmission as well as for the receive time waited.

The idea behind each of these is that the constant value should be the amount of time it will take the device to process the request and prepare the answering reply while the multiplier portion will account for the amount of time it will take for the reply to actually be transmitted.  As mentioned in the LOWIS Architecture article, when a request message is prepared in LOWIS it also calculates the number of characters that are expected to be in the reply.  This count is what the multiplier is applied to in order to determine the transmission time for the reply.   As a result of these, the mscan.exe process will wait the Constant + multiplied time amount before ending listening, if the reply has not already been fully received before then.

Baud Rate/Data Bits/Parity/Stop Bits

RS-232 ports are performing a digital to analog conversion when sending data and an analog to digital conversion when receiving the data.  As such, they need to know how to interpret the voltage signals they are receiving to convert them into their digital equivalents.  This is the purpose of the baud rate, parity and stop bit settings.  In general, all that really needs to be known is that both sides of the connection need to be using the same settings and that there is no way for the RS-232 ports to determine the settings from the communication stream itself.

In more detail, baud rate specifies the rate of bits per second that the devices should be sending/receiving at. A 9600 baud means 9600 bits per second, or roughly 1200 bytes per second (the roughly will make more sense by the end of this section).  The higher the baud rate, the higher the throughput; however, it also makes for a smaller window in which a signal fluctuation can affect how the data is interpreted.  Baud rates are typically specified in groupings of 300, with typical settings being 110, 300, 600, 1200, 2400, 4800, 9600, 14400, 19200, 38400, 57600, and 115200

Data bits indicates how many bits of data are to be sent in each packaging of bits that are sent.  8 data bits is typical, but on some systems 7 bits may be used.

Stop bits indicates the number of bits that are inserted after each byte of data has been transmitted to provide for better error recovery. Typically only 1 stop bit is specified, although some systems allow 1.5 (an extra long bit) or 2 to be specified.

Parity specifies whether an extra error detection bit is to be included with each byte of transmitted data and if so which calculation will be used to check this bit.  Settings for parity can be among the following:

• None (typical) - no parity bit is added
• Even - a bit is added whose value will make the total of on bits in the sequence into an even value
• Odd - like Even, but will make the count an odd value
• Mark - a bit is added that is always on
• Space - a bit is added that is always off

For an N-8-1 setup (No Parity, 8 data bits, 1 stop bit), this will mean that for each transmission packet there will be

• 1 start bit (always included)
• 8 data bits
• 1 stop bit

or 10 bits of transmission for every 8 bits of actual data, meaning that it is 80 % efficient.  If parity bits are added the total will become 11, or 72% efficient.  So for a N-8-1 connection the throughput will be 960 bytes per second (9600 bits per second / 10 bits per byte).

Knowing the baud rate/data bits/parity/stop bits of a COM port allows someone to calculate the read/write multipliers mentioned earlier in this article and is why the multipliers and constants are configured in LOWIS for the COM port as well as the baud rate/data bits/parity and stop bit values.

RTU Error Bytes and Protocol Aware

The RTU Error Bytes and Protocol Aware settings are included at the Scan Task level even though they are related to radio communications.

As mentioned before, when a request is built within LOWIS, we also calculate how many bytes should be in the reply and we wait for that many bytes to be returned (or until the calculated time for receiving the message has passed) before we stop listening for more bytes.  As radios are interpreting radio waves, they might either hear transmissions from other radios or they might think they are hearing a transmission when it is really just radio noise.  In either case, what is received by LOWIS might include characters that were not intended to be interpreted.   If these extra characters happen to occur at the start of the received reply, this will result in the final characters of the actual reply being missed as the expected byte count has already been received.  The RTUErrorBytes setting allows for additional bytes to be included in the expected receive count to work around this issue.  The RTUErrorBytes setting is a value for the number of extra bytes to be listened for before considering the reply to be complete.  While this will allow for correct reception in those cases where error bytes are actually in the reply, the downside is that if in general error bytes are not received then there will not be any extra bytes received to complete the expected byte count, meaning that receives will only be ended after the calculated time for reply has been exceeded, making the overall performance of the COM port slower.

To work around the issue of having to timeout for non-existing error bytes, the communication layers in LOWIS (where appropriate) have been configured to be able to understand certain protocols to know how to detect where the actual reply is in the received data stream.  This functionality is enabled by turning on the ProtocolAware setting in the associated scan task in the LOWIS configuration.  This value works in conjunction with the RTUErrorBytes value in that it will look within the first few bytes (or those few bytes plus the setting for RTUErrorBytes count of bytes) for the beginning unique signature of the reply message.  If it finds it in those bytes, it will discard the extra bytes found before that point and then read only for the original expected byte count of the reply message.  This means that it will stop listening once the completed message has been received instead of waiting for the extra bytes that might not arrive.  If the expected start of the message is not found within those few bytes, it will stop listening at that point and immediately return instead of waiting for the remainder of the characters to be received before timing out.  In both of these cases, overall COM port throughput is enhanced.