PDR初步设想--利用手机浏览器构建通用的无线电设备控制前端
homebrew qrp amateur radioPDR初步设想--利用手机浏览器构建通用的无线电设备控制前端
概要
本文提出一种构想：利用手机浏览器构建一套通用的ham设备控制前端，用于提升电台操控的便利性，同时为自制设备时省去人机交互部分（类似rtl-sdr这种headless）提供了可能性。
动机
我qrp野架一般很少能够重装出击，都是利用在公园遛娃、周末郊游的空隙等顺便架设，要求快架快收，设备也需要便携，经常是一个随身小包容纳全部（efhw/鱼竿天线，50-1.5馈线）。甚至icom-705对于很多时候都嫌太重了，于是有段时间一直在找寻一些小型qrp设备（或者自制方案）。我发现有很多不错的开源项目，例如hermes-lite2、t41-ep等等，但这些几乎都是基地台方案；qrp-labs的qmx似乎不错，但是我仍然希望能有一个大的瀑布频谱，而且闭源的性质导致其ssb功能进展缓慢。也就只有高端一些的商业成品机如elecraft的才兼具了频谱/便携。对于自制qrp设备来说，频谱、强大的扩展、灵活的操控，这些貌似不可兼得。
我在想，对于sdr的时代，各种芯片甚至soc非常发达，自制设备小型化的唯一门槛貌似就是控制面板了：考虑体积、耗电、软硬件复杂度等，这些非核心的东西反倒麻烦。当前的sdr方案都大同小异（adc/dac/microcontroller/Tayloe...），但是面板实现部分却五花八门，各种按钮、旋钮、甚至矩阵满天飞... 每个设备打开后里面都利用了前沿的芯片，但是外壳却像是活在十九世纪。
瞧瞧手机的发展吧。早先年黑莓、诺基亚那种密密麻麻键盘早就淘汰了，现在就一块触摸屏搞定全部，简洁方便、灵活度高（软件定义触控功能）。对于自制设备的作者来说，集成一块触控屏幕硬件上不难，但难在还需要开发配套的UI，这个就太费精力了。
像是rtl-sdr这类的sdr棒将交互前端完全丢给软件，反倒在社区里酝酿了很多优秀的sdr软件的出现，但基本上都是基于台式电脑的。 近年有个ft8cn是个好东西，但一来它只是个协议层软件，二来只能在android上跑，导致我出去要带两台手机...
...对了，手机。我突然想到：人人都会随身带手机，哪怕你在sota的山头上。为何不利用手机屏幕作为设备的操控终端呢？这会非常方便，能带来诸多好处：
- 功能灵活。操控不再锁死到硬件按钮/旋钮上，软件定义，随时扩展，随时更新
- 足够大、足够清晰、高分辨率的瀑布图
- 方便。我们可以躺在远离天馈/电台十几米外的大树下边乘凉边操作（我的竖架鱼竿天线再也不用十米的馈线以避开我的身体干扰了...）。
- 对于自制设备，可以整个省去操控部分电路，将设备消减为核心的bpf+preamp+rf receive/transmit+up/down convert前端
- ...甚至，省去调制解调/编解码/dsp部分（手机能做！）
而且，上述需求，几乎对于每一台设备来说都是通用、大同小异的，完全可以抽取出来作为一个开源的项目公用!
但是，靠谱么？
可行性研究
- 首先我们需要能提取到各个设备的I/Q数据。这个接口对于现代化的sdr架构的商业设备早已准备好了；对于自制设备，这些就是基带采样后的原始数据，非常方便输出。✅
- 其次设备需要输入输出其控制信道。对于商业设备来说，CAT是必备的；对于自制设备来说，也就是增加了一点点复杂：将微控制器的逻辑整合一下由控制信道提供出来而已。✅
- 但怎么连接到手机呢？蓝牙带宽是不够的，只有wifi。一些比较潮流的设备（如我的icom-705、xiegu 6100）早有了wifi交互，但是对于其他设备，特别是自制设备来说，集成一个高速率的wifi是个难题，不用说usdx那种的8位机，哪怕qmx这种stm32核心的微控制器，都比较困难。要想实现100mbps以上的wifi，要采用5G wifi芯片起步，并使用如dma+sdio等较为复杂的集成才行。
我一开始思路也是卡在这里了。
...但是，后来我想到，我们可以利用一个三方系统，桥接一下。例如，树莓派？usb---》wifi！
- 对于商业设备来说，usb接口是较为现成的。对于自制设备来说，甚至很多的微控制器都有PHY核心，集成一个usb（哪怕2.0）就是焊上去个接口的事情，usb的软件代码芯片厂家的sdk里一般也给准备好了。✅
- 人人都有一个树莓派（或者orange pi/banana pi...）。这些玩意儿上有usb、有wifi，可以跑python，有恐怖的算力，可以实现高速的wifi数据转发（wifi速率就看pi的性能了）！✅
- ok，手机可以远处连接上了。app呢？android还好说一些，可以任意安装应用；但是ios是个出名的封闭系统，其开发、上架、审核、发布都很麻烦。
又卡住了？但是我们有万能的web浏览器啊！我们不要原生的、需要安装的app，我们要webapp（就是web页面）！...但是web是个沙盒封闭环境（sandbox），而且javascript是相对低性能的脚本语言，跑高强度的算法，这些，靠谱么？
- 播放声音对于web来说不是难事儿（但仍然需要点小技巧）；作为micphone的话，我们可以使用web-audio实现对手机话筒的利用。这样，就解决了扬声器、手持麦克风的问题✅
- 如果考虑用手机做dsp运算（调制解调、编解码、数字协议解析、数字滤波器等等），js效率太低。但是现在有webasm，可以在浏览器里面实现汇编级别的运效。再加上现代手机的cpu/fpu/neon/simd的算力，我想轻松实现几Mhz频谱的处理问题应该不大！（希望如此）✅
- 还剩下个cw电键问题... 当然手机上软实现（字母-》Morse）很简单，但是对于老式电键的拥趸来说，实在不行还是插到电台上吧... 或者做个简单的小硬件，将电键通过蓝牙发送给树莓派（web的蓝牙协议是个草案，还需要时间）？总之我不太纠结这个✅
发现没有，上述所有的硬件都是现成的（电台的usb、树莓派、手机），我们不用焊任何东西！所缺的就只是软件了。而且，web开发比verilog、嵌入式开发什么的简单多了，更多的人可以参与到项目中！
现在来说下我脑袋里的初步构想吧。
架构
- 对于设备的唯一要求：有usb接口，可以输入输出I/Q sample以及CAT。包括但不限于各种电台、sdr棒、有自制设备。
- 然后你需要一块有足够wifi速率的“派”。所谓“足够”，要看你的需要的采样率（频谱带宽）、派天线的性能/你跟派的距离、遮挡、派的运算性能等因素影响。但无论如何，我猜对于几百k起步的频谱，甚至raspberry pi zero2这种的小东西都问题不大。当然如果你想要sdrplay rsp1那种10Mhz频谱，可能需要raspberry pi 4b起步这种的单板计算机了...
- 对于手机，除了性能（别太老），则无任何要求。
将电池给派供上电，用usb线将它跟你的电台（或者sdr棒）连起来，打开wifi热点，打开手机，找个阴凉，就可以开始CQ了！
agent架构
基于树莓派这种单片计算机的agent方案，反倒实现起来简单，一个python脚本就能够搞定。我将其称之为“胖代理”：
- 派上安装好sdr/电台设备的usb驱动
- 然后脚本里面需要实现一些驱动（厂商相关）的胶水调用代码，以将其I/Q码流、CAT控制命令等接出来
- 如果你的派性能过剩（电池过剩？），可以考虑直接在上面跑dsp，对信号进行全链条的处理。已经有csdr等库在那里等着我们了...
- 或者通过python脚本将原始sample流发送给手机，由浏览器处理
- 手机浏览器打开的这些控制台页面，通过python的web server，提供给手机
- 基本就这些了！（可能再加上些登录/认证、用户配置存储等周边功能）
再往未来预想一下。
在已经有了手机上的这么一套web控制面板的情况下，对于日后的自制设备作者们，多了可以一步到位，直接嵌入到自制设备上，省去三方agent（树莓派）的方案，我称之为“瘦代理”：
- 首先前提是你的设备里可以集成一个过得去的wifi芯片。拜工业化所赐，这不是个很大的问题（除了增加一点成本），现在wifi的soc方案非常成熟多样，高端低端都有，从wifi6专用芯片到esp32这种arm+wifi一体的微控制器
- 实现对于瘦代理的集成：如果你的微控制器可以跑一些rtos（如果能跑linux那不用提了），瘦代理（希望！）可以提供一些库给你；最起码可以提供一些demo代码以供你实现agent的API做参考。大致你需要开发的，是一个最基础版的web server，实现了websocket
- 至于软硬件逻辑控制部分的胶水代码，需要你自己来实现
- 将web前端的页面烧制到你的flash上。如果你拿不出几兆的存储空间，可以考虑将这些页面文件通过用户手机进行（一次性）上传过来，由web server转接一道再发回用户浏览器...
- 齐活儿！这样一来，省去了你硬件的所有扬声器、麦克风、插口、audio功放、液晶屏幕、所有按钮/旋钮... 以及相关的软件开发！
- 而且，还不需要中间的树莓派做代理了！
web前端
整个（设想中的）项目开发的大头是在web前端部分，如有可能我希望能做成一个开放的东西，不但代码本身是开放的，更重要的是体系开放，是一个大家都可以参与进来，贡献算法、功能、控件、插件、或者实现任何有趣的想法！
- 拜web技术发展所赐，最难的部分浏览器厂家已经都替我们在底层实现好了：web-asm、web-audio、websocket...
- 我们要实现的，首先是跟代理互通的api层，这一层应该尽量通用和固定
- 然后是dsp算法部分。fft相关、radio相关的c/cpp代码已经非常多了，需要些时间精力，将这些整理编译为webasm库供调用
- 可能需要实现一个简单的核心（状态机/调度器/引擎/whatever...），将整个体系的纵横向部件、架构粘合起来
- ...并（希望在后期）提供开放的插件化体系
- 若再有精力（贡献者），实现一些常用协议，如wsjt-x协议簇、各种psk31、aprs、rtty、cw解码等应用层功能
- 对于UI界面层，希望能实现一套开放的控件/组件库，供大家二次开发和拓展
- 实现一定程度的界面排布自由度，用户可以按照自己的偏好、常用功能对其进行编排
离这个构想还有多远？
嗯，看起来需要设计、开发的东西还是很多的。但是，想想多年之前就已经有websdr/opensdr了，可供参考的东西其实是非常多的。需要的是借鉴、重构，下手去coding...
预想中的实现步骤：
- 先实现一个demo系统，以拉通链条做可行性验证
- 设计agent api并实现胖代理
- 编译实现基于webasm的dsp库
- 实现瀑布图及至少一个协议（ft8？）
- 设计UI控件库体系
- 初步实现面板应用
- 中后期(有社区或足够数量关注者后)：
- 实现瘦代理体系（等待一些感兴趣的设备自制爱好者共同驱动）
- 实现更多的协议、应用
- 设计并实现插件化体系
- 迭代，不停迭代...
关于PDR的名字
Phone-Defined-Radio！
我希望这一切有价值，希望自己能尽快抽出时间来做验证和启动。
73
by bd8bzy