NXDN One Frequency vs Conventional NXDN Programming

werinshades · Nov 30, 2018

I've been working on a couple new NXDN systems here and have noticed something on both the x36hp and SDS 100 while programming. When I program the system as a One Frequency NXDN and add the TGID 0, both scanners seem to miss alot of transmissions. When it's programmed as Conventional NXDN, transmissions are received as normal. The simple answer would be just to program it as a NXDN Conventional however Alias ID's are not shown if they're programmed by the system administrator and if I'm trying to identify an unknown system, the Alias ID's can be very helpful. I don't believe I'm missing any programming steps...have it set up as s 4 second hold on the NXDN One frequency method to make sure the scanner is sampling the system long enough. TGID also has a 4 second hold and ran it in both ID Search and ID Scan without any differences. Does the scanner "ignore" TGID's of 0? Anyone experience this besides me?

W2GLD · Nov 30, 2018

I’m having the same issues with DMR, NXDN, and P25 One-Frequency Systems. As you said, programmed as conventional channels the miss no calls and I’ve been trying to resolve this myself. I know the programming is correct as is yours, it’s not you, it appears to be Uniden’s latest firmware releases since the SDS100 launch. I’m using two SDS100’s with firmware 1.06 myself. The DMR One-Frequency seems to work better with Motorola DMR repeaters but is sketchy with Hytera and MMDVM devices; basically doesn’t work 95% of the time. With P25 and NXDN One-Frequency Systems the results are identical. The issues are also worse when scanning One-Frequency systems with other scanlists; it’ll never stop on the One-Frequency systems but if I manually hold those system, the scanners will eventually decode them but there is so much missed traffic it makes these systems useless so I’ve simply given up for now and program them as conventional channels and I can hear all traffic just fine. I’ve reported this issue before but it seems to have fallen on deaf ears. Been and issue with the SDS100 since June; however, my previous BCDx36HP scanners didn’t have this issue prior to the SDS100’s release and I no longer own them in order to compare them side-by-side.

werinshades · Nov 30, 2018

W2GLD said:
I’m having the same issues with DMR, NXDN, and P25 One-Frequency Systems. As you said, programmed as conventional channels the miss no calls and I’ve been trying to resolve this myself. I know the programming is correct as is yours, it’s not you, it appears to be Uniden’s latest firmware releases since the SDS100 launch. I’m using two SDS100’s with firmware 1.06 myself. The DMR One-Frequency seems to work better with Motorola DMR repeaters but is sketchy with Hytera and MMDVM devices; basically doesn’t work 95% of the time. With P25 and NXDN One-Frequency Systems the results are identical. The issues are also worse when scanning One-Frequency systems with other scanlists; it’ll never stop on the One-Frequency systems but if I manually hold those system, the scanners will eventually decode them but there is so much missed traffic it makes these systems useless so I’ve simply given up for now and program them as conventional channels and I can hear all traffic just fine. I’ve reported this issue before but it seems to have fallen on deaf ears. Been and issue with the SDS100 since June; however, my previous BCx36HP scanners didn’t have this issue prior to the SDS100’s release and I no longer own them in order to compare them side-by-side.

You brought up something I didn't add. When Holding on TGID 0 on the One Frequency NXDN programmed system, transmissions are received more frequently, but still missing some. I had the SDS 100 programmed conventionally for comparison, and a 536HP programmed as One frequency NXDN trunk. Unfortunately, these systems are not as common so will be harder to duplicate.

jasonhouk · Nov 30, 2018

werinshades said:
You brought up something I didn't add. When Holding on TGID 0 on the One Frequency NXDN programmed system, transmissions are received more frequently, but still missing some. I had the SDS 100 programmed conventionally for comparison, and a 536HP programmed as One frequency NXDN trunk. Unfortunately, these systems are not as common so will be harder to duplicate.

Advise when programming as OFT are scanners in TGID search or scan. Same for RAN, in search or scan mode?

Houk

Sent from my Moto G (4) using Tapatalk

werinshades · Nov 30, 2018

