NEW UPDATE available - 7/11/16

[DonS]

Locked-out frequencies are treated exactly the same as entries with a value of zero. That is, the logic, common to all trunked system types, is like the following:

if ( site.frequency[index].freq && !site.frequency[index].lockout )
  /* use this freq */
else
  /* try next freq */

If there was a problem with handling zero values, you'd see it in every trunked system type. It would not be limited to DMR - and (to my knowledge) no such problem has been reported since the PSR-800 was released.

 

[troymail]

This is a DMR Capacity Plus system I am working with. I am wondering if it has something to do with the timeslot changes since there is no way to set timeslots in DMR trunking. Seems like there should be an additional column so we could set timeslot to any as with conventional.

KF5MWE

Timeslots can matter for conventional but for trunk systems, the timeslot *shouldn't* matter (unless there is something special about DMR/MotoTRBO). This is the same for P25 Phase 2. In TDMA systems, the "time slot" is just another channel the system can dynamically assign to system users.

 

[ipdeman]

Did the Global Attenuator get enabled somehow? Will show as an A or GA on the display.

Global Attenuation is Off so did not accidentally get turned on.

 

[ipdeman]

When programmed as a trunked system, did you leave each programmed frequency's Color Code set to "Any"?

When scanning the trunked system, do you see the inverted 'S' indicator a lot (but not the inverted 'T' indicator)? If so, you have the squelch set too low. Turn the knob clockwise just until the 'S' indicator disappears. If you're seeing that inverted 'S' (but not inverted 'T'), you'll definitely miss DMR traffic.

In the Whistler scanners, DMR trunking is always "time slot 'any'". The scanner doesn't care about time slot. It only cares about talkgroup ID and, if set for a particular frequency, color code.

Color code is set to any and I have the squelch turned to the point it zooms through the inverted S.

As mentioned before, all I did was update the firmware and DMR Trunking stopped receiving. I double checked all my programming and it's exactly as before the update. Thanks

KF5MWE

 

[ipdeman]

Timeslots can matter for conventional but for trunk systems, the timeslot *shouldn't* matter (unless there is something special about DMR/MotoTRBO). This is the same for P25 Phase 2. In TDMA systems, the "time slot" is just another channel the system can dynamically assign to system users.

Thanks. I didn't know.

KF5MWE

 

[ipdeman]

OK Guys. I turned my squelch up even higher and have started receiving some traffic. At least now it's not totally silent. It still misses traffic that the MD-380 receives though..

 

[troymail]

OK Guys. I turned my squelch up even higher and have started receiving some traffic. At least now it's not totally silent. It still misses traffic that the MD-380 receives though..

I see the same issue. But keep in mind that the MD-380 (I have an MD-390) are specific to a band (150Mhz, 450 Mhz, etc.) and scanners are "all band". Obviously, the MD380/390 will do better. This is particularly the case given most DMR systems (with some exceptions) are not designed to cover huge areas like many public safety systems do.

FWIW - I have systems that my Whistlers (and MD-390) receive that the Uniden can hear at all.

 

[buddrousa]

OK Guys. I turned my squelch up even higher and have started receiving some traffic. At least now it's not totally silent. It still misses traffic that the MD-380 receives though..

Your MD380 scans 16 channels is my guess how many channels is your scanner scanning.

 

[KC1UA]

If there was a problem with handling zero values, you'd see it in every trunked system type. It would not be limited to DMR - and (to my knowledge) no such problem has been reported since the PSR-800 was released.

With all due respect to you Don, I must disagree with this.

I was scanning a 4 frequency Con+ DMR system, by itself, against first a Uniden BCD436HP and then DSD+ which is the true telling tale of performance. No matter either way. All test platforms scanned the same system exclusively.

With the remaining 28 entries of 0.00000 unlocked, the TRX-1 was going off into space while the 436 and DSD+ received an abundance of traffic. I adjusted squelch from stem to stern with no difference in the results. As soon as I locked out the 28 0.00000 entries, the TRX-1 came to life and kept up with the other test units.

In each case all scanners or DSD+ setups were using the same antenna via a multicoupler. A few times when the TRX-1 and 436 were being compared both were using a RS 800 antenna. The systems in question are at 935-940 MHz in my area.

It's not a big deal, compared to the slot 2 issue on conventional DMR, which I reported and was fixed in the latest firmware update. This is just a matter of locking out the frequencies. I know what I observed and I'll argue it until the cows come home. It's an easy end-user fix.

It does seem to be unique to DMR as far as I can tell. I left the Motorola 3600 baud mixed-mode system I normally monitor with the remaining 19 or so 0.00000 entries unlocked to see how it stacked up. There was not an issue.

Finally, I do believe that at least one other person stated they confirmed this in my "TRX-1 Missing DMR Transmissions" thread, and I reported it to a customer service rep of Whistler after he called me...not the other way around.

Thanks for your continued effort. I have great faith in the product and I know from years of using your software and interacting with you, you are on top of eveything you're involved with, but I am going to beg to differ on this statement.

 

[ipdeman]

Your MD380 scans 16 channels is my guess how many channels is your scanner scanning.

For testing I had both programmed to scan 2 TGs and 1 site of 3 freqs.

Normal programming is the MD-380 is scanning 19 TGs. The WS-1080 is scanning 17 TGs. Both are programmed to the same number of freqs. 4 sites with 3 freqs each site.

 

[buddrousa]

Are they both sharing the same antenna through a multicoupler?

 

[ipdeman]

