"Dwell time" NXDN vs P25

[ofd8001]

I'm very new to NXDN trunking, but okay with P25 trunking. I just programmed my first NXDN 9600 system (https://www.radioreference.com/apps/db/?sid=7031) (using ARC software and downloaded the system) and something caught my eye.

When I'm scanning the P25 system (https://www.radioreference.com/apps/db/?sid=4303) I see a signal strength indicator 5 bars most of the time and it will go away for a brief few moments. (I understand that the scanner is doing some "brief internal housekeeping".)

However on the NXDN, I'm seeing no signal strength indication most of the time and 5 bars of signal strength for a brief few moments. In other words, the NXDN is opposite of the P25.

Granted I suppose I should wait until during the daytime when the system will be more "chatty", but this struck my curiosity.

 

[hiegtx]

I'm very new to NXDN trunking, but okay with P25 trunking. I just programmed my first NXDN 9600 system (https://www.radioreference.com/apps/db/?sid=7031) (using ARC software and downloaded the system) and something caught my eye.

When I'm scanning the P25 system (https://www.radioreference.com/apps/db/?sid=4303) I see a signal strength indicator 5 bars most of the time and it will go away for a brief few moments. (I understand that the scanner is doing some "brief internal housekeeping".)

However on the NXDN, I'm seeing no signal strength indication most of the time and 5 bars of signal strength for a brief few moments. In other words, the NXDN is opposite of the P25.

Granted I suppose I should wait until during the daytime when the system will be more "chatty", but this struck my curiosity.

I found that, on my TRX-1, the two public safety NXDN systems I monitor missed less calls if I increased the 'dwell' time a little. Dwell on the TRX-1 is roughly equivalent to the System Hold time on Uniden scanners. I have not tried this on my x36HP scanners (set a hold time), but may if it appears to be missing some transmissions.

 

[troymail]

Increasing the Dwell/hold on a control channel on ANY system type should always improve performance on that system/site. However, as you would expect, any increased delays (dwell, post voice delay, etc.) will adversely impact scanning everything/anything else - at least to some degree. It's a trade-off.

I continue to have the issue that my TRX is stopping on NXDN activity (conventional N96 and a single frequency trunked N48 system) that the 436 just doesn't seem to see at all most times.

 

[ofd8001]

Thanks. . .

Something must be programmed incorrectly with this NXDN system as my log file was empty this morning. I listened to them before they changed systems and were pretty talkative during bus run times.

 

[hiegtx]

Increasing the Dwell/hold on a control channel on ANY system type should always improve performance on that system/site. However, as you would expect, any increased delays (dwell, post voice delay, etc.) will adversely impact scanning everything/anything else - at least to some degree. It's a trade-off.

I continue to have the issue that my TRX is stopping on NXDN activity (conventional N96 and a single frequency trunked N48 system) that the 436 just doesn't seem to see at all most times.

interesting. I'm not seeing this pattern on NXDN. The two systems I monitor are fairly close to me, with a strong signal, which could be part of the dirrent result.

However, on DMR, I am seeing my 536HP stop on a specific DMR system's activity, while often the TRX-1 drives right bye without so much as a blink. Both scanners feed off the same antenna through a multicoupler.

 

[troymail]

interesting. I'm not seeing this pattern on NXDN. The two systems I monitor are fairly close to me, with a strong signal, which could be part of the dirrent result.

However, on DMR, I am seeing my 536HP stop on a specific DMR system's activity, while often the TRX-1 drives right bye without so much as a blink. Both scanners feed off the same antenna through a multicoupler.

Yup... this is why we can't always assume that what one user sees in their area can be assumed to be a 'global' thing.

 

[UPMan]

A P25 control channel is a continuous transmission. NXDN Idle channel has control bursts.

See NXDN Idle Channel pic

 

[ofd8001]

That clears up one question, but now I have another. . .

This is a school radio system primarily for bus related communications. I didn't log any transmissions from noon today until 8:30 though I should have received several.

So I programmed this system as a conventional, using all the listed frequencies. It stopped on one which showed a RAN value, so it must have received "something". However, there was no audio sound of any type, including those on the site linked above.

FWIW, the frequency it did stop on was not one listed as a control channel, though I know changes can occur and the database being different than real life.

 

[UPMan]

I would suspect that most or all of their comms go out as "Group Call" which uses TGID 0. First rev did not support TGID 0 -- looks like an invalid TGID. We'll have an update that adds support.

 

[kh6sz]

I would suspect that most or all of their comms go out as "Group Call" which uses TGID 0. First rev did not support TGID 0 -- looks like an invalid TGID. We'll have an update that adds support.

So when a new update comes, will we be able to add TGID 0 and it will pick up all talkgroups it finds, like what the wildcard option on the whistlers do? Isn't that the same thing as what ID Search does?

Edit: Will it do anything now if I add a TGID 0 to systems, or is it showing an error or invalid TG?

 

[budevans]

So when a new update comes, will we be able to add TGID 0 and it will pick up all talkgroups it finds, like what the wildcard option on the whistlers do? Isn't that the same thing as what ID Search does?

Edit: Will it do anything now if I add a TGID 0 to systems, or is it showing an error or invalid TG?

Per UPMan's post, the current firmware does not support TG 0. So adding it manually won't work.

Regarding ID Search and Wildcard, they do the same thing.

 

[kh6sz]

Per UPMan's post, the current firmware does not support TG 0. So adding it manually won't work.

Regarding ID Search and Wildcard, they do the same thing.

I understand that it will not work right now, I was just wondering if it would error or do nothing.

AFTER the update, I was wondering if the TGID 0 will pick up all talkgroups even if they are not programmed in, and what would be the difference in that vs. the ID Search option. It would be nice to have TGID 0 do all talkgroups. The problem with ID Search is that it picks up ALL Talkgroups AND Private Calls and it would be nice to have an option to allow all talkgroups, but NOT all private calls.

 

[UPMan]

TGID will be treated as its own TGID. Not a substitute for wild card (ID Search).