树莓派Pico RTC与NTP时间同步实战：从原理到代码

我先把话说在前头：树莓派 Pico 如果只是用 MicroPython 点个灯、读个传感器，那你只发挥了这个板子两成功力。真正让嵌入式项目“像样”的关键，是给设备一个可信的时间基准。这篇文章我想认真聊一聊在树莓派 Pico 上做 RTC 控制，以及怎么用 NTP 协议把设备时间校准到和互联网时间基本一致。不光是给你一段能跑的代码，更重要的是把背后的原理、常见的坑、还有我踩过的设计误区都拆开讲清楚。适合谁看？正在用 Pico 做数据采集、传感器记录、定时控制、离线日志的开发者，或者对 MicroPython 网络编程感兴趣的玩家，这篇应该能省你不少折腾的时间。

1. 为什么嵌入式设备必须认真对待时间

1.1 RTC 到底是什么，和系统时钟有什么不同

很多人第一次接触 RTC（Real-Time Clock，实时时钟）时容易把它和 MCU 内部的定时器搞混。其实 RTC 在硬件层面就是一组独立的计数器，专门用来维护“人类可读”的年月日时分秒。单片机里的time.ticks_ms()那种，是基于系统主频或者定时器中断计数出来的相对时间，它只能告诉你“距离开机过去了多少毫秒”，并不能知道现在是 2025 年 6 月 8 号还是 2030 年。而 RTC 模块知道。

RTC 在嵌入式项目里的价值，体现在三个场景：第一是数据记录，传感器采集到的每一帧数据如果只有相对时间，后面做分析排序就是一场灾难。第二是定时控制，比如每天 8 点开启水泵、每周五晚上执行一次数据上报，没有真实时间控制逻辑根本写不出来。第三是日志和告警，设备出错时如果没有时间戳，你就不知道故障发生在凌晨还是下午，也没法和外部事件关联。

但这里必须说一个 Pico 用户经常忽略的问题：RP2040 芯片内部确实自带 RTC 外设，但在 MicroPython 里它被封装成了machine.RTC。它的计时精度依赖外部晶振，更关键的是——它没有独立的备用电池引脚。如果你把设备断电重启，RTC 内容会丢失并回到一个初始值。很多初学者在这个地方栽过跟头：明明前一天代码还在正常显示时间，第二天上电就变成了 2021 年 1 月 1 日。

1.2 RP2040 的 RTC 硬件：有 RTC 但没电池，这是最大的坑

我们用树莓派 Pico 做时间相关项目，第一件事就是认清它的硬件限制。RP2040 的 RTC 外设本身是可以工作的，MicroPython 也提供了machine.RTC类，初始化之后能跑。但它不像常见的 DS3231 模块那样有VBAT引脚可以插个纽扣电池，Pico 官方板几乎没有任何保留 RTC 电源的设计。也就是说，你所有用 RTC 记录的时间，都依赖主板持续供电。

这个限制带来什么实际影响呢？我用一个真实项目举例。之前我帮朋友做一个环境监测的小盒子，板子是 Pico W，逻辑是每 5 分钟采集一次温湿度，把数据写到 SD 卡。第一版代码跑起来很顺，数据也有，但第二天检查发现日志文件里时间全是 2021 年。原因不难猜：设备断电过一个晚上，RTC 归零，开机后 MicroPython 的 RTC 初始状态根本不是当前时间。

解决办法其实就两条路。一条是外接 DS3231、PCF8523 等独立 RTC 模块，用纽扣电池维持时间；另一条是每一次开机都通过 NTP 从网络同步一次时间，只要你的设备能联网，这条路线最简单省事，连额外硬件都不用加。如果你做的是需要长期离线运行并且频繁断电的设备，那就老老实实加一个外部 RTC 模块，这也是嵌入式行业里的常规做法。热词里提到的“全志 H136 RTC 电源切换电路”其实就是这类设计的典型思路，只不过在 Pico 上，我们通常用模块方案而不是自己搭切换电路。

1.3 时间同步的整体思路：RTC + NTP 双保险

在开始写代码之前，我建议你先想清楚自己的项目需要什么样的时间精度。根据我自己的实践，时间方案大致可以分三档。

