Timestamp Error on MMR

gjin

We've been using MetaMotion R and logging sensor fused acceleration data to flash, and transferring to iOS devices using our own app. The sensor is using latest firmware 1.44 and HW version is 0.3.

We noticed suddenly jumping in one timestamp, going from normal timing of 8.x seconds, jumping to 6152 second, then back to 8.x seconds. (See screen shots below).

This occurred twice in about an hour period when we were collecting multiple 30 seconds data sets. The sensor cached was flushed, disconnected and reconnected to iOS app in between each data set,

Example 1: 7.540 sec -> 6151.55 sec -> 7.559

Example 2: 8.29 sec -> 6152.306 sec -> 8.31 sec

Please advice. Thank you.

Laura

Seems like whatever tool you are using to read the data is not reading it correctly. This happens in excel all the time because it attempts to read a Number as a String or Date instead.

Try opening the same file using a different viewer like VIM or NOTEPAD. You will see there isn't an issue at all.

gjin

Hi Laura,

This is not an editor issue.

Below is the actual epoch times received from the sensor.

Jumped from 1550050851.54 to 1550056995.549 then back down to 1550050851.559

Thanks

Laura

I can't reproduce on my side as I am not getting this error with timestamps and no one has filed a similar error.

Can you re-install the app, try with other devices and get back to us.

Worst case, just fix the timestamps by hand.

Eric

• What version of the iOS SDK are you using now?
• Did you see the same issue when using other versions?
• Does the same timestamp issue occur if you use the MetaBase app?

gjin

We are using v3.1.9 of iOS SDK.

We've been using 8 different MMRs the last few months without this issues.

Issue did not reproduce in MetaBase app. That is not surprising since within that one hour period we had about 45 normal samples, and 2 error samples.

Yes, we will do more stress testing on that specific MMR and other MMRs to see if it happens again.

gjin

@Eric, @Laura

My team did more digging into the pervious results.

• In addition to the 2 incident reported above, the same sensor produced 6 additional incidents in Feb, 2019. We have 8 total.

• A different MMR had 3 incidents out of 404 samples taken over three days in Nov 2018

All 11 incidents showed single timestamp jumping into 6100 range.

gjin

@Eric, @Laura

We found a third MMR with timestamp error. There were 5 incidents out 279 samples taken between Oct 29 - 30, 2018.

We also found more incidents, 10 out of 1002 samples taken during that period by the second MMR reported yesterday.

All incidents shoes single timestamp jumping to 6100x seconds range.

All samples were logged sensor fused acceleration and MF data. We log about 30 seconds worth of data, download to iOS, clear sensor cache, and repeat. This usually goes for 2-4 hours continuously.

Eric

Can you post a minimal function that creates this issue?

Laura

@gjin,
Please send reproducible steps, we still aren't seeing this error and no reports from other users either.

gjin

@Laura @Eric

We are logging sensor fused Acceleration and MF data simultaneously, then download from log to iOS. We just read the timestamp that's in the log, and have no code relating to timestamps.

Each sample is about 30 seconds in duration.

Getting a sanitized code/function to share will take some time. Would you guys be able to run stress testing with logging of sensor fused accel + mf using your test rigs, and see if that combo triggers the issue?

Thanks

Eric

Code describes what you are doing much better than words. Furthermore, there is no point in us recreating your code.

gjin

@Eric

Here is snippet of what we do to start and stop logging

   func start() {
        // Configure MetaWear
        mbl_mw_settings_set_connection_parameters(device.board, 7.5, 7.5, 0, 6000)
        mbl_mw_metawearboard_set_time_for_response(device.board, 1000)
        mbl_mw_sensor_fusion_set_mode(device.board, MBL_MW_SENSOR_FUSION_MODE_NDOF)
        mbl_mw_sensor_fusion_set_acc_range(device.board, MBL_MW_SENSOR_FUSION_ACC_RANGE_4G)
        mbl_mw_sensor_fusion_set_gyro_range(device.board, MBL_MW_SENSOR_FUSION_GYRO_RANGE_2000DPS)
        mbl_mw_sensor_fusion_write_config(device.board)

        // Get Fusion Accelerometer and Magnetometer Signals
        guard let accSignal = mbl_mw_sensor_fusion_get_data_signal(device.board, MBL_MW_SENSOR_FUSION_DATA_CORRECTED_ACC), let magSignal = mbl_mw_sensor_fusion_get_data_signal(device.board, MBL_MW_SENSOR_FUSION_DATA_CORRECTED_MAG) else
        {
            return
        }
        let source = TaskCompletionSource<[OpaquePointer]>()
        accSignal.datasignalLog().continueWithTask(continuation: { t -> Task<[OpaquePointer]> in
            return Task.whenAllResult([t, magSignal.datasignalLog()])
        }).continueWith(continuation: { t in
            if let error = t.error {
                source.trySet(error: error)
            } else if let result = t.result {
                source.trySet(result: result)
            }
        })
        source.task.continueOnSuccessWith(continuation: { loggers in
            // Start Logging
            mbl_mw_sensor_fusion_enable_data(device.board, MBL_MW_SENSOR_FUSION_DATA_CORRECTED_ACC)
            mbl_mw_sensor_fusion_enable_data(device.board, MBL_MW_SENSOR_FUSION_DATA_CORRECTED_MAG)
            mbl_mw_sensor_fusion_start(device.board)
            mbl_mw_logging_start(device.board, 1)
            state = device.serialize()
        })
    }

    func stop() {
        // Restore MetaWear State
        device.deserialize(state)

        // Subscribe & Download Logger Data
        mbl_mw_logger_subscribe(loggers[0], bridge(obj: context), { (object, data) in
            guard let object = object, let data = data else {
                return
            }
            let context: LoggerContext = bridge(ptr: object)
            let sample: MblMwCorrectedCartesianFloat = data.pointee.valueAs()
            context.acc.append((CoordinateData(x: Double(sample.x), y: Double(sample.y), z: Double(sample.z)), data.pointee.timestamp.timeIntervalSince1970))
        })
        mbl_mw_logger_subscribe(loggers[1], bridge(obj: context), { (object, data) in
            guard let object = object, let data = data else {
                return
            }
            let context: LoggerContext = bridge(ptr: object)
            let sample: MblMwCorrectedCartesianFloat = data.pointee.valueAs()
            context.mags.append((CoordinateData(x: Double(sample.x), y: Double(sample.y), z: Double(sample.z)), data.pointee.timestamp.timeIntervalSince1970))
        })
        mbl_mw_logging_stop(device.board)
        mbl_mw_logging_download(device.board, 100, &handler)

        // After MblMwLogDownloadHandler remains == 0
        // Clear MetaWear States
        for logger in loggers {
            mbl_mw_logger_remove(logger)
        }
        mbl_mw_sensor_fusion_stop(device.board)
        mbl_mw_sensor_fusion_clear_enabled_mask(device.board)
        mbl_mw_debug_disconnect(device.board)
    }

Eric

Thanks, we'll give it a try.

gjin

@Eric

We had a fourth sensor showing the timestamp jump issue.

We also noticed that with all 14 incidents across 4 sensors, the amount of seconds changed is the same: 6144 seconds.

In my two examples above:

6151.55-7.540999989  = 6,144.009000011
6152.306-8.29699993  = 6,144.00900007

Hopefully this clue helps with identifying the culprit.

Laura

@gjin,

Do you ever get this timestamp issue when you use our MetaBase App instead of the APIs?

gjin

@Laura

We are trying to repro the problem with MetaBase App, but found this problem with the app.