Problem receiving partial SNIP and/or PIP message replies

[jeff-tcs]

Hi Bob,
I am Jeff Snyder working with Jake at TCSDCC. I am not yet familiar with how to submit and issue to github so I wanted to use this reply to contact you for now. I am coding similar to the python openlcb software modules where I am sending out a request to far nodes to receive their SNIP. and PIP information respectively. Similar to the way example_remote_nodes.py does it and possibly how the swift version of the OlcbTools app does it.
I notice that in some cases I do not always receive all the messages for SNIP and PIP from some of the RR Cirkits signal nodes and from the Logic fast clock and Logic custom light nodes. This could be because these boards are "slower" to respond to the request message. Not sure. But I also notice OlcbTools sometimes gets partial messages but infrequently. However when JMRI's panelpro CDI gets node configuration info it never seems to get partial messages. Please advise...is there some additional code these apps have that compensates for possible slow reaction times of far nodes? Maybe I need to detect if I do not have all the info and have to then "refresh" the SNIP and PIP info from a far node.

[bobjacobsen]

PIP is a single frame reply. I'm not sure how you could get partial contents for that.

I haven't noticed LccTools getting partial SNIP information. I'll look harder to see if I can understand what's going on.

There aren't any timeouts in the SNIP-handling in JMRI, the Swift implementation for LccTools (https://github.com/bobjacobsen/OpenlcbLibrary) or the PythonOlcbNode library. They look for SNIP to be complete using the first, middle and end bit patterns in the 1st contents byte of the addressed frames for the SNIP Reply message.

Could you get a trace of what frames your code is processing?

Are you seeing the end of the SNIP contents missing, or perhaps some parts out of the middle?

[bobjacobsen]

Here's what JMRI sends for a SNIP request, from a JMRI trace:

11:16:56.522: [[19de8c1c] 0E 8F                  ]  S: 02.01.12.FE.9D.6E - 02.01.57.00.04.8C SimpleNodeIdentInfoRequest with no payload
  Src: JMRI - PanelPro

and here's the response from a Tower-LCC:

11:16:56.536: [[19a08e8f] 1C 1C 04 52 52 2D 43 69]  R: SNIP Reply 1st frame
11:16:56.536: [[19a08e8f] 3C 1C 72 4B 69 74 73 2C]  R: SNIP Reply middle frame
11:16:56.540: [[19a08e8f] 3C 1C 20 49 6E 63 2E 00]  R: SNIP Reply middle frame
11:16:56.541: [[19a08e8f] 3C 1C 54 6F 77 65 72 2D]  R: SNIP Reply middle frame
11:16:56.541: [[19a08e8f] 3C 1C 4C 43 43 00 72 65]  R: SNIP Reply middle frame
11:16:56.542: [[19a08e8f] 3C 1C 76 2D 44 00 72 65]  R: SNIP Reply middle frame
11:16:56.542: [[19a08e8f] 3C 1C 76 2D 43 37 65 00]  R: SNIP Reply middle frame
11:16:56.544: [[19a08e8f] 3C 1C 02 5A 69 6F 6E 45]  R: SNIP Reply middle frame
11:16:56.544: [[19a08e8f] 3C 1C 20 74 75 72 6E 6F]  R: SNIP Reply middle frame
11:16:56.548: [[19a08e8f] 3C 1C 75 74 73 20 31 73]  R: SNIP Reply middle frame
11:16:56.548: [[19a08e8f] 3C 1C 74 20 32 34 2D 30]  R: SNIP Reply middle frame
11:16:56.548: [[19a08e8f] 3C 1C 33 2D 31 32 00 54]  R: SNIP Reply middle frame
11:16:56.548: [[19a08e8f] 3C 1C 75 72 6E 6F 75 74]  R: SNIP Reply middle frame
11:16:56.549: [[19a08e8f] 3C 1C 20 6F 77 6E 65 72]  R: SNIP Reply middle frame
11:16:56.549: [[19a08e8f] 2C 1C 2E 20 54 57 52 00]  R: 02.01.57.00.04.8C - 02.01.12.FE.9D.6E Simple Node Ident Info with content '4,RR-CirKits, Inc.,Tower-LCC,rev-D,rev-C7e,2,ZionE turnouts 1st 24-03-12,Turnout owner. TWR,'
  Src: ZionE turnouts 1st 24-03-12

The 0x1C in the first byte of the first frame is a "1st Frame" indicator: The 0x1 in the high nibble is the "first frame" indicator and the 0x0C is the start of the destination node alias.

There where are a bunch with 0x3 in the high nibble. Those indicate middle.

Then the last frame has 0x2 in the high nibble, indicating end frame. JMRI puts the entire message together and displays it at that point.

[atanisoft]

Maybe I need to detect if I do not have all the info and have to then "refresh" the SNIP and PIP info from a far node.

I'd definitely add a timeout of say 30sec to receive the complete response for SNIP or PIP. In my code I default to 4sec for PIP and 2sec for SNIP.

I also have not seen partial SNIP/PIP/CDI/FDI responses from any nodes in my tools (sorry it's not public code).