255Mesh与语音双相对讲结合的可行性分析

       干了这么多年的lora，其实双向语音对讲一直是我不愿触碰的地方。传统lora方案的舒适区应该在窄带物联。轻量化的数据加上无延时要求场景，才是他发光发热的地方。最近跟行业内的大佬交流了一翻后，我又去学习了一下这块的盲区。就想着跟大伙一块分享一下。

首先明确一下方案架构

硬件组成
1 ：语音采集设备：麦克风
2 ：语音播放设备：扬声器
3 ：255mesh模块：负责将语音信号进行调制和解调，实现无线传输。
4 ：MCU：处理语音信号和 255mesh通信。

软件设计
1语音编码算法
2通信协议
3用户界面

其中我们关心的交互式语音和音频传输的编解码器有：Opus,CELT,Speex,ILBC,G.722,G.729,AMR,ACC等，我们以opus来举例：

Opus 就是合并了 Skype 的 Silk 和Xiph.org的 CELT 技术，参数支持如下：

◆ 采样率从 8kHz（窄带）到 48kHz（全频带）。

◆ 比特率从 6kb/s 到 510kb/s。

◆ 支持固定比特率（CBR）和可变比特率（VBR）。

◆ 帧长从 2.5 毫秒到 60 毫秒。

◆ 支持语音和音乐。

       我们知道语音传输空中速率主要取决于通信链路的特性和实际传输环境，这里可以选择窄带语音的传输方案，通常在低比特率下就能实现较好的语音质量，例如可以在 6 - 10 kbps 的比特率下工作。在这种条件下，所需带宽相对较小，对于网络资源有限的环境较为适用。

介绍了语音编解码器的基本要求，在看看结合传统的lora方案会出现哪些问题：

带宽限制：LoRa 的传输速率相对较低，通常为300bps到几十 kbps，速率越低传输距离越长。而音频传输，尤其是对于高质量的音频，需要一定的带宽来保证音频的流畅性和保真度。较低的传输速率可能导致音频传输出现延迟、卡顿等现象，影响音频的实时性和质量。

时延问题：LoRa 通信中存在一定的时延，例如在半双工通信方式下，当多个终端节点同时发送数据时可能产生信道冲突，导致数据传输延时；网关繁忙时也可能产生数据丢失或延时。在音频传输中，时延可能会影响到音频的同步性，对于实时性要求较高的音频应用场景（如语音通话、实时音频监控等），较大的时延是难以接受的 。

音频编码与压缩：由于 LoRa 的带宽有限，为了在其网络上有效地传输音频，需要采用合适的音频编码和压缩算法，在保证音频质量的前提下，尽可能降低音频数据的大小，以适应 LoRa 的传输能力。这就对音频编码技术提出了较高的要求。

       我们在来看看255mesh模块的特性。255mesh模块的底层硬件采用lora射频前端，整个协议层最大的特点是在处理大数据量并发的时候，可以最大程度的降低丢包率并且支持自路由、自中继。空中速率支持2.1kbps-62.5kpbs可调。

       在面临上述带宽、时延、编码压缩的时候都有一定程度的处理能力。从理论基础上是可以满足语音传输的要求。但要实际应用还需要综合考虑具体的音频传输需求、应用场景特点以及对音频质量和实时性的要求等因素，并通过算法优化编码压缩和时延等问题。相对于一些对音频质量要求不高、传输距离较远且对实时性要求相对较低的场景中，255mesh可能是一种可行的音频传输解决方案。