New system for OCPD-ask questions here

[autopatch]

I have the scoop on just about everything you need to know about the new system (at least as it relates to the PD side)

What is it you want to know, and I'll answer it.

You think I'm kidding? Try me.

If I don't know I will find out.

I AM Santa Claus.


Ready......GO

 

[KK5FM]

OK... I'll bite... will the "outer ring" analog sites simulcast PD traffic... in analog?

 

[dstew67]

OK... I'll bite... will the "outer ring" analog sites simulcast PD traffic... in analog?

Excellent question, KK5FM! autopatch?

 

[autopatch]

OK... I'll bite... will the "outer ring" analog sites simulcast PD traffic... in analog?

Excellent question. As of a few months ago the answer was "yet to be determined" as they were afraid all of the excess analog traffic on the 'outer ring' as you call it would tie up available channels inside the ring. I was told it could be setup to allow the simulcasting to be turned on 'automatically' if determined there was a handheld out in the boondocks that locked onto that 'outer ring' tower's control channel. As soon as the radio/handheld registered on another 'inner ring' tower the simulcast function would cease. I will talk to my source(es) and find out for sure.

My guess is no. I have been told there are a total of 18 different frequencies available (including the control channel) for the system. This is to be shared by all departments (fire, pd, public works, animal control, etc) so I doubt they are going to introduce anything into the system that would require more bandwidth being used unnecessarily.

As is stands right now, the "direct call" function of the system will only be available to supervisors or higher. Sergeants or lower MAY NOT use the direct call function to call other units. I was told this was to minimize bandwidth issues that may arise from too many officers using the system (this is bogus, though in my opinion)

If anyone is interested, I can post the official list of talkgroups that will be setup on the system. In addition, I should be able to clarify what those talkgroups will be used for.

 

[okcetech]

OK... I'll bite... will the "outer ring" analog sites simulcast PD traffic... in analog?

So is the outer ring analog?

 

[dstew67]

If anyone is interested, I can post the official list of talkgroups that will be setup on the system. In addition, I should be able to clarify what those talkgroups will be used for.

Sure, we're interested.

 

[KK5FM]

OK, that makes sense. However, just to clarify, and not trying to be argumentative, but as I understand it, the "outer ring" analog sites will only carry non-ps traffic on a daily basis. Water department, zoo, city inspectors, etc. It seems like they would, by themselves, have a hard time loading down a system with 13 talk channels. I don't know if the system would be smart enough, but what if: The analog sites simulcasted PD-FD traffic in analog, UNLESS the system got loaded down, and then it would prioritize "legitimate users" of analog like the water department- UNLESS there was an actual PD or FD unit on that analog site, which would then bump up the priority.

Food for thought.

 

[dstew67]

Let's ask the question this way:

Let's say that for some reason a user is hitting one of the "outer ring" towers, but is on PD dispatch talkgroup. From what we know, the outer ring is analog. So, the talkgroup will be repeated in analog while that radio is still registered on one of the outer ring towers, right?

From what I've been told, the outer ring is not going to be ProVoice. If this is true, the above is correct. However, it doesn't make sense to me that the outer ring would not be ProVoice-capable, unless the cost of a ProVoice-capable repeater is a whole lot more than a non-ProVoice repeater. This is the only way it makes sense to me.

I dunno, someone step up and correct me...mam1081?

 

[mam1081]

OCPD EDACS - my views

Well, I would imagine if there is a PD/FD or other PV (ProVoice) radio on the "outer ring" as its being called, it will be in PV also. When programming a talkgroup, you have to specify analog, encrypted (which key), or digital. This setting stays with that talkgroup any time it is selected on the radio. Not to say that the programmers and lazy, but the easiest way to program the TGIDs is to make one set (list with all the settings) of TGIDs. You can reference that set of TGIDs for different systems (so all the settings will be the same on multiple systems). The system setting tells the type of digital (AEGIS (old digital) or PV), and the options for analog/PV/Encrypted I-calls and phone patches are in the system set-up. The LID (radio ID)



