Results 1 to 16 of 16

Thread: Crash Course on P25, Anyone? Guidance Wanted Please.

  1. #1
    Join Date
    Jan 26, 2013
    Location
    Somewhere extremely cold and white.
    Posts
    89
    Thanks
    61
    Thanked 50 Times in 26 Posts

    Default Crash Course on P25, Anyone? Guidance Wanted Please.

    I might be faced with having to generate purchasing documents to execute a P25 trunking system buy in the next while. I'm thinking of hiring some expertise, but not before I _at least_ get my bearings. So I ask, can anyone advise me on the best way to get familiar with the technology to the point where I can make reasonably informed decisions, or at least hire a consultant or contractor intelligently to help with the task?

    I've been looking through websites and manufacturer documentation like crazy and I'm picking up fast. Motorola seems to be dominant, but faces competition on the infrastructure side from Cassidian, Daniels, Harris, and some others. Daniels has some solid literature on the fundamentals of P25 system trunking, and it was useful. Motorola seems to keep its cards pretty close to its chest, and makes sure that its language is all flavoured strongly with its Brand. Haven't really explored the Harris web lit yet, but that's next week's job. And so on.

    If anyone can jump in and say something like "hey, you should really read a book called XYZ by this guy called ABC" that would be great. Or something along the lines of "there's a vendor neutral course run by such-and-such institute of technology in Kansas City you should check out" that would be excellent too.

    I plan to get out and meet with some system owners and managers, and chat with their techs, but until I do, advice from those of you who have worked this area - well, I'd be very grateful and I'm sure that there would be others in this forum that would benefit from it too.

    Docs, links, references, contacts, etc - all would be really welcome!

    Thanks in advance, folks.

    Jim


  2. #2
    Astro Spectra's Avatar
    Astro Spectra is offline T S - Moderator
    CS Forums $upporter
    Join Date
    Nov 22, 2012
    Posts
    907
    Thanks
    348
    Thanked 616 Times in 304 Posts
    Country: Great Britain

    Default

    I'd start here:

    http://www.danelec.com/library/engli...ning_guide.asp

    It can get a bit technical but it's a solid reference. Use the PDF download rather than the flip thingy.

  3. #3
    Join Date
    Jan 26, 2013
    Location
    Somewhere extremely cold and white.
    Posts
    89
    Thanks
    61
    Thanked 50 Times in 26 Posts

    Default

    Solid! Thanks Astro Spectra! I think I've seen this before but I'm ploughing my way through it again and it appears to be worth the effort.

    (I was about to recommend a link to an executive summary type of page at a vendor's site, but as I read the PDF you posted, I note that the vendor's site content is merely a word-for-word rip-off from this manual. I'm ok with quoting text, but at least credit the source.)

    I note it mentions the IMBE vocoder but many vendor brochures speak about an AMBE+2 vocoder. Are they compatible? Do most vendors' equipment have the ability to switch between the two or is this a non-issue?

    Thanks again for the help!

    I think I'm going to use this thread to warehouse references to learning resources as I crawl out of my dark cave of ignorance. Hope no one minds, or if there's a thread already established for this, please point the way.

    Jim

  4. #4
    ohiodesperado No Longer Registered

    Default

    Ok, this might be a bit long winded and YES I work for an MSS but I am going to try to be diplomatic and not simply scream that you must buy Motorola or the world will end.

    The first thing that you need to understand is that the P-25 standard is a conventional standard and NOT a system standard. Again being mostly educated on Moto gear, I can tell you that a Moto trunked system works with Moto gear only. The way that other radio types come into the current systems id via a set of conventional repeaters that are P-25 but not trunked. Basically they are conventional repeaters with CAI (common Air Interface) digital modulation. The frequencies are band similar to the trunked system but are not assigned as trunking channels. This is the way that a non-Motorola radio that is P-25 compliant can talk on the Motorola system. It's going to be a safe assumption that any system is going to only work with the manufacturers radios only with all functionality. The same will hold true for many console systems. So bear that in mind. If a manufacture claims its complaint, investigate the claim. See it working with full system capability with your own eyes and know that it has full system functionality.

    The first consideration I would have is what are the surrounding agencies using for trunked radio communications? If they have Moto systems in place, it's only logical to follow suite for the same of simple interoperability. You would exchange ID's for radios, put their systems in your radios and your system in their radios and when a mutual aid call was happening one the mutual aid agency going into the requesting agencies area would simply change channels. Pretty straight forward. It's a better solution than needing to have a big stack of control stations on each others systems so that the other agencies can be patched together on a console.

    The next thing to consider is the served agencies. By this I mean if you are going to put up a wiz bang multimillion dollar system that the subscribers cost thousands of dollars and you are serving a bunch of small volunteer fire departments and police agencies that are still patrolling in Chevy Caprices with 200000 miles on them because they can't afford to buy cruisers, or the fire departments have a total budget of less than $100K a year, it's going to be difficult. They are not going to be able to buy radios that cost as much as the car they are mounted in. System upgrades are and inevitable future concern for all public safety agencies. Of course these are political issues but are every bit as important to address as the fine technical aspects of a system.

    All that being said. Technical considerations of a system, while complex, pail in comparison to the political issue of spending millions of dollars, rest assured, it will REALLY cost every penny of several million dollars between the sites and the subscribers no matter the system that you go with. Setting cost aside, we go back to the first thing I mentioned. Inerop. New systems are great, but neighboring agencies are not going to want to deal with two radios. This is doubly true when it comes to buying expensive radios to just do mutual aid. Next thing to consider is your dispatching center and it's equipment. Is the equipment current or is it old? will it directly interface into the new system? If it will interface, what functionality will be lost without replacing it. Simple things need to be considered like alerting of fire houses. In the days of conventional analog, we just used Quick Call II or a variant. Trunking subscribers will not support fire tones at all, so a different method needs to be considered. There are a number of methods, but one will need to be chosen, based on need, or simply on price. I am finding as I speed of this, there is no real way to fully put the money aspect of this aside, but I am trying.
    Other considerations are data links to vehicle MDT's if needed. If you are investing in a system, it should be purchased to address as many different requirements as possible. MDT's are one of those needs. Initial cost is greater than Sprint cards, but the long term is better.

    Another very important consideration is the installing and supporting vendor. The people I work with are all factory trained and many have years of experience. We have seen what happens when that's not the case a number of times. We have lost contracts to other vendors because of not being low bid only to have the same customer throw the new vendor off the site and pay us time and materials to clean up a mess created by an untrained and inexperienced field tech. This does happen, and when you put this out to bid, you will get responses from many states because of the money involved. You may get a new wiz bang system that has some issue in 6 months that you will need to fly a tech in from 3 states away because no one in your area has any knowledge or experience with the new system and the folks that installed it are 5 states away and tell you it worked when they flew home and it's not their problem.
    The next thing to look at is overall scalability, life cycle and life span of the system being considered. Some time's it's better to pay more and get something that will still be running in 15 years. Federal grant money is only for replacement not for repair. It also dries up depending on who is in DC running the show. A major failure with big costs, or parts that aren't available with a down turn in 4 or 8 years with grant money and your served agencies will be running to WalMart buying FRS radios to communicate with because there is no money or no availability of parts for your system to get it working again if you make a bad choice here.

    One thing I will say is that I am new to professional commercial radio, but have 15 plus years in IT as everything from a computer hardware monkey to a network and security administrator, and I can say one thing is a constant with consultants. They simply know what people to call to get a system designed. Those calls can be make from your office and the vendors who all have on staff engineers will all be happy to engineer a system for you based on the requirements that you give them and the functionality that you want. What's better is that they all do it for free for their specific product line. I have in the past had meetings with multiple vendors, taken theri designs and then pulled the specifics from them and ask the other vendors if they could provide X Y or Z in their system and not specifically said Dell said they could do this, can you. But instead a discussion of " In my own research, I found that this seems to be possible. Can you provide this functionality?" Sales people hate it, but they all know it happens and it's part of what moves them to provide you with what you want and need as opposed to what's giving them the best profit. Understanding the deep intricacies of a system is for the technician and field service guys. Not the end user. Consider a computer, or even a car. Do you know how the data gets from your hard drive to your screen, or how your car knows when to shift as you accelerate? You may know these answers but are you a better driver or computer user because of the knowledge?

    Last thing to consider is who will be administering the system and who is the backup administrator. You will need someone that has knowledge of the system as it's being installed. Even if it's under a full support contract and warranty once it's not, you will need to pay a vendor every time you add a radio to the system. It's not overly cost effective to go this route. Know who will be doing this. Get someone that has both RF and computer knowledge at a support level lined up and expect to pay them well. Ok

  5. #5
    Join Date
    Dec 21, 2011
    Posts
    4,743
    Thanks
    4,470
    Thanked 7,733 Times in 2,153 Posts
    Country: Canada

    Default

    Quote Originally Posted by ohiodesperado View Post
    The first thing that you need to understand is that the P-25 standard is a conventional standard and NOT a system standard.
    APCO Project 25 has many standards. An APCO Project 25 compliant trunking standard is clearly defined in the TIA documents.

    Motorola's own offering -- called ASTRO25 Trunking, is based on the APCO Project 25 Trunking standard, and includes some (optional) Motorola proprietary features/options/hardware/etc. It's not a "bad" thing Motorola has offered enhanced features/options, but a majority of the "Motorola Proprietary" options are not offered or supported in other vendors' products.

    I have asked one of the other moderators to post more information on the APCO Project 25 Trunking TIA standards, as I can't find anything online.

  6. #6
    Join Date
    Jun 10, 2012
    Posts
    224
    Thanks
    30
    Thanked 225 Times in 78 Posts

    Default

    Not being in the cell/wireless world anymore, I don't have access to TIA docs the way I used to, but MOT has a reasonably decent PDF explaining the standards:

    http://www.motorola.com/web/Business...er%20final.pdf

    In short, there's a whole raft of standards involved. CAI is just one of them.

    Also check the Wikipedia entry - http://en.wikipedia.org/wiki/TIA-102 - as it has links to some decent PDFs as well.

    Edited to add:

    Maybe we should take up a collection?

    Screen Shot 2013-01-26 at 3.32.17 PM.png
    Last edited by noaffiliatefan; Jan 26, 2013 at 10:34 PM. Reason: Added screenshot of TIA-102 pricing

  7. #7
    ohiodesperado No Longer Registered

    Default

    Well I am going to defer to yall on that. Again I am Moto trained and they don't talk much about anything that doesn't say Moto on it.
    I was referring to the Astro 7X systems the older stuff did have other subscribers that worked on it. But never as well as the Moto stuff did.

  8. #8
    cyrus's Avatar
    cyrus is online now Trailer Park Superintendent
    Join Date
    Jan 06, 2012
    Location
    Moonbase Alpha
    Posts
    873
    Thanks
    303
    Thanked 405 Times in 182 Posts
    Country: Japan

    Default Crash Course on P25, Anyone? Guidance Wanted Please.

    Quote Originally Posted by ohiodesperado View Post
    The first consideration I would have is what are the surrounding agencies using for trunked radio communications? If they have Moto systems in place, it's only logical to follow suite for the same of simple interoperability. You would exchange ID's for radios, put their systems in your radios and your system in their radios and when a mutual aid call was happening one the mutual aid agency going into the requesting agencies area would simply change channels. Pretty straight forward. It's a better solution than needing to have a big stack of control stations on each others systems so that the other agencies can be patched together on a console.
    That's not the case with a P25 trunking system (I see Mars has already corrected you on what P25 systems exist). One large agency near me operates EADS infrastructure with a variety of user gear. Once a test site was built, they invited vendors to submit quotes. They narrowed it down to a few vendors who met the requirements and than had the vendors submit user gear for compliance testing. They ended up going with two different vendors for their user gear.

    As long as the system doesn't use any proprietary features, you should be able to use any user gear. You do not have to select the same vendor's gear.
    Cyrus

    Bubbles: I'd like to see that Red Blue Green c***sucker put one of those together, duct-tapin' it.

  9. #9
    Join Date
    Apr 09, 2012
    Location
    Australia
    Posts
    929
    Thanks
    286
    Thanked 667 Times in 249 Posts
    Country: Australia

    Default

    All gear that is stamped as being P25 compliant will work on any vendors P25 system. This is a pre-requisite for approval and is the whole point of the P25 project itself.

    The standards documents define almost everything - Air interface, subscriber handset features, ISSI, Vocoder, encryption algorithms, to name just a few. In fact, the P25 specs define some very clear test cases for conformance testing to ensure that your gear works as defined per the standard.

    Here are some of the things that the TIA.102 documents do define and are standard across different vendors systems:-

    4.1 Common Air Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
    4.1.1 General CAI Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
    4.1.2 FDMA Air Interface—Phase 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
    4.1.3 TDMA Air Interface—Phase 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
    4.2 Inter-RF Subsystem Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
    4.3 Fixed Station Subsystem Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
    4.4 Console Subsystem Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
    4.5 Subscriber Mobile Data Peripheral Interface and Data Host Network Interface . . . . . . . . . . 22
    4.6 Network Management Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
    4.7 Telephone Interconnect Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
    5 Standards Suite for Project 25 Conventional and Trunked Systems . . . . . . . . . . . . . . . . . . . . . . 25
    5.1 Project 25 Conventional Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
    5.1.1 Legacy System Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
    5.1.2 FDMA Conventional Digital—Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
    5.1.3 Console Subsystem Interface for Conventional Systems. . . . . . . . . . . . . . . . . . . . 28
    5.2 Project 25 Trunking Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
    5.2.1 FDMA Trunked Digital—Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
    5.2.2 Two-Slot TDMA Trunked Digital—Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
    5.2.3 Console Subsystem Interface for Trunked Systems. . . . . . . . . . . . . . . . . . . . . . . . 34
    6 Standards Suite for Project 25 System Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
    6.1 Advanced Encryption Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
    6.2 Data Encryption Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
    6.3 Key Fill Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
    6.4 Over-the-Air Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
    7 Standards Suite for Project 25 Equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
    7.1 Analog FM Transceivers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
    7.2 Digital Project 25 Phase 1 Transceivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
    7.3 Digital Project 25 Phase 2 Transceivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
    7.4 Vocoder. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
    7.5 Mobile Radio Push-to-Talk and Audio Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
    7.6 Audio Tone Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

    (Ref - http://www.pscr.gov/outreach/p25dsr/...ads/P25dsr.pdf)

  10. #10
    Join Date
    Jan 26, 2013
    Location
    Somewhere extremely cold and white.
    Posts
    89
    Thanks
    61
    Thanked 50 Times in 26 Posts

    Default

    Wow! Seven thousand five hundred and forty-eight pages in the hard copy! I'll bet the shipping is as much again.

    If I'm going to spec a system, I'd better know what standards to quote and what to hold the vendor to. I can see this morphing into a pretty large undertaking.

    But I don't know if I have it in me to plough through 7548 pages of TIA standards. (I took a look at two or three of them at work a few months back. They're pretty dry.)

    I attended a briefing by a pair of gents from NIST (or a subordinate/affiliate agency which keeps up on standard compliance and such) and it was extremely interesting to find out that while the CAI is all sorted out and can be said to support interoperability, ISSI is still in the pipes. They stressed that while the ISSI standards are written, the agreements, or understandings, on how to test for standards compliance across the board are not finalized yet.

    Rather confusing to the newbie, but I get the impression that there is lower risk of facing a situation where you install infrastructure and finding out that only that vendor's mobiles and portables will work on it. I'm alright if the infrastructure vendor's equipment lets us have subscriber stuff which does some fancier stuff than just basic standard P25, but I'm not OK if that infrastructure will not allow another vendor's CAP mobiles and portables to operate to the full extent of the standard. It would be crazy to ask vendor A to support the value-adding gimicks of vendor B, but I should expect that vendor A's Phase 1 P25 digital trunking infrastructure will support all of vendor B's P25 features in their mobiles and portables.

    Are there cases where this is not true, in practice?

    Jim

  11. #11
    Join Date
    Jan 26, 2013
    Location
    Somewhere extremely cold and white.
    Posts
    89
    Thanks
    61
    Thanked 50 Times in 26 Posts

    Default

    Quote Originally Posted by ohiodesperado View Post
    Ok, this might be a bit long winded [...] Get someone that has both RF and computer knowledge at a support level lined up and expect to pay them well. Ok
    Ohiodesperado, I want you to know how grateful I am that you essentially sat down and wrote a 1400+ word essay in response to my appeal for guidance, with a helpful, not condescending, tone to it. Where I come from, that’s a symptom of someone who knows how to deliver solid teamwork. I want you to know how grateful I am for the time you’ve given on this to help me out.
    If I read it correctly, there are several important take-aways. I reiterate just a few:

    Plan for, specify and include a comprehensive test plan to ACTUALLY verify that the interoperability with different vendors’ kit in fact works as advertised. (Never done that. Will need to find someone who has and ask questions about the process.)

    Expect that the budget will need to be substantial. (I am braced for a large budget. Motorola’s rep briefed me - over a coffee and a napkin drawing, not an official quote by any stretch - that what I’m considering will cost between $600k and $1.25M for the central, or core, base station in the configuration being imagined. Forewarned is forearmed, my mom always says. A solid tendering process and a well drafted procurement spec might whittle that down some...)

    Get a jump on nailing down available frequencies in the regions we need to operate. Looking at the ASTRO 25 ordering guidelines, posted elsewhere on the forum, I notice that there seems to be an unchanging rule that if one has an RX frequency, then the corresponding TX frequency is sort of “hard coded” into the transceiver to be a specific and unalterable offset. That means that I’d better be certain that I can secure the frequencies I need in that particular pattern well before going out to tender.
    Consider consoles and their deployment/employment in the radio system and learn how they are interfaced into the infrastructure, what features they can support, etc. This is a good catch. I hadn’t really put much thought into the console end of the business, and that’s pretty short-sighted on my part. Time to roll up my sleeves, because you are right – the consoles will be a big deal to the end-using client agencies.

    Deeply analyze the radio landscape of the regions we are going to deploy P25 systems into. Well, this one’s a tuffy. I anticipate such a hodge-podge of differing neighbors that I’m thinking of putting one or two guys on this full time for a while. And I think I’ll be looking at the “85% solution” more often than not. I just don’t want our own front line people having to have two different radios in one vehicle. I think there will be situations where I’ll have to look at “customizing” solutions. Like, what if one of our departments sees the requirement to work with agency A on VHF legacy conventional FM and agency B on UHF P25 digital? Or even more crazy, agency C on an older EDACS system? Something for me to think about. I’ve met vendors who say they can help me with gateways and such to achieve things like this, so again, more learning, more homework. It’s all good, no?

    Anyway, plenty more to go through and digest. Again, ohiodesperado, I really appreciate the input. Thanks!

    Jim

  12. #12
    Join Date
    Jan 26, 2013
    Location
    Somewhere extremely cold and white.
    Posts
    89
    Thanks
    61
    Thanked 50 Times in 26 Posts

    Default

    Quote Originally Posted by cyrus View Post
    ... As long as the system doesn't use any proprietary features, you should be able to use any user gear. You do not have to select the same vendor's gear.
    That's where I want to go with all this. As vanilla a system as possible. But I worry that should one particular user group dig in their heels and REQUIRE a particular feature (vendors often contact our userbase and push non-standard features as essential - for example, knock-down sensor telemetry features which are outside P25 spec but add value and product differentiation to enhance a vendor's attractiveness - completely understandable) then this will throw a wrench into the works.

    Say, for example, client A wants to have neat GPS situational awareness data fired back to a console in a command center from their vendor X handhelds and mobiles. Will we be obliged to go with a vendor X base station? Or can that data get delivered to the console for processing if we go with vendor Y's infrastructure? I suspect not, but I'm not sure.

    Thanks,

    Jim

  13. #13
    Join Date
    Feb 04, 2012
    Posts
    1,921
    Thanks
    189
    Thanked 742 Times in 333 Posts

    Default

    I am always looking for copies of the TIA102 Axxx ,Bxxx series .pdfs

  14. #14
    Join Date
    Apr 09, 2012
    Location
    Australia
    Posts
    929
    Thanks
    286
    Thanked 667 Times in 249 Posts
    Country: Australia

    Default

    If you work for the US Government, all you need to do is get in touch with the TIA and they will give you the PDFs for free for exactly this purpose.

    (A whole bunch of disclaimers and caveats apply of course - such as do not redistribute etc)

    From the PDF I linked to above -->

    1.8.2 Attaining Project 25 DocumentsFollow these links to attain Project 25 standards and technical service bulletins (TSBs):

    * P25 documents are available for purchase from http://global.ihs.com/.

    1.) Enter a specific document number in the Document Number... field.
    Alternatively, enter Project 25 in the Title or Keyword... field.

    2.) Click the search arrow.

    * P25 documents are available to U.S. local, state, and Federal, agencies free of charge upon request.
    Please contact TIA at standards@tiaonline.org to receive additional information.
    Cheers,
    Matt

  15. #15
    Join Date
    May 31, 2012
    Posts
    229
    Thanks
    41
    Thanked 61 Times in 31 Posts

    Default

    Quote Originally Posted by jimbo View Post
    I attended a briefing by a pair of gents from NIST (or a subordinate/affiliate agency which keeps up on standard compliance and such) and it was extremely interesting to find out that while the CAI is all sorted out and can be said to support interoperability, ISSI is still in the pipes. They stressed that while the ISSI standards are written, the agreements, or understandings, on how to test for standards compliance across the board are not finalized yet.
    This is true, P25 is still an evolving standard. A lot of people don't realize this, but Motorola is a huge contributor to the P25 standard. Most of it is based on Moto's R&D...which makes sense as they were the first to market with IMBE and CAI by a big margin, especially on the infrastructure side.

    It can make sense to go with a two tiered approach on their systems, using higher end Moto subscribers with their extra features for Public Safety agencies, and lower tiered basic P25 subscribers for everyone else.

    As far as infrastructure, there are only a handful of vendors who can truly provide an end-to-end solution...Motorola, Harris, Cassidian are the ones I'm aware of. There are others who claim it, but they need to bring in partners such as the 3 mentioned.

  16. #16
    ohiodesperado No Longer Registered

    Default

    Jim, not a problem. One of the things I get to experience as a field tech and system installer integrator is what was expected as opposed to what's delivered. It can be major things like a sales man talking about GPS tracking of vehicles with a MOTOTRBO system, and then the customer just buying a repeater and some subscribers and expecting to get the tracking without buying that part, or simple things like the Cross muting from the mike in a tone remote desk set being globally muted and the handset mike not being muted. Ran into that today. It's always easier to understand what you are getting going in. And knowing that it's all going to work with the functionality expected. An example would be a new Astro 7.x system. It will do TDMA with APX radios. In layman's terms it will take one repeater channel and give you two talk paths. The problem arises when you have a different radio that doesn't support Motorola TDMA. The system will support only one talk path per channel (frequency) with those radios and you have half as many talk paths as expected and that isn't enough to support the traffic load you have. Who makes the radio isn't relevant, there are Moto radios like that are current product that are P-25 compliant, and 7.X system compliant that are NOT TDMA compliant. If you don't have those specifics, and think you do, it becomes a problem for everyone involved. I hate seeing that.
    And honestly, I don't want someone to say their console system X will work with vendor Y's new system directly when it doesn't. I have a customer that is convinced that he's going to simply plug his IP Zetron console into a Motorola 7.X core and be fully connected with all functionality of the Motorola 7500 console system would have if he had bought it instead. It could to turn into a mess because he may end up needing control stations for every talk group he wants on the console, which cost $7K each. More over the amount of resources needed in the back end may or may not be sufficient (connection from the radio site in his county back to the core). He is not getting a core, the core belongs to the state. Beyond that, it's yet to be determined if the state will even allow his Zetron to attach to the radio IP network to begin with. There are alot of unanswered questions with this. And the money involved if things will not operate the way he has claimed to his hire ups, it could seriously limit his employment situation. I don't like seeing that sort of thing either, especially when it's fairly easy to avoid by asking all the questions ahead of time and being thorough, and getting it from more than one source. In this case, Zetron has claimed it will work. Motorola was asked the same question and they basically laughed. And now back to what I do, I am the one that gets to make it work. This can be a simple software change or it could be an attempt to put a Semi truck motor in a Chevy Vega.
    Last edited by ohiodesperado; Jan 29, 2013 at 12:15 AM.