jasonhouk said:
Advise when programming as OFT are scanners in TGID search or scan. Same for RAN, in search or scan mode?

Houk

Sent from my Moto G (4) using Tapatalk

TGID has been programmed as both ID Scan and ID Search mode. RAN's are programmed not in Search.

W2GLD · Nov 30, 2018

werinshades said:
TGID has been programmed as both ID Scan and ID Search mode. RAN's are programmed not in Search.

Same here, all of the OFT systems I've programmed (DMR, NXDN, or P25) have contained programmed talkgroups AND talkgroup search mode on and have had the associated Color Code, RAN, or NAC codes programmed (i.e. not search mode).

Ubbe · Nov 30, 2018

W2GLD said:
The DMR One-Frequency seems to work better with Motorola DMR repeaters but is sketchy with Hytera and MMDVM devices.....it’ll never stop on the One-Frequency systems but if I manually hold those system, the scanners will eventually decode them .....however, my previous BCDx36HP scanners didn’t have this issue prior to the SDS100’s release...

It's no different with BCD536 and my experiance are that it was that way long before any SDS100 firmwares where released.

/Ubbe

jasonhouk · Dec 1, 2018

I have forwarded this thread to engineering as well as the SDS100 Beta Group for discussion/testing to try to reproduce.

Houk

frazpo · Dec 2, 2018

W2GLD said:
The issues are also worse when scanning One-Frequency systems with other scanlists; it’ll never stop on the One-Frequency systems but if I manually hold those system, the scanners will eventually decode them but there is so much missed traffic it makes these systems useless so I’ve simply given up for now and program them as conventional channels and I can hear all traffic just fine. .

I agree with the previous posts on this matter. The quote I clipped above I have wondered about also. I see the same here with both a 436 and a SDS100. However, I also have noticed that it seems to do better with different antennas. I was thinking sensitivity but now I wonder. I'll do more experimenting with programming as conventional.

LeSueurC · Dec 2, 2018

This works for me, if it’s OFT just program the Color Code, nothing else. Also on your trucked NXDN and TRBO systems, run LCN finder, I have found if you at least 2 or more confirmed LCN’s found you will get more traffic

werinshades · Dec 2, 2018

I don't see this issue with DMR One Frequency as I do with NXDN One Frequency. My "theory" is that DMR One Frequency systems use talk groups 1 or above while NXDN One Frequency use talk group 0 unless someone has a NXDN one frequency system that's different. Like I mentioned in the OP, I suspect the firmware needs a "tweak" to recognize talk group 0 and all will be right in the NXDN One Frequency world again. This is primarily to see Alias ID's if the system administrator has programmed them. If not Conventional NXDN will work just fine.

W2GLD · Dec 3, 2018

This is not just related to NXDN OFT, the issue is happening with ALL OFT systems. If you hold on the system and that OFT system alone, it decodes; however, when scanning multiple systems at the same time, it will never stop on the OFT systems, even though there is traffic on the system. Programming the same NXDN, DMR, or P25 frequencies as conventional, the scanner hits them every time. I have this occurring on two different SDS100's from different serial number lots and others report the same issue with the BCDx36HP series as well. Finally someone has passed this over to engineering so they can have a look; but as it stands today, OFT systems are useless with the current 1.06 firmware on the SDS100 and all previous firmware releases as well; I went back and tested each one and confirmed the exact same operation. For now, the only way to track single frequency NXDN, DMR, and P25 systems alongside multiple systems is to use the conventional programming method and forgo using OFT systems. Check you programming, I bet if you followed the same methods as we have you will clearly see the issue first hand. Example, create a OFT system (mode doesn't matter) and enter several different sites and then a frequency for each site, set the RAN/COLOR/NAC Code and add some talkgroups, set talkgroup search to on and then try to scan that system with other conventional, P25 Trunking, etc scan lists and see how often it actually captures traffic from the OFT system; I think you'll be pretty surprised how often it completely misses traffic; then add those same frequencies to a conventional list and see it stop each and every single pass on that system missing nearly no traffic at all. OFT systems are useless at the present time.

