Error 'Sample points must be unique'

[Milou-N]

Hi,

In my most recent batch analysis using ActiPASS version 2025.04.1, there is one Axivity file that gives the following error during analysis: 'Sample points must be unique'. Re-running only this file has yielded the same result. I have pasted the CrashLog below. The raw data looks normal, so we can't quite figure out where this error comes from.

Any ideas how we can still analyse this file?

Thanks,

Milou

_CrashLog:
"Batch: 2025-11-12 11.36.48
Error using matlab.internal.math.interp1
Sample points must be unique.

Error in interp1 (line 188)

Error in actiPass_UI_Process (line 654)

Error in ActiPASS_GUI/ProcessStartButtonPushed (line 770)

Error in appdesigner.internal.service.AppManagementService/executeCallback (line 165)

Error in matlab.apps.AppBase>@(source,event)executeCallback(ams,app,callback,requiresEventData,event) (line 60)"_

[pasan-h]

If you think the Axivity file is not corrupted (use OmGui first and double check), then convert it to "WAV" format using OMGui and try to process it. Axivity MATLAB file parser can read some CWA file incorrectly in rare situations. ActiPASS cannot do much if that is the case other than above workaround (converting to WAV files).

[Milou-N]

Thanks for the swift reply! The file looks fine in OmGUI. I've tried converting to WAV, but now I get another error:
"Batch: 2025-11-12 16.49.53
Unrecognized field name ""AXES"".

Error in actiPass_UI_Process (line 699)

Error in ActiPASS_GUI/ProcessStartButtonPushed (line 770)

Error in appdesigner.internal.service.AppManagementService/executeCallback (line 165)

Error in matlab.apps.AppBase>@(source,event)executeCallback(ams,app,callback,requiresEventData,event) (line 60)"

[pasan-h]

Hi Milou,
OK, you found a bug 😀. ActiPASS at some point in the past switched to the latest Axivity parser (linked above), but reading WAV files are in accordance with the old parser it seems. I am planning to release a version of ActiPASS very soon with inclusion of feature #125. I will also fix this bug in that version.
Meanwhile, you can also check the battery status of the device during the measurement. In OmGui turn off all axes and temperature but keep the battery-axis visible. If you see at the end of measurement the battery voltage drops fast, then data can get corrupted. OMGui (which has much better C# Axivity file parser) handles this situation better than the Matlab based Axivity file parser. Anyway in rare occasions we have observed data corruption can occur even when battery is still full. Such situations can be fixed by processing those files separately as WAV files (after I fix the bug you found).

[pasan-h]

See my email with a link to download a new version with the bugfix for WAV file parser. See the commit 6e464dd for details.
BR
Pasan