企业官网建设流程全解析

一直做单片机项目的朋友应该都有这种感觉：设备一旦离开实验室，网络问题就变得特别现实。我之前接了一个远程设备监控的活儿，现场没有 WiFi，只有 4G 信号，于是开始认真评估怎么做联网。查了一圈，最后落到了这块 SIM7600G-H CAT4 4G (LTE) Shield for Arduino 上，它把 SIMCom 的 SIM7600G-H 模组、SIM 卡座、天线座、电源管理、串口电平转换都集成到了一块标准 Arduino 扩展板上，插上 UNO 或者 Mega 就能用。整个项目的核心就变成了“通过串口发 AT 指令”，对单片机开发者来说几乎是零门槛。这篇文章就把我从选型、硬件接线、AT 指令调通，到写一个带数据上报和指令下发的完整流程整理出来，特别是供电和网络注册这些坑，希望能帮你少走弯路。

1. 为什么选 SIM7600G-H CAT4 4G Shield 作为 Arduino 联网方案

1.1 SIM7600G-H 是一颗什么样的 4G 模组

SIM7600G-H 是 SIMCom 旗下的 LTE Cat 4 模组，支持 LTE-FDD、LTE-TDD、HSPA+、GSM/GPRS/EDGE 这些网络制式，频段覆盖非常广，比较常见的 LTE-FDD 频段 B1/B2/B3/B4/B5/B7/B8/B12/B13/B18/B19/B20/B25/B26/B28，以及 LTE-TDD 的 B38/B39/B40/B41 都在支持范围里，同时还内置 GNSS，可以输出 GPS/北斗/GLONASS 定位结果。理论上行速率 50Mbps，下行 150Mbps，对 Arduino 这种串口带宽根本跑不满，但好处是响应快、覆盖好，后期如果要升级成传输图片或者做远程固件下发，也不会被网络带宽卡住。

很多朋友会问，为什么不用 NB-IoT 或者 Cat.1？这个我后面单独说。单就这块 Shield 而言，它已经把模组本身最难搞的射频部分，也就是天线阻抗匹配、叠层走线、ESD 防护这些全处理好了，用户只需要把 SIM 卡插好、天线接上、串口连上，剩下的全是逻辑问题。我自己之前也试过自己画 4G 模组的最小系统，PCB 打样回来光搜网就花了两天，最后发现是天线馈线附近的地没处理好。所以如果目标是快速做产品原型或者项目验证，直接用这种 Shield 是最划算的。

1.2 CAT4、CAT1、NB-IoT 到底怎么选

关于通信制式的选择，我做了个表格，方便直接对比：

我的判断标准很简单：如果产品只上报几个字节，一天一次，NB-IoT 真的够用；如果要频繁上报、延迟要低，还要兼顾未来固件升级包下载，Cat.1 是性价比之选；而像我现在这个项目，不光要上报传感器数据，还要偶尔下传几十 K 的配置文件，更重要的是需要全国范围稳定漫游，Cat.4 显然更稳。再加上 SIM7600G-H 在国内主流运营商网络下都有完整频段支持，所以选它基本是“一次到位”的方案。

1.3 用 Shield 而不是自己搭模组电路

自己做 4G 电路最大的问题是射频和电源。LTE 的射频走线有严格的阻抗要求，天线位置、馈线长度、地平面切割都会影响灵敏度，别说是新手，就算有点 RF 经验的工程师也不敢保证一版搞定。另外 4G 模组发射时瞬态电流很容易冲到 2A，板子上的 DC-DC 电路、大电容、电源布局如果不合理，就会导致模组反复重启。Shield 的形态把这些问题全部屏蔽掉了，你只需要关心“供电电源能不能提供足够电流”和“串口电平是否匹配”，这两点我会在下一节详细讲。

2. 到手后的硬件准备与首次上电

2.1 板卡接口、跳帽和串口通道选择

拿到 Shield 以后，先别急着插 Arduino，先看清楚板子上的主要插座和跳帽。通常会有 DC 电源输入口、USB 接口（用于直接连接电脑调试）、4G 天线 SMA 座、GNSS 天线 SMA 座、SIM 卡座、UART 排针、PWRKEY 按键/排针，以及控制串口通道选择的跳帽。

