Add manual and automatic NTP time sync options in Clock menu

[mauriciobridge]

This update adds new options in the Clock menu to set the time from the Internet using NTP servers.

✅ New features:
Sync from Internet: A new button in the Clock menu that lets you update the date and time using an NTP server.

Time Zone: You can now choose your UTC offset (from UTC−12:00 to UTC+14:00).

Auto Sync: If enabled, the goggles will sync the time automatically when connected to Wi-Fi in client mode.

Settings are saved: The time zone and auto sync settings are saved and loaded correctly.

💻 UI changes:
Added dropdown to select UTC time zone.

New buttons: “Sync from Internet” and “Auto Sync”.

Shows messages when sync is successful or failed.

“Sync from Internet” button is disabled if Wi-Fi is not connected.

⚙️ Technical changes:
Added new file: ntp_client.c to handle NTP sync.

Added file: wifi_status.c to check if Wi-Fi is connected.

Modified page_clock.c, settings.c, page_wifi.c, and others.

🔍 Notes:
If sync fails, the user will see a red message.

If sync works, the clock is updated and saved.

Works only when Wi-Fi is in client mode and connected.

Let me know if something needs to be changed.
Thanks for reviewing!

[mauriciobridge]

[pitts-mo]

This is looking pretty good. NTP will be a nice feature :-)

Regardless of the servers we pre-fill the user may need to provide specific NTP servers...

hdzero-goggle/src/util/ntp_client.c

Line 64 in a3fba72

