diff --git a/M17/md380_mods.md b/M17/md380_mods.md index b2969a4..b7433f9 100644 --- a/M17/md380_mods.md +++ b/M17/md380_mods.md @@ -1,18 +1,17 @@ ## M17 on the MD-380 -We are bringing experimental M17 support to the TYT MD-380 DMR radio. However, due to technical limitations of the underlying hardware, transmitting M17 audio on the radio requires two small hardware modifications. +We are bringing experimental M17 support to the TYT MD-380 DMR radio. However, due to technical limitations of the underlying hardware, transmitting and receiving M17 on the radio requires two small hardware modifications. # __WARNING__ -This guide has been updated on **01/06/2022**, if you already performed the mod before the update, you will have to perform a small modification to update your mod! \ -The changes between the old and the new mod are **highlighted in yellow**, so check if they match the state of your hardware. -What has changed between the old mod and the new mod is the value and position of the resistor, and the additional removal of a capacitor. +This guide has been updated on **1 June 2022**, if you already performed the mod before the update, you will have to perform a small modification to update your mod! \ +What has changed is the additional removal of the C556 capacitor from the RF side of the PCB, described at the end of the RF → MCU section. For questions join our [community chat](get_in_touch.md), or write us an [email](https://openrtx.org/#/?id=the-openrtx-project). ### Equipment required To perform the Mic → MCU and RF → MCU mods you need: -- Screwdrivers: Torx T6, Torx T8, Philips #0 +- Screwdrivers: Torx T6, Torx T8, Phillips #0 - Plastic spudger like [this](https://it.aliexpress.com/item/32834353313.html) or similar -- 1x 50KΩ SMD (Surface Mount Device) resistor with at least 5% tolerance +- 1x 50 kΩ SMD (Surface Mount Device) resistor with tolerance of 5% or better. - some 30AWG Kynar wire - A small tip soldering iron - A desoldering pump or solder wick @@ -36,7 +35,7 @@ To perform the Mic → MCU and RF → MCU mods you need: The **RF → MCU mod requires also accessing the RF side of the PCB**, the one which faces the heat sink. -- Remove the 11 Philips #0 screws from the logic side of the PCB \ +- Remove the 11 Phillips #0 screws from the logic side of the PCB \ - Remove the 2 Torx T6 screws from the side button PCB \ - Desolder the antenna connector \ The antenna connector is fixed to the heat sink with two screws, @@ -71,8 +70,8 @@ After the modification: Lastly, since STM32 ADCs can only measure positive voltages, to be able to capture the full audio signal we need a DC biased microphone signal. We are going to take the microphone signal at R158 which is DC biased in the range 0-5V and bridge it to R118 where we want an input range of 0-3.3V. -We recommend to do so by applying a 50KΩ resistor between *C161 or C162 or both* and the microphone signal path, accessible on one of the pads of the EC151 capacitor we just removed. -If you don't have a 50KΩ resistor, anything in the range [40-60]KΩ will work. +We recommend to do so by applying a 50 kΩ resistor between *C161 or C162 or both* and the microphone signal path, accessible on one of the pads of the EC151 capacitor we just removed. +If you don't have a 50 kΩ resistor, anything in the range [40-60] kΩ will work. Finally, remove the C115 capacitor. Here is a picture of the applied modification: @@ -96,7 +95,7 @@ In this second part of the mod we'll be working on the lower right portion of th First we will desolder R150: put some flux, heat one side of the resistor, slide it away on one side, heat the other side and slide it away on the other side, heat the pads to clean them up. This is how the pads should look like after the resistor has been removed: -![MD-380 After having desoldered R101](../_media/md380_rtx_detail_desolder.jpg) +![MD-380 After having desoldered R150](../_media/md380_rtx_detail_desolder.jpg) Afterward we will bridge with some Kynar wire the left pad of the resistor (2T/5T) with pin 1 of U102, which is the demodulator output. Here is a picture of the finished modification: @@ -109,4 +108,8 @@ The filter can be removed by **desoldering the C556 capacitor from the RF side P ### Results -You can put some drops of hot glue to ensure that the resistor and the Kynar wire stay in place. +- You can put some drops of hot glue to ensure that the resistor and the Kynar wire stay in place. +- Close the heat sink over the PCB, paying attention to the side keys PCB. +- Make sure that the antenna connector is screwed exactly perpendicular to the rest of the radio. +- Solder the antenna connector pin. +- Reassemble the radio by following the disassembly instructions backwards. diff --git a/M17/mduv380_mods.md b/M17/mduv380_mods.md index 40045c3..e8aade7 100644 --- a/M17/mduv380_mods.md +++ b/M17/mduv380_mods.md @@ -10,16 +10,16 @@ There are two audio paths that require some hardware modifications: - RF → MCU: Requires hardware mod # __WARNING__ -This guide has been updated on **18/09/2021**, if you already performed the mod before the update, you will have to perform a small modification to update your mod! \ -The changes between the old and the new mod are **highlighted in yellow**, so check if they match the state of your hardware. +This guide has been updated on **18 September 2021**, if you already performed the mod before the update, you will have to perform a small modification to update your mod! \ +The changes between the old and the new mod are **highlighted in bold**, so check if they match the state of your hardware. What has changed between the old mod and the new mod is the value and position of the resistor, and the additional removal of a capacitor. For questions join our [community chat](get_in_touch.md), or write us an [email](https://openrtx.org/#/?id=the-openrtx-project). ### Equipment required To perform the Mic → MCU and RF → MCU mods you need: -- Screwdrivers: Torx T6, Torx T8, Philips #0 +- Screwdrivers: Torx T6, Torx T8, Phillips #0 - Plastic spudger like [this](https://it.aliexpress.com/item/32834353313.html) or similar -- 1x **50KΩ SMD (Surface Mount Device)** resistor with at least 5% tolerance +- 1x **50 kΩ SMD (Surface Mount Device)** resistor with tolerance of 5% or better - some 30AWG Kynar wire - A small tip soldering iron - A desoldering pump or solder wick @@ -46,7 +46,7 @@ To perform the Mic → MCU and RF → MCU mods you need: Both mods (Mic → MCU and RF → MCU) require accessing the RF side of the PCB, the one which faces the heat sink. -- Remove the 11 Philips #0 screws from the logic side of the PCB \ +- Remove the 11 Phillips #0 screws from the logic side of the PCB \ ![MD-UV380 back screws](../_media/uv380_back_screws.jpg) - Remove the 2 Torx T6 screws from the side button PCB \ ![MD-UV380 side screws](../_media/uv380_side_screws.jpg) @@ -89,10 +89,10 @@ Steps: ![MD-UV380 Mic mod capacitor removal](../_media/uv380_mic_cap_remove.jpg) - **Cover the PCB in Kapton tape leaving the left pad of the first capacitor you removed accessible.** \ ![MD-UV380 Mic mod adding kapton](../_media/uv380_mic_kapton.jpg) -- **Solder the 50KΩ SMD resistor on the left pad of EC151.** \ +- **Solder the 50 kΩ SMD resistor on the left pad of EC151.** \ ![MD-UV380 Mic mod soldering resistor](../_media/uv380_mic_resistor.jpg) - **Solder a piece of Kynar wire from the right pad of the resistor you just soldered to C161 or C162 or both.** \ -![MD-UV380 Mix mod finished](../_media/uv380_mic_wire.jpg) +![MD-UV380 Mic mod finished](../_media/uv380_mic_wire.jpg) **The Mic → MCU mod is now complete, go share it on your favourite social network!** diff --git a/NVM.md b/NVM.md index b53b834..a2d5272 100644 --- a/NVM.md +++ b/NVM.md @@ -18,7 +18,7 @@ It also implements the following functions defined in interfaces/nvmem.h * the nvm_getDesc that returns an nvmDescriptor given a device number * the nvm_readCalib that populates a given buffer with the calibration data * the nvm_readHwInfo that populates a hwInfo_t structure using data stored in nvm devices - * int nvm_readVFOChannelData that reads the last saved VFO state + * the nvm_readVFOChannelData that reads the last saved VFO state * nvm_readSettings/nvm_writeSettings that reads/writes the device settings (callsign, accessibility settings, ...) * nvm_writeSettingsAndVfo that writes the current vfo states as well as the device settings @@ -28,7 +28,7 @@ These functions use the functions nvm_read/nvm_write/nvm_erase defined in nvmem_ This layer implements the driver for a particular non-volatile memory device. -An NVM device is represented by an nvmDevice structure. This structure contains pointers to an information structure and an ops structure. It also contains a priv pointer that is differently by each driver. +An NVM device is represented by an nvmDevice structure. This structure contains pointers to an information structure and an ops structure. It also contains a priv pointer that is used differently by each driver. ### ops structure diff --git a/README.md b/README.md index 58d2d11..9693dc2 100644 --- a/README.md +++ b/README.md @@ -30,11 +30,11 @@ If you are interested in keeping updated with the latest news or you want to joi #### Acknowledgments: -All this was made possible by the huge reverse engineering effort of Travis Goodspeed and of all the contributors of [md380tools](https://github.com/travisgoodspeed/md380tools), which provided a valuable starting point when we moved our first steps with the MD-380. +All this was made possible by the huge reverse engineering effort of Travis Goodspeed and of all the contributors of [md380tools](https://github.com/travisgoodspeed/md380tools), which provided a valuable starting point when we took our first steps with the MD-380. Thanks to Roger Clark VK3KYY and all the contributors of the [OpenGD77](http://opengd77.com/) project which both inspired this project and, as a precursor, provided a working code example for the GD77 radio family. -A warm thank goes also to Wojciech Kaczmarski SP5WWP and the [M17](https://m17project.org) community for collaboration and support given during the long process of implementing the M17 protocol in our firmware. +Warm thanks also go to Wojciech Kaczmarski SP5WWP and the [M17](https://m17project.org) community for collaboration and support given during the long process of implementing the M17 protocol in our firmware. Also thanks for donating hardware to the project to: * M17 Project diff --git a/at1846_registers.md b/at1846_registers.md index fafec78..0b3cafa 100644 --- a/at1846_registers.md +++ b/at1846_registers.md @@ -18,7 +18,7 @@ ##### 0x0A bit | function | notes --- | --- | --- - 5:0 | PA bias voltage | 000000: 1.01V
000001:1.05V
000010:1.09V
000100: 1.18V
001000: 1.34V
010000: 1.68V
100000: 2.45V
1111111:3.13V + 5:0 | PA bias voltage | 000000: 1.01V
000001:1.05V
000010:1.09V
000100: 1.18V
001000: 1.34V
010000: 1.68V
100000: 2.45V
111111: 3.13V ##### 0x0F @@ -29,7 +29,7 @@ ##### 0x1F bit | function | notes --- | --- | --- -14:15 | GPIO7 mode | 00 = hi-z
01 = vox
10 = low
11 = high +15:14 | GPIO7 mode | 00 = hi-z
01 = vox
10 = low
11 = high 13:12 | GPIO6 mode | 00 = hi-z
01 = squelch or squelch & CTC/DCS when sq_out_sel = 1
10 = low
11 = high 11:10 | GPIO5 mode | 00 = hi-z
01 = txon_rf
10 = low
11 = high 9:8 | GPIO4 mode | 00 = hi-z
01 = rxon_rf
10 = low
11 = high @@ -51,12 +51,12 @@ ##### 0x2B bit | function | notes --- | --- | --- -15:0 | reference clock frequency in kHz | 12\~14MHz: crystal freq1000
24\~ 28MHz: (crystal freq/2)1000 +15:0 | reference clock frequency in kHz | 12\~14MHz: crystal freq (MHz) × 1000
24\~28MHz: (crystal freq (MHz) / 2) × 1000 ##### 0x2C bit | function | notes --- | --- | --- -15:0 | ADC clock frequency in kHz | 12\~14MHz: crystal freq1000
24\~ 28MHz: (crystal freq/2)1000 +15:0 | ADC clock frequency in kHz | 12\~14MHz: (crystal freq (MHz) / 2) × 1000
24\~28MHz: (crystal freq (MHz) / 4) × 1000 ##### 0x2D bit | function | notes @@ -67,7 +67,7 @@ 6 | dtmf_idle interrupt enable | 5 | ctcss phase shift detect int. enable | 4 | idle state time out int. enable | - 3 | rxon_rf timerout interrupt enable | + 3 | rxon_rf timeout interrupt enable | 2 | sq interrupt enable | 1 | txon_rf time out interrupt enable | 0 | vox interrupt enable | @@ -87,12 +87,12 @@ ##### 0x35 bit | function | notes --- | --- | --- -15:0 | DTMF tone freq 1 | register_value = freq (2^12) +15:0 | DTMF tone freq 1 | register_value = freq (kHz) × 2^12 ##### 0x36 bit | function | notes --- | --- | --- -15:0 | DTMF tone freq 2 | register_value = freq (2^12) +15:0 | DTMF tone freq 2 | register_value = freq (kHz) × 2^12 ##### 0x3C bit | function | notes @@ -130,8 +130,8 @@ set to 01)
11 = not Tx any signal 10 | enable CTC/DCS detection | 7 | enable CDCSS inverse code detect | 4 | CDCSS code selection | 1 = 24 bit code
0 = 23 bit code - 3 | CTCSS code selection | 1 = ctcss_cmp/cdcss_cmp out via gpio
0 = ctcss/cdcss sdo out vio gpio - 2:0 | CTC/DCS mode selection | 000 = disable
001 = inner ctcss en
010 = inner cdcss en 101 = outer ctcss en
110 = outer cdcss en
others = disable + 3 | CTCSS code selection | 1 = ctcss_cmp/cdcss_cmp out via gpio
0 = ctcss/cdcss sdo out via gpio + 2:0 | CTC/DCS mode selection | 000 = disable
001 = inner ctcss en
010 = inner cdcss en
101 = outer ctcss en
110 = outer cdcss en
others = disable ##### 0x48 bit | function | notes @@ -146,17 +146,17 @@ set to 01)
11 = not Tx any signal ##### 0x4A bit | function | notes --- | --- | --- -15:0 | CTCSS frequency | CTCSS freq = reg_value2^16 khz.
It must be set to 134.4Hz when use standard cdcss mode.
When use ctcss/cdcss, this register must be set both in rx and tx state +15:0 | CTCSS frequency | register_value = CTCSS freq (kHz) × 2^16 (e.g. 97.4 Hz → 0.0974 × 2^16 = 6383).
It must be set to 134.4Hz when use standard cdcss mode.
When use ctcss/cdcss, this register must be set both in rx and tx state ##### 0x4B bit | function | notes --- | --- | --- 7:0 | CDCSS code [23:16] | MSB sent first -##### 0x4A +##### 0x4C bit | function | notes --- | --- | --- -15:0 | CDCSS code [23:16] | +15:0 | CDCSS code [15:0] | ##### 0x54 bit | function | notes @@ -198,8 +198,8 @@ set to 01)
11 = not Tx any signal bit | function | notes --- | --- | --- 9:8 | DTMF mode | 11 = transmit or receive Dtmf single tone2
01 =transmit or receive Dtmf dual tone1+tone2
others = disable - 7:4 | DTMF time 1 | Time interval for dual tone transmission. Time = register_value5ms - 3:0 | DTMF time 2 | Time interval for DTMF idle state. Time = register_value5ms + 7:4 | DTMF time 1 | Time interval for dual tone transmission. Time = register_value × 5ms + 3:0 | DTMF time 2 | Time interval for DTMF idle state. Time = register_value × 5ms ##### 0x66 bit | function | notes diff --git a/binary_cps_format.md b/binary_cps_format.md index 4c0d5e7..2987fb8 100644 --- a/binary_cps_format.md +++ b/binary_cps_format.md @@ -137,7 +137,7 @@ For DMR contacts, this section is laid out in the following manner: | --------------- | ----------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | mode | uint8_t | Operating mode; refer to [Mode lookup table](#mode-lookup-table) | | traits | uint8_t | First two bits are channel bandwidth (refer to [Bandwidth lookup table](#bandwidth-lookup-table)), then one bit indicating true if the channel is RX only | -| power | uint8_t | transmit power, stored as number of fifths dBm added to 10bBm (e.g. a value of 5 would represent 10+5\*0.2=11dBm) | +| power | uint8_t | transmit power, stored as number of fifths dBm added to 10dBm (e.g. a value of 5 would represent 10+5\*0.2=11dBm) | | rx_frequency | uint32_t | RX frequency in Hz | | tx_frequency | uint32_t | TX frequency in Hz | | scanList_index | uint8_t | "Scan List: None, ScanList1...250" | diff --git a/coding_style.md b/coding_style.md index 4f0a186..c49a57e 100644 --- a/coding_style.md +++ b/coding_style.md @@ -4,7 +4,7 @@ This page provides a brief summary of the coding style used in the OpenRTX repos ## General guidelines * Code width must not exceed the limit of 80 columns. -* Variables' must be explicative of their role and written in camel case (i.e. `aVarInCamelCase`) when necessary. +* Variable names must be explicative of their role and written in camel case (i.e. `aVarInCamelCase`) when necessary. * Integer variables must be declared using the following data types, clearly specifying their width: `uint64_t, uint32_t, uint16_t, uint8_t, int64_t, int32_t, int16_t, int8_t`. Use of `char` and `unsigned char` for signed and unsigned 8 bit variables is not allowed. These data types are defined in `stdint.h` and `cstdint` C and C++ headers, respectively. * When multiple conditions connected by logical operators are inside `if` and `while` body, each condition must be surrounded by round brackets ```C @@ -22,7 +22,7 @@ int something = (a * b) + c; ``` ## Code spacing and inlining -* Only spaces are allowed for code indentation and the indentation with amounts to four spaces. +* Only spaces are allowed for code indentation and the indentation width amounts to four spaces. * When multiple variables are defined and/or initialised at subsequent lines, their names and the assignment operators must be aligned. ```C int aVar = 0; @@ -33,7 +33,7 @@ char secondVar = 'c'; int c = a + b; if((a == 0) || (c != 0)) ``` -* Is preferable to break condition statements inside `if` and `while` body exceeding the 80 columns limit over multiple lines, dedicating each line to one condition +* It is preferable to break condition statements inside `if` and `while` body exceeding the 80 columns limit over multiple lines, dedicating each line to one condition ```C if((foo == 0) && (goo != 0) && @@ -41,7 +41,7 @@ if((foo == 0) && ``` ## Brackets -* The Allmann code style must be used. The space between the end of the function name or operator and the open round bracket is optional. +* The Allman code style must be used. The space between the end of the function name or operator and the open round bracket is optional. ```C void foo (int d) { diff --git a/compiling.md b/compiling.md index bcaa82f..495852d 100644 --- a/compiling.md +++ b/compiling.md @@ -1,26 +1,26 @@ # Building OpenRTX from sources -1. [Installing the basic tools](#installing-the-basic-tools) +1. [Installing the basic tools](#_1-installing-the-basic-tools) - [Linux toolchain setup](#linux-toolchain-setup) - [Windows toolchain setup](#windows-toolchain-setup) - [MacOS toolchain setup](#macos-toolchain-setup) -2. [Obtaining the source code](#obtaining-the-source-code) -3. [Compiling the firmware](#compiling-the-firmware) +2. [Obtaining the source code](#_2-obtaining-the-source-code) +3. [Compiling the firmware](#_3-compiling-the-firmware) - [Compiling for a radio](#compiling-for-a-radio) - [Compiling the emulator](#compiling-the-emulator) -4. [Flashing the firmware to a radio](#flashing-the-firmware-to-a-radio) +4. [Flashing the firmware to a radio](#_4-flashing-the-firmware-to-a-radio) - [Tytera and Retevis radios](#tytera-and-retevis-radios) - [GD-77 and DM-1801](#gd-77-and-dm-1801) - [Other radios](#other-radios) -[Appendix: compiling for a Zephyr-based target](#Compiling-for-a-Zephyr--based-target) +[Appendix: compiling for a Zephyr-based target](#compiling-for-a-zephyr-based-target) ## 1. Installing the basic tools As a general rule, the basic tools required to compile OpenRTX from the sources are: `git`, `python`, the `meson` build system and the GCC toolchain for the **Miosix** kernel. This rule has two exceptions: -1. the linux emulator, which doesn't the miosix GCC toolchain since the compiler shipped with your distribution is sufficient; +1. the linux emulator, which doesn't need the miosix GCC toolchain since the compiler shipped with your distribution is sufficient; 2. the T-TWR Plus, which requires the **Zephyr** RTOS build system. #### Linux toolchain setup @@ -36,7 +36,7 @@ sudo apt update && sudo apt install git pkg-config build-essential meson Alternatively to the package manager, `meson` and `ninja` can be installed also using pip: ``` -sudo apt install python-pip3 +sudo apt install python3-pip pip3 install --user meson ninja ``` @@ -45,7 +45,7 @@ The miosix kernel GCC toolchain (`9.2.0mp3.2`) is required, comes with its own i ``` wget https://miosix.org/toolchain/MiosixToolchainInstaller9.2.0mp3.2.run -sh MiosixToolchainInstaller.run +sh MiosixToolchainInstaller9.2.0mp3.2.run ``` **WARNING: since the latest release, the GCC toolchain for miosix kernel is compatible only with x64 systems!** @@ -58,7 +58,7 @@ If you're targeting a TYT or Retevis radio, (i.e. the MD-380, MD-UV380, RT3, ... sudo apt install cmake libusb-1.0-0 libusb-1.0-0-dev ``` -To use `radio_tool` from your non-root Linux user, you need to provide the correct permissions for user-space USB access: +To use `radio_tool` from your non-root Linux user, you need to provide the correct permissions for user-space USB access. The `99-openrtx.rules` file is in the root folder of the OpenRTX repository (see [Obtaining the source code](#_2-obtaining-the-source-code)); run these commands from there: ``` sudo cp 99-openrtx.rules /etc/udev/rules.d sudo udevadm control --reload-rules @@ -73,12 +73,13 @@ sudo apt install dfu-util Alternatively, it can be compiled from source with the following commands: ``` -sudo apt install autoconf +sudo apt install autoconf automake pkg-config libusb-1.0-0-dev git clone git://git.code.sf.net/p/dfu-util/dfu-util +cd dfu-util ./autogen.sh ./configure make -make install +sudo make install ``` --- @@ -138,14 +139,6 @@ To flash the firmware on the *Module 17* and *CS7000-M17* (non Plus) platforms, brew install dfu-util ``` -**Additional notes:** - -The gd77 and dm1801 targets use `bin2sgl`. In order to run it on Apple Silicon Macs, you may need to install Rosetta 2 with the following command: - -``` -softwareupdate --install-rosetta --agree-to-license -``` - --- ## 2. Obtaining the source code @@ -183,13 +176,15 @@ Where `CROSS_FILE`, `BUILD_DIR` and `TARGET` have to be properly selected basing | Module17 | cross_cm4.txt | build_cm4 | `mod17` | | Connect Systems CS7000-M17 | cross_cm4.txt | build_cm4 | `cs7000` | | Connect Systems CS7000-M17 Plus | cross_cm7.txt | build_cm7 | `cs7000p` | +| Baofeng DM-1701 | cross_cm4.txt | build_cm4 | `dm1701` | +| Radtel RT-4D | cross_cm4.txt | build_cm4 | `rt4d` | **NOTE: if you are using a version of Meson older than v0.55.0, the above command will fail. To compile, use the following command:** ``` meson setup --cross-file CROSS_FILE BUILD_DIR -ninja -C BUILD_DIR openrtx_MODEL -jN +ninja -C BUILD_DIR openrtx_TARGET -jN ``` Where N is the number of cores that you want to allocate to the build process. @@ -267,10 +262,10 @@ Then follow the same compilation procedure listed above for a plain build. To flash the newly compiled binary image connect the radio to the computer using the USB programming cable, put it in firmware upgrade mode and issue the following command: ``` -meson compile -C build_cm4 openrtx_MODEL_flash +meson compile -C build_cm4 openrtx_TARGET_flash ``` -where `MODEL` is the same radio model used to compile the firmware, as listed in the table at point 2. +where `TARGET` is the same target used to compile the firmware, as listed in the table in [section 3](#compiling-for-a-radio). Once the flashing process terminated without errors, you can power cycle your radio and enjoy the OpenRTX firmware! @@ -286,20 +281,20 @@ Substituting `new_firmware.bin` with the name of the binary image you want to fl Currently, the Radioddity GD77 and Baofeng DM1801 devices are not supported by `radio_tool`. However, the required tools used to flash the firmware are already included in the main OpenRTX repository. To flash the firmware, you just need to connect the radio to the computer, put it in firmware update mode and issue the following command: ``` -meson compile -C build_cm4 openrtx_MODEL_flash +meson compile -C build_cm4 openrtx_TARGET_flash ``` -where `MODEL` is the same radio model used to compile the firmware, as listed in the table at point 2. +where `TARGET` is the same target used to compile the firmware, as listed in the table in [section 3](#compiling-for-a-radio). #### Other radios The *Module17* and the *CS7000-M17* use the `dfu-util` tool to manage the firmware updates. To write a new firmware, put the target in firmware update mode, connect it to the computer and issue the following command: ``` -meson compile -C build_cm4 openrtx_MODEL_flash +meson compile -C build_cm4 openrtx_TARGET_flash ``` -where `MODEL` is the same radio model used to compile the firmware, as listed in the table at point 2. +where `TARGET` is the same target used to compile the firmware, as listed in the table in [section 3](#compiling-for-a-radio). To write a new firmware on *CS7000-M17 Plus*, you have to use the Connect Systems' firmware update tool to write a "wrapped" binary image. This "wrapped" binary image can be obtained directly from the OpenRTX build system by issuing the command: @@ -308,7 +303,7 @@ by issuing the command: meson compile -C build_cm7 openrtx_cs7000p_wrap ``` -the resulting file will be located in the `build_cm7` folder inside the main OpenRTX folder and will be named `openrtx_cs7000p_wrap.bin` +the resulting file will be located in the `build_cm7` folder inside the main OpenRTX folder and will be named `openrtx_cs7000p_wrap` --- diff --git a/cspell.yaml b/cspell.yaml index 656e9aa..c596911 100644 --- a/cspell.yaml +++ b/cspell.yaml @@ -185,6 +185,12 @@ words: - teardown - AMBE - DVSI + - openrtx + - Hannes + - Friedrichshafen + - Tmes + - littlefs + - Gigadevices patterns: - name: markdown_code_block pattern: /^\s*```[\s\S]*?^\s*```/gm diff --git a/docRepository.md b/docRepository.md index 63c47d5..f0cec06 100644 --- a/docRepository.md +++ b/docRepository.md @@ -4,14 +4,14 @@ This page collects all the available documentation about both radios and their i ## Datasheets -* [HR_C5000 datasheet](https://raw.githubusercontent.com/OpenRTX/OpenRTX-external-docs/main/Datasheets%20and%20refmans/HR_C5000.pdf). Chinese language! -* [HR_C6000 "base" datasheet](https://raw.githubusercontent.com/OpenRTX/OpenRTX-external-docs/main/Datasheets%20and%20refmans/HR_C6000_minimal.pdf). English translation from Chinese language, credits: the OpenGD77 development team. -* [HR_C56000 "extended" datasheet](https://raw.githubusercontent.com/OpenRTX/OpenRTX-external-docs/main/Datasheets%20and%20refmans/HR_C6000_translated.pdf). English translation from Chinese language, credits: the OpenGD77 development team. +* [HR_C5000 datasheet](https://raw.githubusercontent.com/OpenRTX/OpenRTX-external-docs/main/Datasheets%20and%20refmans/HR_Cx000/HR_C5000.pdf). Chinese language! +* [HR_C6000 "base" datasheet](https://raw.githubusercontent.com/OpenRTX/OpenRTX-external-docs/main/Datasheets%20and%20refmans/HR_Cx000/HR_C6000_minimal.pdf). English translation from Chinese language, credits: the OpenGD77 development team. +* [HR_C6000 "extended" datasheet](https://raw.githubusercontent.com/OpenRTX/OpenRTX-external-docs/main/Datasheets%20and%20refmans/HR_Cx000/HR_C6000_translated.pdf). English translation from Chinese language, credits: the OpenGD77 development team. -* [RDA1846 datasheet](https://raw.githubusercontent.com/OpenRTX/OpenRTX-external-docs/main/Datasheets%20and%20refmans/RDA1846_datasheet.pdf) -* [RDA1846 programming guide](https://raw.githubusercontent.com/OpenRTX/OpenRTX-external-docs/main/Datasheets%20and%20refmans/RDA1846_programming_guide.pdf) -* [SKY73210 datasheet](https://raw.githubusercontent.com/OpenRTX/OpenRTX-external-docs/main/Datasheets%20and%20refmans/SKY72310.pdf) +* [RDA1846 datasheet](https://raw.githubusercontent.com/OpenRTX/OpenRTX-external-docs/main/Datasheets%20and%20refmans/AT1846S/RDA1846_datasheet.pdf) +* [RDA1846 programming guide](https://raw.githubusercontent.com/OpenRTX/OpenRTX-external-docs/main/Datasheets%20and%20refmans/AT1846S/RDA1846_programming_guide.pdf) +* [SKY72310 datasheet](https://raw.githubusercontent.com/OpenRTX/OpenRTX-external-docs/main/Datasheets%20and%20refmans/PLL%20and%20IF/SKY72310.pdf) * [BK4819 datasheet](https://prkele.prk.tky.fi/~ftg/files/datasheets/BK4819_Datasheet_V1.01.pdf) * [BK4819 application notes](https://prkele.prk.tky.fi/~ftg/files/datasheets/BK4819(V3)%20Application%20Note%2020210428_machine_translated_English.pdf) @@ -21,7 +21,7 @@ This page collects all the available documentation about both radios and their i * [STM32F405xx reference manual](https://www.st.com/resource/en/reference_manual/dm00031020-stm32f405-415-stm32f407-417-stm32f427-437-and-stm32f429-439-advanced-arm-based-32-bit-mcus-stmicroelectronics.pdf) * [DP32G030 datasheet (Chinese)](https://github.com/amnemonic/Quansheng_UV-K5_Firmware/raw/main/hardware/DP32G030/DP32G030_Chinese_Datasheet.7z) * [MK22FN512VLL datasheet](https://www.nxp.com/docs/en/data-sheet/K22P121M120SF7.pdf) -* [MK22FN512VLL reference manual](https://raw.githubusercontent.com/OpenRTX/OpenRTX-external-docs/main/Datasheets%20and%20refmans/MK22FN512_refman.pdf) +* [MK22FN512VLL reference manual](https://raw.githubusercontent.com/OpenRTX/OpenRTX-external-docs/main/Datasheets%20and%20refmans/MCU/MK22FN512_refman.pdf) * [GD32F330CBT6 datasheet](https://www.mouser.com/datasheet/2/870/GD32F330xx_Datasheet_Rev2_3-3082872.pdf) * [GD32F330CBT6 programming manual](https://www.zlgmcu.com/data/upload/file/Utilitymcu/GD32F3x0_User_Manual_EN_Rev2.0.pdf) diff --git a/get_in_touch.md b/get_in_touch.md index 563a348..4e7db1a 100644 --- a/get_in_touch.md +++ b/get_in_touch.md @@ -18,4 +18,4 @@ Alternatively to the Matrix space, you can join our [Discord server](https://dis We try to bridge together the Discord server and the Matrix space, but these things tend to be fragile. As Discord was the original community chat, it is still where most of the discussions take place. -Finally, if don't have a Matrix account nor a Discord one and you want to join our community, we strongly encourage you to choose the Matrix way! :smiley: +Finally, if you don't have a Matrix account nor a Discord one and you want to join our community, we strongly encourage you to choose the Matrix way! :smiley: diff --git a/hardware/c62.md b/hardware/c62.md index 69bd998..559cdbe 100644 --- a/hardware/c62.md +++ b/hardware/c62.md @@ -113,7 +113,7 @@ ListenAI's container image, so the simplest path is to build in that container. ```bash docker pull listenai/csk6:latest -# --platform linux/amd64 is only needed on Apple silicon +# On Apple silicon, add --platform linux/amd64 after "docker run" docker run --privileged -v /dev:/dev -v /run/udev:/run/udev \ -v "$PWD":/OpenRTX -it listenai/csk6:latest ``` diff --git a/hardware/cs7000.md b/hardware/cs7000.md index 638a93e..7aba48f 100644 --- a/hardware/cs7000.md +++ b/hardware/cs7000.md @@ -27,7 +27,7 @@ The CS7000-M17 series represents the first amateur digital radios specifically d ### Common Specifications (Both Models) * **Display**: 1.8" color TFT, 160x128 resolution * **Frequency Range**: 400-512 MHz (UHF) -* **Receiver Type**: Dual Conversion Superhetrodyne +* **Receiver Type**: Dual Conversion Superheterodyne * **Front-end**: Varactor tuning * **Battery**: 2400 mAh with belt clip * **Waterproof Rating**: IP67 @@ -38,9 +38,9 @@ The CS7000-M17 series represents the first amateur digital radios specifically d | Component | CS7000-M17 | CS7000-M17 Plus | |-----------|-------------|------------------| -| Flash Memory | 128MB | 256MB | +| Flash Memory | 128 Mbit (16 MB) | 256 Mbit (32 MB) | | Code Memory | 1MB | 2MB | -| RAM | 384KB | 1MB | +| RAM | 192KB (128KB SRAM + 64KB CCM) | 1MB | ## Hardware Configuration @@ -48,7 +48,7 @@ The CS7000-M17 series represents the first amateur digital radios specifically d * **MCU**: STM32F405VG (CS7000-M17), STM32H743VI (CS7000-M17 Plus) * **DMR Baseband**: HR-C6000 * **RF Chip**: SKY72310 -* **Display Controller**: HX8302A +* **Display Controller**: ST7735R * **Non-volatile Memory**: 25Q128FV SPI flash * **GPS**: MC-1010-2RE (Plus model built-in, standard model optional) @@ -91,7 +91,7 @@ If you need to flash the radio, the instructions are here: Flashing the radio in the factory manner requires windows and the use of the factory flash tool. -If you all you want on the radio is openRTX for FM/M17 use, there is an alternate procedure that involves rebuilding/linking OpenRTX. That procedure can be done on Linux/Mac. +If all you want on the radio is OpenRTX for FM/M17 use, there is an alternate procedure that involves rebuilding/linking OpenRTX. That procedure can be done on Linux/Mac. Again, be aware, you will *NOT* have DMR capability if you flash the radio this way. @@ -99,7 +99,7 @@ Procedure follows: Make the following modifications: -[meson.build](https://github.com/OpenRTX/OpenRTX/blob/master/meson.build) (currently on line 906) +[meson.build](https://github.com/OpenRTX/OpenRTX/blob/master/meson.build) (the `cs7000p` entry of the `targets` list) The code section looks like this: ``` @@ -108,14 +108,15 @@ The code section looks like this: 'opts' : cs7000p_opts, 'flashable': true, 'wrap' : ' ', - 'load_addr': '0x08100000' + 'load_addr': '0x08100000', + 'cpu' : 'cm7' }, ``` You need to replace the `load_addr` with `0x08000000` And the second file: -[linker_script_cs7000p.ld](https://github.com/OpenRTX/OpenRTX/blob/master/platform/mcu/STM32H7xx/linker_script_cs7000p.ld) (currently line 52) +[linker_script_cs7000p.ld](https://github.com/OpenRTX/OpenRTX/blob/master/platform/mcu/STM32H7xx/linker_script_cs7000p.ld) (the `MEMORY` block) The code section looks like this: @@ -129,7 +130,7 @@ MEMORY } ``` -Again, you need to replace the "origin" variable with `0x08000000` +Again, you need to replace the `ORIGIN` of the `flash` region with `0x08000000`. Do not change the `ram` region. When this is complete, build the firmware using the commands from the developer's guide: diff --git a/hardware/ft2d.md b/hardware/ft2d.md index f17c1dd..b36b983 100644 --- a/hardware/ft2d.md +++ b/hardware/ft2d.md @@ -26,7 +26,7 @@ H8SX is supported by a GCC 4.7 fork by Renesas, no Ghidra module exists. RX600 is supported by a GCC 8.3.0 fork by Renesas, a [Ghidra processor module](https://github.com/ballon-rouge/rx-proc-ghidra) is available. The two Renesas CPU communicate through a serial port, connected to the RXD6 and TXD6 ports of both processors. -The RX630 (SUB) is responsible of managing the screen and the GPS module, while the H8SX (MAIN) is responsible for all +The RX630 (SUB) is responsible for managing the screen and the GPS module, while the H8SX (MAIN) is responsible for all the main radio features. The OpenRTX firmware will run on the MAIN CPU, with full multi-threading support, the SUB CPU will run a single OpenRTX-compatible diff --git a/hardware/hardware.md b/hardware/hardware.md index 675181d..4b3d6c9 100644 --- a/hardware/hardware.md +++ b/hardware/hardware.md @@ -14,8 +14,8 @@ This table provides a glance on the underlying hardware of each of the supported | HD1 | MK22FN512 | HR-C6000 | AT1846S | | 25Q80BV SPI flash +
AT24C512 I2C EEPROM | ST-26-U7L | | MD-9600 | STM32F405VG | HR-C6000 | SKY72310 | ST7567 | 25Q128FV SPI flash | JS-M710 | | T-TWR Plus | ESP32-S3 | SA868S | AT1846S | SH1106 | optional microSD | L76K | -| CS7000-M17 | STM32F405VG | HR-C6000 | SKY72310 | HX8302A | 25Q128FV SPI flash | MC-1010-2RE | -| CS7000-M17 Plus | STM32H743VI | HR-C6000 | SKY72310 | HX8302A | 25Q128FV SPI flash | MC-1010-2RE | +| CS7000-M17 | STM32F405VG | HR-C6000 | SKY72310 | ST7735R | 25Q128FV SPI flash | MC-1010-2RE | +| CS7000-M17 Plus | STM32H743VI | HR-C6000 | SKY72310 | ST7735R | 25Q128FV SPI flash | MC-1010-2RE | | C62 | CSK6011B | - | BK4819 | ST7735R | PY25Q40HB SPI flash | - | | Anytone AT-D890UV | STM32U575VI | SCT3288? | WX4818N? | | TC58CVG2S0HRAIJ SPI Flash | CC1167Q | | Radtel RT-4D | AT32F423CCT7 | HF6853 | BK4819 | ST7567 | PY25Q128HA SPI flash | - | diff --git a/hardware/hd1.md b/hardware/hd1.md index bc2ffa4..3454a36 100644 --- a/hardware/hd1.md +++ b/hardware/hd1.md @@ -160,11 +160,11 @@ USB cable is a serial adaptor, this log appears even without radio. | 7 | 3v3 | 3v3 | | 8 | SWD_IO | SWDIO | -![HD1 SWD Detail](_media/hd1_swd_detail.JPEG) +![HD1 SWD Detail](../_media/hd1_swd_detail.JPEG) ## CHORD U306 -This chip is the voice synthesize from the baofeng radio +This chip is the voice synthesizer from the baofeng radio 86 -> "Channel Mode" 85 -> "Frequency Mode" diff --git a/hardware/md380.md b/hardware/md380.md index 23a123d..91a1fd5 100644 --- a/hardware/md380.md +++ b/hardware/md380.md @@ -35,7 +35,7 @@ Here are summarised the differences between the GPIO connections reported on the ADC2 samples the voltage on PC3 pin (2T/5T signal), data is drained via DMA2_Stream and conversion is triggered by TIM3 trigger output signal, on both rising and falling edges. ### ADC3 -ADC2 samples the voltage on PA2 pin (QT_DQT_IN signal), conversion is triggered by software in a function at address 0x0803e45e and data is collected and processed either in the function at address 0x0803eb2a or in the function at address at 0x0803e47e. The function starting the conversion and then processing the acquired sample is called from TIM7 interrupt handler. +ADC3 samples the voltage on PA2 pin (QT_DQT_IN signal), conversion is triggered by software in a function at address 0x0803e45e and data is collected and processed either in the function at address 0x0803eb2a or in the function at address at 0x0803e47e. The function starting the conversion and then processing the acquired sample is called from TIM7 interrupt handler. ### TIM3 TIM3 is configured in compare mode with the trigger output signal sending a positive pulse when the CC1IF flag is to be set (even if it was already high), as soon as a capture or a compare match occurred. Output compare channel 1 is set to toggle mode, its output toggles when TIM3_CNT is equal to TIM3_CCMR1. Prescaler is set to 9 and reload value is 0x2CF (719 decimal). CCMR1 register is set to 0x359 (857 decimal). diff --git a/hardware/md9600.md b/hardware/md9600.md index 2272885..9d4a6aa 100644 --- a/hardware/md9600.md +++ b/hardware/md9600.md @@ -70,7 +70,7 @@ GPIO | Mode | Function | Notes PC0 | input | TimeSlot interrupt | EXTI0 PC1 | input | Sys interrupt | EXTI1 PC2 | input | TX interrupt | EXTI2, to be confirmed - PC3 | | | + PC3 | analog | RX audio | ADC2_IN13, CTC/DCS and DTMF decoding PC4 | output | ?? | PC5 | analog | heatsink temp. | ADC1_IN15, to be confirmed PC6 | output/AF | display backlight | @@ -111,8 +111,8 @@ GPIO | Mode | Function | Notes PE1 | input | front keys col. 4 | internal pull-up PE2 | output | HR_C6000 chip select | PE3 | output | HR_C6000 SCK | - PE4 | output | HR_C6000 SDI | chip -> MCU - PE5 | output | HR_C6000 SDO | MCU -> chip + PE4 | output | HR_C6000 SDO | MCU -> chip + PE5 | input | HR_C6000 SDI | chip -> MCU PE6 | output | ?? | PE7 | output | TBD audio control | PE8 | output | ?? | @@ -159,8 +159,8 @@ PD2, PD3 and PD4 also have external pull-up resistors, which allows to read thei The SPI control interface is connected to the following GPIOs: * PE2 - chip select * PE3 - SCK -* PE4 - SDI -* PE5 - SDO +* PE4 - SDO +* PE5 - SDI These SPI connections are shared with some other chip, since the firmware locks a semaphore/mutex before initiating any kind of data transfer through the SPI interface. The semaphore variable is at address 0x2001EC90. @@ -187,7 +187,7 @@ PLL1 is used for the VHF band, while PLL2 for the UHF band. Both PLLs have a ref - VCO_freq = (freq - 49'950'000) for the UHF band ### External flash memory -The external flash memory for CPS and calibration data storage is a Winbond W25Q128. Data is exchanged through the SPI2 peripheral and chip select seems to be PB12. The SPI bus is shared with the LCD controller and at least another peripheral whose chip select is on PB13. +The external flash memory for CPS and calibration data storage is a Winbond W25Q128. Data is exchanged through the SPI2 peripheral and chip select seems to be PB12. The SPI bus is shared with the LCD controller and at least another peripheral whose chip select has not been identified yet (PB13 is the SPI2 clock line). Functions identified: * 0x080463FC - function reading a data block from main memory @@ -204,9 +204,9 @@ The STM32F405 microcontroller has three Analog to Digital Converters, here is ho ADC1 is initialised in the function starting at 0x080664AA, and configured for the sampling of eight channels through a regular sequence of conversions. Conversion order is: ADC1_IN9 (PB1), ADC1_IN15 (PC5), ADC1_IN8 (PB0), ADC1_IN0 (PA0), ADC1_IN3 (PA3), ADC1_IN1 (PA1), ADC1_IN6 (PA6), ADC1_IN7 (PA7). Data is transferred through DMA2_Stream0 to a sample buffer starting at 0x2001e8d4, from here the samples are retrieved and processed in various functions in the firmware image. ##### ADC2 -ADC2 is initialised in the function starting at 0x080664AA, and configured for the sampling ADC2_IN13 (PC13). Data is transferred through DMA2_Stream3 to a buffer starting at 0x2001c014. The IRQ handler for DMA2_Stream3, at address 0x080B2D38, copies data from the sample buffer to another buffer located at 0x2001C214 and, before exiting, sends a signal to a task through the semaphore at address 0x2001ECB8. +ADC2 is initialised in the function starting at 0x080664AA, and configured for the sampling ADC2_IN13 (PC3). Data is transferred through DMA2_Stream3 to a buffer starting at 0x2001c014. The IRQ handler for DMA2_Stream3, at address 0x080B2D38, copies data from the sample buffer to another buffer located at 0x2001C214 and, before exiting, sends a signal to a task through the semaphore at address 0x2001ECB8. -Data is processed by a task whose function body is located at 0x0806B308. This task is spawned by the function at 0x0806B1B8 and is assigned the name "Tone fft": from this we can conclude that PC13 is connected to the analog audio output of the receiver stage and is used for CTCSS/DCS and DTMF decoding through the FFT task. +Data is processed by a task whose function body is located at 0x0806B308. This task is spawned by the function at 0x0806B1B8 and is assigned the name "Tone fft": from this we can conclude that PC3 is connected to the analog audio output of the receiver stage and is used for CTCSS/DCS and DTMF decoding through the FFT task. ##### ADC3 ADC3 is initialised in the function starting at 0x0804B160, and configured for the sampling ADC3_IN2 (PA2). Where the data is processed is yet to be discovered, anyway no DMA transfer is involved. diff --git a/hardware/mduv380.md b/hardware/mduv380.md index d48d334..34f7872 100644 --- a/hardware/mduv380.md +++ b/hardware/mduv380.md @@ -140,7 +140,7 @@ GPIO | Mode | Function | Notes PE2 | output | HR_C6000 chip select | PE3 | output | HR_C6000 SCK | PE4 | output | HR_C6000 SDO | MCU -> chip - PE5 | output | HR_C6000 SDI | chip -> MCU + PE5 | input | HR_C6000 SDI | chip -> MCU PE6 | output | HR_C6000 power down | PE7 | input/AF | LCD_D4 - keyboard | FSMC PE8 | input/AF | LCD_D5 - keyboard | FSMC @@ -184,7 +184,7 @@ Functions identified: ## Memory mapping There are two Linux tools for writing the codeplug that can be used as a reference -- [dmrconfig uc380.c](https://github.com/sergev/dmrconfig/blob/master/uv380.c): Some addresses seems +- [dmrconfig uv380.c](https://github.com/sergev/dmrconfig/blob/master/uv380.c): Some addresses seem to be incorrect - [qdmr uv390_codeplug.hh](https://github.com/hmatuschek/qdmr/blob/master/lib/uv390_codeplug.hh): Detailed UV380 codeplug reverse engineering @@ -238,5 +238,5 @@ Body address | Stack address | ID | Priority | -------------|:-------------:|:---:|:--------:| 0x0806B05C | 0x200186CC | 6 | 6 | -This task controls is in charge of managing the AT1846S baseband chip, setting the TX and RX frequencies and other functionalities to be discovered. Upon startup, the task calls the function at 0x0806B05C to perform the initial configuration of the AT1846S registers. Then it enters in an infinite loop which waits for new data on the mailbox at address 0x2001EFAC; this data is the processed in the function at 0x0804B5D4. +This task is in charge of managing the AT1846S baseband chip, setting the TX and RX frequencies and other functionalities to be discovered. Upon startup, the task calls the function at 0x0806B05C to perform the initial configuration of the AT1846S registers. Then it enters in an infinite loop which waits for new data on the mailbox at address 0x2001EFAC; this data is then processed in the function at 0x0804B5D4. diff --git a/hardware/ttwrplus.md b/hardware/ttwrplus.md index 6e3d54d..833f3b2 100644 --- a/hardware/ttwrplus.md +++ b/hardware/ttwrplus.md @@ -31,7 +31,7 @@ This version is not released yet and should come with a few improvements: - VHF OpenEdition (134-174MHz) - UHF OpenEdition (400-480MHz) -OpenEdition devices come with an unprogrammed SA868S, even though you can also reprogram non-OpenEdition modules, these SKU can show the manufacturer the size of the community interest towards this device. +OpenEdition devices come with an unprogrammed SA868S, even though you can also reprogram non-OpenEdition modules, these SKUs can show the manufacturer the size of the community interest towards this device. ## Specifications diff --git a/hardware/uv878.md b/hardware/uv878.md index b73f880..d844877 100644 --- a/hardware/uv878.md +++ b/hardware/uv878.md @@ -10,10 +10,10 @@ * UHF: 400.0000-480.0000 (?) ## Additional Links -* [Jason Reilly's Anytone Mods and Techinfo Website](https://web.archive.org/web/20220831184913/https://members.optuszoo.com.au/jason.reilly1/868mods.htm) +* [Jason Reilly's Anytone Mods and Tech Info Website](https://web.archive.org/web/20220831184913/https://members.optuszoo.com.au/jason.reilly1/868mods.htm) * [Large Collection of Anytone Related Material](https://web.archive.org/web/20230102224956/https://premier01.com/inf/?C=M;O=D) -The collection link is often referenced in the Anytone support facebook group and seems to be somehow directly related to the +The collection link is often referenced in the Anytone support Facebook group. ## FCC Information * [Internal Pictures](https://fccid.io/T4KD878UVII/Internal-Photos/Internal-Photos-5369862.pdf) @@ -24,7 +24,7 @@ The memory map of the device is very well described in the [datasheet](https://w ## Flashing -Someone built some Python [scripts to flash Anytone devices](https://github.com/reald/anytone-flash-tools) based on a analysis of the USB traffic. They are a good source to validate findings from the reverse engineering process. +Someone built some Python [scripts to flash Anytone devices](https://github.com/reald/anytone-flash-tools) based on an analysis of the USB traffic. They are a good source to validate findings from the reverse engineering process. At the moment there is no update security like encryption or app signing implemented. Updates can be written to the device without any additional effort using the \x01 command. @@ -52,7 +52,7 @@ srec_cat 878MCU.hex -intel -o 878MCU.bin -binary An already converted version of the provided image can be [downloaded here](https://pwn.su/research/anytone/878MCU.bin). This image is a full image starting at offset 0x00. The bootloader starts at 0x8000000 and the main application at 0x8004000. -The hardware of the 868 and 878 seems that similar that a software based conversion of the device is possible. Which is also the topic of the github ticket above. A comprehensive guide how to attach the ST-Link adapter and make dumps of the device [can be found here.](https://www.spacesupport.de/digitalfunk/dmr-dmr/geraete/anytone/at868-at878/) +The hardware of the 868 and 878 seems so similar that a software-based conversion of the device is possible. Which is also the topic of the github ticket above. A comprehensive guide how to attach the ST-Link adapter and make dumps of the device [can be found here.](https://www.spacesupport.de/digitalfunk/dmr-dmr/geraete/anytone/at868-at878/) ### Bootloader Communication @@ -68,7 +68,7 @@ Example command structure (write): Anytone firmware updates are not encrypted. They can be loaded in IDA as is. A guide how to do it can be [found here](https://do1alx.de/2022/reverse-engineering-radios-arm-binary-images-in-ida-pro/). -If you download an image from the Anytone website the CDD is basically a image of the main application starting at 0x8004000. The bootloader is not included. +If you download an image from the Anytone website the CDD is basically an image of the main application starting at 0x8004000. The bootloader is not included. The firmware is all Thumb, so disable automatic mode switching. @@ -86,13 +86,13 @@ The factory mode is enabled by sending the string *FALTORY* as a serial command. The device uses an SCT3258 baseband chip as it is used in multiple other devices. The vendor leaked a tool from the SDK to flash the baseband chip via USB. -There is also a special SCT mode which allows direct communication to the baseband bootloader. More details are about this can be found in the PDF file included in the baseband update package. The package can be downloaded below. +There is also a special SCT mode which allows direct communication to the baseband bootloader. More details about this can be found in the PDF file included in the baseband update package. The package can be downloaded below. ### Downloads * [Baseband Flashtool, Update Hex Files and Guide](https://pwn.su/research/anytone/D8x8UV_Base_Band_Update_SCT3258.zip) * [Hardware Development Kit User Guide](https://web.archive.org/web/20220518011541/https://cmlmicro.com/wp-content/uploads/2018/07/SCT3258_HDK_User_Guide_V1_9.pdf) * [GD32F303VGT6 datasheet](https://web.archive.org/web/20230202004134/https://www.gigadevice.com/microcontroller/gd32f303vgt6/) -* [SCT3258 to datasheet](https://cdn.hackaday.io/files/1642237026116832/SCT3258_datasheet_v2_0.pdf) +* [SCT3258 datasheet](https://cdn.hackaday.io/files/1642237026116832/SCT3258_datasheet_v2_0.pdf) ## Linkboard (APRS and FSK) diff --git a/linux.md b/linux.md index 6cfccb0..d58c804 100644 --- a/linux.md +++ b/linux.md @@ -23,11 +23,11 @@ The `tests/unit/assets` directory contains the following baseband recordings: ### Demodulating a raw baseband file with OpenRTX Linux -The Linux build uses a file source driver that reads, on loop, a raw 16-bit, little-endian, mono, 24 kHz file from `/tmp/baseband.raw`. +The Linux build uses a file source driver that reads, in a loop, a raw 16-bit, little-endian, mono, 24 kHz file from `/tmp/baseband.raw`. #### Decimation -The OpenRTX M17 modulator works at a sample rate of 48 kHz, but the demodulator works at a sample rate of 24 kHz. Because the sample baseband files have a sample rate of 48 kHz, they must be decimated to 24 kHz first in order to be demodulated. This can be done easily using the `sox` audio utility, available in most packagers. To decimate a sample baseband file, run: +The OpenRTX M17 modulator works at a sample rate of 48 kHz, but the demodulator works at a sample rate of 24 kHz. Because the sample baseband files have a sample rate of 48 kHz, they must be decimated to 24 kHz first in order to be demodulated. This can be done easily using the `sox` audio utility, available in most package managers. To decimate a sample baseband file, run: ```bash # Convert the sample baseband recording from 48 kHz to 24 kHz diff --git a/peripheral_table.md b/peripheral_table.md index 63f523d..6e05bf6 100644 --- a/peripheral_table.md +++ b/peripheral_table.md @@ -69,9 +69,9 @@ This page provides an overview on which hardware peripherals are used by the Ope | TIM12 | | | | TIM13 | | | | TIM14 | USED | Tone generator time base for CTCSS/beep sine wave generation | -| USART1 | | | +| USART1 | USED | GPS data RX | | USART2 | | | -| USART3 | USED | GPS data RX | +| USART3 | | | | SPI1 | USED | External flash memory | | SPI2 | | | | SPI3 | | | diff --git a/posts/openrtx-office-hours-20260213.md b/posts/openrtx-office-hours-20260213.md index ef745e3..988335b 100644 --- a/posts/openrtx-office-hours-20260213.md +++ b/posts/openrtx-office-hours-20260213.md @@ -112,7 +112,7 @@ Held on 2026-02-13T17:00Z in [https://meet.jit.si/OpenRTX](https://meet.jit.si/O * Morgan to think about this alongside other actions post as part of his next big task * *[???] Please make it possible to use M17 TX on the TYT VHF 380 radio.* * Still work required; nobody is actively working on this though - * Silvano previously researched, seems like troubleshooting on other side of HC5000 + * Silvano previously researched, seems like troubleshooting on other side of HR_C5000 * Unclear how valuable this is at this point given that these devices are EOL * *[???] Please add some information on a public website about the APRS development timeline* * Please refer to the release planning section at the top of the notes diff --git a/posts/openrtx-office-hours-20260424.md b/posts/openrtx-office-hours-20260424.md index 1fc7947..3e656b0 100644 --- a/posts/openrtx-office-hours-20260424.md +++ b/posts/openrtx-office-hours-20260424.md @@ -22,7 +22,7 @@ Held on 2026-04-24T17:00Z in [https://meet.jit.si/OpenRTX](https://meet.jit.si/O * v0.4.4: incoming release * all features are landed, we're ready to cut the release. - * investigating the off-frequency bug on CS7000, the fix may part of the release. + * investigating the off-frequency bug on CS7000, the fix may be part of the release. * v0.5.0: next release * re-scoping of the release: we have M17 SMS, APRS RX, and spectrum scan all close to go @@ -81,7 +81,7 @@ Held on 2026-04-24T17:00Z in [https://meet.jit.si/OpenRTX](https://meet.jit.si/O * *[Jeff KF0CSJ] T-TWR?* * What's the current status? Interested in buying a new radio, but trying to decide between C62 or T-TWR because they're not requiring mods to run M17 - * [IU2KWO] Nico and Edgetriggered made a working POC for the ADC (in order to compensate for a hardware issue in teh current revision); edgetriggered has adjustments that need to be merged now + * [IU2KWO] Nico and Edgetriggered made a working POC for the ADC (in order to compensate for a hardware issue in the current revision); edgetriggered has adjustments that need to be merged now * We need to prove the DAC is capable for M17 transmission and get M17 reception working through the ADC support. Some UI changes would benefit the unusual hardware interface on this platform. * Persistence would be very helpful for configuring pre-defined channels to work around limitations of the physical interface. diff --git a/posts/openrtx-office-hours-20260723.md b/posts/openrtx-office-hours-20260723.md index e164589..1c249e9 100644 --- a/posts/openrtx-office-hours-20260723.md +++ b/posts/openrtx-office-hours-20260723.md @@ -34,7 +34,7 @@ Held on 2026-07-23T17:00Z in [https://meet.jit.si/OpenRTX](https://meet.jit.si/O * Persistence: * Considered integrating the slicer and memory savings bits together, decided against this because the group believed that the slicer may have standalone value for special cases * Proposal that slicer should be able to take a map for variable slice size: e.g. one slice with M17, one with FM; decided instead that intentionally positioning high vs low churn entries would be enough - * Morgan working on VFO structure, current approach is funky and coupled to md380 + their CPS expectations; going to reimagine this to be more consistent with + * Morgan working on VFO structure, current approach is funky and coupled to md380 + their CPS expectations; going to reimagine this to be more consistent with [unfinished in the original notes] * We \_don't\_ expect that every setting present in the codeplug should be editable via UI; e.g. Tmes, calibration editing would clutter the UI * Planning two CPS: one for constrained radios that will have read-only codeplug to the UI, another that will have littlefs and full editing capabilities @@ -43,7 +43,7 @@ Held on 2026-07-23T17:00Z in [https://meet.jit.si/OpenRTX](https://meet.jit.si/O * Computer-aided transceivers (CAT interface) * Working on the new implementation currently based on some past learnings from a hackathon * Yaesu/kenwood compatible approach is being chosen - * If a radio has USB, there is will be one with CAT (serial mode) and one with file transfer (file mode) (either way, CAT must enable file transfer) + * If a radio has USB, there will be one with CAT (serial mode) and one with file transfer (file mode) (either way, CAT must enable file transfer) * Mass storage may be hard for qDMR based on the existing work done, dual port challenges too; maybe another approach like dfu would work more easily? To be researched * Github bot checking for stale issues: diff --git a/rtxlink.md b/rtxlink.md index 833c4dd..63377a2 100644 --- a/rtxlink.md +++ b/rtxlink.md @@ -19,7 +19,7 @@ fragmentation of the transmitted data. ## Data Link Layer The data link layer of the rtxlink protocol consists of variable-length frames encoded using the [Serial Line Internet Protocol (SLIP)](https://en.wikipedia.org/wiki/Serial_Line_Internet_Protocol). -Each SLIP frame must begin with an END character: incoming frames not beginning with and END character are accepted anyway, even if not strictly conformant to the specification. SLIP can extend +Each SLIP frame must begin with an END character: incoming frames not beginning with an END character are accepted anyway, even if not strictly conformant to the specification. SLIP can extend the frame length up to the double of the original length, this needs to be taken into account when sizing buffers during the protocol implementation. The frames format is the following: @@ -69,7 +69,7 @@ Following the opcode there are two bytes containing the resource ID and N bytes #### Peek Requests -A peek request allow the client to read the content of the host internal memory at a given address. The command frame has a fixed length of six bytes, with the opcode set to 0x50 (ASCII character 'P'). +A peek request allows the client to read the content of the host internal memory at a given address. The command frame is 4, 6 or 10 bytes long, depending on the address length, with the opcode set to 0x50 (ASCII character 'P'). The command opcode byte is followed by one byte specifying the number of bytes to read and by the start address for the read operation. The length of the address depends on the host architecture and it can be either 2, 4 or 8 bytes long; any other length is considered invalid. The host replies to a peek request with a data response packet or, in case of failures, an ack frame reporting an error code. @@ -102,13 +102,13 @@ must at least use the values 0x00 and 0xFF for the status field. | Request | Get | 0x47 'G' | ID | 3 | Gets the N Byte word corresponding to the specified ID. | | Response | Data | 0x44 'D' | Value | Variable | The N Byte word which was requested. | | Request | Set | 0x53 'S' | ID, Value | Variable | Sets a N Byte word to the specified ID. | -| Response | Ack | 0x41 'A' | Status | 1 | Status of the previous Set command, success or error. | -| Request | Peek | 0x50 'P' | Address | 5 | Gets the 32bit word corresponding to the specified 32-bit address. | -| Response | Data | 0x44 'D' | Value | 5 | The 32bit word which was requested. | +| Response | Ack | 0x41 'A' | Status | 2 | Status of the previous command, success or error. | +| Request | Peek | 0x50 'P' | Length, Address | 4, 6 or 10 | Reads Length bytes starting at the specified address (2, 4 or 8 bytes long). | +| Response | Data | 0x44 'D' | Value | Variable | The memory content which was requested. | #### Get/set resource IDs -The tables below summarizes the CAT resource identifiers with their respective size, semantic and permissions. +The tables below summarize the CAT resource identifiers with their respective size, semantic and permissions. | Permissions | Symbol | |:---------------|:-------| diff --git a/software.md b/software.md index a3dfda3..f738aff 100644 --- a/software.md +++ b/software.md @@ -18,9 +18,11 @@ OpenRTX software architecture documentation * Tytera MD-UV390 * Tytera MD-UV390G * Retevis RT3s (with or without GPS) - * Baofeng DM-1701 (not tested) * Tytera MD-2017 (not tested) + * **DM-1701** platform, compilation target `dm1701` + * Baofeng DM-1701 + * **MD-9600** platform, compilation target `md9600` * Tytera MD-9600 (with or without GPS) @@ -29,12 +31,24 @@ OpenRTX software architecture documentation * Radioddity GD-77, compilation target `gd77` * Baofeng DM-1801, compilation target `dm1801` -* **Module17** platform, compilation target `hd1` +* **Module17** platform, compilation target `mod17` * Module17 board * **Talkpod** family * **A36plus Platform** - * Talkpod A36plus MAX (8W), compilation target `a36plus` + * Talkpod A36plus MAX (8W), compilation target `a36plus` (maintained outside the main OpenRTX repository) + +* **CS7000** family + * Connect Systems CS7000-M17, compilation target `cs7000` + * Connect Systems CS7000-M17 Plus, compilation target `cs7000p` + +* **T-TWR Plus** platform, compilation target `ttwrplus` + * LILYGO T-TWR Plus + +* **RT-4D** platform, compilation target `rt4d` + * Radtel RT-4D + +* **Linux** emulator, compilation targets `linux`, `linux_smallscreen` and `linux_mod17` ## Threading Model OpenRTX employs a **multi-threaded** architecture. \ @@ -46,6 +60,8 @@ The current implementation uses three threads: - **DEV Thread**: Updates the device parameters (e.g. battery voltage) and handles parsing of GPS sentences - **RTX Thread**: Controls the RF section and handles the protocol management, executing requests from the UI Thread +Additional threads are created on demand: the audio codec spawns a **Codec2 thread** while encoding or decoding voice (stack size `CODEC2_THREAD_STKSIZE`, 16kB), and the audio drivers of the MDx and CS7000 targets spawn an **audio thread** (stack size `AUDIO_THREAD_STKSIZE`, 512B). + The OpenRTX threads communicate between them by using _event queues_ and _shared state_ data structures. This diagram shows the interaction between threads, queues and shared states. @@ -61,7 +77,7 @@ following table for details |DEV |200Hz (5ms)|- |2kB | |RTX |33Hz (30ms)|- |512B | -The thread stack sizes are defined in the `openrtx/include/threads.h` file, **except for the DEV one**. The DEV task is currently run in the ```main()``` function, whose stack size depends on a configuration parameter of the miosix kernel and is thus non modifiable. The only way to effectively change the stack size for the ```main()``` function is to recompile the miosix kernel and change the file `lib/miosix-kernel/libmiosix.a`. +The thread stack sizes are defined in the `openrtx/include/core/threads.h` file, **except for the DEV one**. The DEV task is currently run in the ```main()``` function, whose stack size depends on a configuration parameter of the miosix kernel and is thus non modifiable. The only way to effectively change the stack size for the ```main()``` function is to recompile the miosix kernel and change the file `lib/miosix-kernel/libmiosix.a`. ## Interfaces Overview The OpenRTX firmware has been designed also with the goal of being able to be run on many different models of ham radios. To allow for this interoperability, we defined a set of **standard interfaces** providing a well-defined decoupling point between the common code (like the one for UI management) and the platform-specific one, most notably the device drivers. @@ -85,7 +101,7 @@ By design, low level drivers (display, keyboard, ...) are **not** written to be In any case, the low level drivers provide a means to determine if the controlled device is busy, thus allowing for concurrent access management. As said above, since the low level drivers are **not** thread safe, these functions should be preceded by ```__disable_irq()``` and followed by ```__enable_irq()```, which are the CMSIS functions for interrupt disabling and enabling, respectively. Disabling the interrupts prevents any kind of unwanted preemption, either from the RTOS or from the hardware peripherals. However, it also has an impact on the real-time performance of the overall system, thus each critical section has to be as short as possible. -As an example, let consider the display driver's function to check if rendering is in progress: +As an example, let us consider the display driver's function to check if rendering is in progress: ```C @@ -103,8 +119,8 @@ __enable_irq(); ### Parts with C++ code in the codebase As the miosix kernel is completely written in C++ and designed primarily to be coupled to C++ sources, some points of the OpenRTX codebase have to be adapted to be able to interface with the kernel. In particular, all the names for the interrupt handler functions are subjected to the **C++ name mangling scheme**, thus all the C code written for handling interrupts must have the handler name matched with the C++ mangled one. Affected modules are: -* The `HX8353_MDx` file, providing the low-level display driver for MDx targets. -* The `GPS_MDx` file, providing the low-level GPS driver for MDx targets. +* The `HX8353_MD3x` file, providing the low-level display driver for MDx targets. +* The `gps_stm32` file, providing the low-level GPS driver for STM32-based targets. * The `toneGenerator_MDx` file, providing an implementation of a tone generator for system "beeps" and CTC/DCS. In case there is need to interface with an interrupt handler from the C code, the general name mangling scheme is the following: @@ -121,7 +137,7 @@ As an example, take the TIM3 interrupt handler: its function name is ```TIM3_IRQ * Content of display framebuffer is changed inside ```display_renderRows() ``` or ```display_render() ```. Since the display controller needs to be provided with pixel data in big endian order, while the MCU is little endian, inside the two render functions the whole content of the framebuffer is byte-swapped to accommodate for the endianness of the display controller. As a consequence, writing a pixel and then reading it back returns the written value **as long as** ```display_renderRows() ``` **or** ```display_render() ``` **are not called**. #### MD-380 -* SKY73210 and HR_C5000 share part of the SPI bus. SKY73210 provides ```SKY73210_spiInUse()``` function to allow high level modules determine if SPI bus is taken by PLL driver or not. +* SKY72310 and HR_C5000 share part of the SPI bus. The SKY72310 driver provides ```SKY73210_spiInUse()``` function to allow high level modules determine if SPI bus is taken by PLL driver or not. #### MD-9600 * The external flash memory and the display driver share the same SPI bus. The SPI2 driver module provides an API to get exclusive access to the bus by locking a dedicated mutex, however application code has to explicitly call the ```spi2_lockDevice()```/ ```spi2_lockDeviceBlocking()``` and ```spi2_releaseDevice()``` functions, respectively before and after committing a transaction on the SPI bus. diff --git a/software_modes.md b/software_modes.md index feccd55..b84871b 100644 --- a/software_modes.md +++ b/software_modes.md @@ -14,7 +14,7 @@ The encoding and decoding digital modes with a DSP has its own advantages becaus that the radio manufacturer will not have to implement it in the radio firmware, also the baseband follows the protocol timings and fires an interrupt to the microcontroller when a certain protocol event happens (like the start of a DMR timeslot). -Unfortunately decoding digital modes in software has an hardware requirements: it requires the target radio to have some +Unfortunately decoding digital modes in software has a hardware requirement: it requires the target radio to have some __audio paths__ which are mandatory: - RF to MCU: Used to receive signal to be decoded - MCU to RF: Used to transmit encoded signal diff --git a/tests.md b/tests.md index 52aea0e..54327c5 100644 --- a/tests.md +++ b/tests.md @@ -1,4 +1,4 @@ -When working on OpenRTX we often find in need to test some features or to execute some standalone programs without running the main OpenRTX code. +When working on OpenRTX we often need to test some features or to execute some standalone programs without running the main OpenRTX code. To do so we use the so called **platform tests** that can be used for example to dump the calibration data of a radio. This page shows how to compile and run platform tests on your radio. diff --git a/user_guide.md b/user_guide.md index 7cccdfa..c1a104f 100644 --- a/user_guide.md +++ b/user_guide.md @@ -54,7 +54,7 @@ To put the radio in bootloader mode look at the instructions for firmware flashi |---|---|---|---| | **Green Book** | **Up Arrow**
Squelch step up | **Down Arrow**
Squelch step down | **Red Book** | | **1**
T- CTCSS
Frequency Step down | **2**
T+ CTCSS
Frequency Step up | **3**
CTCSS Mode
(Disable / Encode /
Decode / Encode+Decode) | **\* \ Lock** | - | **4**
IF Filter bandwidth
(12.5 / 20 / 25 KHz) | **5**
Modulation Mode
(DMR/FM/M17) | **6**
Transmitter Power
(high / low or 1W / 5W) | **0 \ \_** | + | **4**
IF Filter bandwidth
(12.5 / 20 / 25 kHz) | **5**
Modulation Mode
(DMR/FM/M17) | **6**
Transmitter Power
(high / low or 1W / 5W) | **0 \ \_** | | **7**
B+
Increase Display
Brightness| **8**
B-
Decrease Display
Brightness | **9**
Lock | **# \ Shift arrow** | * M17 Mode diff --git a/website.md b/website.md index 0ffe13b..9a42eae 100644 --- a/website.md +++ b/website.md @@ -12,7 +12,7 @@ This page discusses the basic setup for contributing to the OpenRTX website. The OpenRTX website is a _static site_. This means that content is pre-built and packaged for viewing in a browser without the need for a complex webserver or database configuration. This makes contributing to the website relatively simple, and only requires installing a few packages, many of which you may already have if you have done any kind of development before. -OpenRTX uses the `docsify` static site generator, which converts convert Markdown files into HTML that can be rendered in a browser. This generated output is hosted on GitHub Pages. +OpenRTX uses the `docsify` static site generator, which converts Markdown files into HTML that can be rendered in a browser. This generated output is hosted on GitHub Pages. --- @@ -24,10 +24,10 @@ In order to build and run the website locally, you must have the following packa - `nodejs` - `npm` -Once you have these installed, you will need to use `npm` to install the `docsify` npm package: +Once you have these installed, you will need to use `npm` to install the `docsify-cli` npm package, which provides the `docsify` command: ```bash -npm i docsify -g +npm i docsify-cli -g ``` You can also install the `cspell` package to check your changes for any spelling errors: @@ -66,7 +66,7 @@ You can now make changes to the website by editing any of the Markdown (`.md`) f --- ## Checking your changes for typos -To check for spelling errors, you can run use the `cspell` command installed earlier. For example, to check for spelling errors in the file you are reading right now, you can run the following command inside the `openrtx.github.io/` directory: +To check for spelling errors, you can use the `cspell` command installed earlier. For example, to check for spelling errors in the file you are reading right now, you can run the following command inside the `openrtx.github.io/` directory: ```bash cspell website.md