[Download not found]

A device failing to alarm or restore properly can be the result of a number of different things. This is part 3 of a multiple week series and this week we will cover reading and analyzing the System Log.
The system log can be a very valuable tool for installation, and can be especially useful troubleshooting sticky RF issues. Most of the data in the System Logs for all intents and purposes will be unreadable. The system log however can be used to identify a device ID, observe which locators are picking up a device you are testing, or verify whether or not a locator signal is getting back to the Master Receiver.
Step 1: Accessing System Log:
 a) Select System Settings Tab
 b) Select Systems Log

Step 2: Device ID’s:

a) Time Info – Date and time that the signal was processed by the cube. This section also covers the name of your server and the device reporting to the server as well. In the case of an alarm signal, it will always be MR-500.
b) Device Info – If the device is unlearned, it will show up in the system log as an “Unknown device”. Otherwise, it will have a system generated Account number. This section also displays the device type (EX: UT-3). Pendants will have WTC and most other devices will display UT-3. You will also see (ALARM) or (RESTORE) indicating what kind of signal it is.
c) Wireless Network info – The final section shows Flags (such as Power (P), Tamper (T) or Battery (B). It also shows the Locator and Repeater ID that is transmitting back to the MR-500. Here, you’ll notice both a Gen 3 and a Gen 4 Locator. Gen 3 locators have 3 digit ID’s while Gen 4 have 6 digit IDs. Then you’ll see the Master Receiver ID number. Finally, you’ll notice only the Gen 4 Locator (00001E) has an RSSI value. This will tell you if the signal from the transmitter to the Locator is strong or weak. For Response Care servers, the lower the value the higher the strength

Step 3: Locator Check-In:

This image displays what to look for in the system log when you hit the test button from the locator. Here you will be able to verify several features including Locator ID and name, but more importantly this will confirm if you are getting a signal back to the cube. NOTE: For Gen 4 systems, a locator test will only show up in the system log after they have been learned in to both the wireless network and the MR-500 itself.
Learning to read the system log can give you an invaluable tool for troubleshooting a suspected device or RF interference issue, among other things. You can use the system log to cross reference the accounts and the wireless network link to ensure you aren’t just held up by a programming error. When used in conjunction with the previous “My device won’t work” Tech Bulletins, the system log will aid in confirming or refuting suspected 433MHz or 900MHz RF coverage concerns.
[Download not found]
A device failing to alarm can be the result of a number of different things. This is part 2 of a multiple week series and this week we will cover the steps for narrowing down and identifying RF interference.


Once you’ve checked the Service Report and the Edit Device screen, you can then begin checking the wireless devices themselves. The first thing you will check is the individual transmitters. If the individual transmitters appear to be functioning then there are a set of steps to take to see if it is an issue with on the 433MHz or 900 MHz side.
Step 1: Does my device work?
Does the red light come on when I activate my transmitter? How old is the device and when is the last time I changed out my batteries? These are the questions you need to ask, particularly after you feel you have ruled out any issue with the wireless network. If you’ve replaced the batteries and the device still isn’t alarming, you may be having an RF interference issue. The easiest and quickest way to differentiate between a faulty device and an RF issue is to swap out the device in questions with a known good or spare device. If that new device begins working, then you have a bad device. If it still doesn’t work, you could be having an RF issue.
Step 2: Is it an RF issue?
Identifying an RF problem is going to require two people that have an open line of two-way communication: one person will test the device and the other will observe the closest locator to see if it receives and re-transmits the signal. If the device flashes red that means a signal is being transmitted at 433 MHz. If the locator does not flash red, this confirms that a 433MHz signal was not received by the Locator. The flash indicates it is receiving and then retransmitting it back out at 900 MHz. If the locator does receive the signal and an incident is not created you could be having a 900 MHz RF interference issue.
If you have what you believe to be an RF coverage problem there are several things you can do.
1) If the issue is considered to be 433 MHz: check the potentiometer in the back compartment to increase the range. If it is maxed out already, you may need additional locators for better coverage.
2) If you observe the locator LED’s going off, and no incident is created it doesn’t automatically mean you’re having 900 MHz problem.
     a) Is the device learned in to the Cube? It could be as simple as
     b) If this is not the case, you may need a repeater or external
         master receiver to increase coverage.
     c) If there is a repeater or external master receiver in place an
         you are still having issues – call the tech support line and we
         will discuss a potential upgrade to our G4 products.
    It’s important to remember, just because your locators are all checking in, does not mean you have a good wireless network. You need to verify that all of the wireless devices are able to reach the Cube 100% of the time.
