search

usnistgov / mass

Microcalorimeter pulse-analysis software
MIT License
6 stars 0 forks source link

Better abstraction for sub-frame timing info: uncouple # of rows from subframe divisions #265

Closed joefowler closed 7 months ago

joefowler commented 7 months ago

Original report by Joseph Fowler (Bitbucket: joe_fowler, ).

The current version of MASS handles the sub-frame time resolution of external triggers by converting them to a row rate, and carefully considering each channel’s row offset. But that language makes no sense for µMUX systems. Only TDM systems have a row offset anyway.

The problem is that HEATES is subdividing the frame time (16.384 µs for them) into 64 divisions for the external trigger timing, but it reports that the “number of rows” is 115, because that’s how many resonators were found. These two numbers are allowed to vary separately, but MASS is treating them as if they were linked, and equal!

@{557058:1d7cdc44-ad41-4fa3-b6d4-08c21e9216af} identified the problems with this, and he made a work-around, but we should solve the problem, rather than working around it. (Thanks, Tadashi!)

Plan:

  1. Use the concept of sub-frame. Quantities that need to be tracked on times faster than a frame may be tracked at the sub-frame rate, which is the frame rate times the sub-frame divisions.

  2. Define a quantity SubframeDivisions within a MASS TESGroup (and inherit it within each single-channel MicrocalDataSet).

    1. This quantity will strictly equal the number of rows for TDM systems.
    2. For µMUX systems, it defaults to 1, but its actual value is given in the text header of the *_external_trigger.bin file, if one is found. Expect 64 for HEATES.

  3. Rename all quantities named something about “row-time” to be “subframe”-related, and also change any corresponding methods or properties. Have them rely on the SubframeDivisions rather than the number of rows.

‌

joefowler commented 7 months ago

Original comment by Joseph Fowler (Bitbucket: joe_fowler, ).

Complete change to "subframe" terminology

Fixes #265. Will break user code, but so be it. (Should require only simple renamings.)