You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This request is related with issue PlusToolkit/PlusLib#1198. Sorry for the delay as I was waiting for the response from NDI for having a correct understanding of the problem.
When loading markers of both passive and wireless active type, the transformations reported by PlusServer are incorrect, thus seeing transforms related to not visible markers as visible and reporting incorrect transforms for visible ones.
The NDI Polaris Vega uses one frame for each different type of marker used, thus dividing the effective tracking frecuency by the number of marker types. The NDI API documentation says that each BX2 response can contain one or more frames of data, being that each frame can be of a different type of marker:
Thus we though that shouldn't be any problem on mixing markers of different types as it would report them together. But we noticed that when responding to the BX2 command sent by the NDICAPI, the tracker is alternatively reporting markers of only 1 of the types at a time with each command sent, matching with each of the different type of marker frames. We've also noticed this using other connection methods that used STREAM mode of the BX2 command. This seems to be the cause for the behavior of the PlusServer incorrect output, since, as far as I could find out in the code, some kind of averaging with consecutive frames is done with the received tracking data.
This was kinda confusing for us, so we decided to contact NDI for clarification on how the API works in this case, and the first NDI response was that the BX2 response should report all the markers with the format noted up here, but after some discussion they reported:
BX2 will report the most recent unreported transformation data. This means that the content of a BX2 reply depends on the frequency of the BX2 request relative to the frame rate. If BX2 is requested at frame rate (or if streaming is used), each BX2 reply will only contain the transformation data of one tool type since everything else has been reported previously (this behavior is different from BX). If BX2 is requested at lower frame rates, then the reply will contain transformations of frames that have not been previously reported.
Thus the BX2 response will only report all markers if requested slower than the actual framerate. They mentioned that in a demo they did, that included both active wireless and passive markers, they wait until both types markers are received after "completing" a tracking frame and reporting the transformations, but this would imply that the types of markers loaded are known. Anyways, some kind of extra processing of the responses is needed for the command to work if more than 1 type of marker is loaded at a time.
I include a document with some packets caught with Wireshark of the responses we get with both types of markers loaded into the tracker, just in case it could help understand the issue.
Good morning,
This request is related with issue PlusToolkit/PlusLib#1198. Sorry for the delay as I was waiting for the response from NDI for having a correct understanding of the problem.
When loading markers of both passive and wireless active type, the transformations reported by PlusServer are incorrect, thus seeing transforms related to not visible markers as visible and reporting incorrect transforms for visible ones.
The NDI Polaris Vega uses one frame for each different type of marker used, thus dividing the effective tracking frecuency by the number of marker types. The NDI API documentation says that each BX2 response can contain one or more frames of data, being that each frame can be of a different type of marker:
Thus we though that shouldn't be any problem on mixing markers of different types as it would report them together. But we noticed that when responding to the BX2 command sent by the NDICAPI, the tracker is alternatively reporting markers of only 1 of the types at a time with each command sent, matching with each of the different type of marker frames. We've also noticed this using other connection methods that used STREAM mode of the BX2 command. This seems to be the cause for the behavior of the PlusServer incorrect output, since, as far as I could find out in the code, some kind of averaging with consecutive frames is done with the received tracking data.
This was kinda confusing for us, so we decided to contact NDI for clarification on how the API works in this case, and the first NDI response was that the BX2 response should report all the markers with the format noted up here, but after some discussion they reported:
Thus the BX2 response will only report all markers if requested slower than the actual framerate. They mentioned that in a demo they did, that included both active wireless and passive markers, they wait until both types markers are received after "completing" a tracking frame and reporting the transformations, but this would imply that the types of markers loaded are known. Anyways, some kind of extra processing of the responses is needed for the command to work if more than 1 type of marker is loaded at a time.
I include a document with some packets caught with Wireshark of the responses we get with both types of markers loaded into the tracker, just in case it could help understand the issue.
Passive active marker BX2 frames.pdf
Thanks a lot and kind regards
The text was updated successfully, but these errors were encountered: