The third version worked in previous recommendations and is being evaluated right now. Important change is replacement of MCU. MSP430 microcontrollers offer very low power consumption which is secured with features like low clock speeds and small RAM and selection of sleep modes. These were the main reason why it has been changed to 32-bit MCU from STM. New MCU has more Flash, RAM, double maximum frequency while allowing faster response times and more tools for compression or encryption. Using the right sleep modes power requirements are not significantly worse, especially compared to those of 500mW transceiver. USB communication is now serviced by FTDI chip and has been tested to work with Windows and Linux systems. This allows new users of STM32 MCU to learn programming from absolute start. It is likely the best to learn peripherals in following steps :

toggle LED (GPIO) → use Timer → use Interrupts → use Serial interface (UART/SPI) → combine known.

This version is also mechanically smaller as it uses 0603 as opposed to 0805 package of passive components. More experiments are in progress with 0402 package. Last change was replacement of LDO regulator for a switching buck converter. The CC1120+CC1190 combo is quite power hungry during full power transmission. Whole device is tested to draw 55mA during reception and 275mA during transmission. Switching converter decreases current taken from 5V rail, but also introduces more noise to 3V3 power rail. Will the noise reduce RX sensitivity? Well … the tests are still in progress. However the power draw has decreased to 40mA during RX and 121mA during TX. (no power-saving features used)

Testing of the 8kHz bandwidth revealed an important issue. Temperature drift. Crystal oscillators have very good frequency stability over temperature. Yet there are conditions where they are unsatisfactory. The third version of the device uses crystal with +-10ppm stability. This means 32Mhz crystal CC1120 requires will over its operational temperature range ( -20° C to +70° C ) change frequency by no more than 320Hz up or down. Creating for example 868MHz requires multiplying the 32MHz by a little over 27. Temperature error is also multiplied which brings max error above the whole bandwidth. ( 8690 Hz ) Also not to forget is that this drift goes in either direction causing whole temperature delta to be 17kHz. To reliably receive signal with 8kHz bandwidth, the receiver has to use 25kHz bandwidth. While there are software methods of temperature compensation there is also an easier way of using directly temperature compensated oscillator. After swift peak at the market I’ve found these oscillators at comparable price to the bare crystal have stability of just +-2ppm. More expensive models can easily go below +-0.5ppm. This greatly reduces the problem to the level where crude temperature measurement of MCU with resolution of about 10° C would be enough to suppress any effects of the drift. Practical testing with +-10ppm crystal and 8kHz bandwidth at both devices showed 15° C delta is enough to disrupt the datalink. If both devices are in the same environment temperature drift is not an issue. Its a different story if, for example one device is indoors and other is outdoors. Next version will therefore use TXCO with hopes no or minimal software compensation will be required.