WS1080: 1080 Dec DSP Firmware Update V3.0; What is it?

Status
Not open for further replies.

AggieCon

Member
Premium Subscriber
Joined
Nov 25, 2015
Messages
1,444
Location
Texas
Whistler EZ SCAN Digital
Handheld Trunking Scanner
DSP Firmware
Release Notes
Version 3.0 - December 15, 2016
  • Add support for NXDN
 

EricCottrell

Member
Database Admin
Joined
Nov 8, 2002
Messages
2,293
Location
Boston, Ma
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
 

AggieCon

Member
Premium Subscriber
Joined
Nov 25, 2015
Messages
1,444
Location
Texas
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.
 

SCPD

QRT
Joined
Feb 24, 2001
Messages
65,126
Location
Virginia
Quality?

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.

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,312
They are grasping at strings to make a sale, I suppose. There's no technological reason the 1080 couldn't do NXDN.
Doesn't the WS1080 lack enough flash memory to be able to support NXDN?

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.
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.
 

scosgt

Member
Joined
Jul 22, 2004
Messages
1,276
Then, in theory, it should do NXDN. Maybe program the SD with the TRX version and load NXDN and see what it does.
 

Wackyracer

Member
Premium Subscriber
Joined
Feb 18, 2016
Messages
1,244
Then, in theory, it should do NXDN. Maybe program the SD with the TRX version and load NXDN and see what it does.
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
 

EricCottrell

Member
Database Admin
Joined
Nov 8, 2002
Messages
2,293
Location
Boston, Ma
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
 

AggieCon

Member
Premium Subscriber
Joined
Nov 25, 2015
Messages
1,444
Location
Texas
I don't buy it. There's no way decoding NXDN takes substantially more memory or power than P25 or DMR.
 

scosgt

Member
Joined
Jul 22, 2004
Messages
1,276
I don't buy it. There's no way decoding NXDN takes substantially more memory or power than P25 or DMR.
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
 

AggieCon

Member
Premium Subscriber
Joined
Nov 25, 2015
Messages
1,444
Location
Texas
Version 4.4 - December 15, 2016
  • Changed 450-470 MHz range to 3.125kHz steps
  • Misc, minor DMR enhancements & optimizations
  • Memory usage reductions
 

milf

Careful, I CAN hear you!
Database Admin
Joined
Dec 18, 2002
Messages
12,989
Location
Indianapolis, IN
I don't buy it. There's no way decoding NXDN takes substantially more memory or power than P25 or DMR.
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.
 

AggieCon

Member
Premium Subscriber
Joined
Nov 25, 2015
Messages
1,444
Location
Texas
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.
 

EricCottrell

Member
Database Admin
Joined
Nov 8, 2002
Messages
2,293
Location
Boston, Ma
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
 

AggieCon

Member
Premium Subscriber
Joined
Nov 25, 2015
Messages
1,444
Location
Texas
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.
 

DonS

Member
Joined
Jun 17, 2003
Messages
4,105
Location
Franktown, CO
Version 4.4 - December 15, 2016
  • Memory usage reductions
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.

It fit. There was room.
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".
 
Status
Not open for further replies.
Top