第一档是“完全离线但能容忍偏差”，直接用外部 RTC 模块，精度取决于晶振和温度，一般一个月偏差几十秒，很多仪表类应用够用了。第二档是“偶尔联网、定期校准”，设备平时靠 RTC 走时间，每隔一定时间连一次 Wi-Fi，从 NTP 服务器拉取标准时间覆盖 RTC。这也是我推荐大多数 Pico 项目采用的方案。第三档是“每次开机强制同步”，适合对时间一致性要求高的数据采集节点，比如多个设备同时采数据，后续做时间对齐。你不需要在第一时间追求极端复杂的算法，先用 RTC 保底、用 NTP 校准，这是实践中性价比最高的组合。

我见过不少开发者纠结“我要不要用 PTP 那种微秒级同步”，说实话，Pico 这种级别的板子，加上 Wi-Fi 本身的不确定性，能把时间同步到几十毫秒级别已经很不错了。NTP 在局域网内通过有线方式可以达到 1 毫秒量级，但在 Wi-Fi 环境下受干扰和调度影响，做到 20~50 毫秒就已经很理想。所以咱们这篇不整那些高深的 PTP 原理，先把 NTP 这套建立起来、弄明白，你的项目时间体系就已经超过 90% 的业余作品了。

2. NTP 协议原理：从报文到时间戳

2.1 为什么不用 HTTP 而用 NTP

有朋友可能想到，我直接用一个 HTTP API 获取时间不行吗？比如访问某个天气或时间接口，解析返回的 JSON。行是行，但有几个很现实的问题：一是 HTTP 接口响应体臃肿、解析慢，嵌入式设备得消耗不少内存去处理字符串。二是大多数公共 HTTP 接口并不承诺高精度，响应里经过多层服务器处理，时间偏差可能到几百毫秒甚至更高。三是依赖第三方服务的可用性，万一接口挂了你整个设备就同步不了时间。

NTP（Network Time Protocol）就是专门为时间同步设计的协议。它走 UDP 协议，端口 123，报文固定长度，解析非常简单。公共 NTP 服务器有稳定的层级结构，服务端时间精度普遍很高，兼容性也最好。所以做嵌入式联网校时，NTP 是默认选择，没有之一。

NTP 协议里有个基本概念叫“层（Stratum）”，数字越小越接近权威时间源。比如卫星、原子钟是 Stratum 0，直接连它们的是 Stratum 1，Stratum 2 又是从 Stratum 1 同步来的，以此类推。公共 NTP 服务器一般都在 Stratum 1 或 Stratum 2，我们设备去请求它们，逻辑上就成为 Stratum 3 以下的客户端。这个层级结构保证了整个互联网时间体系的可靠传递。不过对于咱们 Pico 项目，不必太纠结 stratum 数字，重要的是能拿到准确时间。

2.2 NTP 报文结构拆解

MicroPython 发送 NTP 请求，本质上就是构造一个 48 字节的 UDP 数据包发给服务器，然后解析服务器回包。NTP 报文的前几个字段很关键，我简单拆一下。

报文第 0 个字节可以拆成 3 个部分：前 2 位是闰秒指示器（LI），通常为 0；中间 3 位是版本号（VN），我们现在常用 3 或 4；最后 3 位是工作模式（Mode），客户端请求时填 3。第 1 个字节是 stratum 层级，第 2 个字节是轮询间隔，第 3 个字节是精度。从第 40 个字节到第 43 个字节，存放的是“发送时间戳”（Transmit Timestamp），这是服务器准备发送响应包那一刻的时间，单位是自 1900 年 1 月 1 日 0 时起算的秒数。客户端真正需要解析的，往往就是这个发送时间戳，再加上前面第 32 到 35 字节的“接收时间戳”（Receive Timestamp），用于更精确的往返时延计算。

NTP 时间戳和我们平时用的 Unix 时间戳起点不一样。Unix 时间戳从 1970 年 1 月 1 日算起，而 NTP 从 1900 年算起，两者之间相差 2208988800 秒。所以拿到 NTP 报文的发送时间戳后，要减去这个固定常量，才能转换成我们熟悉的 Unix 时间。在 MicroPython 里，可以用time.localtime(unix_timestamp)直接得到本地时间元组。