werinshades · Dec 3, 2018

W2GLD said:
This is not just related to NXDN OFT, the issue is happening with ALL OFT systems. If you hold on the system and that OFT system alone, it decodes; however, when scanning multiple systems at the same time, it will never stop on the OFT systems, even though there is traffic on the system. Programming the same NXDN, DMR, or P25 frequencies as conventional, the scanner hits them every time. I have this occurring on two different SDS100's from different serial number lots and others report the same issue with the BCDx36HP series as well. Finally someone has passed this over to engineering so they can have a look; but as it stands today, OFT systems are useless with the current 1.06 firmware on the SDS100 and all previous firmware releases as well; I went back and tested each one and confirmed the exact same operation. For now, the only way to track single frequency NXDN, DMR, and P25 systems alongside multiple systems is to use the conventional programming method and forgo using OFT systems. Check you programming, I bet if you followed the same methods as we have you will clearly see the issue first hand. Example, create a OFT system (mode doesn't matter) and enter several different sites and then a frequency for each site, set the RAN/COLOR/NAC Code and add some talkgroups, set talkgroup search to on and then try to scan that system with other conventional, P25 Trunking, etc scan lists and see how often it actually captures traffic from the OFT system; I think you'll be pretty surprised how often it completely misses traffic; then add those same frequencies to a conventional list and see it stop each and every single pass on that system missing nearly no traffic at all. OFT systems are useless at the present time.

I have and am properly trunk tracking 5 different One Channel DMR sites and my 536 and SDS100 are following them. I only have 1 site programmed per system which would be the proper way to program these systems. Maybe program 1 site per system and see if that improves the DMR One channel issue you're experiencing. If more than 1 site is programmed, the scanners sample each site which would defeat the purpose. Find the closest one to your location and shut off the others systems.

W2GLD · Dec 3, 2018

werinshades said:
I have and am properly trunk tracking 5 different One Channel DMR sites and my 536 and SDS100 are following them. I only have 1 site programmed per system which would be the proper way to program these systems. Maybe program 1 site per system and see if that improves the DMR One channel issue you're experiencing. If more than 1 site is programmed, the scanners sample each site which would defeat the purpose. Find the closest one to your location and shut off the others systems.

Not exactly true, I am tracking DMR ham frequencies which each frequency is a different repeater system / site or a hotspot; there is no reason these all cannot be added to a OFT system which then can scan between the frequencies/sites to allow talkgroup tracking. Even programmed with a single OFT > Single Site > Single Frequency the same scan issues exist. I have exhausted this troubleshooting to no end with the OFT systems. Conversely, I also have a Whistler TRX-1 which I program a DMR trunk system and it tracks all of these sites/frequencies without issue and NEVER misses traffic and tracks the talkgroups perfectly. With that said, there is no reason the Uniden's shouldn't do the same and ideally I'd like to only have one radio, the Uniden in this case. The Uniden clearly has issue with the firmware amongst others; but I prefer Uniden's programming schema, but if it cannot properly track systems then what's the point. The feature is not working properly so please don't defend Uniden's firmware flaws.

werinshades · Dec 3, 2018

W2GLD said:
Not exactly true, I am tracking DMR ham frequencies which each frequency is a different repeater system / site or a hotspot; there is no reason these all cannot be added to a OFT system which then can scan between the frequencies/sites to allow talkgroup tracking. Even programmed with a single OFT > Single Site > Single Frequency the same scan issues exist. I have exhausted this troubleshooting to no end with the OFT systems. Conversely, I also have a Whistler TRX-1 which I program a DMR trunk system and it tracks all of these sites/frequencies without issue and NEVER misses traffic and tracks the talkgroups perfectly. With that said, there is no reason the Uniden's shouldn't do the same and ideally I'd like to only have one radio, the Uniden in this case. The Uniden clearly has issue with the firmware amongst others; but I prefer Uniden's programming schema, but if it cannot properly track systems then what's the point. The feature is not working properly so please don't defend Uniden's firmware flaws.