不同厂商的 Shield，跳帽定义会有区别。我用的这块是默认通过排针连接 Arduino UNO 的数字口 D2/D3 作为软串口，如果你用 Mega，可以拨到硬件串口 Serial1。上电之前一定要确认跳帽位置，否则会出现“串口没反应”的假故障。我的习惯是先看原理图或者丝印，把跳帽对应通道记下来，再上电，避免反复插拔。

2.2 供电：最容易翻车的环节

这句我要说得非常绝对：不要指望 Arduino UNO 的 5V 引脚能直接带动 4G Shield。Arduino UNO 的 5V 来自 USB 或者板载稳压器，在 USB 供电时满打满算也就 500mA，而 SIM7600G-H 在注册网络、发送数据时峰值电流能到 1.5A 甚至 2A，电压一跌，模组就会反复重启，或者表现为 CSQ 信号极差、AT 无响应。后者的迷惑性很大，很多人以为是天线问题，其实是供电问题。

正确的做法是：用 5V/2A 以上的适配器，从 Shield 的 DC 电源口单独供电。如果现场只有 12V 电源，也可以从 Arduino 的 DC 口进，让 Arduino 的板载电路先降到 5V，再由 Shield 二次处理，但注意 Arduino 的稳压芯片持续供 2A 会很烫，不建议长期跑。我实测最省心的方案是实验室那套 5V/3A 直流电源，或者找一个质量好点的 5V/2A USB 适配器，直接怼到 Shield 的电源口，Arduino 再单独供电或由 Shield 的电源输出供给。

另外，在首次通电前一定要先把 4G 天线接上。空载不接天线不仅是信号差的问题，长期空载还可能损坏射频前端。GNSS 天线如果暂时不用可以不接，但 4G 主天线必须接。

2.3 SIM 卡安装与第一次开机

SIM 卡建议用 4G 物联网卡，或者运营商正常开通了数据业务的手机卡。插卡时把缺口对准卡座的斜角方向，用力推到底，听到清脆“咔嗒”声才算到位。常见的问题是 SIM 卡没完全插入，导致 AT+CPIN? 一直返回 ERROR 或者提示 SIM not inserted。

开机有两种方式：一种是直接按板上的 PWRKEY 键，按住 100ms 到 500ms；另一种是用 Arduino 的 GPIO 控制 PWRKEY 引脚，拉低几百毫秒再释放。我用 Arduino 控制时写了一个软开机函数，上电后先启动串口，再拉低 PWRKEY 引脚启动模组。开机后观察指示灯：一般 NETLIGHT 慢闪表示正在搜网，快闪表示已经注册到网络，不同厂商的 Shield 指示逻辑可能略有差异，最好翻一下对应的手册。

2.4 Arduino IDE 环境准备与扩展板适配

SIM7600G-H Shield 不需要额外的 Arduino 库，它就是一个串口设备，所以环境准备的核心是 Arduino IDE 本身。我用的是 1.8.19，稳定性比 2.x 在部分老电脑上好很多，如果你遇到 IDE 打不开的问题，可以先切回 1.8.x。开发板选择 Arduino UNO 或者 Mega，然后在项目里加载 SoftwareSerial 库即可。

如果后续想把主控换成 ESP32，要注意 ESP32 的 UART 电平是 3.3V，而一些 Shield 的 UART 可能按 5V 电平设计了，需要确认是否支持 3.3V 输入，或者加电平转换。用 ESP32 时可以直接用 Serial2 硬件串口连接 Shield，具体代码我会在第 4 节后面提一下。

3. 用 AT 指令打通 4G 数据链路

3.1 串口连接与基本通信

首次调试 4G Shield 时，我强烈建议先用 USB 线把 Shield 直接连电脑，用串口助手发 AT 指令，这样排查问题最快。等指令流程全部跑通了，再换回 Arduino 控制。如果你直接用 Arduino 发指令，建议先用最简单的透传程序：

#include <SoftwareSerial.h> SoftwareSerial sim(8, 7); // RX, TX void setup() { Serial.begin(115200); sim.begin(115200); delay(1000); sim.println("AT"); } void loop() { if (sim.available()) Serial.write(sim.read()); if (Serial.available()) sim.write(Serial.read()); }