可能你会想：NTP 只有 32 位秒字段，到 2036 年不就雪崩了吗？这个官方早有设计，NTP 时间戳是循环使用的，协议设计者认为 2036 年后系统会自然过渡到新版本。咱们做产品不用操心这个周期，等真到那一年，手里的设备八成早换掉了。

2.3 往返延迟与时间偏移的计算原理

NTP 同步的核心不只是“把服务器时间抄过来”，而是要估算网络往返延迟，并修正设备本地时间和服务器时间的偏差。这个概念很像你和朋友对表：你发出“现在几点”的消息，朋友收到后回你“我这里是 X 点”，你收到消息时已经是 Y 点，这之间的半个来回就是网络延迟。

在实际实现中，我们会记录四个关键时间点：

• T0：客户端发送请求的时间
• T1：服务器接收到请求的时间
• T2：服务器发送响应的时间
• T3：客户端接收到响应的时间

那么网络往返延迟（round-trip delay）约为(T3 - T0) - (T2 - T1)，客户端与服务器之间的时间偏移（offset）约为((T1 - T0) + (T2 - T3)) / 2。有了偏移量，我们就能调整本地时钟。但注意，MicroPython 的socket模块里获取精确到毫秒级的时间戳并不容易，实际做 NTP 客户端时，很多精简实现会直接忽略复杂的偏移计算，只取报文里的发送时间戳，然后加上我们估算的网络延迟作为补偿。

我自己的做法比较务实：发出请求前记录time.ticks_ms()，收到响应后计算总耗时，把耗时一半作为网络传输延迟加到服务器时间上。这个近似值在 Wi-Fi 环境下通常能提供 20~100 毫秒的精度，对于绝大多数 RTC 校准场景绰绰有余。真要追求更高精度，那就得在代码里手工记录四个时间点，同时尽量保证发送前和接收后的本地时钟稳定。

3. 开发环境准备与快速验证

3.1 MicroPython 固件与开发板准备

动手之前，先把开发环境理顺。树莓派 Pico 或 Pico W 都行，我下面的代码基于 Pico W，因为它自带 Wi-Fi。如果你用普通 Pico，需要外接 ESP8266/ESP32 这类 Wi-Fi 模块，代码逻辑会复杂不少。我个人建议做时间同步项目优先上 Pico W，省心。

首先要把 MicroPython 固件刷进去。从树莓派官网或 MicroPython 官方下载对应的.uf2文件，按住 Pico 板上的 BOOTSEL 键接入 USB，会弹出一个 U 盘，把固件文件拖进去即可。这一步没什么难度，网上教程也很多，我就不展开了。刷完固件之后，用串口终端软件（Thonny、PuTTY 或 minicom）验证 MicroPython 是否正常。

然后确认你的网络环境。Pico W 只支持 2.4GHz Wi-Fi，不支持 5GHz，很多同学卡在这一步：手机热点如果是 5GHz，Pico 根本搜不到。建议直接开一个 2.4GHz 的热点，或者用家用路由器的 2.4G 频段。连接代码很简单，直接network.WLAN(network.STA_IF)然后connect(ssid, password)。

3.2 用 REPL 快速验证 NTP 连通性

在写完整代码之前，我强烈建议你先在 REPL 里手动测试一遍 NTP 请求流程。因为这样可以快速暴露网络或协议层面的问题，然后逐步把代码抽象成函数。

测试的第一步是连接 Wi-Fi。第二步，在 MicroPython 里写一个朴素的 UDP 客户端：创建 socket，设置超时，向 NTP 服务器地址发送 48 字节的报文。我用的是ntp.aliyun.com，国内访问稳定；如果你在国外，也可以直接用pool.ntp.org。完成之后打印收到的报文长度，如果成功收到 48 字节，就说明网络侧没问题。

这一步看起来简单，但实际很有价值。有时候你代码逻辑没问题，纯粹是 DNS 解析超时或者 UDP 被路由器拦截，提前验证能帮你把问题定位到网络层而不是应用层。

3.3 基础 RTC 设置代码

Pico 的 MicroPython 里操作 RTC，核心就是machine.RTC()。设置时间可以用rtc.init()或者直接给rtc.datetime()赋值。rtc.datetime()返回一个 8 元组：(year, month, day, weekday, hours, minutes, seconds, subseconds)。特别提醒：weekday从 0 开始，0 代表周一，这和很多初学者习惯的“周日是 0”不一样，别搞反了。

