Transform Packet Odd Behavior

[alexanderdsmith]

Hi there,

I'm using Slicer 4.8.1, and I am attempting to develop a Javascript Implementation of the IGTL packing algorithm for NodeJS. I have gotten to the point where Slicer is reading in my transform, name and all, with no warnings, but the transform received is empty. I believe I have correctly implemented the header with CRC and message correctly, but Slicer does not appear to be reading my message. I tried receiving a simple transform from Slicer, and it looks like the message I received does not follow the format I expected.

Here is an example transform message I am sending (no rotation, and +10mm in X, Y, and Z):
00015452414e53464f524d0000006530000000000000000000000000000000000000000000000000000000000000000000307842ab4c3f4df49b3f8000000000000000000000000000003f8000000000000000000000000000003f800000412000004120000041200000
106 bytes

And here is that exact same transform sent to Javascript from IGTLink in Slicer:
00015452414e53464f524d0000006530000000000000000000000000000000000000000000000000000000000000000000307842efbfbd4c3f4defbfbdefbfbd3fefbfbd00000000000000000000000000003fefbfbd00000000000000000000000000003fefbfbd0000412000004120000041200000
118 bytes

I noticed that in a few places in the received message from Slicer, a 0xefbfbd seemed to appear seemingly out of nowhere, either added in, or replacing 0x80, or 0x9b. My checksum was calculated using the CRC64-ECMA182 standard.

I'm a bit lost, and any help with this issue would be greatly appreciated.
Thank you!
-Alex

[alexanderdsmith]

Note: I've noticed that 0xefbfbd replaces the following bytes in the Transform header and message received from Slicer:

0xab, 0xf4, 0x9b, 0x80.

Everything else in my sent message is identical. I've attempted sending the exact same message that Slicer sends me back to Slicer, but the transform I receive is again just the identity.

[Sunderlandkyl]

4.8.1 is an old version, and does not use SlicerOpenIGTLink.

The SlicerOpenIGTLink extension is used in the latest stable and preview releases (4.10.1 and 4.11.0).
Can you try with a newer version?

[alexanderdsmith]

Hi,

Just tried with the newer version, and I am running into a similar problem.

Now packets I receive from Slicer are header v2 protocol (OpenIGTLink version 3.0?).

Am I still able to send data via the header v1 protocol in the new Slicer version? Or for that matter, is there a well defined example packet that exists that I can use to test my server and make sure the data is not corrupted between my server and Slicer?

Thanks for your response!

[alexanderdsmith]

Update: I've determined that my problem is with the CRC generation. My algorithm is working correctly, but I may be performing the CRC on the wrong component of the message. I have been under the impression that you're supposed to generate a CRC from the body component of the packet (in hex), and this appears to not be the way to do this. Any ideas?

[Sunderlandkyl]

The packet that you receive now from Slicer is a STATUS message.
The format of the header is here: https://github.com/openigtlink/OpenIGTLink/blob/master/Documents/Protocol/header.md

The type: "535441545553000000000000", resolves to = STATUS\0\0\0\0\0\0, so this is not the message you are looking for.

[adamrankin]

The type: "535441545553000000000000", resolves to = STATUS\0\0\0\0\0\0, so this is not the message you are looking for.

[alexanderdsmith]

Hmm.. I think that status message includes my data though - the 3f800000 corresponding to my 1s in the matrix were present... Still working on the CRC to see if I can get that resolved

Thanks!!