这里有个细节：SoftwareSerial 的 RX 引脚要接 Shield 的 TX，TX 引脚接 Shield 的 RX，交叉连接，不要接反。如果你的 Arduino 是 Mega，建议用硬件串口 Serial1，因为 SoftwareSerial 在 115200 波特率下容易丢字节，除非把波特率降到 9600 或 57600。第一次通信如果出现乱码，优先检查波特率是否和 Shield 默认一致，一般默认 115200。

3.2 检查 SIM 卡、信号和网络注册状态

模组开机并连接串口后，按顺序执行这几条指令：

AT ATE0 AT+CPIN? AT+CSQ AT+CREG?

逐条解释一下实际意义：

• AT：握手，返回 OK 就说明串口链路通了。
• ATE0：关闭回显，否则后面指令看得心累。
• AT+CPIN?：检查 SIM 卡状态，返回 +CPIN: READY 表示卡已准备好；如果返回 ERROR，大概率是卡没插好或卡没开卡。
• AT+CSQ：查询信号强度，返回两个数字，比如 +CSQ: 18,99，第一个数字范围 0-31，越大信号越好，一般大于 12 就能正常联网，第二个 99 表示误码率未知，不用管。如果长期返回 0 或者 99，先检查天线和电源。
• AT+CREG?：网络注册状态，返回 +CREG: 0,1 表示注册到归属网络，0,5 表示漫游，0,3 表示网络拒绝。

我测试时遇到过一次比较奇怪的情况：CSQ 有 20，但 CREG 一直返回 0,2（正在注册中），排查半天发现是 SIM 卡的 APN 没有配置，虽然注册和 APN 不完全是一回事，但物联卡的套餐状态也会影响注册结果。后来换了正确的 APN 并激活 PDP 上下文后，CREG 马上变 1。

3.3 配置 APN 并激活 PDP 上下文

4G 拨号最核心的一步，是在模组上定义 PDP 上下文。不同运营商、不同物联网卡的 APN 都不一样，常见的有 cmnet、cmiot、ctnb 等，具体要问卡商。配置指令如下：

AT+CGDCONT=1,"IP","你的APN" AT+CGACT=1,1 AT+CGATT?

• AT+CGDCONT=1,"IP","APN"：定义编号为 1 的 PDP 上下文，协议类型 IPv4，APN 按实际替换。
• AT+CGACT=1,1：激活这个上下文，如果返回 OK，说明拨号成功。
• AT+CGATT?：查询是否附着到 GPRS/LTE 网络，返回 +CGATT: 1 就是已经附着。

这一步如果返回 ERROR，先执行 AT+CGDCONT? 查看当前上下文，确认是否本来就有残留配置，有的话先 AT+CGDCONT=1 删除再重建。另外，不要小看 APN 这个问题，我之前用一张测试卡，卡商给的文档里写的是自定义 APN，结果我一路默认 cmnet，怎么都激活不了，换了自定义 APN 之后秒成功。

3.4 用 HTTP 指令完成一次真实的数据上报

网络打通以后，最直接的应用就是 HTTP 上报。SIM7600 系列通常有传统 HTTPAT 指令和简化版 HTTPCLIENT 指令。传统流程比较繁琐，但兼容性好：

AT+HTTPTERM AT+HTTPINIT AT+HTTPPARA="CID",1 AT+HTTPPARA="URL","http://your-server.com/api/upload" AT+HTTPPARA="CONTENT","application/json" AT+HTTPDATA=64,10000

AT+HTTPDATA 后面两个参数分别是要发送的 JSON 数据长度（字节）和等待数据的超时时间（毫秒）。执行后模组会返回一个>提示符，此时把 JSON 数据一次性发过去，比如：

{"device":"sim7600","temp":25.6}

发送完成后模组返回 OK，接着执行：

AT+HTTPACTION=1

HTTPACTION 的参数 1 代表 POST 请求，0 是 GET，2 是 HEAD。这条指令会阻塞直到服务器响应，返回的格式类似+HTTPACTION: 1,200,24，其中 200 就是 HTTP 状态码，24 是响应体长度。最后用 AT+HTTPREAD 读取服务器返回内容。