from machine import RTC rtc = RTC() # 手动设置时间：2025年6月8日，周日，14点30分0秒 # weekday: 0=周一, 6=周日 rtc.datetime((2025, 6, 8, 6, 14, 30, 0, 0)) # 读取时间 year, month, day, weekday, hours, minutes, seconds, subseconds = rtc.datetime() print("{:04d}-{:02d}-{:02d} {:02d}:{:02d}:{:02d}".format( year, month, day, hours, minutes, seconds ))

subseconds字段是亚秒值，在 RP2040 上精度有限，一般不需要真正依赖它做高精度计时。machine.RTC还有一个memory功能，可以存几个字节的用户数据，掉电后会丢失，别把它当闪存用。

需要注意的是：如果你在 REPL 里手动设置了时间，代码里又不主动初始化和校准，重启后时间就会回到默认值。所以真正的产品代码必须在校时逻辑上做兜底。

4. 完整实现：NTP 时间同步与 RTC 控制

4.1 Wi-Fi 连接与时间服务器通信

下面我给出一个可以直接用的完整示例。代码分为几个模块：网络连接、NTP 请求、时间解析、RTC 同步。这样的结构方便你移植到自己的项目里。

import network import socket import struct import time from machine import RTC rtc = RTC() # 配置你的 Wi-Fi SSID = "your_ssid" PASSWORD = "your_password" NTP_HOST = "ntp.aliyun.com" NTP_PORT = 123 NTP_DELTA = 2208988800 # 1900 -> 1970 之间的秒数 def connect_wifi(): wlan = network.WLAN(network.STA_IF) wlan.active(True) if not wlan.isconnected(): print("正在连接 Wi-Fi...") wlan.connect(SSID, PASSWORD) timeout = 10 while not wlan.isconnected() and timeout > 0: time.sleep(1) timeout -= 1 if wlan.isconnected(): print("Wi-Fi 已连接，IP:", wlan.ifconfig()[0]) return True else: print("Wi-Fi 连接失败") return False def get_ntp_time(): """发送 NTP 请求，返回 Unix 时间戳""" ntp_sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) ntp_sock.settimeout(5) # 构造 NTP 请求报文：共 48 字节 packet = bytearray(48) # 第 0 字节：0b00100011 # LI=0, VN=4, Mode=3 (client) packet[0] = 0x23 # request 模式 try: # 解析域名并发送 addr = socket.getaddrinfo(NTP_HOST, NTP_PORT)[0][4] ntp_sock.sendto(packet, addr) # 接收响应 data, _ = ntp_sock.recvfrom(48) if len(data) != 48: raise ValueError("NTP 响应长度异常") # 提取第 40~43 字节：Transmit Timestamp tx_ts = struct.unpack("!I", data[40:44])[0] # 转为 Unix 时间戳 unix_ts = tx_ts - NTP_DELTA return unix_ts except Exception as e: print("NTP 请求失败:", e) return None finally: ntp_sock.close()

这段代码里有几个容易出问题的地方，我逐个说。packet[0] = 0x23这个值的含义是版本号 4、客户端模式 3。你也可以用(1 << 3) | 3来表达，这样可读性更好一些。接收时我设置了 5 秒超时，这个值在弱网环境可以适当调大，但不要超过 10 秒，否则阻塞太久会影响主流程。

4.2 从 NTP 报文解析时间戳

刚才代码里解析的是第 40 到 43 字节，也就是服务器发送响应的时间戳。为什么取这一段？因为在 NTP 协议的 48 字节报文里，前 16 字节用于 root delay、root dispersion、reference ID 等不太常用的字段，第 16 到 23 字节是参考时间戳，第 24 到 31 字节是发起时间戳（Originate Timestamp），第 32 到 39 字节是接收时间戳（Receive Timestamp），第 40 到 47 字节才是发送时间戳（Transmit Timestamp）。

对我们精简客户端来说，发送时间戳已经够用。但如果你想算得更精细，可以同时取出接收时间戳和发送时间戳，然后利用它们做偏移修正。我提供一个稍进阶的版本：

