If anyone actually knows what was changed in DSP 3.0 besides turning on the two different vocoder rates for NXDN, that would be interesting to know.
They are grasping at strings to make a sale, I suppose. There's no technological reason the 1080 couldn't do NXDN.
The only reason the older scanners got DMR is so there wouldn't be a massive return of recently purchased scanners.
Why have people upgrade the DSP firmware for no reason? That's just silly, especially considering how many people have trouble with connection and software incompatibility issues.
Gosh this is such a gimmick just to move new product. Why not improve quality, service, and user experience instead? Now that would sell a scanner.
Doesn't the WS1080 lack enough flash memory to be able to support NXDN?They are grasping at strings to make a sale, I suppose. There's no technological reason the 1080 couldn't do NXDN.
DSP 3.0 for the TRX-2 and the WS1080 is 100% identical, byte for byte. I'm assuming this is done so they don't have to maintain different builds of the DSP for almost identical radios, even though NXDN is not supported on the older radios of the series.Why have people upgrade the DSP firmware for no reason? That's just silly, especially considering how many people have trouble with connection and software incompatibility issues.
Interesting....if that is true, download the TRX-1 ezscan, the firmware for trx-1 (renamed to WS1080) and I bet the the dsp doesn't matter. then install via the grefwtool eric wrote.Then, in theory, it should do NXDN. Maybe program the SD with the TRX version and load NXDN and see what it does.
Hello,Interesting....if that is true, download the TRX-1 ezscan, the firmware for trx-1 (renamed to WS1080) and I bet the the dsp doesn't matter. then install via the grefwtool eric wrote.
If someone sends me the firmware for a trx-1 I will try it on my pro-668
This isn't like that at all. It's like sending some data frames to a vocoder and making analog audio out of similar data rates of P1/P2 P25.The processor is completely different, and thus incompatible with the processing options. It's like trying to run Windows XP on an 8088 Processor.... Won't work.
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.Version 4.4 - December 15, 2016
- Memory usage reductions
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 haven't looked at suppliers for the two different chips, but I suspect price or availability is a more likely reason for the change.
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.I bet most of the code for NXDN revolves around fitting to the RR DB
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".It fit. There was room.