DSD FME

[BD7PPA]

For Baofeng GMSK, now its vocoder is known: AMR-NB MR475. I was able to identify it by analyzing the ALERVITES AT2, which is unusual among these Baofeng GMSK radios because it has official phone app (named Ola Radio) support, and after analyzing its behavior I found it can exchange digital voice data with a phone over BLE.
The voice path is roughly: Radio->BLE vocoder frames->official app->built-in libtalkie.so codec->PCM audio, and also vice versa. This made it possible to directly observe the vocoder payload format and analyze the codec library independently of the RF layer.
After analyzing the heavily obfucsated android codec library structure and tables, I found that they match AMR-NB MR475. After testing, the original vocoder payloads from OlaRadio can be decoded correctly with OpenCORE AMR-NB, and OpenCORE-generated MR475 frames can also be sent to the AT2 and are correctly decoded by it. The voice frames are 12 bytes every 20 ms, with 95 useful bits per frame. In the OpenCORE/IETF storage format, an MR475 frame is 13 bytes: a 1-byte ToC/frame header (0x04 for an MR475 good speech frame), followed by a 12-byte payload containing the 95 codec bits plus one padding bit. The AT2 BLE format simply omits the first header byte and transmits the remaining 12 bytes unchanged. Converting an AT2 frame back to the IETF format is therefore just a matter of prepending 0x04.
Because the AT2 allows controlled vocoder payloads, as well as UTF-8 text and JPG images to be sent over BLE, it should also be possible to generate RF IQ recordings together with the exact corresponding AMR payloads or just by repeatedly transmitting a known fixed text payload. This may be useful for further work on frame synchronization, interleaving, and FEC.
I have also made (well, vibe coded) a working replacement for the Ola Radio app that implements the complete AT2 BLE protocol and replaces the proprietary libtalkie.so codec with this open-source AMR-NB MR475 implementation (GitHub - BelledonneCommunications/opencore-amr: Linphone.org mirror for opencore-amr (git://git.code.sf.net/p/opencore-amr/code)). The replacement codec has been tested successfully with real AT2 hardware. I am preparing to publish the source soon.
This obviously does not solve the RF framing and FEC yet, but at least the vocoder part is now identified, and hopefully this will make future work easier.

The app for AT2 GitHub - byf3332/Baofeng-ALERVITES-AT2-Android: Open-source Android app for the Baofeng ALERVITES AT2 radio
There is also technical information in README

 

[lwvmobile]

This obviously does not solve the RF framing and FEC yet, but at least the vocoder part is now identified, and hopefully this will make future work easier.

I can't make any guarantees on this, or even when I might be able to really do work into looking into this, but just looking at one of the signal files I found on sigid, looks like the frame is 400 ms to align with the voice, and I'd guess perhaps a sync pattern, header, empty, voice payload.

 

[MELERIX]

The AMD / USB issue is a known issue to effect a range of B450 and B550 board and CPU combinations. You can google search all about it, or read other related issues from users on this board found here.

Odd SDR behaviour on USB 2.0 ports only

If I have any sdr's connected to a usb 2.0 port, the sdr's water display on any program such as sdrsharp, sdr trunk, and others dont move if I dial in a frequency but if I drag left and right and move on the water display say in sdr sharp to move the frequency, it works but if I adjust the...

forums.radioreference.com

btw, this is fixed now in DSD-NEO and now it works fine with USB 2.0 ports on AMD Ryzen CPUs, will be good if can you implement the same changes (I'm not sure if this one) in DSD-FME too.

 

[BD7PPA]

I can't make any guarantees on this, or even when I might be able to really do work into looking into this, but just looking at one of the signal files I found on sigid, looks like the frame is 400 ms to align with the voice, and I'd guess perhaps a sync pattern, header, empty, voice payload.

View attachment 203884

There are several highly related patents about this type of signal (in chinese), basically confirming it is WIoTa protocol by ucchip. Docs of it (also in chinese):WIOTA INTRODUCE

CN113595955B - 一种弹性前导序列结构和时域频域同步方法 - Google Patents

本发明涉及无线通信技术领域，具体涉及一种弹性前导序列结构和时域频域同步方法，配置恒包络零自相关序列和伪随机序列，将恒包络零自相关序列的生成和系统的身份标识号关联，将伪随机序列的生成和系统的身份标识号关联，用配置的恒包络零自相关序列和伪随机序列实施时域频域同步方法，根据通信系统所在环境的信噪比水平的不同，可以配置多个相同的恒包络零自相关序列和配置所生成的恒包络零自相关序列长度，可以配置多个相同的伪随机序列和配置所生成的伪随机序列长度，解决了常见的前导序列结构难以适应变化繁杂的物联网应用场景，导致时域频域同步方法在超低信噪比中方法性能不足的问题。

patents.google.com

CN110858788B - 一种数据符号的配置方法 - Google Patents

本发明公开了一种通信帧结构中数据符号的配置方法，涉及通信领域。所述数据符号为一个数据传输单位，由PCP控制加数据组成；所述PCP控制为一PCP序列，并通过相应的生成方法得到。对于上下行公共控制信道，所述PCP序列由相应的PCP生成器生成；当上行公共控制信道在承载非ACK信息时，或上行共享数据信道在承载短消息时，通过从C‑PCP序列集中随机或指定选取一个作为PCP序列。采用了上述技术方案，可以用于在不同的信道上预定义不一样的序列长度来高整个系统的效率，还与接收机的结合可以使通信系统接收信号信噪比可低达‑30dB，使得WIoTa的终端可以在一些极端情况下仍能工作，同时基站也可以覆盖很大的范围...

patents.google.com

CN116546599B - 一种增程转发无线通信方法和系统 - Google Patents

本发明公开了一种增程转发无线通信方法和系统。第一节点和多个第二节点之间建立配对关系；各第二节点选择驻留的频点；第一节点向目的节点发送消息，并在接收到目的节点在该消息的帧结构帧尾回复的ACK信息后，进入休眠状态，该目的节点为与第一节点配对的多个第二节点之一；目的节点解析消息，在该消息指示是需要增程转发的消息时，依据该指示，将消息转发给其他第二节点，转发消息在所有预设信道上都进行一次。本发明可以在较低的电量消耗情况下，保证数据的有效传输，可以有效避免单一频点工作模式遇到干扰时无法正常通信的情况，在同一帧结构中完成发送和确认，有效保证了消息的传输时效性和送达率，节省电源消耗。

patents.google.com

CN117041927A - 一种数字对讲机低功耗监听式应急求救通信方法 - Google Patents

本发明涉及无线通信技术领域，具体涉及一种数字对讲机低功耗监听式应急求救通信方法，在应急监听模式下，救援主机发射信号经求救机接收信号建立连接，得到双通道；救援主机基于双通道发送唤醒序列，并保持接收状态，等待数据上报，直至救援任务完毕关闭；求救机电量低于阈值后，求救机自动进入应急监听模式进行休眠状态；当求救机检测到应急唤醒位置，退出休眠状态进入工作模式，在双通道进行求救操作，并再次进入应急监听模式，该方法在低功耗监听模式，可将缓存的求救信息在唤醒后的第一时间自动发送给搜救方，自动应答搜救信号，在电量紧缺条件下的持续应急通信方式，为搜救人员提供了便利，增大了搜救成功的几率。

patents.google.com

CN119629767B - 无互联网环境下的组网通信方法、平台、设备及存储介质 - Google Patents

本申请涉及无互联网环境下的组网通信方法、平台、设备及存储介质，其属于网络通信技术领域，其中方法包括：接收用户智能终端发出的连接请求，筛寻可用中介终端；其中，可用中介终端指能够与用户智能终端建立蓝牙连接的中介终端，且任意中介终端能够基于预构建的对讲组网与其他中介终端实现通信；从所有可用中介终端中获取目标中介终端，将目标中介终端与用户智能终端建立蓝牙连接；接收用户智能终端发出的通信请求，通过用户智能终端所对应连接的目标中介终端执行通信请求，以将通信内容通过目标中介终端和对讲组网传输至通信请求所包含的、用于接收通信内容的用户智能终端。本申请具有在无互联网环境下实现通信和信息交互的效果。

patents.google.com

CN119629767B seems to be the device/method used by ALERVITES AT2 walkie.
Edit: CN119629767B seems to be the description of the system for sending text message and picture through RF, used by the ALERVITES AT2 walkie.

Additionally this besides encryption key described in cps, there is also a value called subsystemid, which is only 1 id per device（Edit: Each radio stores only one subsystem id, and this id is not assigned per channel. Only radios using the same subsystem id can communicate with each other. The range is 0 to 255.)
To check it, turn off radio, set the channel knob to ch3, hold down side key 1 and ptt while turning on, you will hear the radio say: X, power-on, three, the X here is 1, 2, or 3 digits, which is the subsystemid for this device.

 

[gary123]

I grabbed the English translations from the pages. Its a direct C&P.

This may make it easier for oithers to read and extract the important formatting information.

 

[BD7PPA]

I can't make any guarantees on this, or even when I might be able to really do work into looking into this, but just looking at one of the signal files I found on sigid, looks like the frame is 400 ms to align with the voice, and I'd guess perhaps a sync pattern, header, empty, voice payload.

View attachment 203884

I recorded an IQ sample for your reference. Please look at README.txt in the archive first.
AT2 known voice IQ.zip
Edit: Encryption Key: 0, SubSystem ID: 1