def get_ntp_time_with_offset(): ntp_sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) ntp_sock.settimeout(5) packet = bytearray(48) packet[0] = 0x23 try: addr = socket.getaddrinfo(NTP_HOST, NTP_PORT)[0][4] t0 = time.ticks_ms() ntp_sock.sendto(packet, addr) data, _ = ntp_sock.recvfrom(48) t3 = time.ticks_ms() if len(data) != 48: raise ValueError("NTP 响应长度异常") # 从报文解析 T1 和 T2 recv_ts_sec = struct.unpack("!I", data[32:36])[0] recv_ts_frac = struct.unpack("!I", data[36:40])[0] tx_ts_sec = struct.unpack("!I", data[40:44])[0] tx_ts_frac = struct.unpack("!I", data[44:48])[0] t1_ntp = recv_ts_sec + recv_ts_frac / 4294967296.0 t2_ntp = tx_ts_sec + tx_ts_frac / 4294967296.0 # 本地时间戳近似换算（注意：t0/t3 是 ticks_ms，不是绝对时间） total_rtt = (t3 - t0) / 1000.0 # 从服务器时间推算出本地系统当前时间 server_time = t2_ntp - NTP_DELTA # 加上半个往返时延作为补偿 offset = total_rtt / 2 local_unix_ts = server_time + offset return local_unix_ts except Exception as e: print("NTP 请求失败:", e) return None finally: ntp_sock.close()

这个进阶版本从报文的“接收时间戳”和“发送时间戳”字段中取服务器侧的两个时刻，再结合本地收发耗时估算偏移，比只解析发送时间戳更稳。不过 MicroPython 的性能有限，解析浮点数也会有一些开销，实际精度提升可能并不明显。我自己的感觉是，对 Pico 的时间同步来说，简单版其实已经足够。这里写出来是为那些有洁癖、想尽量严谨的朋友做个参考。

4.3 同步到 RTC 并校准日期时间

拿到 Unix 时间戳之后，剩下的事情就是把它转换成 RTC 所需的日期时间元组。MicroPython 的time.localtime()可以把 Unix 时间戳转为本地时间。注意：time.localtime()默认按 UTC 时区处理，如果你的设备在中国，需要加上 8 小时的偏移再转换，或者你统一用 UTC 时间存储，只在展示时转换。

我建议在设备内部统一使用 UTC 时间存储，避免时区换算带来的混乱。比如记录日志时用 UTC，到了云平台或上位机再转换成当地时区。这个习惯能让你避免很多“时间对不上”的诡异问题。如果一定要在设备本地显示北京时间，那就加 28800 秒再做转换。

def sync_rtc(unix_ts=None): if unix_ts is None: unix_ts = get_ntp_time() if unix_ts is None: print("没有获取到 NTP 时间，RTC 未更新") return False # 转成北京时间（UTC+8） local_ts = unix_ts + 8 * 3600 year, month, day, hour, minute, second, weekday, yearday = time.localtime(local_ts) # MicroPython 的 weekday: 0=周一, 6=周日 # time.localtime 的 weekday: 0=周一, 6=周日，正好一致 rtc.datetime((year, month, day, weekday, hour, minute, second, 0)) print("RTC 已同步:", "{:04d}-{:02d}-{:02d} {:02d}:{:02d}:{:02d}".format( year, month, day, hour, minute, second )) return True

还有一个容易踩的小坑：time.localtime()返回的第 7 个元素是“星期几”，但第 8 个元素是“年内第几天”，有些新手会把它们顺序弄错，导致 RTC 读出来的日期不对。MicroPython 里time.localtime()默认返回 8 元组，和 CPython 是一致的，顺序是(year, month, mday, hour, minute, second, weekday, yearday)，注意这里的weekday是 0 到 6，0 表示周一。和machine.RTC.datetime()的 8 元组顺序略有不同，后者是(year, month, day, weekday, hours, minutes, seconds, subseconds)，其中第 4 个元素才是星期几。两边并不完全对应，赋值时要多留个心眼。

4.4 开机自动校时与周期同步机制

时间同步不是“同步一次就完事”。晶体振荡器会受温度影响产生漂移，Pico 上用的晶振精度普通，一天下来可能差个几秒到十几秒都正常。所以如果设备长期运行，我建议做周期同步，间隔可以根据精度需求来定。

