Open samuelpowell opened 7 months ago
Thanks for opening this @samuelpowell .
I was thinking that it was appropriate to put this information in the probe
object, perhaps creating probe.multiplexing
.
But from there, I am not sure how to describe it.
For temporal multiplexing, we need to indicate which sources and wavelengths are on for any given state. This could be described in a 2D array. But then we also need to describe what is conveyed in each column (say which source and which wavelength) and what is conveyed in each row (perhaps the timing of the state). I think that would capture what I have in my experience for temporal multiplexing.
For frequency multiplexing, do we need to convey the encoding frequency? It seems that we could probably just capture this in the temporal multiplexing scheme above, perhaps with the addition of perhaps a parallel 2D array that indicates the encoding frequency for the given source/wavelength and state.
This needs further discussion.
One representation would be that each channel (measurementList entry) has optional fields for a temporal multiplex index, and frequency multiplex index.
Without any further information, one would be able to determine the potential for excess shot-noise by checking to see if two channels share the same temporal multiplex index. If the frequeny multiplex index were also the same (or not present) then that would indicate that cross-talk was possible.
I don't think it's essential, but if present these indices could optionally index into an array which gives the temporal offset (from start of frame) or the modulation frequency.
Further to #112 it may be desirable to add information to the probe description which allows one to understand the multiplexing scheme used to acquire the data, where this may be informative in terms of signal to noise, and so on.
Note that the intention is not to provide information that is strictly neccesary to interpret the data (this process should happen in the vendor's acquisiton software).