I have encountered a very strange bug with FreeD data output. There seems to be some significant discrepancies between the data as it appears in the UI in TD and on the destination application when streaming. This also occurs when streaming from a FreeD Out CHOP to a FreeD In CHOP on localhost (see attached).
I think the problem here is the relatively low bit depth of the FreeD protocol and the values you are sending it are out of range.
The FreeD Out chop is showing the full 32 bit channel data that it is receiving from upstream, but most of the channels (tx, rx, focus, etc) are transmitted using only 24 bits so some of that data is getting lost.
For example:
tx, ty, tz are sent as a 24 bit signed integer scaled to 1/64000 of a meter. Which means it can go from -8,388,608/64000 → +8,388,608/64000 or -131.07 → +131.07
rx, ry, rz are also 24 bit signed integers but scaled to 1/32768 of a degree so that ranges from -256 → +256
focus and zoom are just left as 24 bit unsigned integers ranging from 0 to 16 milllion and the user value is a 16 bit integer ranging from 0 to 65k
Sorry this isn’t better explained in the docs. I’ll update the wiki to make it clearer. The node would probably benefit from a warning message when the data goes out of bounds as well.
This makes perfect sense, thanks for the detailed response. I was trying to send this data in centimeters- converted it to meters prior to FreeD transmission and all seems happy now. Thanks again.
In case this is useful to others facing these limits:
We made a workaround with a script CHOP that flips any rotation values that exceed +180 or go below -180, see attached.
td_freeDom.toe (6.7 KB)