openrtx/openrtx

Modular Open Source Radio Firmware

OpenRTX

Modular Open Source Radio Firmware

OpenRTX is a free and open source firmware for digital amateur radio devices, top-down designed with modularity, flexibility and performance in mind.

Currently OpenRTX is being actively developed for the following radios:

• TYT MD-380/390
• TYT MD-UV380/390
• TYT MD-9600
• Radioddity GD77 and Baofeng DM-1801

This firmware is highly experimental and currently under development, this means that it may not have all the expected functionalities. Anyway, contributions and testing will be warmly welcomed and accepted!

For information on the radios that are currently supported and their features, see the Development Status page on our website.

For hardware and software documentation visit openrtx.org

Obtaining the firmware

Warning: Read the disclaimer section first!

Pre-built binary images of the OpenRTX firmware for each one of the supported devices are available on the releases page: to flash them to your radio, you can use the OEM firmware upgrade tool or — alternatively and for TYT MD-3x0 and MD-UV3x0 radios only — you can also use the radio_tool program or tarxvf's web based flashing tool dmr.tools.

Between releases, pre-built binary images containing the latest firmware updates are available through nightly builds from the master branch. The nightly builds are available here:

• on Phil DF5PMF's page
• on the OpenRTX nightly builds page

Finally, the instructions on how to compile the OpenRTX firmware for hardware as well as emulation on Linux, are available on the compilation instructions page on our website.

Have a look at the the dedicated page for detailed instructions on flashing the firmware to your radio, look at the OpenRTX website or reach out to us on our channels!

M17 support

From the release version 0.3.3 onwards the OpenRTX firmware provides experimental support for the M17 digital voice mode.

The following radios are currently supported for use with this digital mode:

• MD-380, MD-390 and RT3 UHF version are supported for both modulation and demodulation.
• MD-380, MD-390 and RT3 VHF version are supported for demodulation only, modulation is a work in progress.
• MD-UV380 and MD-UV390 are supported for both modulation and demodulation.
• GD77 and DM-1801 currently are not supported for the new digital voice mode.

To make the digital mode work, some modding is required: Refer to the dedicated page on our website for the details on that.

Disclaimer

This project was created for research and amateur radio use only, we are not responsible for improper use of this code which might lead to unauthorized transmission, reception or any patent infringments.

The OpenRTX firmware is released WITHOUT ANY WARRANTY: Anyone flashing a binary image obtained from the sources made available through this repository does so at their own risk. We always test all the code on our devices before publishing it on the repository, however we cannot guarantee the absolute absence of bugs nor of potential side effects.

Contact

To reach out, visit our M17 Reflector or join our Matrix room for general discussion #openrtx_general:matrix.org or the Matrix space #openrtx:matrix.org which contains many additional rooms or our Discord Server.

Donate

To support the development of OpenRTX you can donate using Liberapay.
If you want to donate hardware to facilitate porting and development of OpenRTX, please contact us.

License

This software is released under the GNU GPL v3.

minmea is released under the DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE v2.

Code for STM32F405 USB driver is released under the MCD-ST Liberty SW License Agreement V2.

uf2conf.py and related files are released by Microsoft Corporation under MIT license.

Credits

OpenRTX is being made by:

• Niccolò Izzo IU2KIN [email protected]
• Silvano Seva IU2KWO [email protected]
• Federico Amedeo Izzo IU2NUO [email protected]
• Frederik Saraci IU2NRO [email protected]

Our wholehearted thanks go to the following contributors from the community:

• Joseph Stephen VK7JS, who implemented voice prompts

All this is possible by the huge reverse engineering effort of Travis Goodspeed and all the contributors of the md380tools.

A huge thanks goes to Roger Clark, and his OpenGD77 (repo no longer available) which not only inspired this project, but as a precursor, provided a working code example for the GD77 radio family.

A warm thank you goes to SP5WWP and the M17 community for bringing their libre protocol into our obscure undocumented hardware.

Also, a thank you for donating hardware to this project goes to:

• M17 Project
• laurivosandi

And thanks to everyone who donated via LiberaPay.

openrtx's Issues

RTX stack size change breaks UV3x0 support

The commit e2f3225 increases RTX thread stack size from 128 to 512.

This breaks OpenRTX on the UV3x0, but not on MD3x0.

Spurious keyboard events on Linux

When running OpenRTX on Linux, the UI receives a lot of spurious keyboard messages containing KEY_2 and KEY_3 pressed.

These events generate double clicks due to interaction with other pressed keys.

Volume setting not restored after transmitting (FM?)

