NAT_REQUEST_FRAMEOFDATA results in unrecognised request 100

[Marek]

I am using Motive 1.10.1 on a windows box and NatNetSDK 2.10 on a linux box
with the PythonSample

Whenever I send command NAT_REQUEST_FRAMEOFDATA I get the response NAT_UNRECOGNIZED_REQUEST from the server,

The connection works fine as I get the model information when I send NAT_REQUEST_MODELDEF

Has the motive streaming interface changed?

[ryanhaun]

Hi Marek,

The interface has not changed since the release of the python sample.

Can you try running the python client on Windows to see if it works there?

Ryan Haun
OptiTrack Support

[Marek]

Hi Ryan,

It is the same on Windows

i get NAT_UNRECOGNIZED_REQUEST after sending NAT_REQUEST_FRAMEOFDATA

yet the NAT_REQUEST_MODELDEF returns the packet with the info

It occurs on both local loopback and over the network

Just in case my python version (for windows) is 3.5.2.3 and motive 1.10.1.3

Cheers,
Marek

[Marek]

After some more testing it seems that the frame_data request is not working with the C library

Looking directly at the packets I see that the correct value is sent:

----------------------------- REQUEST MODEL DEF ---------------------
12840 228.112215 192.168.255.3 192.168.255.101 UDP 60 60327→1510 Len=4
----------------------------------data-----------------------------------------
Frame 12840: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0
Ethernet II, Src: SamsungE_27:ff:1c (18:67:b0:27:ff:1c), Dst: EdimaxTe_a3:43:9e (00:50:fc:a3:43:9e)
Destination: EdimaxTe_a3:43:9e (00:50:fc:a3:43:9e)
Address: EdimaxTe_a3:43:9e (00:50:fc:a3:43:9e)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Source: SamsungE_27:ff:1c (18:67:b0:27:ff:1c)
Address: SamsungE_27:ff:1c (18:67:b0:27:ff:1c)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IPv4 (0x0800)
Padding: 0000000000000000000000000000
Internet Protocol Version 4, Src: 192.168.255.3, Dst: 192.168.255.101
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
Total Length: 32
Identification: 0xf7a2 (63394)
Flags: 0x02 (Don't Fragment)
Fragment offset: 0
Time to live: 64
Protocol: UDP (17)
Header checksum: 0xc36f [validation disabled]
[Header checksum status: Unverified]
Source: 192.168.255.3
Destination: 192.168.255.101
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 60327, Dst Port: 1510
Source Port: 60327
Destination Port: 1510
Length: 12
Checksum: 0x8a8d [unverified]
[Checksum Status: Unverified]
[Stream index: 4]
Data (4 bytes)
Data: 04000000
[Length: 4]
-----------------------------end----------------------------------

which results in a packet with mode 5 - MODEL DEF data
whereas the NAT_REQUEST_FRAMEOFDATA packet sending correct value '6' (according to the NatNet SDK)

----------------------------- NAT_REQUEST_FRAMEOFDATA ------------
13670 242.312053 192.168.255.3 192.168.255.101 UDP 60 60327→1510 Len=4
------------------------------------- data --------------------------------------------
Frame 13670: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0
Ethernet II, Src: SamsungE_27:ff:1c (18:67:b0:27:ff:1c), Dst: EdimaxTe_a3:43:9e (00:50:fc:a3:43:9e)
Destination: EdimaxTe_a3:43:9e (00:50:fc:a3:43:9e)
Address: EdimaxTe_a3:43:9e (00:50:fc:a3:43:9e)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Source: SamsungE_27:ff:1c (18:67:b0:27:ff:1c)
Address: SamsungE_27:ff:1c (18:67:b0:27:ff:1c)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IPv4 (0x0800)
Padding: 0000000000000000000000000000
Internet Protocol Version 4, Src: 192.168.255.3, Dst: 192.168.255.101
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
Total Length: 32
Identification: 0xfed4 (65236)
Flags: 0x02 (Don't Fragment)
Fragment offset: 0
Time to live: 64
Protocol: UDP (17)
Header checksum: 0xbc3d [validation disabled]
[Header checksum status: Unverified]
Source: 192.168.255.3
Destination: 192.168.255.101
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 60327, Dst Port: 1510
Source Port: 60327
Destination Port: 1510
Length: 12
Checksum: 0x888d [unverified]
[Checksum Status: Unverified]
[Stream index: 4]
Data (4 bytes)
Data: 06000000
[Length: 4]
------------------------------------- end -----------------------------------------

Note that the data sent is '06' which is the frame data request on port 1510 same as the model def request (value 04). This command results in unrecognised request (value 100).

same unrecognised request (100) returned on test request from c code

Also the in Motive log contains the 'model def request' command, but does not show anything when it returns unrecognised request.

Is there a more detailed log?

Cheers,
Marek

[JackYang]

I want to echo Marek's issue on NAT_REQUEST_FRAMEOFDATA. I encountered the same issue when using motive and running the python client on another computer.

It would be great if there can be a solution to this issue. Thank you.