New Jersey Interoperability Communication System (NJICS)

[GTR8000]

Our policy regarding encrypted talkgroups is clearly spelled out in the Admin Handbook.

Encrypted Talkgroups​

In general, encrypted talkgroups will not be entered in the database, unless either of two specific conditions are met.

• If the agency which "owns" an encrypted talkgroup can be confirmed to a reasonable degree of certainty, it may be entered in the talkgroup category for that agency. Ways to confirm ownership include monitoring unencrypted talkgroups for references to an encrypted talkgroup which then becomes active (ie "Switch to Tac 2" and the same units appear on the encrypted talkgroup), or regular use of the talkgroup by an overwhelming preponderance of radio IDs which have been confirmed as a specific agency.
• Provided there are no clear (unencrypted) talkgroups on the system, encrypted talkgroups may be entered to indicate that there is activity on the system.

The NJSP secure talkgroups meet the requirement of condition #1 based upon the observation of the subscriber IDs being from the NJSP block(s), and therefore may be listed in the database.

By all rights these should be listed in the existing NJSP Statewide Operations category, however given that there are a ridiculous amount of them, I will likely create a new category for them so that end users can simply ignore the entire category if they wish.

As a reminder (since we're skirting the edges a bit here), we do not modify the database in order to cater to any particular manufacturers or devices, nor do we modify the database in order to provide workarounds for bugs/glitches in software or hardware.

 

[RadioDitch]

Our policy regarding encrypted talkgroups is clearly spelled out in the Admin Handbook.

The NJSP secure talkgroups meet the requirement of condition #1 based upon the observation of the subscriber IDs being from the NJSP block(s), and therefore may be listed in the database.

I can certify that thus far, all of the 2600-series secure TG's that I have observed have all been in the NJSP range. More specifically, in what is known/believed to be the NJSP portable range. Hopefully by next week I'll have the mega-Unitrunker computer up and running up on the hill in Boonton, collecting full-time data from multiple sites to help confirm the current users of others.

Likely I'll post a weekly log from each site anybody can download and sift through.

 

[GTR8000]

And btw, if someone does decide to submit them, format them so that I can import them directly. If you copy/paste out of a spreadsheet it should paste the tab character between fields.

1234 TE NJSP Secure 1234 NJSP Secure 1234 Law Tac
1235 TE NJSP Secure 1235 NJSP Secure 1235 Law Tac

 

[rr60]

The above posts are helpful, (rules) triggered fuzzy memory. I will submit a block for consideration. This will be done In this thread first for group review by power users like @nosoup4u and many others in next couple of days, unless they go first. Open source please.

 

[RadioDitch]

Just got a message that the NJTransit Brotherhood of Locomotive Engineers & Trainmen had NJTransit walk out of the room on them without a deal around 10pm. A strike is officially in effect. Good possibility there might be some finds or abnormal traffic on the ICS tomorrow as a result for managing the alternative bussing and traffic.

 

[rr60]

So then, many of these TG’s have been mentioned for some time by several members. Most of these members are power users.

A few of us are in direct contact by email and on first and last name basis. We freely share information from time to time. There are some very well read people that keep a low profile here on NJRR. Perhaps to avoid the horses. TG‘s in the 2615-2651 are NJSP Encrypted in many people’s opinion including mine.

Without disclosing sources and methods, if you have been at this long enough certain patterns arise and enough bread crumbs are left here and there. Of course various units and consoles also contribute, going here and there.

There was a major shuffle with the last 18 months for some units on Analog but their hard work and dedication can still be seen but not heard 24/7/265.

Mentioned earlier the advantage of having in DB is significant when doing a discovery search my SDS skips right over rather nicely.

So lets kick this around here for a bit, I will make the DB submission for @GRT8000
to decide what to do if anything after this has been vetted. 27,28,29 likely CIB.

2615
2617
2619
2621
2623
2624
2625
2626
2627
2628
2629
2630
2631
2632
2633
2634
2635
2636
2637
2638
2639
2640
2641
2642
2643
2644
2645
2646
2647
2648
2649
2650
2651
2652
2653
2654
2655
2656
2657
2658
2659
2660
2661
2662
2663
2664
2665
2666
2667
2668
2669
2670
2671
2672
2673
2674
2675
2676
2677
2678
2679
2680
2681

 

[RadioDitch]

Since I absent mindedly put it in the wrong thread last night at 2am...

I've been watching NJSP Secure 2627 for several weeks. It's active daily, basically around the clock, but particularly at night. I'm seeing it on the West Orange Simulcast mostly. It has made some appearances on the Union County Simulcast though. Based on the amount of activity, the RID's being mostly NJSP portables with several NJSP mobiles, and in combination with what I was previously told, I suspect this is probably a secure replacement for B2-09. It's likely some form of newly authorized version of the previously disbanded Metro North Task Force, or something similar.

Educated speculation, but speculation nonetheless.

 

[RadioDitch]

TG8081 ENC with 4000xxx REMU/Cache/Testing radios. Probably ICS Testing 2.

 

[RadioDitch]

Just FWIW, I'm noticing a bunch of 438xx DOT radios being denied access today.

 

[RadioDitch]

I noticed the ranges for the West Orange Simulcast and Union County Simulcast no longer reflect their actual effective range. I know there is a method admins use to calculate the range of sites for publication in the database. However, Union County for example is showing 9mi when it's in actual practice and observation at least 20mi on a handheld with a rubber duck. West Orange in the database is at 11mi, when I can easily receive it with an RSSI of -52 on an SDR and a rubber duck in a basement in Boonton, and still solid on base at Picatinny.

Would a simple submission be adequate to correct this? Or is there additional information needed? Was there a policy change?

 

[rr60]

SWAG method here. Location based scanning via GPS and a scanner once set up can be a wonderful thing for those unable to think manually selecting sites.

The challenge is the vast performance differences between various setups.

Fuzzy memory the radius is conservative to facilitate scanner setups such as a SDS inside a car with no external antenna.

 

[richee2000]

In the last couple of months there has been a significant decrease in signal strength from the Morris county site at my East Hanover location. It is now barely readable, prior to this it was full signal strength. West orange site remains full signal strength at this location.

 

[GTR8000]

The range values in the RRDB are purposely conservative, as we try to base them on the intended coverage area of the site/cell, not necessarily how far the signal propagates beyond that intended coverage area. In reality the signal will almost certainly propagate further than those ranges have been set, as radio signals don't conform to perfect circles drawn on a map based on the best guesstimate by an RR dbadmin.

If the range is legitimately wrong and/or dreadfully over/under reported, then by all means make a submission to have it fixed. However we're not going to go down the "but I can receive it from 50 miles away with my XYZ setup!" rabbit hole. If the real life range winds up being greater than the intended coverage area, that's good for those monitoring, but for large multi-site systems like NJICS there's a reason why they have multiple sites/cells with overlapping coverage.

In this specific case I've increased the range of those two sites by 1 mile each, which appears to still fall within the intended coverage area of each. I think we're good unless new subsites are built in the future.

 

[RadioDitch]

If the real life range winds up being greater than the intended coverage area, that's good for those monitoring, but for large multi-site systems like NJICS there's a reason why they have multiple sites/cells with overlapping coverage.

I'll make a submission, because in the instance of these two, the range is significantly lean for even the most comprise setup potentially in service by a mobile user.

Not a rant, by my logic though... The average user, unlike us active in this thread, probably is not aware of the nuances of RF propagation and engineering. They also probably aren't active in the forums to inquire about it. They can easily take that number as gospel. It also shortchanges many more average enthusiasts who rely on GPS based scanning or Uniden location based programming from hearing traffic that is usually contained to a single site, but which is actually in their range of reception in practical application. And for those who are more advanced users, it definitely complicates the purpose of having the RRDB being a single resource by requiring them to keep additional notes of their own for each site they may travel past. Particularly if they are only visiting or transiting the area.

 

[GTR8000]

Keep in mind that unless Uniden users have purposely set their range to 0, there is always overlap which will cause the scanner to start to scan outside of the range set in the RRDB. Generally speaking, only power users are affected by these nuances, not the general population.

I'll stress again that the ranges are set based on intended coverage area, not best case scenarios. Yes there are other factors such as "X agency only operates on the Y simulcast", but again there are other factors that determine that having nothing to do with the RRDB range. This is all a deep rabbit hole, as evidenced many times over many years here by people asking the simple question "Why can't I hear X on Y site???"

I'm inclined to leave the range values as-is. If you really want to get into the mud, send me an email, but I don't believe this thread is the appropriate venue to continue the debate.

 

[wa8pyr]

Not a rant, by my logic though... The average user, unlike us active in this thread, probably is not aware of the nuances of RF propagation and engineering. They also probably aren't active in the forums to inquire about it. They can easily take that number as gospel. It also shortchanges many more average enthusiasts who rely on GPS based scanning or Uniden location based programming from hearing traffic that is usually contained to a single site, but which is actually in their range of reception in practical application. And for those who are more advanced users, it definitely complicates the purpose of having the RRDB being a single resource by requiring them to keep additional notes of their own for each site they may travel past. Particularly if they are only visiting or transiting the area.

Our administrators select ranges based on the intended coverage area of a site, as well as typical conditions which may be experienced by the average scanner user.

To go much farther out in range settings could complicate matters for the majority of our users, who may experience greater difficulty receiving something they think they should be able to receive based solely on the range settings.

As GTR8000 noted, we make entries based on intended coverage area rather than best-case scenario. I do understand that it's an inconvenience to advanced users to have to fiddle with range settings, but we have to keep our work as general as possible to ensure that it works as well as possible for everybody.

Tom WA8PYR
Lead Database Administrator

 

[RadioDitch]

Obviously there's a near zero chance of ever identifying it, but again I need to note NJSP 2627 is seeing extremely heavy use daily around the clock this weekend, and this past week. Numerous mobiles, portables, and two console ID's noted. All of which are mostly or entirely associated in history with Troop B. It's most active on the Union County site. It definitely appears to be a more significant talkgroup than just an arbitrary investigations channel.

Just a wild shot in the dark, but this might be the talkgroup for the NJSP Port Security Section.

 

[richee2000]

Obviously there's a near zero chance of ever identifying it, but again I need to note NJSP 2627 is seeing extremely heavy use daily around the clock this weekend, and this past week. Numerous mobiles, portables, and two console ID's noted. All of which are mostly or entirely associated in history with Troop B. It's most active on the Union County site. It definitely appears to be a more significant talkgroup than just an arbitrary investigations channel.

Just a wild shot in the dark, but this might be the talkgroup for the NJSP Port Security Section.

My guess would be the Metro stolen auto task force.

 

[RadioDitch]

My guess would be the Metro stolen auto task force.

Fair guess. The reason though I suspect it to be Port Security Section is the intensity and consistency of activity, combined with what I was told by a contact that it was "not regular patrol". I know that person well enough to know if it was investigative, he would likely have said "it's not patrol" and left the regular part out.

I think the Motor Vehicle Crimes North Unit is likely 2623 since it's more active at night than day from what I've seen.

Again, near zero probability of ever confirming, but just sharing thoughts.

 

[richee2000]

Fair guess. The reason though I suspect it to be Port Security Section is the intensity and consistency of activity, combined with what I was told by a contact that it was "not regular patrol". I know that person well enough to know if it was investigative, he would likely have said "it's not patrol" and left the regular part out.

I think the MSATF is likely 2623 since it's more active at night than day from what I've seen.

Again, near zero probability of ever confirming, but just sharing thoughts.

Thanks for the info.....I am sure all of the suspected Task Forces are within this E block, of course