Are they both sharing the same antenna through a multicoupler?

No both with stock antennas. The thing is I did not have this problem until the latest firmware upgrade.

 

[buddrousa]

My TRX-2 got better on DMR Trunking with the new upgrade. Unless you share the same antenna with a multicoupler you are not comparing apples to apples.

 

[ipdeman]

My TRX-2 got better on DMR Trunking with the new upgrade. Unless you share the same antenna with a multicoupler you are not comparing apples to apples.

I am in no way comparing the receive capabilities of the WS-1080 to the MD-380. I am only pointing out that I received a lot of traffic on the MD-380 and none on the WS-10180 since the change, with both programmed the same,

DMR programmed as conventional works great. So for now, I have programmed channels as conventional and that works.

KF5MWE

 

[rickey456]

Does this fix the Spectrum Sweeper problem?

Doing the update - does this fix the spectrum sweeper problem?

 

[buddrousa]

POST #12
The changes can be viewed within the PC app. Do the "check for updates" for PC app, DSP, and CPU and you'll see a "View Release Notes" button. Click it, and a web browser will open showing the changes.

Here's a copy/paste of the changes displayed by the WS1080/88 PC app (all other models are the same):

PC App:
Version 2.11 - July 11, 2016
•Revised the method used to update scanlists which resulted in a very noticeable speed difference in the process.
•Added ability to add a DMR conventional channel using the new channel wizard on the Scanlist tab. To do so, select the Conventional DMR type when adding the channel. DMR options will then be presented.
•Conventional objects may now be switched between all modes including DMR. When the mode column is selected, a drop-down will appear to allow the selection of the desired channel mode.

Please note the following: ◦When switching between FM and NFM, the squelch information will be preserved.
◦When switching to or from any other mode, the squelch information will be changed to search mode and the digital mode will be set based on the channel mode.
◦To cancel the mode change once the pull-down appears, press the Esc key.
◦If multiple conventional objects are selected, all objects will be changed to the new mode. Squelch and digital mode changes will be done on an object by object basis.

•Conventional DMR import will now accept an Asterisk (*) or the word "Any" (Without quotes, not case sensitive) as a color code wildcard value in addition to an empty value. An invalid color code value will also import with a wildcard (any) color code.
•Conventional objects in the scanlist tab will now show either "Analog" or "DMR" in the system column depending on the conventional object type.
•Changed the method used to determine the system type on the audio recording screen. This allows the application to show the talkgroup ID in the correct format based on the system type.

Note: Recordings made before CPU Firmware version 3.6 and coming from an EDACS, Motorola type I or type IIi, or LTR systems may not display properly in this software version depending on the currently loaded configuration.
•Fixed an issue where the object lists in the conventional and trunked import from clipboard or text would autoscroll when the mouse was moved out of the list area.
•Fixed tab order and selection issues when using tab on conventional object add screens
•Fixed tab order and selection issues when using tab on the new channel wizard screens in the scanlist tab.
•Fixed an issue with the conventional import from the clipboard or CSV file where DMR frequencies being imported were being given a color code 0 (Zero) value when the import did not include a color code field. Imported items will now have a wildcard (any) value.
•Fixed a display bug in the scanlist listing for LTR and EDACS systems.
•Fixed a crash when attempting to load the listing of audio files stored on the computer when the default audio folder does not exist.
CPU Firmware:
Version 3.6 - July 11, 2016
•Search/Sweeper: Fixed recording info error
•DMR: Fixed problem with slot 2 in CONV objects
•Search/Sweeper: extend allowed "store" time into delay
•Added trunking system type to recording header
•Search/stalker modes "record stop" revisions
•Fixed problem with search record "always on"
•Fixed Sweeper bug
DSP Firmware:
Version 2.3 - June 21, 2016
•Change how DMR PDUs are sent to CPU

 

[kikito]

Doing the update - does this fix the spectrum sweeper problem?

Yep it does. I mentioned that in the first page of this thread.

 

[ipdeman]

I am in no way comparing the receive capabilities of the WS-1080 to the MD-380. I am only pointing out that I received a lot of traffic on the MD-380 and none on the WS-10180 since the change, with both programmed the same,

DMR programmed as conventional works great. So for now, I have programmed channels as conventional and that works.

KF5MWE

Latest update. I deleted my DMR Trunked system programming and started over. The first thing I noticed is the subtype now says "Auto" instead of "P25 Auto". In any case after reprogramming all the talk groups back in with the the frequency programming, it's works again.

 

[ipdeman]

Latest update. I deleted my DMR Trunked system programming and started over. The first thing I noticed is the subtype now says "Auto" instead of "P25 Auto". In any case after reprogramming all the talk groups back in with the the frequency programming, it's works again.

I wanted to say thanks for all the help and replies during my quest to find out why the update broke my DMR receiving. It seems that the whole problem appears to have been corrupted programming even though I wrote to the radio many times. Everything is working perfectly now. Staring over fixed it. Loving my WS-1080. Thanks everyone.

KF5MWE

 

[chankel]

TRBO upgrade working on WS-1095

I spent yesterday and today setting up my WS-1095 with the DMR update and adding channels and systems from RR. After updating the firmware and loading up the new information it seems to work so far on TRBO, although there wasn't much traffic as these systems are mostly used by businesses in Lancaster Co PA. I'm pleasantly surprised so far.

Still planning to get the TRX-1 and TRX-2 though as the old PSR-800 will never have DMR or NXDN capability and I suspect the -1095 lacks the capability for NXDN.