如果你手里的固件版本比较新，可以使用更简洁的 AT+HTTPCLIENT 指令，一条命令就能完成 GET 请求。POST 也可以，但要注意 JSON 里的引号需要转义。我建议优先用传统 AT+HTTPINIT 流程，因为网上能找到的参考多，问题排查也容易；HTTPCLIENT 虽然短，但不同固件对参数的解析差异比较大。

3.5 用 Arduino 实现一个 60 秒心跳上报

把上面的 AT 指令封装成 Arduino 函数，就可以做一个最小的心跳程序。核心思路是：初始化串口 -> 启动模组 -> 等待 CPIN READY -> 配置 APN -> 激活 PDP -> 每 60 秒执行一次 HTTP POST。我写了一个精简版供参考：

#include <SoftwareSerial.h> SoftwareSerial sim(8, 7); const char apn[] = "cmiot"; const char url[] = "http://your-server.com/api/heartbeat"; void sendAT(const char* cmd, unsigned long wait = 2000) { sim.print(cmd); sim.print("\r\n"); unsigned long t = millis(); while (millis() - t < wait) { while (sim.available()) Serial.write(sim.read()); } } void setup() { Serial.begin(115200); sim.begin(115200); pinMode(9, OUTPUT); digitalWrite(9, HIGH); delay(1000); digitalWrite(9, LOW); // PWRKEY 拉低启动模组 delay(500); digitalWrite(9, HIGH); delay(5000); // 等模组启动 sendAT("AT"); sendAT("ATE0"); sendAT("AT+CPIN?"); sendAT("AT+CSQ"); sendAT("AT+CGDCONT=1,\"IP\",\"cmiot\""); // 改成你的 APN sendAT("AT+CGACT=1,1"); } void loop() { sendAT("AT+HTTPTERM"); sendAT("AT+HTTPINIT"); sendAT("AT+HTTPPARA=\"CID\",1"); sendAT("AT+HTTPPARA=\"URL\",\"http://your-server.com/api/heartbeat\""); sim.println("AT+HTTPACTION=0"); delay(8000); sendAT("AT+HTTPREAD"); delay(60000); }

这个代码只做演示，实际项目需要解析 AT 指令的返回值，不能像这样只发送不校验。我写代码时习惯把每个 AT 步骤封装成“发送-等待-断言返回值”的函数，比如expectOK()，这样可以快速定位故障在哪一步。

4. 实战案例：温湿度远程监控与指令下发

4.1 项目需求与硬件连接

这批项目要做的是：室外设备箱里的温湿度实时监测，设备没有网线，只能走 4G，云端平台需要每 5 分钟看到一次数据，同时支持远程下发一个“重启设备”的指令。最终的硬件清单是：

• Arduino UNO 一块
• SIM7600G-H CAT4 4G (LTE) Shield for Arduino 一块
• DHT22 温湿度传感器一个，数据脚接 D4
• 5V/3A 电源适配器一个
• 继电器模块一个，控制被监控设备供电，控制脚接 D6

连接时注意 DHT22 的 VCC 接 5V，GND 接 GND，DATA 接 D4，并在 DATA 与 VCC 之间接一个 10k 上拉电阻。继电器模块的 VCC 接 Arduino 5V，GND 接 GND，IN 接 D6。整块板子的电源由 5V/3A 适配器从 Shield 电源口进入，Shield 再给 Arduino 供电，这样从上电顺序上就保证了 4G 模组优先拿到足够的电流。

4.2 数据上报协议设计

上报数据我用了 JSON，简单明了，服务器端和调试时都容易看。格式如下：

{"device_id":"box001","type":"env","temp":26.3,"humi":58.2}

服务器处理完上报请求后，返回一个 JSON，告诉设备有没有待执行的指令：

{"cmd":"reboot","param":0}

设备解析到 cmd 字段是 reboot，就拉高继电器引脚，断开设备电源 5 秒，再重新闭合。这个“服务器下行指令”的设计其实包含在上报的响应里，避免了 Arduino 端做 TCP 长连接，资源占用小，逻辑也简单。对延迟要求不高的控制类场景，这种“轮询＋响应”的模式非常实用。

4.3 Arduino 端核心代码与关键注释