It appears the audio volume is reset to some low value after every transmission.

To reproduce:
You need two radios in FM on the same channel, one with OpenRTX (in my case an MD-UV380 (without GPS) running the nightly firmware from yesterday).

• Transmit from the other radio so the OpenRTX radio receives a signal, volume knob is adjusted until it is nice and loud.
• Make a transmission with OpenRTX radio of any length.
• Transmit from other radio so the OpenRTX radio receives the signal. It will be quiet.

I think I know where to look, so I claim this one unless you beat me to it. :P

I drew a prototype of MD-380

I drew a prototype of MD-380, hoping to be useful for the project.

upload png and svg.

openrtx.svg.zip

Create a button to open the squelch (at least in FM mode)

Could a button (or a switchable parameter in the menu) be created for opening the squelch?
This would be nice to have in FM mode, and maybe also in digital modes to verify if a signal can be heard which is below the squelch detector.

On MD380 there is a 3rd button above the PTT which could be used for this, maybe it can be (user) programmed to do so?

Incorrect demodulation in UHF rx when bandwidth of 12.5 khz is used

I flashed the latest master on my uv390 (which is basically identical to the uv380).

The rx and tx capabilities are mostly fine, but I noticed an incorrect demodulation, causing voice not to be intelligible, when the radio is used on the UHF band, in rx mode.

Thanks to the help of @Nimayer, we noticed that this problem arises only when a bandwidth of 12.5 kHz is used, therefore happening mostly when you use pre-saved channels.
If you start up your radio in VFO mode, with a bandwidth of 20/25 kHz, the demodulation is correct and you can hear voice fine.

Let me know if I can help you with testing/reproducing the bug, and thanks again for this fantastic project!

DMR

Hello,
Will you add DMR mode to OpenRTX, and when?

MD-UV380/DM-1701: USB Virtual COM does not work

USB Virtual COM (serial port over USB) does not work on Tytera MD-UV380 and Baofeng DM-1701

This is the Linux kernel dmesg shown after connecting DM-1701

[55737.767635] usb 1-1.4: new full-speed USB device number 30 using xhci_hcd
[55742.855829] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[55748.236025] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[55748.443965] usb 1-1.4: device not accepting address 30, error -62
[55748.444046] usb 1-1-port4: unable to enumerate USB device

This is the Linux kernel dmesg after connecting MD-UV380

[ 2085.026956] usb 1-12: new full-speed USB device number 4 using xhci_hcd
[ 2085.148375] usb 1-12: device descriptor read/64, error -71
[ 2085.381680] usb 1-12: device descriptor read/64, error -71
[ 2085.614957] usb 1-12: new full-speed USB device number 5 using xhci_hcd
[ 2085.741684] usb 1-12: device descriptor read/64, error -71
[ 2085.978388] usb 1-12: device descriptor read/64, error -71
[ 2086.090196] usb usb1-port12: attempt power cycle
[ 2086.738317] usb 1-12: new full-speed USB device number 6 using xhci_hcd
[ 2086.738436] usb 1-12: Device not responding to setup address.
[ 2086.951060] usb 1-12: Device not responding to setup address.
[ 2087.155017] usb 1-12: device not accepting address 6, error -71
[ 2087.281683] usb 1-12: new full-speed USB device number 7 using xhci_hcd
[ 2087.281828] usb 1-12: Device not responding to setup address.
[ 2087.488452] usb 1-12: Device not responding to setup address.
[ 2087.695278] usb 1-12: device not accepting address 7, error -71
[ 2087.695419] usb usb1-port12: unable to enumerate USB device

MD-UV380: Side buttons (MONI and F1) are swapped

Executing the keyboard demo on the Tytera MD-UV380, I have noticed that the two side keys above and below the PTT key are swapped.

The MONI key should be the lower one (with M embossed on it) but it is swapped with the upper one.

You can test this issue by rebooting your radio in bootloader mode
(turning on the radio while pressing the PTT and the key above it)
and flashing the keyboard demo on the radio using the following commands:

cp tests/platform/print_keys.c openrtx/src/main.c
meson setup --cross-file cross_arm.txt build_arm
meson compile -C build_arm openrtx_mduv380_flash

feature: Wrap selection when scrolling up from top of list

Latest nightly, v0.3.2-82-g2bb05a2f. TYT MD-UV390.

Opening the Zone menu, I can't scroll up to get to items at the bottom, not with the up/down buttons or the clicker knob. Maybe this is just what I'm used to from the stock firmware but it's pretty handy when you have a lot of zones or channels and want one near the bottom.

