Closed jonnew closed 2 months ago
@jonnew actually the link controller is hidden only from the exposed properties. Otherwise it is registered in the device manager as a normal device and therefore could be accessed by a data node like other streams.
If you have a proposal for what a useful data stream might look like, we can draft it here and look towards implementing it in a future release.
Aside from controlling port voltages, setting passthough vs normal mode, etc the FMC Link Controller exposes a data stream that is useful for monitoring port state.
https://open-ephys.github.io/onix-docs/Hardware%20Guide/Datasheets/fmc-link-control.html#device-to-host-data-frames
This provides information on e.g. the loss of lock or deserialization parity check failures. AFIAK, this stream is not currently used in the library. It would be a very nice thing to have access to in terms of a savable data stream that can be used both for diagnoistic reasons and for potentially taking action within the library to e.g. automatically attempt to re-establish lock.
Im not sure where such a device really belongs -- currently the register access portion of the device is used but hidden inside headstage aggregates. I really like this and want to preserve that. But it kinda conflicts with then creating a Data node that is linked to --- what?