目前实现细节尚未成熟，协议版本号为v1

数据链路

• 设立了一个中间后台设备的目的如下：
• 设备目前处于开发初期，如果把大量数字调制解调逻辑和控制协议直接放在ESP32侧，而且不方便排查调试；
• 使用RK3568小板子可以利用相较ESP32更强的CPU性能，运行更复杂的FT8解码算法，解码出更多消息；
• 后台可以设置在内网，实现IQ原始采样数据的低延迟传输，并减小发射命令的时偏；前端通过远程中转/穿透等远程方式进行开发；后台与前端只传输必要的信息，并且可以容忍一定的延迟和卡顿；

后期可以考虑将后台控制端的部分简易解码功能转移至ESP32侧，简化通信链路；

• ESP32侧使用C语言编程；

• 后台控制侧使用Rust编程；

• 前端APP使用Flutter编程；

• 如果PC设备就位于内网，则可以直接在PC上同时启动后台和前端，实现近似PC直连ESP32的效果；

• 此外ESP32侧还额外有一套OTA固件空中升级机制，见文章最后描述。

电台控制交互协议

一、射频采样数据持续上报（UDP单播）

原本采用UDP广播，测试发现ESP32S3在持续多播和广播UDP消息时存在异常卡顿，遂改为单播

传输行为

数据内容

• I/Q信号传输模式
• 当电台被配置为IQ信号直采模式时，每个数据包长度固定为1356字节，交替放置了226对I/Q信号采样数据（形如IQIQIQ……IQIQIQ），每个数据占24bit，以小端法放置，每字节形如[I, I, I, Q, Q, Q, I, I, I, Q, Q, Q, … ]；
• 射频信号采集后将持续上报发送数据包，目前电台的ADC采样速率为48kHz，因此传输速率将持续在每秒228KB左右。

• 解调音频传输模式
暂未实现该模式

二、控制命令交互（UDP广播）

传输行为

• ESP-DX正常运行时，将持续监听局域网内1432端口的UDP广播消息，当消息格式符合要求时，将进行解析处理。

• ESP-DX正常运行时，将通过UDP发送广播消息到1532端口，实现控制命令回复，心跳状态上报，日志打印等内容的发送。

• 后台主控与电台直接的消息交互均使用下文统一规定的格式。

消息格式

• 第0~1字节作为保留字段，目前固定为0xE3、0x2D；

• 第2字节用于说明消息格式版本，目前为0x01

• 第3字节是消息类型，具体定义见下表，注意表中【类型】这一列使用的是十进制数字。

• 第4字节开始是实际消息内容，具体要求见下表

下表中： 方向为【请求】时，代表该类型消息只会由后台主控下发给电台； 方向为【响应】时，代表该类型消息是电台执行一定命令后回复给后台主控的； 方向为【主动发起】时，代表此类消息即便后台主控没有下发相关命令，也会定时上报或在某些工作场景中自动上报；

注意消息内容没有进行字节对齐，全部使用紧凑格式。

前后端交互协议（WebSocket）