DTrac APP 新增了对泉盛UV-K5/K6/K1的支持,现在可以通过APP操控UV-K5/K6/K1实时同步卫星转发器参数,方便业余卫星通联操作。
仅需使用APP连接对讲机,抛弃繁琐一个手机全搞定,业余卫星通联操作更智能,实现以下功能:
注:由于泉盛UV-K5/K6/K1硬件限制,除FM外的模式仅对接收信道有效。
泉盛UV-K5/K6/K1系列电台虽然自带串口,可以基于外接网络转串口的方式来实现对接,但总是不太方便,最好的方法是在电台内部加上经典蓝牙透传串口组件,一劳永逸。
推荐使用3.3V的经典蓝牙透传模块,如HC-04、度云doBT-M02,操作步骤:
注:UV-K1和UV-K5-v3的接线方法,请参照相关电路图,关键是找到RXD、TXD、3V3、GND的位置,一般根据K头或USB串口走线很容易查找,以上内容仅供参考。
定制的固件在egzumer、F4HWN、BA7IQE等最新开源固件上轻微修改,完整保留了原固件功能。注: 固件使用Apache-2.0协议
刷机方法简介:在线刷机、离线线刷和蓝牙无线刷机的方法都是一样的,长按PTT键开机,选择正确的端口,连接电台,选择固件,点击更新即可。固件升级详细操作步骤可参考官方升级固件程序和说明文档。
其它版本硬件,强烈推荐在线刷机方式。
养成良好的习惯,刷机前先备份校准数据,刷机后再恢复校准数据,GL!
警告:固件仅供学习和业余无线电交流,由于泉盛UV-K系列对讲机版本迭代很多,下载使用时请认准对应的版本,如果造成对讲机变砖,概不负责!
固件修改自
https://github.com/egzumer/uv-k5-firmware-custom
仅限MCU为DP32G030的UV-K5和UV-K6使用。
固件下载地址: uv-k5-k6_dp32g030_firmware_for_dtrac.bin
在线刷机
固件修改自
https://github.com/armel/uv-k1-k5v3-firmware-custom
仅限MCU为PY32F071的新版UV-K5和UV-K6使用。
固件下载地址:uv-k5-k6-k1_py32f071_firmware_for_dtrac.fusion.bin
在线刷机
固件修改自
https://github.com/qbs524/uv-k1-k5v3-firmware-custom-main-chn
仅限MCU为PY32F071的UV-K1系列机型使用。
固件下载地址:uv-k5-k6-k1_py32f071_firmware_for_dtrac.fusion.bin
在线刷机
泉盛UV-K1在不加装蓝牙的情形下,仅使用USB串口转网络服务的方式,可与DTrac APP对接,实现多普勒频率的同步控制。当然,加装蓝牙后操作更方便一些!
电台类型选择“QUANSHENG UV-K6”,选择已配对的电台蓝牙适配器,如上述自定义的“UV-K6”,然后用蓝牙方式连接对讲机。
当然,你也可以通过使用电脑的虚拟串口软件将电台自带的串口转换为网络透传服务,然后用网络接口的方式来与DTrac APP对接,可参考以下内容 使用虚拟串口 。
进入固件隐藏校准菜单的方法如下:先按住“PTT”键和“按钮1”,然后打开对讲机,接着松开所有按键,即可进入隐藏菜单。进入后,找到与电池校准相关的选项,如“BatCal”,即可进行电压校准等操作。
The programming protocol used by this software has been reverse engineered by observing communications between the radio and the original programming software. It is not a variation of the typical Baofeng-like protocol.
The format of the datagram sent to the radio is:
0xAB 0xCD len 0x00 <data bytes> <2 bytes CRC> 0xDC 0xBA
The length is the length of the data bytes.
The data is protected by a typical CRC-16 xmodem algorithm. The data bytes and the CRC are obfuscated by xor-in it with an 8-byte sequence.
Fortunately the EEPROM data contains a lot of 0xFF and 0x00 bytes, so the XOR sequence is easy to find by observing the traffic.
The datagram sent from the radio is the same, but the CRC field is set to 0xFFFF. This shows that the CRC is not for data integrity, but for further obfuscation (same as the XOR).
I intend to publish a further description of the protocol, and the EEPROM contents, meanwhile the sources can be used as documentation.
以下是您在全盛码头选择[F-0]调频收音机时的序列数据。
AB CD 06 00 17 64 16 E6 2E 91 E8 EA DC BA
发送和接收的数据在以下字节列中进行了异或加密:
通过异或处理的数据可以通过异或解锁,每个字节对应的字节{ 0x16, 0x6c, 0x14, 0xe6, 0x2e, 0x91, 0x0d, 0x40, 0x21, 0x35, 0xd5, 0x40, 0x13, 0x03, 0xe9, 0x80 }
AB CD 06 00 17 64 16 E6 2E 91 E8 EA DC BA
实际数据 → AB CD 06 00 01 08 02 00 00 00 E5 EA DC BA
typedef struct {
Header_t Header; uint8_t CTCSS_CODE;
} CMD_9999_t;
typedef struct {
Header_t Header; uint32_t DownFrequency;
} CMD_8888_t;
typedef struct {
Header_t Header; uint32_t UpFrequency;
} CMD_7777_t;
typedef struct {
Header_t Header; char Mode;
} CMD_6666_t;
typedef struct {
Header_t Header; char MonitorStatus;
} CMD_5555_t;