When to Test for ERRCS / BDA / Emergency Responder Radio Communications

In commercial buildings across the country, Fire Marshalls enforce a code that might be referred to as any of the following:

• ERECES
• ERRCS
• BDA / BDA System
• Public Safety Radio DAS
• Emergency DAS

While there are many possible terms that might get used, they all point to the same solution. For simplicity’s sake, I will use the most commonly used term:  ERRCS. This term stands for “Emergency Radio Responder Communication System.”  At their core, these systems ensure that fire fighters, EMS, police, paramedics, and other emergency personnel can use their two-way radios within the building. 

These systems represent one of the few scopes in your building that are variable.  You will only be required to install one if the coverage levels within the building are deficient upon completion of the project. 

This presents a challenge for building construction, development, and ownership teams as they will either have to budget for a system that may not be needed or omit the scope and hope they don’t receive notice of a need for the system at the last minute prior to Certificate of Occupancy. 

I have been deploying ERRCS solutions for a decade, and anecdotally, I have seen a few scenarios continue to plague the industry.   

The Six Most Common ERRCS/BDA/Public Safety System Issues

1. Initial system budget is a guess. The initial planning for the system reveals that a system might be required in that jurisdiction. The estimating/development team throws a potential number at the scope based on another project they completed a few months back which may or may not be a credible comparison. 
2. Assuming you won’t need a system. I have talked to plenty of teams that assume they won’t need a system because they have built four of the same building types in the same city, and have never needed it before.  There is an element of randomness to RF signal. Projects built in the past have no bearing on the need for a system in the new projects.
3. Contracting through too many layers. A general contractor might bid the BDA system to the electrical contractor, who asks the fire alarm team, who asks a DAS team to put together a number. The GC gets two layers of margin put on the number and has ZERO visibility into whether the system is even needed or not. 
4. Choosing the low bid.  Choosing the low bid can often be the best option, but it’s prudent to level-set the bids prior to doing so.  Many teams will bid projects assuming that only half the building might need coverage and take a risk that they won’t have to deploy for the full site. Then, if they need to deploy for the full site, their number can increase down the line.
5. Testing too late. Many teams will wait until the building is fully complete or nearing full completion before taking their first test or asking the Fire Marshall to test the building. This approach ensures either a last-minute retrofit or premature install of a system that was never needed in the first place. 
6. Improper / Inaccurate Tests. As this industry grows, many new entrants see a code-required system as a great place to grow their service offerings.  In theory, it can seem like an easy way to add revenue for projects that you’re already performing for other scopes. Because of this, we have seen a recent influx of tests that are improperly completed and show inaccurate results. Some of these tests are an honest mistake due to complexity of the technology, and some of these tests are likely an effort to sell a system where it might not be needed.  In either event, these vendors can have you paying $150k++ for something you never needed.  

Testing to Alleviate ERRCS Issues

Many of the challenges with ERRCS can be alleviated by following a proper process for the testing, installation, and commissioning.  Our philosophy behind testing is to provide hyper-accurate tests that predictively help determine the need for ERRCS, while remaining firmly grounded in reality. 

Testing the site and the eventual building is core to understanding the full picture of ERRCS at the project.  Without proper and thorough testing, everything else becomes a guess. 

Testing should be a low impact, low investment activity that allows you to get a progressively clearer picture of the site to ultimately make better decisions on how and where to deploy ERRCS.  When our recommendations are followed, we can guarantee that the building developer will pay the lowest overall cost for the ERRCS, while staying 100% protected from needing to deploy a solution at the 11^th hour right before building completion.  (A late stage deployment is not a problem on our side, but for the building development team, it typically represents not only a substantial risk of TCO or CO delay, but also a significant cost increase due to the necessary drywall damage from the install.)

Approach + Testing Protocol

Our approach to testing is not complicated and will not add any complexity to the project. It simply allows for the development teams to make decisions based off of better information gathered from the site.

This standardized protocol is an excellent way to determine the best path forward for most building types. However, there are some exceptions where the building type typically lends itself to a more simplified approach.

Exceptions to the Testing Protocol

Small scale buildings – For buildings under 50k sq/ft, it is encouraged to check with the jurisdiction/AHJ to see if a system is even required by code in that municipality.

High Rise Towers – These buildings can be more difficult to test as there are presently no perfect ways to test predicted coverage levels hundreds of feet in the air before the building exists.  Many of these buildings will, however, need a system.

Data Centers/Heavily Fortified Buildings – For buildings that have a large intensity of building materials, it can be better to assume a system will be needed and plan on a prewire.

ERRCS can be an exhausting headache that feels impossible to properly nail down. However, it can also be an opportunity for the building owner and developer to see a large cost savings if testing protocols are done properly.