时间过得很久吗,这不是七月初的事情,还不到一个月呢,怎么资料就丢了
小时候住在某国家基准气象站旁,每天都能够迎着朝阳看着气球飞往天空。
从那时起,我就对天空充满了向往。
前几年浏览科创,看到了爱好者自己放飞的气球,算是埋下了种子。
年中的时候逐渐闲了下来,翻找SSDV的资料时又看到了业余无线电爱好者放飞的气球。
气象气球可以携带载荷进入介于阿姆斯特朗极限和卡门线之间的“近太空”。
在这个高度下,地球的弧度隐约的开始可以被观察到。
这是很多人一生难以企及的高度,我想去看看。
恰好,风信子卫星项目的部分设计也需要以某种方式进行验证,气球计划由此提上日程。
2025年5月,风信子气球开始进入论证。这正好是“星火计划”开展后的第十年。
同样,我们先从合规性入手:
依据《升放气球管理办法》[1]第二条之定义,本次实验中所升放的气球不属于相关部门的管辖范畴,依法免于进行报备。
为避免潜在的法律风险,我们后续向气象部门进行了咨询,被告知载荷传感器数据可能属于气象数据。
随后我提交了“其他部门、组织或个人新建、迁移、撤销气象台站及临时气象观测备案”。
(最后反倒惹了麻烦,详见第七章)
另外,气球还利用业余无线电频率开展了数字通信实验,依照《业余无线电台管理办法》[2]等相关法律法规,我们在试验前进行了技术参数公开工作。 [3]
考虑到气球预定发射地点为海南省沿岸地区,高空气象环境复杂,四面环海。
我们连续多日基于高空风场气象数据进行了轨迹仿真计算,结果表明回收概率极低。[4]
图:论证期间某日的轨迹仿真计算
显然,数据并不能寄希望于通过回收来获取。
这就要求包括图片在内的所有系统运行数据均应通过无线链路进行回传。
结合任务性质与资源条件,确定本次飞行应满足如下约束目标:
飞行高度(设计)应大于 10000 米
载荷重量应小于等于 100 克
单次放飞成本应小于 500 元
具备无线数据回传功能
具备命令远程上注功能
具备上行命令安全特性
具备 GNSS 定位系统
具备可配置成像能力
具备半双工数字中继
应验证上下行链路的可靠性
应验证测控系统理论计算的准确性
应验证风信子卫星星务软件架构的设计可靠性
应验证热控制的可靠性
其他,略……
任务整体工作应围绕如上约束有序开展。
任务设计的硬件方面主要分为气球与载荷两个系统,相互约束,相互配合。
初期调研时拟选定采用中国化工株洲橡胶研究设计院(原化工部乳胶工业研究所)生产的70寸气象气球,气象专用技术装备型号“100克”,编号“SXZ-14-2014”。参数如下:
参数名称 | 数值 | 单位 |
|---|---|---|
气球重量 | 100 – 118 | g |
球柄长度 | ≥ 8 | cm |
球柄直径 | ≤ 4.5 | cm |
球体长度 | 75 – 85 | cm |
水平直径 | 48 – 54 | cm |
爆破直径 | > 180 | cm |
充气检查直径 | ≥ 122 | cm |
球柄举力 | 410 | g |
净举力 | 160 | g |
总举力 | 260 | g |
推荐充气量 | 0.15 – 0.20 | m³ |
平均升速 | 200 | m/min |
平均升空高度 | 15000 | m |
依据此参数进行计算并查阅相关文献,对载荷质量得出初步约束,以小于80克为宜。[5][6]
载荷方面,为加快开发进度,主要功能单元均选用 COTS 成品模块。
综合成像与控制需求,选用 ESP32 CAM 作为主控单元,在负责系统事务外负责摄影。配备原生支持 JPEG 的 OV2640 摄像头,减轻综合算力负担。
图:ESP32 CAM 开发板
为满足图像数据的高速率回传需求,通信链路选用基于 SI4463 的 HC-12 无线模块。
该模块使用 GFSK 调制模式,提供了较为可观的速率与灵敏度,稳定、高效,适用于本任务所要求的中长距离高速回传场景。
图:HC-12 技术参数[7]
出于重量与体积限制,使用缩短弹簧天线,安装后为垂直极化。
为评估系统性能,我们基于以下参数进行通信链路预算:
接收与发射频率:435.4MHz
气球端发射功率:20 dBm
气球端天线增益:2 dBi
地面站天线增益:10 dBi
地面站解调门限:-111 dBm
根据自由空间路径损耗模型进行计算:
接收功率:
链路余量:
初步计算表明,该链路在理想自由空间传播条件下具备可观系统裕度,在实际飞行中,能够有效抵抗信号传播中的突发衰落、干扰、极化扭转等问题。
GNSS 则在经过调研后,决定选用 ublox 生产的MAX-M10S,该款芯片性能较好,功耗较低,同时其COCOM限制为and型,即在同时触发速度大于500m/s和高度大于80km的限制后才会进入锁定状态。具体参数如下:
表:MAX-M10S 性能参数与技术规格[8][9]
另外,考虑到重量约束,采用了 All in one 的软硬件设计模式,将所有功能系统集中化处理。
图:载荷 PCB
ESP32等部分元器件需使用DC 5V供电,为保证系统运行稳定,设计 DC-DC 电路进行升压,通过内电层进行 5V 总线供电:
图:DC-DC升压电路
经测试,电压、纹波、效率、功率及电路保护均达到设计指标要求。后期因成本等因素更换为市售成品 DC-DC 模块。
图:简单的分压测量
图:完整组装3D图
硬件完整组装后,整体质量仅为 65 克。
(抱歉载荷没怎么拍照,现在实在找不到照片了)
图:组装好的载荷
虽然轨迹仿真计算表明落点位于陆地的概率极低,但为保证安全,我们配备了一个50cm直径降落伞,伞重8克。
使用终端速度公式进行估算:
理论终端速度为 1.88m/s ,属于安全范畴。
随后使用挂载重物的方法进行测试,实际终端速度约为3.4m/s,较预期偏高。推测是释放高度较低,伞未完全展开并建立稳定气流阻力。后续以展开状态释放进行测试,终端速度为2.1m/s,虽未达到理论效果,但整体属于安全范畴。
载荷主程序架构以风信子卫星的星务程序架构为基础,以验证其设计可靠性。为适应气球功能,进行了部分迁移修改与任务整合,最后分为五个 RTOS 任务,分层负责相关工作:
P5 数据链路,以队列方式处理无线电数据收发
C++// 定义数据链路层任务 (P5 - 最高优先级)
void V_Datalink_Task(void *pvParameters) {
// 初始化帧缓冲区
RadioPacket_t txPacket;
static char frame_buffer[MAX_RX_BUFF_SIZE];
static int frame_len = 0;
// 将当前任务加入 WDT 监控 (注册看门狗)
esp_task_wdt_add(NULL);
for (;;) {
// 标志位,记录本轮循环是否处理任何收发任务
bool task_did_work = false;
// 喂狗
esp_task_wdt_reset();
// 优先处理发送任务
if (xQueueReceive(txQueue, &txPacket, pdMS_TO_TICKS(10)) == pdTRUE) {
// 更新标志位
task_did_work = true;
// 从队列中获取数据包并写入串口
Serial.write(txPacket.data, txPacket.length);
}
// 然后看看串口是否有数据,处理接收和分发
if (Serial.available()) {
// 更新标志位
task_did_work = true;
// 读取串口数据
while (Serial.available()) {
char c = Serial.read();
// 检查帧尾 (换行符)
if (c != '\n') {
if (frame_len < MAX_RX_BUFF_SIZE - 1) {
frame_buffer[frame_len++] = c;
} else {
// 缓冲区已满但未收到换行符,丢弃此帧,防止解析错误
frame_len = 0;
}
}
// 如果收到换行符,说明一帧数据接收完毕
else {
// 添加字符串结束符
frame_buffer[frame_len] = '\0';
// 判断帧类型并分发到对应的队列
if (frame_len > 2) {
// 指令帧 (@@)
if (strncmp(frame_buffer, "@@", 2) == 0) {
xQueueSend(cmdQueue, &frame_buffer[2], 50);
}
// 中继帧 (##)
else if (strncmp(frame_buffer, "##", 2) == 0) {
// 获取当前系统状态的副本
SystemStatus_t local_status;
GET_System_Status(&local_status);
// 如果中继功能已启用且没有正在进行 SSDV 传输,则将数据包转发到中继队列
if (local_status.isRelayEnabled && !local_status.isSsdvTransmitting) {
xQueueSend(relayQueue, &frame_buffer[2], 50);
}
}
}
// 强制性让出 CPU 时间片,以进行指令解析
vTaskDelay(pdMS_TO_TICKS(10));
// 重置帧缓冲区,准备接收下一帧
frame_len = 0;
}
}
}
// 如果既没有发送任务,也没有接收到数据,则短暂挂起,让出CPU
if (!task_did_work) {
vTaskDelay(pdMS_TO_TICKS(10));
}
}
}P4 指令处理,验证处理指令队列中的控制指令
C++/* 其余子函数略 */
// 执行命令
void Process_Command(const char *cmd) {
// 初始化命令缓冲区
char buffer[MAX_RX_BUFF_SIZE];
strncpy(buffer, cmd, sizeof(buffer));
buffer[MAX_RX_BUFF_SIZE - 1] = '\0';
// 解析命令字段
char *type = NULL;
char *target = NULL;
char *value = NULL;
char *password = NULL;
// 查找最后一个逗号,从末尾提取密码
char *last_comma = strrchr(buffer, ',');
if (last_comma != NULL) {
*last_comma = '\0';
password = last_comma + 1;
} else {
Transmit_Status(CMD_NACK_FORMAT_ERROR);
return;
}
// 检查密码是否正确
if (strcmp(password, "<Password>") != 0) {
Transmit_Status(CMD_NACK_INVALID_PWD);
return;
}
// 使用 strtok_r 从字符串开头解析剩余部分
char *saveptr;
type = strtok_r(buffer, ",", &saveptr);
target = strtok_r(NULL, ",", &saveptr);
value = strtok_r(NULL, ",", &saveptr);
// 检查命令格式是否正确
if (!type || !target) {
Transmit_Status(CMD_NACK_FORMAT_ERROR);
return;
}
// 查询类命令
if (strcmp(type, "GET") == 0) {
Handle_GET_Command(target);
return;
}
// 其余函数需要 Value 字段
if (!value) {
Transmit_Status(CMD_NACK_NO_VALUE);
return;
}
// 控制类命令
else if (strcmp(type, "CTL") == 0) {
Handle_CTL_Command(target, value);
return;
}
// 设置类命令
else if (strcmp(type, "SET") == 0) {
Handle_SET_Command(target, value);
return;
}
// 未定义的命令
else {
Transmit_Status(CMD_NACK_INVALID_TYPE);
return;
}
}
// 指令解析任务 (P4 - 较高优先级)
// 指令格式:@@<Type>,<SubType>,<Value>\n
void V_Command_Task(void *pvParameters) {
// 初始化指令缓冲区
char cmd_buffer[MAX_RX_BUFF_SIZE];
// 将当前任务加入 WDT 监控 (注册看门狗)
esp_task_wdt_add(NULL);
for (;;) {
// 喂狗
esp_task_wdt_reset();
// 从指令队列中等待消息,如果1000ms内没有消息,会自动超时返回
if (xQueueReceive(cmdQueue, cmd_buffer, pdMS_TO_TICKS(1000))) {
Process_Command(cmd_buffer);
}
}
}P3 基本遥测,采集全系统基本情况并组帧发送
C++// 构建类 UKHAS 格式的遥测数据帧
// $$CALLSIGN,Telemetry_Counter,Time,Latitude,Longitude,Altitude,Speed,Sats,Heading,Temprature,Voltage,GPS_Validity
void Build_Telemetry_Frame(char GPS_Validity) {
// 读取芯片温度
float Chip_Temp = Get_Chip_Temperature();
// 读取电池电压
float BAT_Voltage = Get_Battery_Voltage();
// 调试模式:构建一个不依赖 GPS 的调试遥测帧
if (DEBUG_MODE) {
snprintf(TelemetryMessage, sizeof(TelemetryMessage),
"$$%s,%d,DEBUG_MODE,0.000000,0.000000,0.00,0.00,0,0.00,%.2f,%.2f,%c",
CALLSIGN, Telemetry_Counter, Chip_Temp, BAT_Voltage, GPS_Validity
);
Telemetry_Counter += 1;
return;
}
// 拼装 ISO 格式的 UTC 时间戳,如 2006-10-12T05:20:00Z
snprintf(GPS_Timestamp, sizeof(GPS_Timestamp),
"%04d-%02d-%02dT%02d:%02d:%02dZ",
gps.date.year(), // 年
gps.date.month(), // 月
gps.date.day(), // 日
gps.time.hour(), // 时
gps.time.minute(), // 分
gps.time.second() // 秒
);
// 拼装类 UKHAS 格式的遥测字符串
snprintf(TelemetryMessage, sizeof(TelemetryMessage),
"$$%s,%d,%s,%.6f,%.6f,%.2f,%.2f,%d,%.2f,%.2f,%.2f,%c",
CALLSIGN, // 呼号
Telemetry_Counter, // 帧数
GPS_Timestamp, // 时间
gps.location.lat(), // 纬度
gps.location.lng(), // 经度
gps.altitude.meters(), // 高度
gps.speed.kmph(), // 速度
gps.satellites.value(), // 卫星数
gps.course.deg(), // 航向角
Chip_Temp, // 摄氏度
BAT_Voltage, // 电压值
GPS_Validity // 有效性
);
Telemetry_Counter += 1;
}
// 遥测发送任务 (P3 - 中等优先级)
void V_Telemetry_Task(void *pvParameters) {
// 将当前任务加入 WDT 监控 (注册看门狗)
esp_task_wdt_add(NULL);
for (;;) {
// 先喂狗
esp_task_wdt_reset();
// 尝试获取 GPS 更新
int retries = 0;
char GPS_Validity = 'V';
while (retries < 3) {
// 尝试从串口读取 GPS 数据
while (GPS_Serial.available()) {
gps.encode(GPS_Serial.read());
}
// 位置有更新则停止重试
if (gps.location.isUpdated()) {
GPS_Validity = 'A';
break;
}
// 如果没有更新,等待1秒后重试
retries++;
vTaskDelay(pdMS_TO_TICKS(1000));
}
// 喂狗
esp_task_wdt_reset();
// 重试结束后,无论 GPS 是否更新,都构建并发送遥测帧
Build_Telemetry_Frame(GPS_Validity);
Transmit_Text("%s", TelemetryMessage);
// 每 20 秒发送一次遥测数据
vTaskDelay(pdMS_TO_TICKS(20000 - 3000));
}
}P2 图像传输,驱动摄像头进行拍摄并调制发送
SSDV 部分,请参见:SSDV——面向不可靠信道的数字图像传输设计[10]
C++/* 功能代码略 */
// 图像回传层任务 (P2 - 较低优先级)
void V_SSDV_Task(void *pvParameters) {
// 初始化图像帧缓冲区
camera_fb_t *fb = NULL;
// 将当前任务加入 WDT 监控 (注册看门狗)
esp_task_wdt_add(NULL);
for (;;) {
// 喂狗
esp_task_wdt_reset();
// 获取当前系统状态的本地副本
SystemStatus_t local_status;
SystemConfig_t local_config;
GET_System_Status(&local_status);
GET_System_Config(&local_config);
// 检查任务启用状态
if (!local_status.isSsdvEnabled) {
vTaskDelay(pdMS_TO_TICKS(5000));
continue;
}
// 更新状态,发送 "START" 信号,开始处理流程
Update_System_Status(SSDV_TRANSMITTING_STATUS, true);
Transmit_Status(SSDV_ENCODE_START, ssdvImageId);
// 根据预设模式选择图像源
uint8_t preset_mode = local_config.ssdvPresetMode;
if (preset_mode >= 1 && preset_mode <= 3) {
SSDV_Preset_Mode(preset_mode, &local_config);
} else {
SSDV_Camera_Mode(&local_config);
}
// 然后等待发送队列被完全清空
while (uxQueueMessagesWaiting(txQueue) > 0) {
vTaskDelay(pdMS_TO_TICKS(200));
esp_task_wdt_reset();
}
// 图像编码并发送完成,发送结束标识,并附带图像编号
Transmit_Status(SSDV_ENCODE_END, ssdvImageId - 1);
// 增加一个额外的延时,以确保物理串口的硬件发送缓冲区有足够的时间将最后一个数据包完全发出。
// 对于 9600 波特率,发送一个 256 字节的数据包大约需要 256 * 10 / 9600 ≈ 267ms。
// 因此,一个 300ms 到 500ms 的延时是比较安全的。
vTaskDelay(pdMS_TO_TICKS(500));
// 修改 SSDV 发送状态至 False,允许 SET/CTL 命令的执行。
Update_System_Status(SSDV_TRANSMITTING_STATUS, false);
// 重置 SSDV 预设模式至默认值 0
GET_System_Config(&local_config);
local_config.ssdvPresetMode = 0;
Update_System_Config(&local_config);
// 降频节电
setCpuFrequencyMhz(80);
// 待数据全部发送完毕后,开始计算并执行发送周期。
GET_System_Config(&local_config);
int cycle_time_sec = local_config.ssdvCycleTimeSec;
vTaskDelay(pdMS_TO_TICKS(cycle_time_sec * 1000));
// 恢复高速运行频率,为下一次拍摄做准备
setCpuFrequencyMhz(240);
}
}
P1 中继任务,以应答格式转发上行的中继数据
C++// 中继任务 (P1 - 最低优先级)
// 地面站格式 : ##ToCall,FmCall,Grid,INFO\n
// 转发器格式 :##RELAY,ToCall,FmCall,Grid,INFO
void V_Relay_Task(void *pvParameters) {
// 中继帧缓冲区
char relay_buffer[MAX_RX_BUFF_SIZE];
int relay_len = 0;
// 防滥用机制,每两分钟重置一次计数
int relay_count_since_reset = 0;
unsigned long last_reset_time = 0;
static bool relay_limited_warned = false;
const unsigned long reset_interval_ms = 120000;
// 将当前任务加入 WDT 监控 (注册看门狗)
esp_task_wdt_add(NULL);
for (;;) {
// 先喂狗
esp_task_wdt_reset();
// 检查任务启用状态,如果任务关闭,挂起2秒再检查
SystemStatus_t local_status;
GET_System_Status(&local_status);
if (!local_status.isRelayEnabled) {
vTaskDelay(pdMS_TO_TICKS(2000));
continue;
}
// 防滥用机制的计时与重置
if (millis() - last_reset_time > reset_interval_ms) {
relay_count_since_reset = 0;
last_reset_time = millis();
relay_limited_warned = false;
}
// 从中继队列等待消息
if (xQueueReceive(relayQueue, relay_buffer, pdMS_TO_TICKS(1000))) {
// 收到完整的中继数据,进行文本清洗
char *read_ptr = relay_buffer;
char *write_ptr = relay_buffer;
while (*read_ptr) {
// 只保留不是 \n 和 \r 的字符
if (*read_ptr != '\n' && *read_ptr != '\r') {
*write_ptr = *read_ptr;
write_ptr++;
}
read_ptr++;
}
// 在新字符串的末尾添加空终止符
*write_ptr = '\0';
// 检查是否到达限制,若未到达直接转发数据
if (relay_count_since_reset < 80) {
Transmit_Text("##RELAY,%s", relay_buffer);
relay_count_since_reset++;
} else {
if (!relay_limited_warned) {
Transmit_Status(RELAY_RATE_LIMITED);
relay_limited_warned = true;
}
}
}
}
}以上五个任务相互配合,驱动相关硬件并管理配置,构成了完整的球上事务处理与功能实现。
同时,为指导天线指向、接收气球的遥测回传、处理数据、进行数字通信试验和命令上注等工作,我们开发了地面站软件。
由于涉及社区合作,客户端力求简单易用;
为便于开发,该客户端使用 PyQt6 编写:
相关代码已附在文后。
由于成本低廉,一颗简单气球的造价不到300元,业余高空气球流行了非常长的一段时间。高空气球在国外社群被称作HAB,围绕着HAB,欧洲爱好者们建立了全球的网络和平台,也研制了非常多的工具,这也为我们的工作提供了便利。
软件在接收到数据后,进行处理,并通过 SondeHub API 提交,进行数据汇总、统计、多站点协作、数据图表绘制等工作。
我将相关页面以分栏式布局汇总,托管在 https://hab.satellites.ac.cn:
图:数据面板
为带动业余无线电社区的参与,提供链路保障,我们共募集了四位志愿者:
广州站:BA7OGJ
云浮站:BA7NII
万宁站:BG7YYN
三亚站:BG7ZFK
海口站作为主测控站,由 BG7ZDQ 负责。
本次任务原定使用电解法制取氢气进行灌充,并由此设计了一个电解制氢装置……
后续试验发现设计出现严重失误,效率过低。
遂更换为氦气。
图:氦气罐
(吐槽:这帮厂家居然不标实际气体体积)
为实现飞行高度与滞空时间的平衡,需要合理控制平均升速。
我们使用 https://sondehub.org/calc/工具进行计算,确定灌充参数[6]:
参数名 | 值 | 单位 |
|---|---|---|
气体体积 | 261 | L |
球柄举力 | 165 | g |
上升速率 | 3.50 | m/s |
爆破高度 | 17803 | m |
爆破时间 | 85 | min |
四、 放飞
气球原计划在 2025 年 7 月前放飞,但部分元器件在测试中发生故障。
维修期间,我们新增了部分功能并不断进行测试,拉长了研发时间。
最终,气球定于 2025 年 7 月 6 日晚 7:00 进行放飞。
任务概况
发射时间:2025年7月6日 19:26:30 CST
最后报告:2025年7月7日 00:17:01 CST
飞行时长:4小时52分44秒
最高高度:11612 米
飞行距离:50670 米
失联位置:南海西南浅滩以北
失联高度约 8007 米,电池电压 2.82V
图:气球灌充
图:放飞
图:开展测控工作
数据部分
图:报告高度
图:上升/下降率
图:GNSS 卫星数
图:有效载荷速度(计算)
图:电池电压与温度
图:链路测量
图:飞行轨迹
图:飞行过程中的部分图片
总结
本次任务以拍摄地平线曲度、开展数字中继通信实验和验证各类设计为目标,尽管过程中出现了诸多问题,但整体飞行安全完成,积累了宝贵的经验。
气球飞行总里程约为54公里,最大飞行高度11612米。
飞行持续将近五个小时,共获得2291条状态数据与600余幅高空图像。
飞行期间,海口站使用 RTL-SDR 对信号强度进行了简易测量。
测量点与海口站之间的三维空间距离约为 17564.45 米。
基于该距离,结合链路预算模型与自由空间路径损耗公式推导,理论接收信号强度约为 -78.11 dBm。
实测中,海口站记录到的信号包络平均强度约为 -35 dBFS。
根据 RTL-SDR 的设备特性换算,对应的实际接收功率约为 -75 dBm,理论值与实测值高度接近。
根据回传数据,对本次任务做出如下总结:
下行链路总体符合设计指标
热控制设计达到预期
事务管理程序设计合理
数字中继设计合理
数字图像回传设计合理
1.
发射前夕,载荷进行总装测试,发现出现 EMI 问题,GNSS 遭到干扰无法使用。
具体表现为间歇性信噪比减弱,初步研究发现,该问题与数据传输形成时间上的强相关性,推测为GNSS有源天线馈线与测控链路天线最大辐射方向垂直,造成了近场耦合干扰,更改馈线路径与天线布局后该问题解决。
2.
发射阶段,充气过程中未使用标准平衡器进行定量充气,仅在载荷板下方挂载配重,实际操作发现该方法难以操作,最后导致充气量不足。充气结束后,发现球嘴无法扎紧,持续漏气,迫使我们在现场研究扎绳技巧。准备释放时,发现气球存在破洞,只能用透明胶做临时修补。
整个准备过程远比预期复杂,耽误了不少时间,放飞时间比原计划晚了二十余分钟,天色已经变暗,错过拍摄窗口。
同时,如上失误导致了充气量不足、上升率不足、空中漏气、最高飞行高度下降、飞行时间过长等一系列问题。
后续的任务开展将吸取经验,制造或购买专门的平衡器,制定完整的检查及作业流程。
3.
由于未达到预期飞行高度,原定参加测控与通信实验的其他站点均未成功开展工作。
注:气球达到最高飞行高度时,万宁站理论应可以完成接收工作。但由于调度问题,万宁站在相关时段未处于运行状态。
图:信号覆盖范围(条纹状间隔为渲染错误)
4.
海口站于测控中发生下行中断问题,复盘发现该问题由操作人员对无线电相关知识了解不足,未匹配气球信号极化所导致。
5.
气球于19时20分30秒升空,随后命令上注、中继、图像摄制与回传等功能工作正常。
20时10分55秒,测试发现上行链路失效,命令上注失败。
原因目前尚未查清。
6. 飞行进入后期时,GNSS出现失效问题。初步推测是由于过冷所致,但有待商榷。
气球放飞次日(2025年7月7日),海口市气象局进行备案信息复核。
下午五点,气象与国安工作人员上门,在未出示相关行政决定与证明的情况下扣押本人所有设备进行调查。
2025年7月9日,相关工作人员传达通知,要求提交情况说明并领回设备。
交流得知,调查原因是由于提交了“临时气象观测备案”,涉及气象数据,从而牵涉到国家安全问题。
这也算是“不打不相识”,与相关职能负责人交换了联系方式,并意外收获了他们的理解与支持,得到了良好的沟通基础。
[1] https://www.gov.cn/gongbao/content/2021/content_5582636.htm
[2] https://www.gov.cn/gongbao/2024/issue_11286/202404/content_6945591.html
[3] https://mp.weixin.qq.com/s/3gPakV5t0j0iInU4Cj8y4g
[4] https://predict.sondehub.org/
[5] 刘晓玲. 影响探空气球施放高度的因素分析及有效提升方法[J]. 数字化用户,2024(40):275-276.
[6] https://sondehub.org/calc/
[7] https://www.hc01.com/downloads/HC-12.pdf
[8] https://content.u-blox.com/sites/default/files/MAX-M10S_DataSheet_UBX-20035208.pdf
[9] https://content.u-blox.com/sites/default/files/MAX-M10_ProductSummary_UBX-20017987.pdf
[10] SSDV——面向不可靠信道的数字图像传输设计 - 科创网
本项目从系统设计、软硬件实现到测试验证,虽然主要由我个人独立完成,但在实施过程中,得到了多方协助与支持,为任务的顺利推进提供了坚实保障。谨此向在项目筹备及实施期间提供帮助的各位致以诚挚谢意。
特别感谢各地面测控站在试验期间的积极配合与支持。
本次任务中,虽仅有海口站顺利完成遥测数据接收与遥控命令注入工作,并成功对数字中继等载荷开展了完整试验,其余地面站因技术原因最终未能开展测控与试验,但大家的积极参与和努力弥足珍贵,为后续的任务积累了经验,提供了改进方向。
同时,衷心感谢 Sondehub、Habhub 等国际高空气球爱好者社区。他们无私地提供了大量工具、软件、数据以及可视化数据平台等技术资源。这些资源在本项目中的仿真建模、任务规划与飞行监控环节发挥了至关重要的作用,其社区开放共享的精神与丰富的资源令人钦佩。
此外,在本项目的实施过程中,我作为第一技术负责人,在科创论坛上针对部分技术问题进行了阐述与分享,并发布了若干研究成果与技术报告。科创论坛对相关内容给予了创作激励,在一定程度上为本项目的开展提供了经济支持、交流空间与传播助力,在此一并致以衷心的感谢。
十、相关设计文件、代码、图片与资料
十一、后记
这枚气球成功释放后,本以为能清闲一段时间,但立马就碰到了一些其他问题。
真的非常忙,也非常累,所以一直没有腾出时间写完这篇文章。
时间过得有点久了,当时很多的照片,资料都没有留下来。
我也懒得去找了,就把目前手上的东西整合一下发出来,写的很草率,大家见谅。
后续如果大家感兴趣我再进行续编。
修改记录:
2025/07/25 公式识别出现错误,应管理员提醒进行修正
[修改于 3个月13天前 - 2025/07/25 00:57:20]
刚修完公式,发现链接文本全没了(?)
睡醒了起来再修正吧
气球和风筝挂载的负载会旋转,导致拍出来的图像很差, 一直在想有没有什么好的对抗旋转的稳定装置
气球和风筝挂载的负载会旋转,导致拍出来的图像很差, 一直在想有没有什么好的对抗旋转的稳定装置
之前在群里和老虎讨论过……
还不是很确定接下来该怎么改进。
另外的,调试阶段一直贴着一个镜头保护膜,放飞的时候忘记撕了……
总之拍照任务是毁的差不多了
之前在群里和老虎讨论过……还不是很确定接下来该怎么改进。另外的,调试阶段一直贴着一个镜头保护膜,放飞
不加重的情况下恐怕只能加绳子,唯一可利用的就是重力分量了,这样要求绳间夹角尽量大,还要避免重心过高导致易摆动,再优化一下外形,尽量圆滑对称,应该是可实现的
厉害厉害,要是在10年前,我一定到现场助阵,哈哈
拍照的话,气球旋转应该没什么影响。
拍视频的话,可考虑摄像吊舱与气球之间用细线或球头轴承连接,消除扭力耦合,然后摄像吊舱加一个旗状方向舵(参考风速仪,能自动指向迎风面)
狂赞,这也是我一直想做而一直未做的事情。有机会希望同楼主合作一下再放一次。
请教一下楼主经过复盘分析,最后失联是什么原因导致的?上升率和速度曲线末段都存在一个峰值,是否表示气球爆炸后迅速掉高?
狂赞,这也是我一直想做而一直未做的事情。有机会希望同楼主合作一下再放一次。请教一下楼主经过复盘分析,
最后失联应当是电池没电了……
因为漏气的原因,气球并没有按设计预期进行爆破,导致任务时长远超设计的两倍,电池撑不住也算正常。
高度下降是因为漏气的缘故,图中峰值经过后期数据筛查,确定属于GPS失效段数据的巨大误差,排除后确认整体应当是连续平滑的。
我们的下一次气球任务计划搭载风信子卫星项目的试样星,不知您是否有兴趣参与试样星的研发
200字以内,仅用于支线交流,主线讨论请采用回复功能。