static char* g_ntp_servers[] = {

hdzero-goggle/src/util/ntp_client.c

Line 74 in a3fba72

static char* g_ntp_fallback_ips[] = {

Can you remove these two hard coded NTP server lists and replace it with a single user editable NTP server string of comma separated URL/IP and pre-fill the default NTP server string with URLs that remain more neutral.
eg: "0.pool.ntp.org,1.pool.ntp.org,2.pool.ntp.org,3.pool.ntp.org"

?

[nerdCopter]

while i do like the idea of a pilot modifiable field, i do not feel that the 0., 1., ... 3. "redundancy" is required for our purposes. this is not a enterprise server.

a single pool.ntp.org would work as it should be a nearby location time-server. and a pilot may still modify to a specified country-code prefixed pool.

[pitts-mo]

I agree that one ntp server is typically fine but think two should be pre-filled so a user can see how to add alternates when needed.

I also recognize a lot of work went into this. However, the more I think about it I realize this should be simplified into just a user interface for ntpd, date and TZ that are already included with the OS.

[pitts-mo]

Some notes about existing time tools in goggle OS:

root@tina:~# echo $TZ
Asia/Shanghai

root@tina:~# find /usr/share/zoneinfo/
/usr/share/zoneinfo/
/usr/share/zoneinfo/Asia
/usr/share/zoneinfo/Asia/Chongqing
/usr/share/zoneinfo/Asia/Hong_Kong
/usr/share/zoneinfo/Asia/Shanghai

# TZ Note: a current zone list contains 522 zones totaling ~2.1M of space.

root@tina:~# ntpd --help
BusyBox v1.27.2 (2023-07-16 18:23:07 EDT) multi-call binary.

Usage: ntpd [-dnqNwl -I IFACE] [-S PROG] [-p PEER]...

NTP client/server

-d	Verbose
-n	Do not daemonize
-q	Quit after clock is set
-N	Run at high priority
-w	Do not set time (only query peers), implies -n
-S PROG	Run PROG after stepping time, stratum change, and every 11 mins
-p PEER	Obtain time from PEER (may be repeated)
	If -p is not given, 'server HOST' lines
	from /etc/ntp.conf are used
-l	Also run as server on port 123
-I IFACE Bind server to IFACE, implies -l

-I IFACE Bind server to IFACE, implies -l

root@tina:~# ntpd -d -w -p 192.168.2.217
ntpd: sending query to 192.168.2.217
ntpd: timed out waiting for 192.168.2.217, reach 0x00, next query in 1s
ntpd: sending query to 192.168.2.217
ntpd: timed out waiting for 192.168.2.217, reach 0x00, next query in 2s
ntpd: sending query to 192.168.2.217

# ntpd note: my tests environment does not have an ntp server. ntpd -w will just query and not set time. I figure the app could manually trigger ntpd but it would be more stable if the app configured ntpd to run at the OS level and make the app UI read the current server list & time zones, only pre-polulating values when the user enables ntp and ntpd was not previously configured.

root@tina:~# date --help
BusyBox v1.27.2 (2023-07-16 18:23:07 EDT) multi-call binary.

Usage: date [OPTIONS] [+FMT] [TIME]

Display time (using +FMT), or set time

[-s,--set] TIME	Set time to TIME
-u,--utc	Work in UTC (don't convert to local time)
-R,--rfc-2822	Output RFC-2822 compliant date string
-I[SPEC]	Output ISO-8601 compliant date string
		SPEC='date' (default) for date only,
		'hours', 'minutes', or 'seconds' for date and
		time to the indicated precision
-r,--reference FILE	Display last modification time of FILE
-d,--date TIME	Display TIME, not 'now'
-D FMT		Use FMT for -d TIME conversion

Recognized TIME formats:
hh:mm[:ss]
[YYYY.]MM.DD-hh:mm[:ss]
YYYY-MM-DD hh:mm[:ss]
[[[[[YY]YY]MM]DD]hh]mm[.ss]
'date TIME' form accepts MMDDhhmm[[YY]YY][.ss] instead

root@tina:~# date
Fri May 23 18:03:46 CST 2025

root@tina:~# date +"%Y-%m-%d %H:%M:%S"
2025-05-23 18:11:51

# date Note: The best readily available way to get, set, convert, and find a difference in date-time values.

[pitts-mo]

I have had to manipulate / justify time in many ways over the years. The more I did so the more problems I saw even within popular tools and widely accepted practice. In the end the two most reliable and flexible tool sets to manage time ended up being databases and basic linux tools. I have even utilized linux tools for windows many, many times.

Sorry, This is just a hobby product, but wanted to share pain from the past to prevent other pain in the future.

[pitts-mo]

@mauriciobridge I really like the GUI and thoughtfulness of this PR integrating ntp into the app/WiFi state. If you have interest in collaborating please reach out via #open-source or DM on discord.

Below are my current notes for allowing app to manage ntp and timezones on the OS.

primary app gui function:
-read, update, or create /etc/ntp.conf file "server 0.pool.ntp.org" lines
-provide system TZ listing and set update /etc/TZ to user selection
-enable, disable, sync now (one time sync)

app time service management:
-export TZ=$(< /etc/TZ) on app start
-control ntpd start at boot and start/stop as desired

OS support:
-import of complete TZ list into /usr/share/zoneinfo
-note linux programs tend to default "GMT" / UTC or just not report time zone when a specified time zone does not exist

potential OS level changes:
-update /etc/profile script to export TZ=$(< /etc/TZ) instead of setting static value
-add OS level ntpd startup script w/crontrab @reboot and have it reference the users desired ntp state setting

[mauriciobridge]

Hi @pitts-mo ! Thanks for the detailed feedback, I really appreciate it!
You're absolutely right that my current implementation handles time from application level, which isn't the most robust approach. I'll be honest... I don't have much experience with OS level time management in Linux, so my initial approach was more direct.

I really like your suggestion of using the existing system methods (/etc/ntp.conf, /etc/TZ, ntpd). That would definitely be more robust and follow proper Linux conventions. I also agree users should be able to edit their preferred NTP servers.

That said, I was initially thinking that since HDZero Goggles are a specialized FPV device, maybe a simpler plug-and-play approach would be more appropriate for typical users. But you've got me thinking... there's probably a good middle ground here that leverages the system tools without overcomplicating things.
I will do to do some research on Linux time management to have a better approach. This will require some learning on my part, but I think it's worth doing it.