WS1080: 1080 Dec DSP Firmware Update V3.0; What is it?
- Thread starter AggieCon
- Start date
- Status
Hello,
Whistler is using the same DSP version for the TRX series and WS-1080 series. It appears they put the same non-NXDN changes in both firmwares, so DSP 3.0 maybe required. Even though the WS-1080 series will not decode NXDN.
73 Eric
Whistler is using the same DSP version for the TRX series and WS-1080 series. It appears they put the same non-NXDN changes in both firmwares, so DSP 3.0 maybe required. Even though the WS-1080 series will not decode NXDN.
73 Eric
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.
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.
Quality?
What would you do differently in the TRX1 and TRX2?
Looks ok to me.
Wish It decoded better LSM.Maybe selectible step sizes?
What would you do differently in the TRX1 and TRX2?
Looks ok to me.
Wish It decoded better LSM.Maybe selectible step sizes?
Joseph11
Member
- Joined
- Nov 17, 2004
- Messages
- 2,270
Doesn't the WS1080 lack enough flash memory to be able to support 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.
- Joined
- Feb 18, 2016
- Messages
- 1,892
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
Hello,
It will not work. The TRX-1/TRX-2 code is compiled for a M16c processor with 512K of flash memory. The flash memory "grows" down on the processor, so part of the code is expected to be stored in flash memory that does not exist on earlier scanners that have 384K of flash memory.
The NXDN decoding was added to TRX-1/TRX-2 code base. The other changes were added to both. It was not the case of NXDN being removed from the WS-1080.
73 Eric
scosgt
Member
- Joined
- Jul 22, 2004
- Messages
- 1,295
I think what he is saying is that the code for NXDN does not load, because the memory address that it resides in does not exist on the 1080
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.
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.
It's just all lip service; a convenient excuse. Ha, they knew "it couldn't fit" before they even started on it.
Hello,
Adding another mode, like NXDN, requires added CPU code, even when it uses the same vocoder. Code is required to decode the signal format, format the CCDump output, control the scanner, etc...,
It can be difficult to estimate how much additional space is required. Code space was getting tight on the WS-1080, so the company decided to update the platform and produce a new model.
The current code base with NXDN may fit into the flash memory size of the WS-1080. There could be fixes and enhancements in the future that will require more flash memory size, so they could not be applied to the WS-1080. That is not a good situation and it is better to be cautious by going with an improved hardware platform.
73 Eric
Adding another mode, like NXDN, requires added CPU code, even when it uses the same vocoder. Code is required to decode the signal format, format the CCDump output, control the scanner, etc...,
It can be difficult to estimate how much additional space is required. Code space was getting tight on the WS-1080, so the company decided to update the platform and produce a new model.
The current code base with NXDN may fit into the flash memory size of the WS-1080. There could be fixes and enhancements in the future that will require more flash memory size, so they could not be applied to the WS-1080. That is not a good situation and it is better to be cautious by going with an improved hardware platform.
73 Eric
Write new code.
I mean, at some point they are going to have to or the bugs and glitches are just going to accumulate. It can't be a patched on pair of pants forever.
And if it's time to optimize how it runs within the memory constraints, well put those resources into it. Prioritize which items are most important.
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'll never get to see it, but I bet most of the code for NXDN revolves around fitting to the RR DB. The very basic NXDN support offered by the scanner can't be that complicated.
I mean, at some point they are going to have to or the bugs and glitches are just going to accumulate. It can't be a patched on pair of pants forever.
And if it's time to optimize how it runs within the memory constraints, well put those resources into it. Prioritize which items are most important.
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'll never get to see it, but I bet most of the code for NXDN revolves around fitting to the RR DB. The very basic NXDN support offered by the scanner can't be that complicated.
DonS
Member
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.
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'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".
DonS,
Thank you for those insights into the development process. I find it extremely interesting.
Thank you for those insights into the development process. I find it extremely interesting.
- Status