比如数据采集类项目，日误差不能超过 2 秒，那就每 6 小时同步一次；如果只是显示个时钟，每 24 小时同步一次也够。同步太频繁会额外耗电、增加网络请求，没必要。

下面给出一个带周期同步的主循环框架：

import machine import time # 记录上次同步时间 last_sync_time = 0 SYNC_INTERVAL_SECONDS = 6 * 3600 # 6 小时同步一次 def should_sync(): """距离上次同步是否超过间隔""" global last_sync_time now = time.time() if now - last_sync_time >= SYNC_INTERVAL_SECONDS: last_sync_time = now return True return False def main_loop(): global last_sync_time # 开机先尝试同步一次 if connect_wifi(): if sync_rtc(): last_sync_time = time.time() # 同步完可以断开 Wi-Fi，省电 network.WLAN(network.STA_IF).active(False) while True: if should_sync(): # 重新连接网络并同步 if connect_wifi(): sync_rtc() network.WLAN(network.STA_IF).active(False) # 其他业务逻辑，比如读传感器、写日志 # do_sensor_reading() time.sleep(5)

这里我说一个非常实用的建议：同步完成后不用一直保持 Wi-Fi 连接，直接把WLAN.active(False)关掉，能明显降低功耗。等下次需要同步时再连。很多低功耗项目都是这么干的。

还有一个细节，time.time()在 MicroPython 里返回的是 Unix 时间戳吗？这里要注意：MicroPython 的time.time()确实返回 Unix 时间戳，但它的数值依赖 RTC 的设置。如果你之前没有设置 RTC，它可能返回一个很大的值或者负数，这取决于固件实现。所以正确顺序是：先开机同步 RTC，然后再依赖time.time()做业务逻辑。我在项目里的习惯是，用一个变量缓存 “RTC 是否已经同步过”，没同步前不执行任何依赖时间的操作。

5. 常见问题与排查经验

5.1 RTC 读到“错误时间”的根源与对策

热词里有一个很典型的描述叫“RTC 读到错误时间”，这个现象表面上可能是代码问题，但深层原因往往有几个。

第一类是“星期几不对”。很多初学者直接把time.localtime()的第 7 个元组传给rtc.datetime()的第 4 个位置，结果发现日期对但星期错。前面已经解释过原因，两者顺序定义有差异，赋值前你要确认好字段含义。

第二类是“同步后时间被覆盖”。有人在一段代码里，前面已经做了 NTP 同步，后面又有别的地方调用了rtc.init()或者rtc.datetime()给了一个固定时间，导致同步结果被覆盖。排查办法很简单，全局搜索rtc.datetime和rtc.init，确认只有一处设置逻辑。

第三类是“断电重启后时间回到 2021”。这就是 Pico 没有 RTC 后备电池的直接表现。对策要么是每次开机强制 NTP 同步，要么外部加 DS3231 模块。我推荐一种“混合模式”：上电先读外部 RTC，如果时间明显不合理（比如早于编译日期），才触发 NTP；如果外部时间可用，就直接用外部时间，减少网络依赖。

我见过一个更隐蔽的问题。有位朋友把 RTC 的年份初始化为 2021，而业务逻辑里做了“当天日期是否晚于某个固定日期”的判断，结果设备一直走错误分支。这种错误没有报错，但行为完全不对。排查时用日志把每次同步前后的时间都打出来，通常是最高效的手段。

5.2 网络连接失败（ConnectionState Failed）怎么定位

热词里的 “rtc connectionstate failed” 看起来像是某个模块的连接状态报错。在 Pico 上，最常见的对应场景是wlan.isconnected()一直为False，或者socket操作抛出OSError: -3之类的错误。这类问题我总结了四个排查方向：

1. Wi-Fi 频段不匹配：Pico W 不支持 5GHz，连不上 5G 热点很正常。把热点改成 2.4GHz，或者换一个路由器测试。
2. 信号太弱：Pico W 的天线就是板载 PCB 天线，离路由器太远、中间隔的墙太多，都可能握手失败。可以把设备移到路由器旁边试一下。
3. DNS 解析失败：socket.getaddrinfo()需要 DNS 服务。如果ntp.aliyun.com解析不了，可以先用 IP 地址测试。比如用203.107.6.88（阿里云 NTP 服务的一个 IP）发 UDP 包，看是否能收到响应。
4. UDP 被防火墙拦截：家庭路由器一般不会拦 UDP 123 端口，但某些公共网络、办公网络会限制。如果换网络环境后正常，说明是网络策略问题。

