Improve correlation of readings
Right now, a MOOC object that gets a reading request (reading, read setting, basic status) doesn't know anything about the entire request of which it is a part. Is it the only device in the list? How can a MOOC object ensure the data it returns is correlated to data returned by other MOOC objects in the request? The philosophy has been reading all the devices takes such a short amount of time that it doesn't matter. This might be true in many cases. However, we know GPIB devices, for instance, can take many 15 Hz cycles before returning data. That would prevent the correlation with any other fast-responding devices in the request. In addition, if the requested data can't fit in a single reply, the acquisition will get spread across multiple requests.
This issue will be used to track discussion on how to improve correlated data in MOOC. Here are some ideas:
- The request structure, which is passed to every MOOC method, could have a field added to it holding an ID. The ID could uniquely identify a list of requests. It may also be useful to have to total number of devices participating in the list and the index in the list for the current request. These fields, along with the RETDAT_INIT method could let a MOOC object set-up acquisition and then recognize when other methods are called to service the same list.
- The Erlang front-ends don't pass the FTD to the drivers. Instead they pass an absolute timestamp. Drivers can keep a short history of collected data and the timestamp can be used to return the appropriate data. We could add a timestamp to the request structure to allow the method to return data obtained closer to the timestamp.
The MOOC methods should also be able to return a timestamp. Right now, the time when the method completes is used as the data's timestamp which could be many milliseconds off.
Targeted for MOOC v5.0 since this would probably be a disruptive API change.