Huge inconsistency in Timestamp while Accelerometer Streaming
Mbeint Device : Metamotion C
Relevant Code Used :
...
accelerometer.acceleration().addRouteAsync(new RouteBuilder() {
@Override
public void configure(RouteComponent source) {
source.account().stream(new Subscriber() {
@Override
public void apply(Data data, Object... env) {
Acceleration d = data.value(Acceleration.class);
Log.v("Time", data.timestamp().getTimeInMillis()));
}
});
}
})
...
In one session gave me an erratic timestamp jump
... 1583342413134, 1583342413214, 1583342413294, 1589633869214, 1589633869454, 1589633869533, 1589633869613 ...
As you see, the timestamp jumped from 1583.. to 1589.. which is a future timestamp.
I recognised this after completing the streaming session.
I started another session and saw that the timestamp was still in the range of 1589.. range
The timestamp changed back to 1583.. range after a session that I started after restarting my app.
Any idea as to why this could have happened? I have never encountered this problem before.
Comments
Can you send us the device diagnostic, Device information (MMC, which firmware, which version?), and the full code to replicate. We want to look into this asap.
Also, if you fully reset your board (use the reset from our tutorial -> https://mbientlab.com/tutorials/CPPDevelopment.html#reset), does it still happen?
We think this happens then the device log hasn't been fully cleared after a download.
Please experiment and let me know.
Device Information:-
Model : MetaMotion C
Model Number : 6
Firmware : 1.5.0
Hardware : 0.1
Battery 100%
I have not been able to replicate the error myself after that instance. Process I am using in the code:-
For each session of 2 minutes,
1. Board connect
2. Configure Accelerometer to 12.5 Hz and 2G
3. Add Route Async to Accelerometer with configure as source.account().stream(new Subscriber) and store the result in an arraylist
4. Start Accelerometer
5. Wait for 20 seconds
6. Stop Accelerometer
7. Copy the values to another arraylist for later use
8. Repeat from Step 4 till the end of 2 minutes
9. Board teardown
10. Board disconnect
The error occurred in steps 4-6 where the only thing the code is doing is what I mentioned in the post. I believe it is only the timestamps that are messed up. I havent gotten to analyse the x, y and z axis yet. I will update you on that.
We are going to be running a few more data capture sessions today.
@Vinay,
Any news on this? We would like to be able to replicate it but we are not able to do so.
We ran into the problem again twice.
We currently have 3 Metamotion C devices that are being used by different people in our organisation.
Until now, we have been testing out our system on our Development phone which has been a Oneplus and a Metamotion C designated for development. We had been using a Samsung phone for testing purposes along with a Metamotion C designated for testing, which has proven to be working fine. We decided to get a new phone for parallel testing purposes and decided to go ahead with a Redmi and paired our spare Metamotion C device with it.
We had been collecting data from two Metamotion Cs paired with the Redmi and the Samsung. The Samsung has been working alright without any issues. We developed the fault of jumping timestamps on the Redmi phone.
We initially thought it was a problem with the new phone. Hence, decided to revert back to the Oneplus for testing purposes and paired it with the spare device that was causing the problems. But we ran into the error again. It is really unclear what is causing the error.
We haven't had the time to zero in on what is causing the issue. However, one of the things that was clear with switching phones is that the problem is not with the new phone. At this point, the only thing that makes sense is that the spare Metamotion C we had has developed some problem and is causing a problem.
Do you think there is any other possibility? We considered the device log not being cleared. But I dont think that would be a problem. 1. Because we are not using logging but are streaming data. 2. Because we are disconnecting from the device completely after a 2 minute period where the board handles the clearing if I am not wrong.
We have been switching around phone and biosensor pairs a lot to confirm that the problem is being caused by the biosensor. One last test that will confirm the same is if the spare biosensor causes a problem after being paired with the Samsung phone. We have scheduled a complete test in the coming week. Would you want more device information if we are to run into the error again?
Can you send us steps to replicate? Again, if we can't replicate we can't do anything on our side.
I wish I could replicate it myself. However, it seems to be occuring randomly.
I still think it's a reset problem. If you ensure that you reset your sensor with these steps: https://mbientlab.com/tutorials/CPPDevelopment.html#reset
I bet it won't happen anymore.
Can you confirm? At least this would prove the log/reset issue theory.
We are currently switched focus over from Android to something else. Will get back if I am able to replicate the issue when we switch our focus back.