1. 从一场大学生竞赛看无线技术如何真正落地全国大学生物联网设计竞赛这类赛事圈外人看是学生拿板子搭Demo圈内人看的是另一回事——它其实是无线技术从实验室走向真实场景的一次集中预演。2026年这届竞赛落幕之后我翻了不少参赛队伍的方案发现一个很明显的分水岭拿奖的队伍几乎都不是堆传感器数量最多的而是把无线连接这一层吃透了。Nordic作为长期深耕低功耗无线领域的芯片厂商这次深度参与赛事支持背后折射出的其实是整个物联网行业对连接稳定性这件事的重新重视。如果你正在做物联网相关的课程设计、毕业设计或者在企业里负责无线模块选型和组网方案这篇内容应该能帮到你。我会从竞赛里暴露出的真实技术问题切入把无线技术在高校科创项目中的典型用法、常见坑、选型逻辑讲清楚。不是泛泛而谈物联网很重要而是具体到芯片怎么选、协议怎么配、功耗怎么算、组网怎么调。这些内容在官方文档里往往一笔带过但实际做项目时恰恰是这些细节决定成败。先给一个基本判断物联网项目的三层架构——感知层、网络层、应用层——里最容易被低估的就是网络层。感知层无非是选传感器应用层无非是写界面但网络层涉及射频、协议栈、功耗管理、抗干扰任何一个环节出问题整个系统就是数据上不来或者跑两天就没电。竞赛里大量作品卡在这一层不是学生不努力而是无线技术的门槛确实藏在细节里。2. 竞赛作品里暴露的无线连接真实痛点2.1 为什么能连上和稳定连是两回事很多参赛队伍在答辩时演示很流畅但评委一走设备就开始掉线。这不是偶然。实验室环境和真实部署环境的射频条件差异巨大。实验室里路由器、蓝牙设备、WiFi热点密集2.4GHz频段本身就拥挤而竞赛现场往往有几十支队伍同时开机信道冲突几乎是必然的。我见过一个典型方案用BLE做数据传输手机App作为网关。单机测试时延迟20ms以内但现场同时有十几台设备广播时扫描响应时间直接飙到几百毫秒数据包丢失率超过15%。问题出在哪BLE的广播信道只有三个37、38、39所有设备都在抢这三个信道。解决方案不是换芯片而是调整连接参数——把广播间隔从默认的100ms拉长到300ms以上同时启用白名单过滤只允许已配对设备响应。这个改动让丢包率降到了3%以下。注意广播间隔不是越短越好。短间隔意味着更快的发现速度但也意味着更高的碰撞概率和功耗。实际项目中要根据设备密度动态调整。2.2 功耗预算算错项目直接短命另一个高频问题是功耗估算过于乐观。很多队伍用纽扣电池供电理论上算出来能跑半年实际两周就没电。原因通常有三个一是忽略了射频发射时的峰值电流Nordic的nRF52系列在发射时峰值可达十几毫安远超数据手册里的平均电流二是没有正确配置低功耗模式MCU一直在跑三是传感器轮询频率过高白白浪费能量。正确的做法是建立功耗预算表。以nRF52840为例睡眠模式电流约1.5微安接收模式约5毫安发射模式0dBm约6毫安。假设每秒发送一次20字节的数据包发射持续时间约1毫秒那么平均电流大约是睡眠电流 (发射电流 × 占空比) (接收电流 × 占空比)。算下来大概在几十微安级别这才有可能撑到半年以上。但如果你用的是连续扫描模式接收占空比接近100%那平均电流直接上到毫安级电池几天就没了。2.3 天线设计被忽视的代价竞赛里有个很普遍的现象队伍把无线模块焊在板子中央周围铺满铜皮和元件然后抱怨通信距离只有几米。这不是芯片的问题是天线被屏蔽了。PCB板载天线对周围环境极其敏感地平面大小、元件布局、外壳材质都会影响辐射效率。我建议的做法是如果用的是模块比如带陶瓷天线的模组尽量把模块放在板边天线区域下方和周围禁止铺铜如果自己画PCB天线严格按照芯片厂商的参考设计来包括走线宽度、匹配网络、净空区尺寸。别自己发挥射频电路不是靠感觉能调好的。竞赛现场我见过一个队伍把天线放在金属外壳里通信距离从50米直接降到3米这就是典型的射频禁忌。3. Nordic方案在高校项目中的适配逻辑3.1 为什么是Nordic而不是其他高校科创项目选无线方案核心诉求和工业项目不太一样。工业项目看重长期供货和认证齐全高校项目更看重开发门槛低、社区资源多、功耗表现好。Nordic的nRF系列在这几点上确实有优势。它的SDKnRF Connect SDK基于Zephyr RTOS虽然学习曲线比Arduino陡但一旦跑通后续扩展性很强。而且Nordic的文档和示例代码质量在业内口碑不错学生遇到问题容易找到参考。另一个关键点是协议支持。Nordic芯片同时支持BLE、Thread、Zigbee、Matter等多种协议这意味着一个项目可以从简单的BLE点对点通信起步后续升级到Mesh组网不需要换硬件。竞赛里很多队伍一开始用BLE后来发现需要多节点组网如果芯片不支持Thread或Zigbee就得重新选型时间根本来不及。3.2 开发环境搭建的坑与捷径nRF Connect SDK的安装是第一个拦路虎。官方推荐用VS Code nRF Connect扩展但国内网络环境下工具链下载经常卡住。我的经验是提前下载好离线工具链包或者用国内镜像源配置pip和west。另外Zephyr的构建系统对路径长度敏感Windows下建议把项目放在根目录附近比如C:\ncs\避免路径过长导致编译失败。还有一个容易被忽略的点J-Link调试器的固件版本。Nordic的DK板载J-Link固件如果太旧可能无法识别新的芯片型号。竞赛前一定要用nRF Connect for Desktop里的Programmer工具检查并更新固件。我见过队伍因为调试器固件问题比赛当天烧录不了程序直接弃赛。3.3 从竞赛作品看典型架构选型竞赛里获奖的作品架构通常很清晰。我总结了几种典型模式架构类型适用场景无线方案功耗表现开发难度点对点直连单设备数据采集BLE GATT低低星型组网多传感器汇聚BLE 网关中中Mesh组网大范围覆盖Thread/Zigbee中高高混合架构复杂场景BLE WiFi回传高高对于大多数高校项目星型组网是最务实的选择。一个网关可以用树莓派或手机负责收集多个节点的数据节点之间不需要通信逻辑简单调试容易。Mesh虽然听起来高级但路由维护、节点加入退出、网络自愈这些机制没有足够的时间调试很难做稳定。4. 无线组网方案从选型到落地的完整链路4.1 需求拆解先搞清楚你到底要连什么很多队伍一上来就选芯片、画板子这是本末倒置。正确的顺序是先明确数据量、通信频率、节点数量、覆盖范围、供电方式再倒推无线方案。举个例子如果你做的是食用菌栽培车间环境监控需要监测温度、湿度、二氧化碳浓度节点分布在几个大棚里每个节点每分钟上报一次数据节点用电池供电。那么关键参数就是数据量小几十字节、频率低每分钟一次、节点分散可能几十米到几百米、电池供电要求低功耗。这种情况下BLE就不太合适因为BLE的覆盖范围通常只有几十米而且星型组网需要网关在中心位置。更合适的是Sub-1GHz方案或者LoRa但LoRa的芯片选型和开发门槛又比BLE高。折中方案是用Nordic的802.15.4Thread做Mesh节点之间可以中继覆盖范围能扩展。4.2 信道规划与抗干扰的实际操作2.4GHz频段只有三个不重叠的信道1、6、11而BLE的广播信道固定在37、38、39正好落在WiFi信道1、6、11的间隙里。这个设计本来是为了避让WiFi但实际环境中WiFi的带外辐射仍然会干扰BLE。实操建议在部署前用频谱分析工具比如nRF Connect的RSSI Viewer扫描环境看看哪些信道最干净。如果条件允许把WiFi路由器的信道固定到1或11给BLE留出中间区域。另外BLE的连接信道有37个可以通过sd_ble_gap_conn_param_update调整跳频图案避开持续干扰的频点。4.3 数据吞吐量与连接间隔的平衡BLE的连接间隔Connection Interval直接决定吞吐量和功耗。间隔越短吞吐量越高但功耗也越大。Nordic的协议栈允许设置7.5ms到4s的间隔。对于传感器数据上报通常设置100ms到1s就够了。但如果你要传音频或图像就需要更短的间隔甚至考虑用BLE的2M PHY模式把物理层速率翻倍。这里有个计算公式有效吞吐量 ≈ (每个连接事件能传的包数 × 每包有效载荷) / 连接间隔。假设连接间隔100ms每个事件传4包每包20字节那么吞吐量大约是800字节/秒。对于大多数传感器应用这远远够用。但如果你要传固件升级包这个速度就太慢了需要考虑用Nordic的DFU服务它支持后台传输不影响正常数据通信。5. 竞赛级项目调试中那些文档不会写的事5.1 用RTT代替串口打印调试无线项目时串口打印是最常用的手段但串口本身会引入延迟而且占用引脚。Nordic的RTTReal-Time Transfer通过J-Link调试接口输出日志速度比串口快得多而且不占用UART资源。在nRF Connect SDK里启用RTT很简单在prj.conf里加上CONFIG_LOG_BACKEND_RTTy就行。但要注意RTT日志在射频活动频繁时可能会丢包因为调试接口和射频共享某些资源。如果发现日志不完整可以降低日志级别或者用RTT的阻塞模式。5.2 射频测试的简易方法没有专业频谱仪的情况下怎么评估射频性能一个土办法是用RSSI接收信号强度指示。Nordic的协议栈提供了ble_gap_rssi_get接口可以读取当前连接的信号强度。在固定距离下RSSI应该在-40dBm到-70dBm之间。如果低于-80dBm说明链路质量很差需要检查天线或调整发射功率。另一个方法是做丢包率测试。连续发送1000个包统计接收到的数量。如果丢包率超过5%就需要排查干扰源或调整连接参数。竞赛现场我建议提前做这个测试把数据记录下来答辩时也有说服力。5.3 电源管理的实战技巧低功耗不是靠一个函数就能搞定的需要系统级设计。首先把不用的外设全部关掉包括UART、SPI、I2C。其次合理使用Nordic的电源管理API比如nrf_pwr_mgmt_run它会在空闲时自动进入低功耗模式。第三传感器不要一直供电用MOS管控制电源需要采集时才上电。还有一个细节BLE的连接参数会影响功耗。如果从设备允许的延迟Slave Latency设置得大一些从设备可以在多个连接事件中不响应从而节省功耗。但延迟太大又会影响响应速度需要根据应用场景权衡。6. 从竞赛作品到产品化还有多远6.1 稳定性验证的缺失环节竞赛作品通常只验证了功能没有验证稳定性。产品化需要做长时间老化测试、高低温测试、电磁兼容测试。我建议学生在竞赛结束后至少做一轮72小时连续运行测试记录掉线次数、重启次数、数据丢失率。这些数据不仅能改进项目写在简历上也是加分项。6.2 固件升级与远程维护竞赛作品很少考虑固件升级但实际部署中设备装到现场后不可能每次都拆下来烧录。Nordic的DFUDevice Firmware Update服务支持通过BLE或UART升级固件而且支持双区备份升级失败可以回滚。这个功能在竞赛里用不上但如果你想把项目变成产品这是必须提前规划的。6.3 成本与供应链的现实考量竞赛用DK板无所谓成本但产品化必须考虑BOM成本。nRF52840的单价在几美元到十几美元之间取决于采购量。如果项目对成本敏感可以考虑nRF52810或nRF52811功能裁剪但核心射频性能一致。另外Nordic的芯片供货周期在疫情期间波动很大选型时要考虑替代方案避免单一供应商风险。7. 给下一届参赛者的几条实在建议第一别贪多。一个稳定的单节点方案比一个漏洞百出的Mesh网络得分更高。评委看的是完成度和技术深度不是功能列表的长度。第二提前做射频环境测试。比赛现场的条件和你实验室完全不同提前用RSSI工具扫一遍心里有数。第三功耗预算要留余量。理论计算和实际测量至少差30%电池容量按理论值的一半来选。第四文档和代码规范。竞赛答辩时评委可能会翻你的代码。变量命名清晰、注释完整、架构分层明确这些细节会影响印象分。第五多利用Nordic的开发者社区。Nordic的DevZone论坛响应速度很快很多问题已经有现成答案。提问时附上SDK版本、芯片型号、错误日志能更快得到帮助。我在实际带学生做物联网项目的过程中发现无线技术这一层入门容易精通难。但恰恰是这一层的功底决定了项目是演示级还是产品级。Nordic的芯片和工具链提供了很好的起点但最终能不能做出稳定的系统还是取决于你对射频、功耗、协议这些底层细节的理解深度。竞赛只是一个开始真正的学习发生在你反复调试、反复失败、反复改进的过程中。
1. 从一场大学生竞赛看无线技术如何真正落地全国大学生物联网设计竞赛这类赛事圈外人看是学生拿板子搭Demo圈内人看的是另一回事——它其实是无线技术从实验室走向真实场景的一次集中预演。2026年这届竞赛落幕之后我翻了不少参赛队伍的方案发现一个很明显的分水岭拿奖的队伍几乎都不是堆传感器数量最多的而是把无线连接这一层吃透了。Nordic作为长期深耕低功耗无线领域的芯片厂商这次深度参与赛事支持背后折射出的其实是整个物联网行业对连接稳定性这件事的重新重视。如果你正在做物联网相关的课程设计、毕业设计或者在企业里负责无线模块选型和组网方案这篇内容应该能帮到你。我会从竞赛里暴露出的真实技术问题切入把无线技术在高校科创项目中的典型用法、常见坑、选型逻辑讲清楚。不是泛泛而谈物联网很重要而是具体到芯片怎么选、协议怎么配、功耗怎么算、组网怎么调。这些内容在官方文档里往往一笔带过但实际做项目时恰恰是这些细节决定成败。先给一个基本判断物联网项目的三层架构——感知层、网络层、应用层——里最容易被低估的就是网络层。感知层无非是选传感器应用层无非是写界面但网络层涉及射频、协议栈、功耗管理、抗干扰任何一个环节出问题整个系统就是数据上不来或者跑两天就没电。竞赛里大量作品卡在这一层不是学生不努力而是无线技术的门槛确实藏在细节里。2. 竞赛作品里暴露的无线连接真实痛点2.1 为什么能连上和稳定连是两回事很多参赛队伍在答辩时演示很流畅但评委一走设备就开始掉线。这不是偶然。实验室环境和真实部署环境的射频条件差异巨大。实验室里路由器、蓝牙设备、WiFi热点密集2.4GHz频段本身就拥挤而竞赛现场往往有几十支队伍同时开机信道冲突几乎是必然的。我见过一个典型方案用BLE做数据传输手机App作为网关。单机测试时延迟20ms以内但现场同时有十几台设备广播时扫描响应时间直接飙到几百毫秒数据包丢失率超过15%。问题出在哪BLE的广播信道只有三个37、38、39所有设备都在抢这三个信道。解决方案不是换芯片而是调整连接参数——把广播间隔从默认的100ms拉长到300ms以上同时启用白名单过滤只允许已配对设备响应。这个改动让丢包率降到了3%以下。注意广播间隔不是越短越好。短间隔意味着更快的发现速度但也意味着更高的碰撞概率和功耗。实际项目中要根据设备密度动态调整。2.2 功耗预算算错项目直接短命另一个高频问题是功耗估算过于乐观。很多队伍用纽扣电池供电理论上算出来能跑半年实际两周就没电。原因通常有三个一是忽略了射频发射时的峰值电流Nordic的nRF52系列在发射时峰值可达十几毫安远超数据手册里的平均电流二是没有正确配置低功耗模式MCU一直在跑三是传感器轮询频率过高白白浪费能量。正确的做法是建立功耗预算表。以nRF52840为例睡眠模式电流约1.5微安接收模式约5毫安发射模式0dBm约6毫安。假设每秒发送一次20字节的数据包发射持续时间约1毫秒那么平均电流大约是睡眠电流 (发射电流 × 占空比) (接收电流 × 占空比)。算下来大概在几十微安级别这才有可能撑到半年以上。但如果你用的是连续扫描模式接收占空比接近100%那平均电流直接上到毫安级电池几天就没了。2.3 天线设计被忽视的代价竞赛里有个很普遍的现象队伍把无线模块焊在板子中央周围铺满铜皮和元件然后抱怨通信距离只有几米。这不是芯片的问题是天线被屏蔽了。PCB板载天线对周围环境极其敏感地平面大小、元件布局、外壳材质都会影响辐射效率。我建议的做法是如果用的是模块比如带陶瓷天线的模组尽量把模块放在板边天线区域下方和周围禁止铺铜如果自己画PCB天线严格按照芯片厂商的参考设计来包括走线宽度、匹配网络、净空区尺寸。别自己发挥射频电路不是靠感觉能调好的。竞赛现场我见过一个队伍把天线放在金属外壳里通信距离从50米直接降到3米这就是典型的射频禁忌。3. Nordic方案在高校项目中的适配逻辑3.1 为什么是Nordic而不是其他高校科创项目选无线方案核心诉求和工业项目不太一样。工业项目看重长期供货和认证齐全高校项目更看重开发门槛低、社区资源多、功耗表现好。Nordic的nRF系列在这几点上确实有优势。它的SDKnRF Connect SDK基于Zephyr RTOS虽然学习曲线比Arduino陡但一旦跑通后续扩展性很强。而且Nordic的文档和示例代码质量在业内口碑不错学生遇到问题容易找到参考。另一个关键点是协议支持。Nordic芯片同时支持BLE、Thread、Zigbee、Matter等多种协议这意味着一个项目可以从简单的BLE点对点通信起步后续升级到Mesh组网不需要换硬件。竞赛里很多队伍一开始用BLE后来发现需要多节点组网如果芯片不支持Thread或Zigbee就得重新选型时间根本来不及。3.2 开发环境搭建的坑与捷径nRF Connect SDK的安装是第一个拦路虎。官方推荐用VS Code nRF Connect扩展但国内网络环境下工具链下载经常卡住。我的经验是提前下载好离线工具链包或者用国内镜像源配置pip和west。另外Zephyr的构建系统对路径长度敏感Windows下建议把项目放在根目录附近比如C:\ncs\避免路径过长导致编译失败。还有一个容易被忽略的点J-Link调试器的固件版本。Nordic的DK板载J-Link固件如果太旧可能无法识别新的芯片型号。竞赛前一定要用nRF Connect for Desktop里的Programmer工具检查并更新固件。我见过队伍因为调试器固件问题比赛当天烧录不了程序直接弃赛。3.3 从竞赛作品看典型架构选型竞赛里获奖的作品架构通常很清晰。我总结了几种典型模式架构类型适用场景无线方案功耗表现开发难度点对点直连单设备数据采集BLE GATT低低星型组网多传感器汇聚BLE 网关中中Mesh组网大范围覆盖Thread/Zigbee中高高混合架构复杂场景BLE WiFi回传高高对于大多数高校项目星型组网是最务实的选择。一个网关可以用树莓派或手机负责收集多个节点的数据节点之间不需要通信逻辑简单调试容易。Mesh虽然听起来高级但路由维护、节点加入退出、网络自愈这些机制没有足够的时间调试很难做稳定。4. 无线组网方案从选型到落地的完整链路4.1 需求拆解先搞清楚你到底要连什么很多队伍一上来就选芯片、画板子这是本末倒置。正确的顺序是先明确数据量、通信频率、节点数量、覆盖范围、供电方式再倒推无线方案。举个例子如果你做的是食用菌栽培车间环境监控需要监测温度、湿度、二氧化碳浓度节点分布在几个大棚里每个节点每分钟上报一次数据节点用电池供电。那么关键参数就是数据量小几十字节、频率低每分钟一次、节点分散可能几十米到几百米、电池供电要求低功耗。这种情况下BLE就不太合适因为BLE的覆盖范围通常只有几十米而且星型组网需要网关在中心位置。更合适的是Sub-1GHz方案或者LoRa但LoRa的芯片选型和开发门槛又比BLE高。折中方案是用Nordic的802.15.4Thread做Mesh节点之间可以中继覆盖范围能扩展。4.2 信道规划与抗干扰的实际操作2.4GHz频段只有三个不重叠的信道1、6、11而BLE的广播信道固定在37、38、39正好落在WiFi信道1、6、11的间隙里。这个设计本来是为了避让WiFi但实际环境中WiFi的带外辐射仍然会干扰BLE。实操建议在部署前用频谱分析工具比如nRF Connect的RSSI Viewer扫描环境看看哪些信道最干净。如果条件允许把WiFi路由器的信道固定到1或11给BLE留出中间区域。另外BLE的连接信道有37个可以通过sd_ble_gap_conn_param_update调整跳频图案避开持续干扰的频点。4.3 数据吞吐量与连接间隔的平衡BLE的连接间隔Connection Interval直接决定吞吐量和功耗。间隔越短吞吐量越高但功耗也越大。Nordic的协议栈允许设置7.5ms到4s的间隔。对于传感器数据上报通常设置100ms到1s就够了。但如果你要传音频或图像就需要更短的间隔甚至考虑用BLE的2M PHY模式把物理层速率翻倍。这里有个计算公式有效吞吐量 ≈ (每个连接事件能传的包数 × 每包有效载荷) / 连接间隔。假设连接间隔100ms每个事件传4包每包20字节那么吞吐量大约是800字节/秒。对于大多数传感器应用这远远够用。但如果你要传固件升级包这个速度就太慢了需要考虑用Nordic的DFU服务它支持后台传输不影响正常数据通信。5. 竞赛级项目调试中那些文档不会写的事5.1 用RTT代替串口打印调试无线项目时串口打印是最常用的手段但串口本身会引入延迟而且占用引脚。Nordic的RTTReal-Time Transfer通过J-Link调试接口输出日志速度比串口快得多而且不占用UART资源。在nRF Connect SDK里启用RTT很简单在prj.conf里加上CONFIG_LOG_BACKEND_RTTy就行。但要注意RTT日志在射频活动频繁时可能会丢包因为调试接口和射频共享某些资源。如果发现日志不完整可以降低日志级别或者用RTT的阻塞模式。5.2 射频测试的简易方法没有专业频谱仪的情况下怎么评估射频性能一个土办法是用RSSI接收信号强度指示。Nordic的协议栈提供了ble_gap_rssi_get接口可以读取当前连接的信号强度。在固定距离下RSSI应该在-40dBm到-70dBm之间。如果低于-80dBm说明链路质量很差需要检查天线或调整发射功率。另一个方法是做丢包率测试。连续发送1000个包统计接收到的数量。如果丢包率超过5%就需要排查干扰源或调整连接参数。竞赛现场我建议提前做这个测试把数据记录下来答辩时也有说服力。5.3 电源管理的实战技巧低功耗不是靠一个函数就能搞定的需要系统级设计。首先把不用的外设全部关掉包括UART、SPI、I2C。其次合理使用Nordic的电源管理API比如nrf_pwr_mgmt_run它会在空闲时自动进入低功耗模式。第三传感器不要一直供电用MOS管控制电源需要采集时才上电。还有一个细节BLE的连接参数会影响功耗。如果从设备允许的延迟Slave Latency设置得大一些从设备可以在多个连接事件中不响应从而节省功耗。但延迟太大又会影响响应速度需要根据应用场景权衡。6. 从竞赛作品到产品化还有多远6.1 稳定性验证的缺失环节竞赛作品通常只验证了功能没有验证稳定性。产品化需要做长时间老化测试、高低温测试、电磁兼容测试。我建议学生在竞赛结束后至少做一轮72小时连续运行测试记录掉线次数、重启次数、数据丢失率。这些数据不仅能改进项目写在简历上也是加分项。6.2 固件升级与远程维护竞赛作品很少考虑固件升级但实际部署中设备装到现场后不可能每次都拆下来烧录。Nordic的DFUDevice Firmware Update服务支持通过BLE或UART升级固件而且支持双区备份升级失败可以回滚。这个功能在竞赛里用不上但如果你想把项目变成产品这是必须提前规划的。6.3 成本与供应链的现实考量竞赛用DK板无所谓成本但产品化必须考虑BOM成本。nRF52840的单价在几美元到十几美元之间取决于采购量。如果项目对成本敏感可以考虑nRF52810或nRF52811功能裁剪但核心射频性能一致。另外Nordic的芯片供货周期在疫情期间波动很大选型时要考虑替代方案避免单一供应商风险。7. 给下一届参赛者的几条实在建议第一别贪多。一个稳定的单节点方案比一个漏洞百出的Mesh网络得分更高。评委看的是完成度和技术深度不是功能列表的长度。第二提前做射频环境测试。比赛现场的条件和你实验室完全不同提前用RSSI工具扫一遍心里有数。第三功耗预算要留余量。理论计算和实际测量至少差30%电池容量按理论值的一半来选。第四文档和代码规范。竞赛答辩时评委可能会翻你的代码。变量命名清晰、注释完整、架构分层明确这些细节会影响印象分。第五多利用Nordic的开发者社区。Nordic的DevZone论坛响应速度很快很多问题已经有现成答案。提问时附上SDK版本、芯片型号、错误日志能更快得到帮助。我在实际带学生做物联网项目的过程中发现无线技术这一层入门容易精通难。但恰恰是这一层的功底决定了项目是演示级还是产品级。Nordic的芯片和工具链提供了很好的起点但最终能不能做出稳定的系统还是取决于你对射频、功耗、协议这些底层细节的理解深度。竞赛只是一个开始真正的学习发生在你反复调试、反复失败、反复改进的过程中。
