Feature #19839

Improve correlation of readings

Added by Richard Neswold almost 3 years ago. Updated over 2 years ago.

MOOC Framework
Target version:
Start date:
Due date:
% Done:


Estimated time:


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.


#1 Updated by Richard Neswold almost 3 years ago

The trigger library merges equivalent events to monitor. Maybe the handle returned by the trigger library can be some of the information used by objects across different requests to correlate their data?

#2 Updated by Richard Neswold almost 3 years ago

  • Description updated (diff)

Expand upon the idea of new fields in the request structure.

#3 Updated by Richard Neswold over 2 years ago

  • Category set to MOOC Framework
  • Target version deleted (MOOC v5.0)

Removing target version since this requires a lot more thought and discussion before implementing it.

Also available in: Atom PDF