American Signal sign controller exhibit some odd behaviour when communicating with IRIS. These must be remedied in the controller firmware to be properly addressed.

Known Versions

There are several different firmware versions in use by NDOT as of 9/15/2021. All seem to be equally affected by the bugs. Count Firmware Version

• 10 20181016 - v664
• 4 20181224 - v669
• 3 20190308 - v685
• 32 20200405 - v702

Bug Summary

1. No response from the sign when an unknown SNMP/NTCIP object is referenced (for both SET and GET commands) using a recognized community name. The firmware should respond with a standard SNMP noSuchName error-response. This is confusing when using UDP communication since it looks the same as a communication failure.
2. Font IDs are not CRC values calculated from the content of the font as defined in NTCIP 1203, but are sequential (running from 1...N; where N is the number of fonts in the controller). The sequential numbers make it difficult to determine whether the font is different from an font in the IRIS table and complicate font management.
3. The dmsMsgTableSource object initially stores the correct value, but at some random time later, substitutes zero for the CRC portion of the value.
4. When a controller resets or restarts the dmsMsgSourceMode object is not always set.
5. This may be by design and isn’t an NTCIP-related issue, but the font table in the sign appears to be permanent and not updateable. As a result a standard font can’t be loaded into a consistent font slot across all NDOT PDMS.

#3 and #4 are why message sources are shown as "External" with an “OTHER SYSTEM” user in IRIS for some American Signal controllers. Without consistent message source information, IRIS has no way of knowing if it or some other system has posted a message.