还有一个容易忽略的问题：MicroPython 的网络 socket 在某些异常断开后不会自动释放，你反复尝试连接，可能报OSError: [Errno 110] ETIMEDOUT。解决办法是每次连接前先wlan.active(True)，失败后不要立刻重试，等 2~3 秒再试，并且把上一次的 socket 彻底close()。

5.3 毫秒级误差的高精度方案

如果你真的需要比“秒级”更精确的时间同步，比如多个 Pico 设备同时采集传感器数据，事后要把数据按时间对齐，那么纯用字符串格式的 “YYYY-MM-DD HH:MM:SS” 是不够的。我建议用 Unix 时间戳，最好是浮点数或者带毫秒的整数来表示采样时刻。

Pico 上获取毫秒可以用time.ticks_ms()，但它是相对时间，不能直接和 Unix 时间戳做加法。更靠谱的做法是：把 NTP 同步的绝对时间基准保存下来，配合ticks_ms()计算出当前的绝对毫秒时间。比如同步完成后记录sync_unix_ms和sync_tick_ms，之后任意时刻的绝对时间毫秒数是sync_unix_ms + (time.ticks_ms() - sync_tick_ms)。这个方法在 Wi-Fi 断开期间依然有效，只要板子不重启。

import time from machine import RTC rtc = RTC() sync_unix_ms = 0 sync_tick_ms = 0 def set_time_base(unix_ts): global sync_unix_ms, sync_tick_ms sync_unix_ms = unix_ts * 1000 sync_tick_ms = time.ticks_ms() def current_unix_ms(): return sync_unix_ms + (time.ticks_ms() - sync_tick_ms)

这套逻辑配合 NTP 的秒级同步，能让你在两次同步之间获得稳定的毫秒级时间戳。真要做到微秒级，那就得靠 PTP 协议和硬件时间戳，Pico 这个平台很难支撑，也没必要。

5.4 低功耗场景的 RTC 电池备份扩展

如果你的项目要长期离线运行，又经常断电，那就别硬扛内置 RTC 了。外接 DS3231 是高性价比方案。DS3231 内置了温度补偿晶振（TCXO），年误差通常只有几分钟，而且有VBAT引脚可以接 CR2032 纽扣电池，主电源断了之后它还能继续走时。

MicroPython 里驱动 DS3231 很简单，通过 I2C 通信。需要安装ds3231库或者自己写寄存器读取代码，核心数据是 0x00 到 0x06 寄存器。读取时要注意 BCD 编码：寄存器里存的是压缩十进制，需要转换。比如读到 0x15，代表的是“15”而不是“21”。

我自己在项目里是这么分工的：DS3231 负责持续走时，NTP 负责在设备联网时校准 DS3231 的积累误差。这个组合非常稳，既不怕断电，又能维持长期准确。启动流程是：初始化 I2C，读 DS3231 时间，如果年份小于 2024（说明电池没电或首次上电），就连接 NTP 同步一次，然后把时间写进 DS3231。

5.5 时间校准的核心排查清单

为了避免你反复踩坑，我整理了一份我每次排查时间问题时都会过的清单，几乎能覆盖 80% 的“时间不对”问题：

这个表格是我做项目时总结的，基本覆盖了初学者最容易遇到的场景。你对照排查一遍，比自己瞎调效率高得多。

写在最后

我在实际项目中折腾 Pico 的时间同步，最大的感受就是：RTC 和 NTP 不是两个孤立的功能，它们是一体两面的“时间可靠性”方案。NTP 负责把设备拉回正确的轨道，RTC 负责在轨道上稳定行走。你不需要一开始就追求极端复杂的高精度同步，先把“上电自动校时、周期防漂移、断电恢复”这套闭环跑通，就已经解决掉 95% 的时间问题。最后再分享一个小技巧：做任何和时间相关的嵌入式项目，一定要把“同步前的时间”“同步后的时间”“校准的偏移量”这三类信息打日志，哪怕现在用不上，等设备真出了问题，这些日志就是你排障的最强线索。