Get Date/Time Delta Time Calculation

[vweb]

Hello,

For a rough check, I decided to try checking the RTC drift of an android device by using ADB and comparing it to the Get Date/Time In Seconds function. I first use the Get Date/Time in Seconds to set the android device's clock with the understanding that there will be a small delta between the read and the setting. I then read the devices time/date, compare with the output of Get Date/Time and calculate the difference.

I know I could just do everything manually but I'm controlling a temp chamber and logging the data. Plus, what's the fun in that? 🙂

So the part that's driving me crazy. I'm having an issue where the camera time comes back pretty consistently in line with the delay I put in the while loop but the Get Date/Time in Seconds output comes back ~100ms different every time. I'm seeing this if the while loop delay is 10 seconds or 1 minute. Does anyone know what could be causing this behavior and maybe suggest a way to overcome it? I'm at a loss. I attached an image of the block diagram and the output of the date query from the device and the calculated delta t. I'm using LV 2018

[aputman · Accepted solution]

It's hard to tell since you didn't attach the code. Your format code has an extra colon before the decimal seconds.  That value is always .004 in your data sample and I doubt very seriously that is correct.  It would typically be %S.%3u so that your milliseconds are 39.004 rather than 39:004.  Maybe this is somehow screwing with the conversion to DBL.

Besides that, why do you need to get a timestamp for the system time, convert it to a string of a specific format, and then convert it right back to a timestamp?  Rube Goldberg. 

[vweb]

Hello! The Unix epoch time is different than the labview epoch time so I just formatted to get a human readable time stamp and calculate the difference.

That '.004' is definitely suspicious. I will try digging a bit on the device side.

[JÞB]

I'm missing something.   My Android syncs to GPS time of day, local.  The  RTC drift is corrected.

[GerdW]

Hi aputman,

It would typically be %S.%3u so that your milliseconds are 39.004 rather than 39:004.

In LabVIEW it would by typically "%S%3u" - no point in between. That point seems to be part of the %u format code (unfortunately)!

[vweb]

Jeff - we're trying to see how bad the drift may be if the device isn't connected to GPS, wifi, and LTE.

aputman, on the DUT side, I ended up using '%3N' instead of '%3u" and now the ms values are changing. Thank you!

GerdW and aputman, I see what you're talking about with the miliseconds thing. Thank you for pointing that out! I will try to format it the conventional way