[Download not found]
We’ve observed several scenarios Wi-Fi connectivity. We’ve seen some facilities that just don’t have quality Wi-Fi, or simply don’t have quality dedicated IT staff. We’ve made several changes to RCare Mobile and recommendations for improvements that we’ve seen drastically improve Wi-Fi issues at several facilities.


First thing to remember is that not all routers and access points are created equal. A typical access point usually provides a coverage radius of 300 feet under normal conditions. DO NOT assume you have a typical access point or “normal conditions”. If adverse conditions prevent data from reaching its destination, it is referred to as packet loss. When you have enough latency and packet loss, the RCare Mobile devices will log out until there is enough available bandwidth for you to reconnect with an access point. Total bandwidth represents the total amount of digital space you have to transfer data. When the total required bandwidth of all your devices exceeds total available, the network cannot properly receive all the data.
Scenario 1:
Voice quality can diminish because of environmental RF interference, such as reinforced concrete. Stairwells and elevators in particular have been known to cause Wi-Fi dead spots or poor quality reception. An audio codec encodes voice into data, and then it transfers that data through the network to its final destination. If there is interference or too many calls at once (too much data), then the bandwidth becomes congested and begins to drop packets.

Solution 1:

We have begun implementing an upgraded audio codec into our servers that converts audio to use less bandwidth, thus taking up less digital space. This codec utilizes a process similar to what Skype and Google use known as “Loss Concealment”, which allows for greater packet loss without dropping call quality.

Scenario 2:

A bad installation can be caused by several things including loose coax cables, poor and/or not enough quality wireless access points that can cause significant packet loss. Most often, we hear from technicians at a facility with RCare Mobile issues that the Wi-Fi there is very poor, but this isn’t always the case. Most phones today have sim cards that use 4G or LTE connections from external towers. When the Wi-Fi drops in and out, the sim card reaches out to a cell tower to fill in the gaps instantaneously without the user knowing about it. RCare Mobile phones do not have a sim card.

Solution 2:

RCM software version 1.49 or later will include a Wi-Fi optimization option in the admin settings to combat these various issues. This feature will lower latency and packet loss, but will drain the battery quicker to achieve this. This feature will be automatically enabled and if the Wi-Fi is not having problems, you can disable this feature to save battery life.
Scenario 3:
You can also have too many access points or improperly channeled access points. Even experienced networking staff may not configure their access points in a way that optimizes RCare Mobile. Each channel covers a very specific frequency range and these frequencies overlap with adjacent and nearby channels. So having two access points close together on channels 1 and 2 will create more problems because it limits available bandwidth. In this scenario, when caregivers roam the facility and the phone attempts to leap to the adjacent access point, you guessed it, packet loss. Finally, access points should overlap one another to ensure there are not any “dead spots”.
Solution 3:
Facilities should configure their access points to channels 1, 6, and 11, as they have no overlapping frequencies. It is also important to remember not to have access points that are on the same or directly adjacent channels that are providing overlapping physical coverage. If you have two access points, both on channel 6 trying to cover one wing, they will be competing for available transmission time on that channel.
Most of our facilities will not have to implement these changes, and even the ones that are having issues most likely won’t need to apply all three. However, we’ve now identified 3 potential scenarios with three separate solutions for various Wi-Fi related problems. These are situations you need to consider and discuss with the network providers before going live with a system.
[Download not found]
A device failing to alarm or restore properly can be the result of a number of different things. This will be a multiple week series and this week we will cover several general rules of thumb when trying to identify the possible causes.