This boils down to my opinion (or guess, which ever you prefer to call it): If a PD/FD unit is on the outer ring (site 2), it will be in the same modulation as on the inner ring (site 1). I do not think these need to be named the outer and inner rings, because they are simulcast sites around the city - one is not necessarily "outer" in a geographical respect (I don’t think so anyhow – go look up the license and then plot the site locations on a map). The radios automatically search for a site if they do not receive a control channel signal from site 1 (probably their default site). I don’t know if the city services radios are set up to default to site 2 – but that would be the way that everyone thinks is going on. I think all talkgroups are currently simulcasted on both sites. I lived in a city that used about 150 talkgroups. I found about 4000 radios with trunker. They had a single site (actually two sites, simulcast) with 20 frequencies. They did not seem to have too many problems with channel access.

 

[dstew67]

So what you're saying is what makes the most sense to me, and that is the it is simply the talkgroup that selects whether the transmission will be in ProVoice or analog (or exncrypted), and it has nothing to do with the site that the radio is talking to.

 

[crayon]

I AM Santa Claus.

sweet.

How is data traffic getting to the Wi-fi equipment on light poles?

If anyone is interested, I can post the official list of talkgroups that will be setup on the system. In addition, I should be able to clarify what those talkgroups will be used for.

Submit the list to the RRDB and either myself or fast2 will parse it.

Thanks!

 

[freqscout]

the light poles are relay stations not stand alone servers

 

[freqscout]

The lightpole data units are Tropos 5210's.
http://www.tropos.com/products/metromesh_routers.html

 

[mule_tail]

mam1081,

You've just about got it right. The facts... Yes, there are 2 overlapping simulcast systems. The entire system is digital. Analog is determined by user equipment and corresponding talkgroup definition. Both systems have one co-located common site in additon to other distributed sites. One system has 18 channels, the other has 14. The 18 channel system is default for Police and Fire, with sites clustered so as to saturate the highly populated core. The 14 channel system is default for others. Most police and fire usage will stay on core system unless RF signal drops below threshold, at which point it will roam to "wide area" system. Transmissions will not be simulcast on both systems unless same talkgroup users are roamed to both systems.

By the way, 2nd 800 antenna on black and whites is for 2nd EDACS radio dedicated to data. EDACS will provide lower speed umbrella backup for wifi.

 

[mam1081]

mam1081,

By the way, 2nd 800 antenna on black and whites is for 2nd EDACS radio dedicated to data. EDACS will provide lower speed umbrella backup for wifi.

Something tells me this is a bad idea...

 

[mule_tail]

Depends on wifi coverage and application requirement. Time will tell.

 

[mam1081]

I was more thinking of the data bandwidth. If it's set up as a back-up for the WiFi system, and some officer or FD unit is downloading data at the 9600 baud, how is anyone else supposed to get a channel grant? Unless you're just sending very small text messages or status messages, I think using the EDACS control channel as a backup data system is a bad idea. If you're just talking about using the radio to aquire a channel, and do all your data on a channel other than the control channel, then that might work.

 

[mule_tail]

The control channel will not be used to transport the data. The system includes a data gateway (EDG) that acts as a network router. One or more actual channels can be designated as data capable. The mobile client will contain Padcom's TotalRoam middleware and will act as the client's IP. It will determine (based on signal levels) whether to use EDACS or the WIFI as the transport. It will also be used to restrict application availability based upon which transport is used.

 

[mam1081]

What data speed is that going to run at? I don't know what speed ProVoice is, but I would imagine it's around 9600 bps. I've heard of 19200 bps over digital voice channels, and I think I read somewhere that you can get up to 96000 bps on a APCO-25 signal with some new data mode. I know P25 has a low speed (around 88 bps) data sub-channel that is always going. This is not used for anything that I know of yet. Does ProVoice do this also? Can one "read" a ESN from this data? Is ProVoice modeled at all like P25 (other than being AMBE vs IMBE)?

 

[crayon]

the light poles are relay stations not stand alone servers

Right. I think I remember someone mentioned that they relayed traffic ..

Thanks for posting that link to the OEM's website. This tidbit kinda sorta answered my question:

create a self-organizing and self-healing wireless mesh, and intelligently select the most optimum data path to the wired network.

I guess my real question is if system has several feed points to the mesh or just one?

What type of throughtput can a user expect? Can they surf the web? How much latency does the network have esp. out on the fringes?

ps .. mam1081 - check your RR IM.