OpenRTX · silseva · Mar 15, 2026 · Mar 14, 2026 · Mar 14, 2026
diff --git a/NVM.md b/NVM.md
@@ -16,7 +16,7 @@ Each nvmDescriptor contains a name, a pointer to an nvmDevice, a base address us
 It also implements the following functions defined in interfaces/nvmem.h
  * the nvm_init, nvm_terminate that initialize or terminate the nvm subsystem. It initializes all the NVM devices used by the platform.
  * the nvm_getDesc that returns an nvmDescriptor given a device number
- * the nvm_readCalib that populates a given buffer with the cailbration data
+ * 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
  * nvm_readSettings/nvm_writeSettings that reads/writes the device settings (callsign, accessibility settings, ...)
@@ -44,4 +44,4 @@ The info structure is defined in interfaces/nvmem.h as nvmInfo and contains:
 
 ## Low-level driver
 
-This layer implements the low-level drivers required to use the memory device. Those drivers are often not exclusive to the NVM sybsystem. This can be an SPI driver, I2C driver, ... . Those should be initialized in the init function of the memory device.
+This layer implements the low-level drivers required to use the memory device. Those drivers are often not exclusive to the NVM subsystem. This can be an SPI driver, I2C driver, ... . Those should be initialized in the init function of the memory device.
diff --git a/compiling.md b/compiling.md
@@ -114,7 +114,7 @@ To flash the firmware on the *Module 17* and *CS7000-M17* (non Plus) platforms,
 
 #### MacOS toolchain setup
 
-The MacOS toolchain setup is similar to that for Linux. Currently, the Zephyr-based tagets can't be built on MacOS. 
+The MacOS toolchain setup is similar to that for Linux. Currently, the Zephyr-based targets can't be built on MacOS.
 
 To install the basic tools required to compile both the Linux emulator and the firmware images, you can use [Homebrew](https://brew.sh/). Most developers will already have it installed, otherwise follow the instructions at the link. Git and the Xcode tools are automatically installed during the Homebrew installation process, while `meson` needs to be installed separately with the following command:
 

diff --git a/cspell.yaml b/cspell.yaml
@@ -135,7 +135,14 @@ words:
   - Imostlylurk
   - Buchegger
   - Grzegorz
+  - Wojciech
   - Kaczmarek
+  - Kaczmarski
+  - Redman
+  - Balmer
+  - Harzi
+  - Harzenmoser
+  - smeegle5000
   - CICD
   - Edgetriggered
   - IU2KWO
@@ -147,6 +154,22 @@ words:
   - OpenCollective
   - Pulseaudio
   - cppcheck
+  - nvm
+  - nvmem
+  - nvm_readCalib
+  - nonvolatile
+  - Talkpod
+  - rtxlink
+  - callsign
+  - MCUBOOT
+  - hwconfig
+  - OPNRTX
+  - Nitter
+  - CRCL
+  - CRCH
+  - CCITT
+  - nord
+  - priv
 patterns:
   - name: markdown_code_block
     pattern: /^\s*```[\s\S]*?^\s*```/gm

diff --git a/linux.md b/linux.md
@@ -38,4 +38,4 @@ In this example, a receive screen with callsign OPNRTX is expected.
 
 ### Going Further
 
-In theory, you could create a named pipe at `/tmp/baseband.raw` and write to it useing GNU Radio. Something like a source, with resampling to 24kHz if required, then float to short, then a file sink should work.
+In theory, you could create a named pipe at `/tmp/baseband.raw` and write to it using GNU Radio. Something like a source, with resampling to 24kHz if required, then float to short, then a file sink should work.
diff --git a/rtxlink.md b/rtxlink.md
@@ -12,7 +12,7 @@ This page describes `rtxlink`, the communication protocol used by the OpenRTX fi
 
 The physical layer of the rtxlink protocol is a serial communication, which may either be based on a physical link (UART) or a Virtual COM over USB.
 In case a physical link is used, its configuration is 8 data bits, no parity and either EIA hardware flow control, or CLOCAL mode (3-wire null-modem).
-The default baud rate is 115200 bit per second but the change to a different datarate can be requested by the client device. The support for datarates
+The default baud rate is 115200 bit per second but the change to a different data rate can be requested by the client device. The support for data rates
 other than the default one is not mandatory, although an rtxlink host must support at least 115200 bit per second. The protocol tolerates buffering and
 fragmentation of the transmitted data.
 
@@ -29,7 +29,7 @@ The frames format is the following:
 | END | ProtoID | Data | CRCL | CRCH | END |
 
 After the start of frame marker, the first byte of each frame is a protocol identifier describing the frame content. After the payload data and preceding the frame end marker, the frame contains the
-CRC-16 of the protocol identifier and data fields: the CRC is computed using the CCITT polynomial 0x1021 (CCITT CRC-16 polynomial) and transmittend in little-endian format.
+CRC-16 of the protocol identifier and data fields: the CRC is computed using the CCITT polynomial 0x1021 (CCITT CRC-16 polynomial) and transmitted in little-endian format.
 
 The recognized protocol IDs are the following:
Original file line number	Diff line number	Diff line change
Expand Up		@@ -38,4 +38,4 @@ In this example, a receive screen with callsign OPNRTX is expected.

		### Going Further

		In theory, you could create a named pipe at `/tmp/baseband.raw` and write to it useing GNU Radio. Something like a source, with resampling to 24kHz if required, then float to short, then a file sink should work.
		In theory, you could create a named pipe at `/tmp/baseband.raw` and write to it using GNU Radio. Something like a source, with resampling to 24kHz if required, then float to short, then a file sink should work.