Create Timeseries Objekt in MATLAB with the property "StoredUnits"

I have various measured values in MATLAB and would like to convert them into a ‘timeseries’ object so that I can analyze them in SDI. To do this, however, the “StoredUnits” property of the ‘timeseries’ object must also be set so that the scaling for the data cursor can then be changed in SDI from, for example, “m/s” to “km/h.”

But “StoredUnits” is not offered in the properties of the ‘timeseries’ object.

% create timeseries-Objekt (example)
 temp = timeseries(data, time, "Name", "test", "StoredUnits", "m/s")
 

Error:

Error using timeseries/init (line 153)

Invalid property name

The alternative method of loading the corresponding signal from the SDI into MATLAB and then setting the property results in the following message::

% get current run from SDI
countRun = Simulink.sdi.Run.getLatest;

% load respective signal
inSigID = getSignalByIndex(countRun, 1);

% set property
inSigID.StoredUnits = "m/s";

Error:

Unable to set the 'StoredUnits' property of class 'Signal' because it is read-only.

This raises the question: how can a ‘timeseries’ object with the “StoredUnits” property be created in MATLAB?

Answer 1

[dpb]

The timeseries class stores the units in the metadata sub-class.

ts=timeseries(randn(10,1));
ts.DataInfo.Units='m/s';
display(ts.DataInfo)

  tsdata.datametadata
  Namespace: tsdata

  Common Properties:
               Units: 'm/s'
       Interpolation: linear (tsdata.interpolation)

It is read/write, but as noted, there is no property such as 'StoredUnits' available. The units are just metadata associated with the object, however, they have no bearing on actual values -- changing the units value doesn't get reflected in changing the values of the timeseries data itself to reflect that. Also, while one can create a timeseries with more than one column of data, the units metadata is global, not by column. A timetable behaves somewhat similarly although the Units property is by column.

I don't know anything about SDI and how to fix up units there, sorry.

[Paul]

Setting the Units in the DataInfo of the timeseries object does exactly what @Daniel needs. Nice.

[dpb]

@Paul - are you saying that SDI will read the timeseries metadata units and convert? Or just label with the found units string, maybe?

[Paul]

The SDI will use the timeseries.DataInfo.Units as the "Stored Units" in the SDI. I assume that the Datainfo.Units has to be recognizable by the SDI.

I also assume that it also goes the other way, i.e., a signal in the SDI that originated from Simulink can be exported to the base workspace as a timeseries and the Stored Units in the SDI will show up in the DataInfo.Unis in the exported timeseries in the base workspace, but I didn't try that.

[dpb]

Well, that is kewl, indeed...I don't have anything except MATLAB, never seen a Simulink install so that part is all totally foreign...I just knew how the timeseries and timetable handle the units metadata.

It would be a neat trick to be able to have automagic conversion from one to another, but there would have to be the static "who's the reference" units to have the starting point.

[Paul]

"Automagic conversion from one to another of what?"

Units... m/s --> mph, etc., ...

[Paul]

There's no point in the import process for a conversion; the conversion is done afterwards.

The timeseries from the base workspace is imported into the SDI. In that import process the timeseries object is converted, or used to create, the data object in the SDI (which is not a timeseries). That data object in the SDI has a StoredUnits field that is read-only and will be the same as the Units of the imported timeseries object. The SDI object has another field called DisplayUnits. On import, the DisplayUnits are the same as the StoredUnits. The user can subsequently set a different DisplayUnits on the SDI data object through the SDI GUI or programatically. For plotting in the SDI scope, the data in the SDI object is scaled by the conversion from StoredUnits to DisplayUnits. As I understand, that conversion is just for display. The underlying data in the SDI data object doesn't change.

[Daniel]

Hi dpb,

perfect, that's exactly what I'm looking for and it works.

Important to know, that the unit must be given as char-array (e.g. 'm/s') and not as string (e.g. "m/s"). When the unit is given as a string, it's actually not working in the SDI (although the property is set in both cases), but I don't knwo why :-). But would be interessting to know if anybody has an idea...

Working version

% Clear workspace
clear

% Clear any data in the SDI
Simulink.sdi.clear;

% Create timeseries-object
ts=timeseries(randn(10,1));

% Set porperty "Stored Unit" as char-array
ts.DataInfo.Units='m/s';

tsdata.datametadata

Namespace: tsdata

Common Properties:

Units: 'm/s'

Interpolation: linear (tsdata.interpolation

More properties, Methods

% Plot signal information
display(ts.DataInfo);

% Open SDI
Simulink.sdi.view;

Not working version:

% Clear workspace
clear

% Clear any data in the SDI
Simulink.sdi.clear;

% Create timeseries-object
ts=timeseries(randn(10,1));

% Set porperty "Stored Unit" as string
ts.DataInfo.Units="m/s";

tsdata.datametadata

Namespace: tsdata

Common Properties:

Units: 'm/s'

Interpolation: linear (tsdata.interpolation)

More properties, Methods

% Plot signal information
display(ts.DataInfo);

% Open SDI
Simulink.sdi.view;

[dpb]

@Paul, I was just talking of the behavior of the timeseries object itself in whether it could change the Data to match a change in the Units metadata; as noted, I know nuthink! (credits to Sgt Schultz) about Simulink/SDI.

[dpb]

"Important to know, that the unit must be given as char-array (e.g. 'm/s') and not as string (e.g. "m/s"). When the unit is given as a string, it's actually not working in the SDI (although the property is set in both cases)"

Probably because the doc for the timeseries class metadata specifically states that

Units — Character vector specifying data units.

and owing to that the SDI code wasn't prepared with the expectation of having the string although I tested locally that gong back at least as far as R2017b the string was accepted with no warning nor internal conversion to the char string. I think that could be the basis for a quality of implementation support request. I would presume that the internal Mathworks intent would be to eventually expand all to explicitly support the (relatively) new(ish) string as well but just hasn't risen to the top of the pile yet.

[Daniel]

ok, sounds reasonable. But I think as well when the argument given as a string is accepted by the function, then it should work. Otherwise it should have raised an warning.

[dpb]

You want to submit to Mathworks as an official fault/bug at <Product Support Page>? At least suggest the documentation bear the note that the SDI function doesn't recognize the string form wouldn't require any code updates until was fixed in one manner or another.