What high-level problem are you trying to solve?
Get the real time on a device that has incorrect time/
Any ideas on how ODK could help you solve it?
Add a new widget for GPS based time. It might also want to capture the device time as well, so you have the diff.
Upload any helpful sketches, screenshots, and videos.
Android API: https://developer.android.com/reference/android/location/Location#getTime()
Related topic: Satellite time updater app for ODK - #2 by jwrozelle
I think my mini app should address this without too much fuss from odk's side. Can take a bit of time to connect to a satellite in some areas. For the slowness alone, I'm not totally sure it makes sense as a core ODK widget. Moreover, our use case was relatively niche - and I'm not sure it would be useful for a majority of folks.
Our use case for this was in very rural / remote Liberia where data collectors went for days outside of any cell coverage and devices would run out of battery (and be recharged by mini solar panels). The system time would be wrong, so we implemented this.
You can also implement time stamp triggered on that gps time. Then we'd get time stamps throughout the surveys for specific sections we wanted to time. For "true" time, we just calculated the difference between system time and that initial gps time stamp, then added that difference to each time stamp throughout the survey.
Can probably dog up some xlsx examples if helpful.
[Edit: forgive the typos in my posts - using a phone]
Thanks for adding that context, @jwrozelle. Your mini app is great, but my concern is that by the time data managers realize there is a problem, it'll be hard to coordinate with data collectors to download a new app and use it. It'd also be nice not to rely on you to keep it up to date with the various Play Store changes.
If we bake it into Collect, then a manager can add a "gps-datetime" question to the form after the fact and the data collectors would get those updates without having to do anything.
Totally makes sense! If it's something you all would be willing to dedicate time to, I'd certainly use the feature over my app. My current approach is a bit clunky.
Still a huge fan of ODK, and always appreciate the cool community here.
@yanokwa, also - Thanks for the note on Play Store changes! I just submitted updates for anyone who wishes to use it between now and a potential future native ODK widget.
Let me know if/when you build this, and I'll put an update on my app that says it's depreciated and direct users to the native ODK version.
Agree with @yanokwa - ODK Collect is useful for field-based work, and the capability to always have the correct time would be an extremely useful asset as part of the core package.
In what scenarios have you seen enumerators with incorrect time? Is it because they run out of battery and the batteries are reset? Is it because cell-towers are misconfigured?
We are experiencing this issue. We have Raspberry Pi computers that are used to collect data. However, the RPis do not have a clock battery. Our vendor attached an I2C clock, but the clock is only functional when the RPi is powered. So if the RPi is turned off for 2 weeks, the timestamps are also wrong by 2 weeks and need repair. The obvious solution is to attach a GPS I2C module but that requires a mass hardware revision.
And these RPi's are running ODK Collect? And do they have GPS now or are you saying that adding a GPS module would enable you to use this future ODK feature?
They're running a custom offshoot of ODK, but the core is essentially the same.
They do not have GPS. It is a future "want". But I think native timekeeping, the seed of this discussion, would be good as opposed to an extension.
I hope I am not late on this.
Issue: There was an experience on this when I was managing the use of ODK for some activities in a program some years back. The ODK form captured GPS points at the start and end of field data collection, but there was issue verifying the dates provided for reports and the day and time GPS coordinates were captured.
Solution: I added a function that automatically captures the timestamp of GPS data collected and it uses the true time from the GPS satellite signals, not the time set on the phone in case of phone settings error to ensure that the GPS data is accurate and reflects the actual time for data integrity. Below is the code in the XLS form used to automatically generate the timestamp backend when data collectors capture the GPS data -
type: calculate; name: GPS_timestamp; calculation: if(${GPS} = '', '', once(now())). The GPS is an existing data variable that the automated timestamp references.
Outcome: This helped to identify questionable records for further investigation when the date of the report entered is before the date of the automatically captured GPS-based time with the automatic timestamp generated (date reported for the field work cannot be before the actual day of field work indicated with the timestamp). It also helped to better analyze the duration of field work done and some other benefits when we needed more reliable date, time and location based analysis.
So, enabling the automatic time-stamp of the GPS data capture can be a potential solution to add support for GPS-based time or maybe something similar to explore.