Debug log

Description of some of the messages found in the debug log.

Directory Table

W(1.65) ERR_NVRAM, no:26  "CTNS_GPDH2" P1: 0, P2: 29, P3: 863

An element in the directory tables internal hash fast lookup table has a wrong value.
(The directory table sorting system (TNS) will be triggered for be rebuild)

W(1.65) TNS_VERIFY, no:34  "CTNS_V_NOW" P1: 0, P2: 0, P3: 0 

The directory table sorting system is triggered for verification/rebuild (Verify Now) .

W(1.65) TNS_VERIFY, no:35  "CTNS_REGEN" P1: 0, P2: 0, P3: 0

The directory table sorting system is regenerated.

Data Protocol

E(1.65) UNEXP_SWITCH, no:27  "DplcSndMsg" P1: 7, P2: 1, P3: 0

P1: = Link number (ACDP link)
P2: = Link address (Device number)
The ACDP link is not operational thus no message could be sent.

INFO_DPMR_NO_ROUTE, no:1279  CSI#1 sent READY to CSI#1 state CSI/ReadingCommands (3)"" P1: 1, P2: 62, P3: 0 Packet to node 1 device 62 dropped, no routing information

The routing to node 1 device 62 is not available.
(Typicaly after reset before the links are up, or due to no configuration of the route to node/device)

Subscriber key signaling

E(1.65) UNEXP_SIG, no:1281  SBS#30 sent M_PRES_SBS to SBS#30 state SBS/IdleOnHook (14)"SBS010" P1: 0, P2: 0, P3: 0

Relates to physical station 30.
The signal M_PRES_SBS is used during active states of a subscriber. (Active in features like a call)
Since the station now is "IdleOnHook" probably the station just came back from an active state and received this signal delayed.
Maybe event handler or $DP signaled M pres?

E(1.65) UNEXP_SIG, no:6 TO_IF#1 sent KEY_PRES to SBS#30 state SBS/NoSLI 
(1)"SBS010" P1: 0, P2: 0, P3: 0 (1)"SBS010" P1: 0, P2: 0, P3: 0

E(1.65) UNEXP_SIG, no:87  TO_IF#1 sent KEY_REL to SBS#30 state SBS/NoSLI 
(1)"SBS010" P1: 0, P2: 0, P3: 0 (1)"SBS010" P1: 0, P2: 0, P3: 0 

Relates to physical station 30.
The station is in state "No subscriber line interface", this means not connected/registered or not found jet (ASLT scanning after reset.)
The station receives a KEY PRES/KEY RELEASE signal, this should not be possible unless the signal comes from event handler or $DP signaled key pres.

E(1.65) UNEXP_SIG, no:7  DP#1 sent M_PRES to SBS#30 state SBS/NoSLI (1)"SBS010" P1: 0, P2: 0, P3: 0

Relates to physical station 30.
The station is in state "No subscriber line interface", this means not connected/registered or not found jet after reset.
The station receives a M_PRES signal from date protocol. I.e. from Event Handler or ACDP.

W(1.65) TABLE, no:57  "CipherErr" P1: 0, P2: 0, P3: 0

Problems with decoding of the license key.
Corrupted license string.
Could be wrong license MAC address.
Issues with reading own MAC address.

RCI - RCO

There where made RCI/RCO related fixes 11.2.3.2.

• Multi Drop Master protocol
• RCO timers where made individual.
• New flag for automatically sync of RCI state ON/OFF when RIO/MIO reports states out of the AMC expected order. .ex_profile.flags.RCI_sync = 0

RCI

W(1.65) UNEXP_SIG, no:36262  DP#1 sent SCAN_RCI_ACK to RCI#51 state RCI/WaitResp (8)"sRCI010" P1: 0, P2: 0, P3: 0

Relate to logical RCI 51. The input device (RIO/MIO) is sending $SCAN_RCI_ACK in a state where $RCI_IS_ON or $RCI_IS_OFF is expected.
Last signal received before this state was $SCAN_RCI_ACK, thus it looks like double signaling.

W(1.65) UNEXP_SIG, no:257  DP#1 sent SCAN_RCI_ACK to RCI#71 state RCI/WaitRespAlarm (14)"sRCI010" P1: 0, P2: 0, P3: 0

Relates to RCI 71.
The RCI is active, expected signal is RCI_ON or RCI_OFF (dependent on the polarity setting).
Instead SCAN_RCI_ACK is received.

RCO

W(1.65) UNEXP_SWITCH, no:65294  DP#1 sent CLEAR_RCO_ACK to RCO#1 state RCO/Running (1)"RcoUnexp" P1: 7, P2: 0, P3: 0.

Relates to RCO 7 (P1)
Unexpected CLEAR_RCO_ACK from RIO/MIO, (no pending ACK for this RCO). Could it be resending of CLEAR_RCO_ACK?

W(1.65) UNEXP_SWITCH, no:10429  DP#1 sent SET_RCO_ACK to RCO#1 state RCO/Running (1)"RcoPolarit" P1: 8, P2: 0, P3: 0

Relates to RCO 7 (P1)
unexpected SET_RCO_ACK from RIO/MIO, (no pending ACK for this RCO). Could it be resending of SET_RCO_ACK?

Conference

E(1.65) ILLEGAL_PAR, no:39413  SPF#30 sent ST_TALK_STOP to CNF#5 state CNF/Operating (1)"CnfTalkSto" P1: 30, P2: 0, P3: 0 

Physical station 30 was asked to stop talking in conference 5, but no one was talking in the conference.
P1 = New Talker To stop
P2 = Current talker

E(1.65) UNEXP_SIG, no:39414  SPF#30 sent DP_TALK_END_RCTRL to SBS#30 state SBS/IdleOnHook (14)"SBS010" P1: 0, P2: 0, P3: 0

This is a result of the "CnfTalkSto" error message.
Conference 5 was replying to the "stop talking message" but subscriber 30 was not talking, "IdleOnHook".

E(1.65) UNEXP_SIG, no:41065  SPF#37 sent DP_TALK_SUCCESS to SBS#37 state SBS/GoActiveKeyPres (52)"SBS010" P1: 0, P2: 0, P3: 0 

Station 37 entered talk mode in a conference at the same moment as a key pres was activated on the station.
This resulted in the acknowledge message "DP_TALK_SUCCESS" from the conference was received in a transit state for activating the station because of key pres.

E(1.65) UNEXP_SIG, no:41068  SPF#37 sent CONFERENCE_MODE to SBS#37 state SBS/ConfGoTalk (76)"SBS010" P1: 0, P2: 0, P3: 0 

Station 37 is entering talk mode in a conference and at the same time receives a signal for entering conference mode.
The subscriber and the conference seams to be out of sync, or $DP conference messages are interfering the internal state changes of the station

E(1.65) UNEXP_SIG, no:21354  SPF#30 sent NORMAL_MODE to SBS#30 state SBS/IdleOnHook (14)"SBS010" P1: 0, P2: 0, P3: 0

Physical station 30 is asked to leave conference mode and return to idle, but the station is already in idle.
(Conference and station mismatch in state, $DP messages?)