FYI. Stack pointer add should probably be on a 4 byte boundary

Guys

I noticed that you set the SP to 1 byte below the top of RAM.

https://github.com/n1zzo/OpenDMR/blob/master/linkerscripts/linker_script.ld#L15

FYI.
I found out that bootloader won't load the application if the SP is set to the top of RAM, so I understand you can't use the normal SP adddress

However, I'd advise that you change this to 4 bytes below the top of RAM, rather than 1 byte, because its a 32 bit processor and things just work better / faster if you align everything to 4 byte boundaries.

I know you loose 3 bytes of RAM if you do this, but I think its worth the sacrifice ;-)

UI locks up when changing mode to M17

When running commit c0486fe on my MD-UV380/RT3S, the UI locks up after changing the mode through the Macro-menu away from M17 and back to M17. Pressing PTT refreshes the screen and gets me back to the main screen, but other key inputs don't register. Furthermore, while the RF signal looks fine, the M17 signal does not demodulate anymore. Turning the radio off via the volume knob does not work. After taking out the battery, the radio is working fine and the transmitted M17 stream is decoded again.

FM mode, Squelch not working as expected

Hardware: MD-380G UHF, no modifications.
OpenRTX builds: Both v0.3.2 release, and the nightly build from 2021-10-16 (v0.3.2-82-g2bb05a2f) show this problem.

Description:
When the radio first turns on, the squelch is wide open, and receives as normal, but never closes. I hear noise when not transmitting on the other radio.

But as soon as I transmit on the MD380, the squelch closes and never re-opens. Transmitting again on the other radio, I see the S-meter on the MD380 move, but I don't hear any audio.

The behavior doesn't change whether I have CTCSS decode enabled or disabled, it's the same.

encryption

Hello,

Wy don't you modify the OpenRTX code, to allow to add new encryption algorithm if we want to use better crypto ?

Satellite Tracking with Doppler Shift Correction

@tarxvftech is working on implementing satellite tracking for OpenRTX, to work the LEO satellites with just your radio.
Please ask for any support here and link the PR eventually.

Cannot compile Linux target on aarch64

Compiling the Linux target on an aarch64 machine fails because the Linux uC/OS III port contains x86-64 assembly code.

The compilation fails with the following error

