Version 4.4 - December 15, 2016
While it wasn't detailed in the release notes, that refers to reductions in usage of precious RAM
, not flash memory (where executable code lives). Those changes did not decrease code size; in fact, they increased it a bit.
Adding NXDN to the WS1080/88 and WS1095/98 would exceed available flash space. This became clear during DMR development - presuming roughly the same code size increase for NXDN as for DMR, adding NXDN to the WSxxxx scanners wasn't going to be possible. In fact, the original plan was to support DMR only on the TRX-n with its larger CPU. Adding DMR support to the WSxxxx family of scanners was a last-minute decision because it just barely fit
, while leaving a little bit of space for fixes.
Heck, just the inadvertent inclusion of a small amount of NXDN-related debug code
(without all of the NXDN support code itself) broke the WS1095/98 3.4 release.
It's not just the decoding of the NXDN signal or the vocoder. That happens in the DSP - which, as has been noted elsewhere, is exactly the same across all of the scanners.
As Eric said, it's also what to do with that decoded data - not just the voice frames. All of the NXDN-specific data/control messages have to be decoded and interpreted, menus and displays have to handle NXDN-specific info, RAN and ID info has to be supported, etc.
I haven't looked at suppliers for the two different chips, but I suspect price or availability is a more likely reason for the change.
The only reason for the change to the TRX-1's more expensive CPU (except for internal flash size, it's identical to the WS1080/88 CPU) was planned support for NXDN and, possibly, other modes in the future. Initially, it was to support DMR, too, but that was shoehorned into the WSxxxx's smaller CPU.
I bet most of the code for NXDN revolves around fitting to the RR DB
I'd take that bet. The TRX-1's RRDB support for NXDN was about 1% of the total NXDN-related CPU code size increase. What RRDB support was required for NXDN is handled almost exclusively in the PC-based converter app that generates the weekly files.
Upon what evidence are you basing that assertion? Because it seems to be contradicted by the partial map file generated during a failed link when I tweak the makefile to build "WS1080 with NXDN support".