Not defending anything, just trying to make a programming suggestion. Unless something has changed, Whistler doesn't "trunk track" DMR but rather "scans and decodes" MotoTRBO, NXDN, DMR systems which would explain the difference. Other than that, the One Channel DMR systems are being trunked and decoded properly, but in your case might have to tweak the programming a bit to get the results you want. The One Channel NXDN programming is what I posted about and was submitted for review...thanks Jason Houk!

dave3825 · Dec 3, 2018

W2GLD said:
This is not just related to NXDN OFT, the issue is happening with ALL OFT systems.

I have a p25 set as oft that does a roll call monthly and watched in sdr# with dsd at the same time. The 436 was missing transmissions. My kids school uses nxdn. Programmed them as oft and same thing. Not hearing the whole conversations. Maybe they could add the alias feature to conventional freqs..

sonm10 · Jan 31, 2019

I am also having this issue monitoring dmr with 996p2. just will not scan oft systems along with other systems

kc9pwb · Feb 1, 2019

Just FYI for what it might be worth. If you setup the SDS 100 favorite list with just one P25 system, using one local tower site only. Then set the sds 100 for detailed Trunking Display, then watch the frequency it monitors, you will see it only monitors one frequency, but when there is someone talking it will display the voice channel frequency they are talking on. This is a visual proof of how a true trunking system should work. On the TRX-1, or TRX-2 they scan all the frequencies including the voice channel frequencies to lock on the TG's you are monitoring. This is the primary reason the TRX-1 or TRX-2 will miss some transmissions. I had both the TRX-1 and TRX-2 scanners and sold them both and now use the SDS 100. I have found from testing, that if you add one county from a statewide p25 system from the database in sentinal, it will actually add every trunking site in the state. In Indiana SAFE-T system this is 147 sites, with and average of 5 frequencies per site including voice channels. On the SDS 100 it would scan 147 control channels for you programmed TGID's. On the TRX-1 and TRX-2 it will scan approximately 735 frequencies, 147 time 5 avg. It is rather obvious why the TRX-1 or TRX-2 would miss transmissions. On the SDS 100, if you remove all but the local tower site, you will reduce the scan to 5 to 7 frequencies, much less likely to miss any transmissions. Also remember that by default each P25 frequency, or talk group has a 2 sec delay. In a trunking system, a reply can move to a different frequency and you will miss the response. So I always set any thing on a P25 trunking system to 0 sec, delay. I am pretty sure this would hold true for any true trunking system.

VE2ZPS · Feb 23, 2019

I am very sorry I wrote on the same subject yesterday; I think it was the second or third time I initiated a Thread on RR.
I was so disappointed with my SDS100 and SDS200 it probably didn't help located this Thread

I have severe problem with Single Frequency both DMR and NXDN on both SDS100 and SDS200
They provide roughly 25% of the transmissions picked-up by my 536.

I assume Uniden is well aware of this situation ? and is there any initiative being explored to fix this situation ?

Again very sorry for my othe thread
https://forums.radioreference.com/threads/sds100-200-and-dmr-nxdn-one-frequency.384235/

werinshades · Feb 23, 2019

We all understand, when your pi**ed something is working correctly on a newly purchased scanner, you lose your mind. As far as what the engineers are working on, most of us don't know. It's a triage system i'm sure in which issues are addressed by importance or number of customers affected. The humming issue has taken center stage as I'm sure their have been some returns which isn't making Uniden happy. I've given up on testing this issue as I know it's the scanner's issue and nothing to do with my programming. I've posted on some other issues that I hope get attention as well by submitting debug files and detailed descriptions. It has potential to be as good or better than it's predecessors but needs some tweaking. I'd continue to use what works and possibly divert some other listening to the SDS 200 that it does receive without issues as I have.

NXDN One Frequency vs Conventional NXDN Programming

Member

Active Member

Member

Member

Member

Active Member

Member

Member

Member

IBEW Local 50

Member

Active Member

Member

Active Member

Member

* * * * * * * * * * * *

Central MN Monitor

Member

Member

Member

Similar threads