pinephone:~/Clone-Room/OpenRTX$ meson compile -C build_linux openrtx_linux
Found runner: ['/usr/bin/ninja']
ninja: entering directory 'build_linux'
[1/2] Compiling C object openrtx_linux.p/platform_targets_linux_emulator_emulator.c.o
ninja: job failed: cc -Iopenrtx_linux.p -I. -I.. -I../openrtx/include -I../openrtx/include/calibration -I../platform/drivers/ADC -I../platform/drivers/NVM -I../platform/drivers/tones -I../openrtx/include/fonts/adafruit -I../platform/drivers/baseband -I../rtos/uC-OS3/Source -I../rtos/uC-OS3/Cfg -I../rtos/uC-CPU -I../rtos/uC-CPU/Cfg -I../rtos/uC-LIB -I../rtos/uC-LIB/Cfg -I../rtos/uC-OS3/Ports/POSIX -I../rtos/uC-CPU/Posix -I../platform/targets/linux -I../platform/targets/linux/emulator -I/usr/include/SDL2 -I/usr/include/directfb -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -Wpedantic -g -pthread -D_REENTRANT -DDONT_USE_CMSIS_INIT -DSCREEN_WIDTH=160 -DSCREEN_HEIGHT=128 -DPIX_FMT_RGB565 -MD -MQ openrtx_linux.p/platform_targets_linux_emulator_emulator.c.o -MF openrtx_linux.p/platform_targets_linux_emulator_emulator.c.o.d -o openrtx_linux.p/platform_targets_linux_emulator_emulator.c.o -c ../platform/targets/linux/emulator/emulator.c
{standard input}: Assembler messages:
{standard input}:594: Error: unknown mnemonic `xorl' -- `xorl %ebp,%ebp'
{standard input}:595: Error: operand 1 must be an integer register -- `mov %RDX,%R9'
{standard input}:596: Error: unknown mnemonic `popq' -- `popq %rsi'
{standard input}:597: Error: operand 1 must be an integer register -- `mov %RSP,%RDX'
{standard input}:598: Error: operand 1 must be an integer or stack pointer register -- `and $~15,%RSP'
{standard input}:599: Error: unknown mnemonic `pushq' -- `pushq %rax'
{standard input}:600: Error: unknown mnemonic `pushq' -- `pushq %rsp'
{standard input}:601: Error: operand 1 must be an integer register -- `mov __libc_csu_fini@GOTPCREL(%rip),%R8'
{standard input}:602: Error: operand 1 must be an integer register -- `mov __libc_csu_init@GOTPCREL(%rip),%RCX'
{standard input}:603: Error: operand 1 must be an integer register -- `mov emulator_main@GOTPCREL(%rip),%RDI'
{standard input}:604: Error: unknown mnemonic `call' -- `call *__libc_start_main@GOTPCREL(%rip)'
{standard input}:605: Error: missing immediate expression at operand 1 -- `hlt'
ninja: subcommand failed

gfx_print does not print dots on ARM targets

Calling gfx_print on ARM targets seems not printing dots ('.') eventually present in strings, while on x64 targets it does. By now, a temporary workaround is putting an 1ms delay as first operation in function body.

RT3S can't update codeplug

Just flashed the latest fw 5ffd6e5.

Unfortunately I can't update my codeplug. I tried with the original Retevis software and also with qdmr. Qdmr says recognizes the radio and also when I click "Verify" it returns success.

RT3S incorrect voltage

My battery indicator is (almost) fully green. Settings->Info gives 85%. Voltage is 6.9 to 6.10 (something wrong here...?).
However I checked the battery terminals w/ the multimeter and the voltage is 7.16V. How does the firmware checks the voltage?

MD390G: RX does not work

I can transmit on the MD390G, but receiving does not work.

Neither the LED goes on, nor do I hear any audio.

Squelch level at boot dependent on knob position in MD380/MD390/RT3

On all the radios having a knob with absolute encoder, squelch level is set equal to the knob position detected at boot. This can lead to have squelch level equal to zero at startup, which is not always a good thing.
The fix for this is removing lines 75-77 in openrtx/src/state.c, leaving only default initialisation of squelch level to S3.

Allow spaces in callsign for gateway control

I wasn't able to input a space for the Dst ID. This is required for m17gateway control (e.g. "M17-USA A"). I made this change and tested it with the latest build of M17Gateway:

diff --git a/openrtx/src/ui/ui.c b/openrtx/src/ui/ui.c
index 141f6f1..4eb4f85 100644
--- a/openrtx/src/ui/ui.c
+++ b/openrtx/src/ui/ui.c
@@ -203,7 +203,7 @@ const char *symbols_ITU_T_E161[] =
 
 const char *symbols_ITU_T_E161_callsign[] =
 {
-    "0",
+    "0 ",
     "1",
     "ABC2",
     "DEF3",

Implement input audio stream driver for linux platform

The driver for audio input stream on linux is only a stub, implement it so that it reads data from binary files.

Requirements:

• Implement the behavior described in this header file: https://github.com/OpenRTX/OpenRTX/blob/master/openrtx/include/interfaces/audio_stream.h
• Input comes from files and is read as a binary stream of signed 16-bit values (int16_t).
• The driver API allows to specify different sources, this is mapped by opening files whose filename is the source. For example, we can have files named iStream_RTX.raw, iStream_MIC.raw, ...
• the driver can be written both in C or C++
• driver has to simulate the an hardware sampling analog values with the sample rate set from the API. On x86/x64 this simply translates in putting the caller in waiting for bufLength * sampleRate when the getData function is called.
• code has to follow these guidelines: https://github.com/OpenRTX/openrtx.github.io/blob/master/coding_style.md

GD-77/DM-1801: GLIBC version of scripts/bin2sgl.Linux.bin

Hi, I am trying to build OpenRTX for DM-1801 on Debian11.3/amd64 virtual machine.
But it aborts with following error.

uaa@debian-vm:~/OpenRTX$ meson compile -C build_arm openrtx_gd77_flash
ninja: Entering directory `/home/uaa/OpenRTX/build_arm'
[68/71] Linking target openrtx_gd77
Memory region         Used Size  Region Size  %age Used
           flash:      141648 B       494 KB     28.00%
             ram:        6128 B       128 KB      4.68%
[70/71] Generating openrtx_gd77_wrap with a custom command
FAILED: openrtx_gd77_wrap.sgl
/home/uaa/OpenRTX/scripts/bin2sgl.Linux -f openrtx_gd77_bin && mv openrtx_gd77_bin.sgl openrtx_gd77_wrap.sgl
/home/uaa/OpenRTX/scripts/bin2sgl.Linux.bin: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /home/uaa/OpenRTX/scripts/bin2sgl.Linux.bin)
/home/uaa/OpenRTX/scripts/bin2sgl.Linux.bin: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /home/uaa/OpenRTX/scripts/bin2sgl.Linux.bin)
ninja: build stopped: subcommand failed.
uaa@debian-vm:~/OpenRTX$ 