核心代码分成三个部分：DHT22 采集、SIM7600G-H 初始化、上报与指令执行。我先说初始化部分，因为这部分对稳定性影响最大。我封装了一个waitForReady函数，循环发 AT 直到模组返回 OK，超时 10 秒就报错，这样可以避免上电时序不稳定导致的偶发失败。

上报部分我做了数据长度动态计算，因为 AT+HTTPDATA 需要知道 JSON 长度。注意不要直接用 Arduino 的 String 类拼接超长字符串，UNO 内存只有 2KB，稍微复杂点的 JSON 就爆了。建议用 snprintf 拼到 char 数组里，再算 strlen 传给 HTTPDATA。

下面是节选代码：

#include <SoftwareSerial.h> #include <DHT.h> SoftwareSerial sim(8, 7); DHT dht(4, DHT22); char apn[] = "cmiot"; char server[] = "http://your-server.com/api/upload"; void sendCommand(const char* cmd, const char* expect, unsigned long timeout) { sim.print(cmd); sim.print("\r\n"); unsigned long t = millis(); char buf[64] = {0}; int idx = 0; while (millis() - t < timeout) { while (sim.available()) { char c = sim.read(); buf[idx++] = c; if (idx >= 63) idx = 63; } } if (strstr(buf, expect) == NULL) { Serial.print("FAIL: "); Serial.println(cmd); } } void setupModule() { pinMode(9, OUTPUT); digitalWrite(9, HIGH); delay(800); digitalWrite(9, LOW); delay(600); digitalWrite(9, HIGH); delay(6000); sendCommand("AT", "OK", 3000); sendCommand("ATE0", "OK", 2000); sendCommand("AT+CPIN?", "READY", 5000); sendCommand("AT+CSQ", "OK", 2000); sendCommand("AT+CGDCONT=1,\"IP\",\"cmiot\"", "OK", 3000); sendCommand("AT+CGACT=1,1", "OK", 8000); sendCommand("AT+CGATT?", "1", 3000); }

完整代码不在这里全贴，但结构就是“采集 -> 拼 JSON -> HTTP POST -> 读响应 -> 解析 cmd -> 执行动作”。我建议你在 PC 串口助手上先把 AT 指令流程跑一遍，再烧进 Arduino，会发现调试效率高很多。

4.4 从云端下发指令的实现细节

因为我选择了“轮询响应”方案，服务器端只需要在收到 POST 请求返回时携带指令。Arduino 端解析响应时，我用了一个简单的字符串查找，比如找到"cmd":"reboot"就执行重启逻辑。这种解析方式不严谨，但项目够用。如果你有多个指令，建议用 JSON 解析库，比如 ArduinoJson，但注意 UNO 内存有限，选 5.x 版本，并且配置好缓存大小。

指令执行我做了两层保护：第一层，判断响应的 HTTP 状态码是不是 200，否则不做任何动作；第二层，只在连续两次上报都返回同一个非空指令时才执行，避免网络瞬时干扰造成误动作。

4.5 如果换成 ESP32 该怎么做

项目做到后面，客户提了一个需求：能不能在设备端缓存 24 小时的历史数据，方便断网时本地存储。Arduino UNO 的 Flash 和 RAM 都不够，我就把主控换成了 ESP32。硬件连接上，ESP32 的 UART2 接 Shield：GPIO16 作为 RX 接 Shield 的 TX，GPIO17 作为 TX 接 Shield 的 RX，如果是 3.3V 的 Shield 没问题，否则中间加电平转换。核心代码里只需要把 SoftwareSerial 换成 Serial2，初始化方式如下：

Serial2.begin(115200, SERIAL_8N1, 16, 17);

其他的 AT 指令流程完全复用。ESP32 的好处是可以用多个任务，一个任务跑网络上报，一个任务跑传感器轮询，还能用 SPIFFS 存储断网数据，整体架构会舒服得多。

5. 常见问题与排查技巧实录

5.1 模块不启动，指示灯不亮

遇到这种情况先不要怀疑模块坏了，我统计下来 90% 是电源问题。检查顺序如下：

