Telling it to play only a certain RAN is just one more thing that might hang it up. Unless there is a compelling reason to do otherwise (e.g. interference from nearby system), program the scanner to receive liberally. What is your delay time?
How to improve NXDN scanning
- Thread starter AggieCon
- Start date
- Status
So AggieCon or anybody,
Any ideas or suggestions as to why even programming a NXDN trunked system voice frequencies conventionally, the scanner still doesn't stop at all at any of the active frequecies while scanning them? Even manually tuning to the programmed channel still doesn't decode. I can see the signal bar in full, so I know is receiving it. Is almost like something is keeping it from opening squelch and decoding. The RAN is set to ANY, TG is set to ANY, etc. Tried many other combinations to no avail. I'm open to try any suggestions.
The only way I've been able to decode NXDN in my area is by using the Limit Search and programming the range of frequencies used. Oh and some purely conventional NXDN frequecies can be scanned and decoded as expected.
And I also submitted a bug report email to Whistler about this.
Any ideas or suggestions as to why even programming a NXDN trunked system voice frequencies conventionally, the scanner still doesn't stop at all at any of the active frequecies while scanning them? Even manually tuning to the programmed channel still doesn't decode. I can see the signal bar in full, so I know is receiving it. Is almost like something is keeping it from opening squelch and decoding. The RAN is set to ANY, TG is set to ANY, etc. Tried many other combinations to no avail. I'm open to try any suggestions.
The only way I've been able to decode NXDN in my area is by using the Limit Search and programming the range of frequencies used. Oh and some purely conventional NXDN frequecies can be scanned and decoded as expected.
And I also submitted a bug report email to Whistler about this.
What happens if you hold on just one of the frequencies? Will that play?
EDIT: If you are trying to scan Santa to see what we are getting for Christmas, that's probably your problem. The Red Nose RD encryption protocol is quite effective. That's why Christmas morning is always a surprise.
EDIT: If you are trying to scan Santa to see what we are getting for Christmas, that's probably your problem. The Red Nose RD encryption protocol is quite effective. That's why Christmas morning is always a surprise.
My delay is 2.0 seconds. I tried a delay of 0.3 seconds, but this just makes it resume scanning quicker upon a signal dropout, usually never to stop again.
It sits there, you can see when the frequency becomes active by the signal bar going full and nothing gets decoded.
Now that's funny right there!
Not at this time. I've tried that one too with similar results. This is the one I'm currently working on:
WNHG232 (Communications Equipment and Service, LLC) FCC Callsign Details
Only four frequencies are used in trunked as far as I can tell, including the control channel, which rotates every day and they are:
461.050
461.750
462.050
462.450
The rest are used in analog conventional as determined by my monitoring of all of them conventionally. This company seems to do this a lot. They have bulk licenses in VHF/UHF and 800MHz listed as trunked but only a few of the frequencies are used in trunked.
Well I suppose it's either the demodulator doing a poor job at the 4-level FSK, the decoder not recognizing NXDN, or some sort of firmware error that is causing these problems.
That license is 8K30F1E, which is the wideband variety of NXDN.
I'm wondering if it the firmware, being rushed out, is having trouble determining what is actually NXDN. If it's not reading it correctly, it's just ignoring it I guess. Perhaps they should tell it to send to the vocoder regardless of what header frames they are reading.
Probably to the point of wasting time now. Probably should wait for them to release the version that actually works.
That license is 8K30F1E, which is the wideband variety of NXDN.
I'm wondering if it the firmware, being rushed out, is having trouble determining what is actually NXDN. If it's not reading it correctly, it's just ignoring it I guess. Perhaps they should tell it to send to the vocoder regardless of what header frames they are reading.
Probably to the point of wasting time now. Probably should wait for them to release the version that actually works.
Yep, it shouldn't be this hard or tricky to get the radio to just decode the voice in any mode i.e. trunked, conventional, etc. Especially when it can do so in Limit Search mode just by programming a frequency range and it displays RAN, TG ID, Radio ID, NXDN 4800/9600 Type-D/Type C and even Encryption on any NXDN transmission found.
When DMR was released, I could decode at least voice in any mode without any complicated programming or knowledge.
I really need to set some time aside and get my DSD setup going...
Yep, pretty crazy how it works in search mode but not scan or monitor. I'm thinking they have something not quite right so it's disregarding the broadcast as not being wanted. But in search mode, it plays anything and everything.
I wonder how it is working on the 4800 bit rate systems?
I wonder how it is working on the 4800 bit rate systems?
I know there was a similar bug not that long ago with the Spectrum Search where after a firmware update it wouldn't stop on any hits but it would stop on active frequencies on Search Limit. They released a patch soon thereafter to fix it but it was weird how it suddenly broke from one update to the other.
Your comment about 4800 systems might be another clue on my problem. So far all the NXDN hits I get on Limit Search ALWAYS are identified as "NXDN96" transmissions. I haven't come across any "NXDN48".
The way is acting is almost the same as when you have an analog frequency programmed with a particular CTCSS tone and you receive a transmission with a different tone, therefore, the squelch won't open to let the audio through.
I think you might be on to something.
I vaguely remember a problem with the color code when DMR was first released.
For whatever reason, the scanner doesn't think we want to hear the broadcasts. Likely a minor software programming issue.
PS Sent you mail re DSD
racingfan360
Member
- Joined
- Dec 19, 2005
- Messages
- 1,185
Just to confirm, I have my TRX-1 successfully decoding both Conventional NXDN4800 and NXDN9600 on Spectrum Sweeper and Limit Search. I can't comment on the trunked NXDN.
>and even Encryption on any NXDN transmission found.
kikito: can you confirm you have seen Encryption being displayed on NXDN please? I have undertaken several tests and can't see this at all.
Joseph11
Member
- Joined
- Nov 17, 2004
- Messages
- 2,270
I've received multiple transmissions in NXDN that the scanner recognized as encrypted.
Sent from my iPhone using Tapatalk
troymail
Silent Key
Any chance that some of what people are not hearing voice on might be a data transmission?
I've been monitoring both conventional and trunked systems in my area with DSD+ for a while anticipating the release of this capability. As with DMR, there are some licenses that require you to be pretty close to the transmitter to receive them. Then again, there are other (service providers?) in the area that blast their signals out over many counties (still baffled as to why they can do this but the public safety folks are being told they have to "cut back" their power, but I digress).
The trunk systems I have in the area are both Type C and Type D. I've also played with some in other states during my travels. Most of these systems are not heavily used (yet). What I find interesting is that each of these systems seems/feels "just a little bit different". I'm still learning but as best I can tell, there are many different ways a system can be configured to work - seems like many more than when looking at how P25 systems are configured (which makes sense and is supposed to be one of the reasons public safety, etc. was pushed to P25).
For completeness, I'd like to echo what Mike said earlier - to allow others to try and help, it would be helpful if when indicating a problem that you provide some details of the system, frequencies, license info (if you have it), type (4800? 9600?) - if you know it, etc. Also, if you are using something else like DSD+ and hearing voice but the radio is not, that would help greatly as well.
I was watching site 9 of a Type C system yesterday (had been watching it when in the area on DSD+ but I only get near the site once every 1-2 months) - it has 5-6 frequencies supposedly (licensed as a) trunk system:
Fleetcall Trunking System, Various, Multi-State - Scanner Frequencies
which is location #3 of this license:
ULS License - Industrial/Business Pool, Trunked License - WQFF501 - BayComm, Inc. - Locations Summary
There is a steady (I assume based on the DSD+ information) control channel signal on the first licensed frequency.
In the time I was watching it yesterday (couple of hours), I only noticed a single user set and each time they keyed up, they seemed to use the same frequency as the control channel. I could hear the activity in both conventional and trunked programming modes and the voice never dropped out at all.
Because of these observations, removing the control channel frequency from my configuration would have resulted in me not hearing anything. It was present and it didn't seem to cause me any major issues. However, another system I've watched previously had a control channel and voice never seemed to appear on that one.
As others have reported, there are also (on at least one system I've watched) data like radios registering and leaving the system similar to what I'm used to seeing on P25 systems using Pro96Com (great tool!) but best I can tell, the control channel remains a control channel at all times (no voice)And on yet another system - licensed and reported to be trunked (but I am really starting to think is conventional), each transmission seen on DSD+ ends with what looks like a "private call" on a specific talkgroup ID (not sure what this is - maybe location data?)
What I did see that caused alot of problems was if I had the squelch fully CCW.
From what I am seeing, there are some "specific" settings that improve reception and some that (potentially) make it worse:
Only scan the site closest to you (at least initially) and the frequencies that are believed to be associated with that one site. You must have all of the frequencies programmed but as far as I can tell (just like DMR), they do not need to be in any specific order or "spaced" in the frequency table.
I have seen cases where I didn't hear replies but sometimes it turns out I didn't have all of the frequencies programmed (some systems/sites listed on RRDB only show a control channel but the licenses show others).
Some improvement can be seen by setting the system to the specific type - 4800, etc. vs letting the radio "figure it it".
On a related note - if this value is incorrectly set (i.e. set to 9600 but it's really 4800), you're not going to hear anything. If you're not sure, set it to auto. Once you determine the correct setting, change the system to the proper setting.
Also, keeping the squelch setting to a minimum (best I can explain there is about "half" or at the 12 o'clock position).
It has been said in other threads that anything that the radio "detects" as breaking squelch will be looked at by the radio as a possible NXDN call. Open squelch or noisy environments will then likely cause issues. I suspect that there could potentially be issues (but am not certain) if the system is very busy and/or has many frequencies and you're trying to monitor a specific talkgroup (and/or hear a response).
Some other settings can potentially stop you from receiving - I believe one being the RAN value. If it works the same in the radio as a DMR color code, then it becomes another detail that the radio must detect - other wise you hear nothing. If you don't need to set it, don't.
Delay settings are another thing to play with. If you're having problems, try scanning ONLY the system/site closest to you (as mentioned previously) and experiment with the delay settings. I've found in some cases, the best option is to turn the delay OFF (but only if you're playing with a single system/site).
I'm not sure what to make of "dropouts" of active voice -- I've seen some limited amount of that. There could be a variety of reasons this happens but in my case, watching DSD+, it looks like occasionally I see some type of really strong single in the area that might be causing temporary interference. Of course, there are likely other reasons.
I've been monitoring both conventional and trunked systems in my area with DSD+ for a while anticipating the release of this capability. As with DMR, there are some licenses that require you to be pretty close to the transmitter to receive them. Then again, there are other (service providers?) in the area that blast their signals out over many counties (still baffled as to why they can do this but the public safety folks are being told they have to "cut back" their power, but I digress).
The trunk systems I have in the area are both Type C and Type D. I've also played with some in other states during my travels. Most of these systems are not heavily used (yet). What I find interesting is that each of these systems seems/feels "just a little bit different". I'm still learning but as best I can tell, there are many different ways a system can be configured to work - seems like many more than when looking at how P25 systems are configured (which makes sense and is supposed to be one of the reasons public safety, etc. was pushed to P25).
For completeness, I'd like to echo what Mike said earlier - to allow others to try and help, it would be helpful if when indicating a problem that you provide some details of the system, frequencies, license info (if you have it), type (4800? 9600?) - if you know it, etc. Also, if you are using something else like DSD+ and hearing voice but the radio is not, that would help greatly as well.
I was watching site 9 of a Type C system yesterday (had been watching it when in the area on DSD+ but I only get near the site once every 1-2 months) - it has 5-6 frequencies supposedly (licensed as a) trunk system:
Fleetcall Trunking System, Various, Multi-State - Scanner Frequencies
which is location #3 of this license:
ULS License - Industrial/Business Pool, Trunked License - WQFF501 - BayComm, Inc. - Locations Summary
There is a steady (I assume based on the DSD+ information) control channel signal on the first licensed frequency.
In the time I was watching it yesterday (couple of hours), I only noticed a single user set and each time they keyed up, they seemed to use the same frequency as the control channel. I could hear the activity in both conventional and trunked programming modes and the voice never dropped out at all.
Because of these observations, removing the control channel frequency from my configuration would have resulted in me not hearing anything. It was present and it didn't seem to cause me any major issues. However, another system I've watched previously had a control channel and voice never seemed to appear on that one.
As others have reported, there are also (on at least one system I've watched) data like radios registering and leaving the system similar to what I'm used to seeing on P25 systems using Pro96Com (great tool!) but best I can tell, the control channel remains a control channel at all times (no voice)And on yet another system - licensed and reported to be trunked (but I am really starting to think is conventional), each transmission seen on DSD+ ends with what looks like a "private call" on a specific talkgroup ID (not sure what this is - maybe location data?)
What I did see that caused alot of problems was if I had the squelch fully CCW.
From what I am seeing, there are some "specific" settings that improve reception and some that (potentially) make it worse:
Only scan the site closest to you (at least initially) and the frequencies that are believed to be associated with that one site. You must have all of the frequencies programmed but as far as I can tell (just like DMR), they do not need to be in any specific order or "spaced" in the frequency table.
I have seen cases where I didn't hear replies but sometimes it turns out I didn't have all of the frequencies programmed (some systems/sites listed on RRDB only show a control channel but the licenses show others).
Some improvement can be seen by setting the system to the specific type - 4800, etc. vs letting the radio "figure it it".
On a related note - if this value is incorrectly set (i.e. set to 9600 but it's really 4800), you're not going to hear anything. If you're not sure, set it to auto. Once you determine the correct setting, change the system to the proper setting.
Also, keeping the squelch setting to a minimum (best I can explain there is about "half" or at the 12 o'clock position).
It has been said in other threads that anything that the radio "detects" as breaking squelch will be looked at by the radio as a possible NXDN call. Open squelch or noisy environments will then likely cause issues. I suspect that there could potentially be issues (but am not certain) if the system is very busy and/or has many frequencies and you're trying to monitor a specific talkgroup (and/or hear a response).
Some other settings can potentially stop you from receiving - I believe one being the RAN value. If it works the same in the radio as a DMR color code, then it becomes another detail that the radio must detect - other wise you hear nothing. If you don't need to set it, don't.
Delay settings are another thing to play with. If you're having problems, try scanning ONLY the system/site closest to you (as mentioned previously) and experiment with the delay settings. I've found in some cases, the best option is to turn the delay OFF (but only if you're playing with a single system/site).
I'm not sure what to make of "dropouts" of active voice -- I've seen some limited amount of that. There could be a variety of reasons this happens but in my case, watching DSD+, it looks like occasionally I see some type of really strong single in the area that might be causing temporary interference. Of course, there are likely other reasons.
Last edited:
troymail
Silent Key
I'm just the opposite - everything I've seen is coming up as 4800 - the only indication I've ever seen of 9600 is is DSD+ but that's before or between it seeing a valid NXDN signal - which it then reports as 4800
What is your DSP version on the radio? With all the recent updates to everything this past week I would guess a few have forgotten to update the DSP that are having issues.
Back when Whistler released DMR capability, there were issues with trunking those systems as well. Someone on this list, I think it was "Ubbe", said he got good success with entering each DMR trunking frequency four times in succession (in a trunking configuration, not conventional). I have not tried this with NXDN, and I don't know if this would work with NXDN systems like it supposedly does with DMR systems.
AFAIK, Whistler has never acknowledged any issues with trunking either DMR or NXDN systems. If they haven't acknowledged any issues with DMR trunking, which has been out a lot longer, it seems unlikely that they will acknowledge any issues with NXDN trunking either. Maybe they are aware of issues, but are unable to fix them via a firmware update. Maybe they attribute the issues to things beyond their control. I'm just speculating here.
AFAIK, Whistler has never acknowledged any issues with trunking either DMR or NXDN systems. If they haven't acknowledged any issues with DMR trunking, which has been out a lot longer, it seems unlikely that they will acknowledge any issues with NXDN trunking either. Maybe they are aware of issues, but are unable to fix them via a firmware update. Maybe they attribute the issues to things beyond their control. I'm just speculating here.
troymail
Silent Key
I think it's too early to tell for NXDN but the more useful information we provide, the more likely they'll be able to address any concerns. I'm sure they are reading....at least Wendy is!
bg_nashville
Member
- Joined
- Dec 6, 2004
- Messages
- 269
Same experience on a 4800 system.
- Status