I think it can be solved with rebuilding this binary. Is there any source code for this?
And, target dm1801_flash is not accepted.

uaa@debian-vm:~/OpenRTX$ meson compile -C build_arm openrtx_dm1801_flash
ninja: Entering directory `/home/uaa/OpenRTX/build_arm'
[2/3] Generating openrtx_dm1801_wrap with a custom command
Adding segment 0x0800c000 from file openrtx_dm1801_bin
Done!
[3/3] Generating openrtx_dm1801_flash with a custom command
FAILED: openrtx_dm1801_flash
/home/uaa/OpenRTX/subprojects/radio_tool/./radio_tool -d 0 -f -i openrtx_dm1801_wrap
Error: Radio not supported
ninja: build stopped: subcommand failed.
uaa@debian-vm:~/OpenRTX$ 

Double free on M17 Rx

M17-dev branch on MD380 freezes when radio mode is cycled from M17 to something else back into M17,
symptom of a likely double free somewhere in the code.

I get this asan error on linux, which might be related:

>radio_linux: init() called
radio_linux: updateConfiguration() called
radio_linux: setting opmode to M17
radio_linux: updateConfiguration() called
radio_linux: disableRtx() called
AddressSanitizer:DEADLYSIGNAL
=================================================================
==159446==ERROR: AddressSanitizer: SEGV on unknown address 0x0000000002d0 (pc 0x7f4d1a272fd2 bp 0x7f4d05281ba0 sp 0x7f4d05281b20 T16)
==159446==The signal is caused by a READ memory access.
==159446==Hint: address points to the zero page.
    #0 0x7f4d1a272fd2 in __pthread_clockjoin_ex (/usr/lib/libc.so.6+0x8efd2)
    #1 0x556a3865f6c6 in codec_stop ../openrtx/src/core/audio_codec.c:127
    #2 0x556a38681199 in OpMode_M17::update(rtxStatus_t*, bool) ../openrtx/src/rtx/OpMode_M17.cpp:91
    #3 0x556a3867be2f in rtx_taskFunc ../openrtx/src/rtx/rtx.cpp:203
    #4 0x556a3864af70 in rtx_task ../openrtx/src/core/threads.c:254
    #5 0x7f4d1a2715c1 in start_thread (/usr/lib/libc.so.6+0x8d5c1)
    #6 0x7f4d1a2f6583 in __clone (/usr/lib/libc.so.6+0x112583)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/usr/lib/libc.so.6+0x8efd2) in __pthread_clockjoin_ex
Thread T16 created by T0 here:
    #0 0x7f4d1b44eeb7 in __interceptor_pthread_create /usr/src/debug/gcc/libsanitizer/asan/asan_interceptors.cpp:216
    #1 0x556a3864b44c in create_threads ../openrtx/src/core/threads.c:340
    #2 0x556a386a9a71 in main ../openrtx/src/main.c:78
    #3 0x7f4d1a21130f in __libc_start_call_main (/usr/lib/libc.so.6+0x2d30f)

==159446==ABORTING

Frequency change at power-on

After powering the radio on, the frequency changes by +12.5 kHz.

This bug affects MD-380 only.

Module17 - incorrect baseband output voltage at idle

The DAC used for baseband doesn't seem to idle at Vcc/2 at RX. It only briefly goes to Vcc/2 at TX (PTT button press) before and after the transmission. See attached scope screenshots.
This causes carrier to drift for the first few seconds of the transmission. See SDR++ screenshot below.

MD-UV380: Black screen after splash screen

Introduction

The current OpenRTX main.c should show a VFO interface.
This is done by employing several concurrent threads (tasks in uC/OS III naming) that manage various aspects of the radio:

• UI
• Radio baseband
• Platform state

Problem

After introducing the threads in commit 67622d6 I observed a regression in the MD-UV380 radio.
When booting the radio I see the splash screen and then a black screen instead of the VFO screen.

Other details

By experimenting with a demo I noticed two anomalies:

• The OS sleeps seemed to last much less than the specified time
• The device seems to hang after few seconds

Implement Font Antialiasing

@AlexandreRouma is working on implementing font antialiasing for OpenRTX for better readability.
Please ask for any support here and link the PR eventually.

Initial carrier offset when transmitting M17 after boot

When transmitting M17 for the first time after boot, a negative offset can be noticed on the carrier.
The carrier starts at the equivalent of -3 symbol and slowly fades away, leaving only regular M17 signal.

The offset appears only once after boot, it does not appears on later M17 transmissions.

Display brightness setting

Since settings are not volatile anymore, you should prevent users from turning off the display's backlight (PWM=0).

CTCSS decode not working?

Latest nightly, v0.3.2-82-g2bb05a2f. TYT MD-UV390.

Transmitting from a GMRS Midland radio with a CTCSS tone of 10, which should be 94.8 Hz (and worked on my radio with stock firmware), OpenRTX shows strength indication and flashes the light, but no audio is received. Switching to a non-decode mode from the Macro menu (Handy!), audio works as expected. CTCSS encode appears to work as expected also.

RTX not updated when switching from MEM to VCO mode

When switching back from MEM to VFO mode the RTX configuration is not updated to the last VCO state until either the frequency or any other setting involving the RTX part is changed.
This can be easily spotted on linux emulator: when switching from MEM to VFO the radio_updateConfiguration function is never called, even if it should be.

flash compile error

hello

i tyr final flash compile meson compile -C build_arm openrtx_md380_flash
get error ERROR: Can't invoke target openrtx_md380_flash: target not found but unknown what problem :(

[question] trouble compiling

Hi,

last time I compiled OpenRTX (10 months ago), I did it like this:

meson setup --cross-file cross_arm.txt build_arm
ninja -C build_arm openrtx_md390_bin -j2
radio_tool --wrap -o build_arm/openrtx_md390_wrap -r MD380 -s 0x0800C000:build_arm/openrtx_md390_bin
radio_tool -d 0 -f -i build_arm/openrtx_md390_wrap

However, now

meson setup --cross-file cross_arm.txt build_arm

results in

ERROR: Malformed value in cross file variable cpp_link_args.

and

meson compile -C build_arm openrtx_MD390

results in

usage: meson [-h] {setup,configure,dist,install,introspect,init,test,wrap,subprojects,help,rewrite} ...
meson: error: unrecognized arguments: -C build_arm openrtx_MD390

Have there been any changes in the last 10 months that mean I need to do something differently?

Tried on Ubuntu 20.04 LTS running

% meson --version
0.53.2
% ninja --version
1.10.0

I'm not a dev, so I don't really know what this is trying to tell me. :/

Crash on Linux

When running OpenRTX on Linux, most of the times the execution crashes with a buffer overflow error.

This is the traceback obtained when executing with address sanitizer enabled

=================================================================
==16690==ERROR: AddressSanitizer: global-buffer-overflow on address 0x55adff52e340 at pc 0x55adff4cfc8e bp 0x7f80996b8b40 sp 0x7f80996b8b30
READ of size 8 at 0x55adff52e340 thread T12
    #0 0x55adff4cfc8d in OSSched ../rtos/uC-OS3/Source/os_core.c:452
    #1 0x55adff4d9b60 in OSMutexPend ../rtos/uC-OS3/Source/os_mutex.c:508
    #2 0x55adff4cb69c in ui_task ../openrtx/src/threads.c:145
    #3 0x55adff4f7dd8 in OSTaskPosix ../rtos/uC-OS3/Ports/POSIX/os_cpu_c.c:650
    #4 0x7f80acc473e8 in start_thread (/usr/lib/libpthread.so.0+0x93e8)
    #5 0x7f80acb75292 in __GI___clone (/usr/lib/libc.so.6+0x100292)

0x55adff52e340 is located 0 bytes to the right of global variable 'OSRdyList' defined in '../rtos/uC-OS3/Source/os.h:1207:45' (0x55adff52dd40) of size 1536
0x55adff52e340 is located 32 bytes to the left of global variable 'OSSchedLockNestingCtr' defined in '../rtos/uC-OS3/Source/os.h:1220:45' (0x55adff52e360) of size 1
  'OSSchedLockNestingCtr' is ascii string ''
SUMMARY: AddressSanitizer: global-buffer-overflow ../rtos/uC-OS3/Source/os_core.c:452 in OSSched
Shadow bytes around the buggy address:
  0x0ab63fe9dc10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab63fe9dc20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab63fe9dc30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab63fe9dc40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab63fe9dc50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0ab63fe9dc60: 00 00 00 00 00 00 00 00[f9]f9 f9 f9 01 f9 f9 f9
  0x0ab63fe9dc70: f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9 01 f9 f9 f9
  0x0ab63fe9dc80: f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 02 f9 f9 f9
  0x0ab63fe9dc90: f9 f9 f9 f9 01 f9 f9 f9 f9 f9 f9 f9 02 f9 f9 f9
  0x0ab63fe9dca0: f9 f9 f9 f9 02 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9
  0x0ab63fe9dcb0: f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
Thread T12 created by T6 here:
    #0 0x7f80ace4d1c7 in __interceptor_pthread_create /build/gcc/src/gcc/libsanitizer/asan/asan_interceptors.cpp:214
    #1 0x55adff4f8175 in OSThreadCreate ../rtos/uC-OS3/Ports/POSIX/os_cpu_c.c:724
    #2 0x55adff4f6fcc in OSTaskCreateHook ../rtos/uC-OS3/Ports/POSIX/os_cpu_c.c:251
    #3 0x55adff4e1c31 in OSTaskCreate ../rtos/uC-OS3/Source/os_task.c:417
    #4 0x55adff4cbf81 in create_threads ../openrtx/src/threads.c:316
    #5 0x55adff4ced54 in main ../openrtx/src/main.c:66
    #6 0x55adff4c8791 in startTask ../openrtx/src/bootstrap.c:86
    #7 0x55adff4f7dd8 in OSTaskPosix ../rtos/uC-OS3/Ports/POSIX/os_cpu_c.c:650
    #8 0x7f80acc473e8 in start_thread (/usr/lib/libpthread.so.0+0x93e8)

Thread T6 created by T2 here:
    #0 0x7f80ace4d1c7 in __interceptor_pthread_create /build/gcc/src/gcc/libsanitizer/asan/asan_interceptors.cpp:214
    #1 0x55adff4f8175 in OSThreadCreate ../rtos/uC-OS3/Ports/POSIX/os_cpu_c.c:724
    #2 0x55adff4f6fcc in OSTaskCreateHook ../rtos/uC-OS3/Ports/POSIX/os_cpu_c.c:251
    #3 0x55adff4e1c31 in OSTaskCreate ../rtos/uC-OS3/Source/os_task.c:417
    #4 0x55adff4c8759 in systemBootstrap ../openrtx/src/bootstrap.c:53
    #5 0x55adff4f4e46 in startRadio ../platform/targets/linux/emulator/emulator.c:79
    #6 0x7f80acc473e8 in start_thread (/usr/lib/libpthread.so.0+0x93e8)

Thread T2 created by T0 here:
    #0 0x7f80ace4d1c7 in __interceptor_pthread_create /build/gcc/src/gcc/libsanitizer/asan/asan_interceptors.cpp:214
    #1 0x55adff4f4ffb in emulator_main ../platform/targets/linux/emulator/emulator.c:123
    #2 0x7f80aca9d151 in __libc_start_main (/usr/lib/libc.so.6+0x28151)

==16690==ABORTING

Issues with MD-380

On some versions of MD-380 targets we have:

• flipped screen
• RX not working
• TX working but with a ~20Hz noise superimposed to audio

Affected devices having:

• SW version ≥ S13.032
• HW version ≥ 1704Axxxx

Single "UP" keypress generated at boot on MD-3x0

When powered on, MD-3x0 exhibit a single "UP" key press increasing the VFO frequency of one step (12.5kHz).
MD-UV3x0 is not affected by the same phenomenon, which is probably due to a bug in the management of the absolute encoder connected to the channel knob.

Add Bluetooth BLE to UART module

When I checked the PCB of MD-380, I found that the version without GPS has reserved a blank position. I hope to add a Bluetooth module here for UART communication between the radio and the mobile phone.

I found a Bluetooth module of similar size, made a converted PCB, and installed it on the radio.
module information is here: https://www.ebyte.com/downpdf.aspx?id=1055

The program is now being debugged.

I want to hear your opinions, how about this function?

TYT MD-UV390 can only monitor single channel?

I didn't see this in the capability notes, and I didn't see that there was a way to restore this functionality in the user docs... But is it accurate that OpenRDX right now doesn't work to monitor multiple channels? I'm sorry i don't know the name for this... but in the original firmware you had two "slots" that could independently be channels/frequencies, and you could switch between them and tune them individually. You could for instance have two repeaters in those slots, so that if there were any transmissions from either repeater you'd hear it. It's what the up/down arrows are for on the main screen, switching between those two channels.

Can't compile

Anyone know what this issue is?

%>meson setup --cross-file cross_arm.txt build_arm

ERROR: Malformed value in cross file variable cpp_link_args.

No M17 audio output after Tx

On my Module17 running commit ID 9eee161 I only get demodulated M17 audio out before I press PTT once. Afterwards, it looks like the audio stream is not being processed properly. The sync LED still lights up, but nothing gets put out through the speaker

DM-1701

Hi,

What would be the process for testing this firmware on a new device, i dont really know where to start on this, i already tried to flash this on the device but it doesnt boot so i assume the offsets may be wrong or maybe even things are wired differently.

Here is a picture of the internals:

MD380: radio does not transmit with the external PTT signal

While recording the videos on #40 (comment) I realized than once I flashed the radio with OpenRTX it was no longer transmitting with the external PPT signal. As can be see in the second video, I had to pick the radio in my hand and press the PTT on the radio body.

The radio is a Retevis RT3 UHF

Selected menu item resets to "Zone" when gps is active.

The selected menu item will jump back to the top, selecting "Zone". It seems to happen when the gps has been enabled. I thought it might happen when the gps was on but didn't have a fix, but I've observed the bug while the gps has a fix as well.

With the bug happening, I got the gps turned back off. Note that you can select other menu items if you time it right. With the gps off the bug immediately disappeared. When I re-enabled the gps, it was frozen with a previous fix. The radio otherwise seemed to be working correctly, though I only tested menus, not RX/TX.

Hardware: RT3s w/gps

Repro steps:

1. Power radio on
2. Enable GPS in a location where it can see SVs. It doesn't seem to occur when there are no sats.
3. Go to main menu, select any item other than zone.
4. Wait for the selected item to jump back to zone. Typically in a second or two.

Need for NF filtering?

Hello,
on a MMDVM board, there are a two stage opamp filter and two level adjust potentiometers on the receive path in front of the A/D-Converter of the microcontroller. As far as I understand, in your suggested MD380-Mod, you are connecting the discrimiminator more or less directly to the A/D-Pin of the STM. Why is in your case no need for filtering and level adjustment?
Thanks
Christian DB9CR

RTOS / toolchain feasibility

Hello fellow hams and developers!
Thanks for your great work. This is an interesting and very poorly documented field. I understand the numerous obstac;les we have to pass, just to make a single radio boot up.
This is not an issue, but a query out of my own curosity as a developer.

Could you explain, for example:

• OS: the background behind choosing a Miosix kernel for this development? Are we relying on some parts of the original radio firmware, and therefore need to build upon it, using the same OS? My question can also be formulated like this: without going into it's well known (dis)advantages right now, why not, for example, FreeRTOS?

• Toolchain: I'm not sure about each radio, but the majority of the interesting ones seem to be running STM32 these days. So, once more, I am curious why not using StmCubeIDE from ST?

• Hardware: I understand that manufacturers would like to prevent us from loading anything into their precious products (although 90% of the brands are not really manufactoring or developing anything :-) ). Therefore we have lack of documentation, obscure baseband chips, encrypted firmware images and other obstacles. So my question is: during the development phase, why not use JTAG interface to directly program the mcu? We could skip the whole cycle of wrapping, encrypting and downloading with yet-another-tool before running the latest code. When the work is done (if ever :-) ) the final fw image could be packed and released to the public, to be used with the radio's official upgrade tool.
  Apart from easing the testing, this could also attract more developers who may be put off by the numerous steps involved and the steep learning curve for each. In my own personal case, I am quite interested to get involved, but not keen on spending a lot of time to set up the n-th toolchain for this-or-that, of the many things I am trying to tackle. On the other hand, for the stm32, I have the IDE, in-circuit debugger and free rtos knowledge, where I could start today. Ofcourse, they are all free of charge. Well, that's just my own personal oppinion.

By the way, I own an RT84 with specs quite similar to RT3s and md-uv380. The firmware for rt84 is identical to Baofeng 1701 (and another popular model, I can't remember right now). I prooved this by downloading from their manufacturer's support page and comparing the sha-512 checksums. RT84 uses an stm32 and, based on the checksum fact, it's a safe quess that both the mcu and the baseband hr_c6000 is also the same in those.

Thanks to anyone taking the time to comment.

yt1zkb

Battery level iusse

During debug of my radio i saw that the level of battery go down when i push the ptt and going in transmission.
The battery in openrtx firmware is at middle level on original is on full level.
When i push the level going down for all trasmitting period.
If i continue to push and release push and release appear the battery icon and the radio shut down.
Thanks for your great work.
Roberto - IU2IOL -

Module17 - optional phase inversion

As some radios like to invert phase at both tx and rx, it would be wise to have an option to enable phase inversion in software.

Decode CTCSS tone not working on md-uv3x0

Tested on: Retevis RT3s

The CTCSS tone is set to D or E+D from the macro menu.
When transmitting with a second radio with the corresponding TX CTCSS tone (71.9 in my case) enabled,
no sound is heard on the receiving radio.