SRF-Consulting-Group-Inc / iris

Intelligent Roadway Information System
GNU General Public License v2.0
2 stars 0 forks source link

Skyline Signs Font Update Fails-Makes Sign Unusable #51

Open mgallagher01 opened 1 year ago

mgallagher01 commented 1 year ago

NDDOT has about Skyline brand signs. A combination of conditions in IRIS and the sign controller causes font updates to fail and subsequently the sign is unusable.

Per John's description: Summary: At least two bugs and one "implementation weakness" discovered:

  1. IRIS OpSendDMSFont process was not 100% compatible with the NTCIP1203v3 font sending sequence. When IRIS attempted to send font #1 to the controller, this bug invalidated font #1, and caused an unexpected noSuchName error which then crashed IRIS's upload process. This is fortunately fairly easy to fix (only took about 4 hours to track down and create a fix). But unfortunately leaves the signs in a state where IRIS is unable to upload fonts to that controller because....
  2. The Daktronics controller firmware in these signs has a bug in it where font rows with invalidated (notUsed) fonts throw a noSuchName error when IRIS tries to read the associated fontNumber object. ("This should never happen.") Because, according to NTCIP 1203v3, Annex D, section D.6, paragraph 2: "When a font is deleted by changing its fontStatus to ‘notUsed’ the fontNumber remains, and, according to Section 5.4.2.2, values for this object must be unique across all entries, not just valid entries."
  3. (The "implementation weakness") Once a controller reports noSuchName when retrieving fontNumber from font row #1, IRIS is unable to send fonts to that sign. Unfortunately, the OpSendDMSFont process counts on both parts of "paragraph 2" above and it craps out when it can't read the (guaranteed available -and- unique) fontNumber values for all font rows.

We thought we had this resolved - IRIS was able to send a message to the sign, but even though it appears to be displayed in IRIS, no message appears on the actual display.