There can be any number of reasons an end user makes a service call about alarms not going off. You may even see a variety of questions that will direct you towards one path or another. You might hear “We’re not getting alarms”, or “We have a device that’s not working”, or “We have a device that has stopped working”. The first may indicate a notification configuration issue, the second a bad device, and the last an RF issue; or perhaps it’s just a training issue. Below is a list of progressions you should go through to identify what is causing the alarm to not go off. These will be general guidelines and in successive weeks we will get into more specific details.
Step 1: Service Alerts
Service Alerts will always be one of your best friends. Check Service Report for low battery/missing supervisions for the Device and Locators. Service Reports and Service Alerts should always be your first line of inquiry with alarm failures. If you set up end users with service reports they themselves can stay ahead of any changes problems. Check your RCare Manual or the “Service Reports” Tech Bulletin on the Distributor website in for details on service alerts.
Step 2: Was It Working Before?
If the issue is not easily identifiable in the Service Report the first question you need to ask is was it working before? If so, what changed? Whether the end user is aware of any changes or not, this possibility needs to be scrutinized. Changes can affect the Locators, particularly ones on central power supplies. If it’s worked in the past or there are other devices working, you can often narrow down the issue to a specific hallway, room, or device. If it has never worked, you most likely have a coverage gap which we will discuss in a later bulletin.
Step 3: Check The Account
In this step you will further investigate issues found in steps 1 and 2. You’d also be surprised at how often you get a call for the Pendant in Room 101 not working only to find out that there are no devices programmed into Room 101. Also, by checking the device you will be able to identify the device in question, as well as its supervision history. Pendants’ last supervision should always be “Never” and if they are, it’s possible its diminishing transmitting power is the culprit. Pull cords or bedside station should always be in supervision and the Edit Device screen will provide you a lot of information. EX: you may have identified a transmitter that has been missing supervisions for some time, and it could be because you never told the system to monitor it, or it could identify exact when it stopped supervising.
Step 4: Check Wireless Network
Though this is the fourth recommended step, this is your bread and butter for verifying the health of your wireless network. Your Service Report will tell you when Locators are missing supervisions, but until they know a device has stopped working they may not know or care about a Locator missing supervision. Nobody can force the end user to react to Service Alerts, and so long as everything seems fine, they may overlook an issue with a Locator that they most likely don’t even know exists. They just know their devices are working…until they don’t. Often you can see a progression of a Locator going down and successive transmitters failing to check in within close proximity to one another. If a Locator is highlighted in red, you have a problem. IMPORTANT: Just because you have no Locator flag(s) and your supervisions are good does not mean you have adequate coverage.
When you get this call it can be daunting because of the list of potential causes is very large. First thing to do is mitigate immediate post install problems by making sure you verify the health of every device before you leave an install. Next, make sure you configure your service alerts and train the end user how to read them. Finally, ask yourself what is not alarming, and what is the alarm history of the device in question? These simple steps will limit the variables and get you on your way to identifying the culprit of missed alarms.

RCare was delighted to be highlighted and called out for their advanced location protocol featured in a recent Nurse Call System research report by Grand View Research, a San Francisco-based market research and consulting firm.  

RCare Mobile's "I got it" feature on ensures caregiver accountability and lets multiple caregivers know who will be responding to any given alert.

RCare Mobile’s “I got it” feature on ensures caregiver accountability and lets multiple caregivers know who will be responding to any given alert.

Nurse Call System Market Worth $1.8 Billion By 2022: Grand View Research, Inc.

This study found that the global nurse call market is expected to reach 1.8 Billion USD by 2022. This number will be driven by reimbursement coverage reductions, hospital readmission penalties and the increased expectation for digital health in long term care.

RCare is a market leader with a global footprint throughout the United States, Europe and most recently in Asia with their latest Malaysian distribution partner.

The report singles out RCare for its innovative “I Got it” feature on the RCare Mobile and the Advanced Location Protocol (available for senior housing communities in the United States).

Wireless communication equipment is expected to witness rapid growth. With the increasing healthcare complexities, the need for integrated nurse call systems and electronic health records is driving the industry players to launch advanced solutions. InNovember 2015, RCare launched its G4 technology with Advanced Location Protocol (ALP) for senior living facilities. The “I Got It” button provides a state-of-the-art solution to allow staff to pinpoint locations with the aid of RCare pendant.”

Read the entire release