• 供电电源是否真的插在 Shield 的 DC 口，而不是 Arduino 的 USB 口。
• 电源是否达到 5V/2A，很多廉价 USB 适配器标称 2A，实际带载就掉压。
• PWRKEY 是否按够时间，如果用手动按键，至少按 1 秒再松开；如果用 Arduino 控制，拉低时间不要小于 500ms。
• 如果所有电源都没问题，把 Shield 单独接 USB 到电脑，看有没有新增串口设备。如果 USB 枚举都失败，可能是板子硬件问题。

5.2 串口有输出但 AT 无响应或乱码

AT 完全无响应最常见的是 TX/RX 接反。Shield 的 UART 排针丝印一般是 “TXD” 和 “RXD”，Arduino 的 TX 接 Shield 的 RXD，Arduino 的 RX 接 Shield 的 TXD。很多人习惯按引脚名“同名相连”，结果弄反了。

乱码的情况主要分两种：一种是波特率不对，SIM7600G-H 默认 115200，但也有厂商改成了 9600；另一种是电平不匹配，部分 Shield 的串口是 3.3V 逻辑，Arduino UNO 的 5V 逻辑直接接进去可能造成识别异常，这时候最好加一个双向电平转换模块。

5.3 信号差、CSQ 低、搜不到网

先说结论：搜不到网优先怀疑天线，信号差优先怀疑电源。具体排查步骤：

• 确认 4G 天线已接好，并且尽量远离金属外壳和 Arduino 板上的排针排母。
• 确认 SIM 卡已开通 4G 数据业务，物联网卡还要确认套餐没有停机。
• 用 AT+COPS? 查看当前运营商，如果返回运营商名称，说明已经注册；如果返回空，可以试 AT+COPS=0 让它自动选网。
• 在室内调试时信号经常只有一格，可以把天线放在窗边，或者换成吸盘天线延长馈线到室外。

我之前踩过一个很隐蔽的坑：Shield 上同时有 LTE 主天线和分集天线两个座，我误把 GNSS 天线当主天线插上，结果 CSQ 只有 5，换成配套的 LTE 天线后马上到了 18。

5.4 HTTP 请求超时或一直返回错误

HTTP 请求失败时，先按顺序检查基础状态：

• AT+CGATT? 是否返回 1，如果没有，说明还没附着到 LTE 网络，先解决上网问题。
• AT+CGACT? 是否返回 1，PDP 上下文没激活的话 HTTP 肯定起不来。
• 如果确认网络已激活，可以用 AT+HTTPPARA="URL","http://8.8.8.8" 这种纯 IP 的地址做测试，排除 DNS 解析问题。
• 域名测试 OK，但 HTTP 超时，检查服务器是否允许公网访问，80/8080 端口是否通。

还要强调一点：AT+HTTPDATA 发送数据时，长度参数必须准确，如果你告诉模组要发 64 字节，实际只发了 60 字节，它就会一直等着，直到超时。我建议在代码里用 snprintf 后立刻计算 length，不要手动换算。

5.5 GNSS 定位一直无数据

如果这个项目需要定位，一定要分清 GNSS 天线和 4G 天线不能混用。GNSS 天线有源供电，通常需要模组的 GNSS 天线馈电引脚供电，Shield 上一般已经处理好。冷启动状态下，在室内基本定不了位，需要靠近窗户或者室外空旷处，等待时间 1-3 分钟。常见的 AT 指令是：

AT+CGNSPWR=1 AT+CGNSSINF

其中 CGNSSINF 返回的是 NMEA 语句或者解析后的坐标格式，取决于固件版本。如果一直不返回，先确认天线是否接对，再用 AT+CGNSSPWR=0 关闭电源，重启后重新打开。

5.6 常见问题速查表

我把上面这些经验整理成一张表，方便现场照着查：

关于这套方案，我自己在项目里最深的体会是：4G 模块不是“单片机外设”那种简单的芯片，它有自己的电源时序、网络状态机和协议栈，所以调试时不要怕慢，一步一步用串口助手把 AT 指令流程跑透，再移到 Arduino 上，看起来绕路，实际是最快的路径。如果你也想用 SIM7600G-H CAT4 4G (LTE) Shield for Arduino 做联网项目，我的建议是前期别急着写代码，先把手上的卡、天线、电源这三样基础条件确认到位，后面所有问题都会简单很多。