04-04-2019 04:45 PM
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
Solved! Go to Solution.
04-04-2019 05:05 PM
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.
04-04-2019 05:17 PM - edited 04-04-2019 05:32 PM
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.
04-04-2019 08:24 PM
I'm missing something. My Android syncs to GPS time of day, local. The RTC drift is corrected.
04-05-2019 01:15 AM
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)!
04-05-2019 11:15 AM - edited 04-05-2019 11:25 AM
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