Tamper Alerts Caused by HF Radio Transmitter

Support
1

Qolsys 16-F Hardwire Translator

Qolsys IQ Panel 4 Keypad

Qolsys IQ Remote PowerG Keypad

My HF ham radio transmitter is consistently causing nuisance tamper alerts on most zones. If the alarm is set, the tamper alerts set off the alarm. On one occasion it set off the fire alarm.

I’ve installed Mix 31 ferrite beads inside the hardwire translator box on all 16 zone wires including the smoke/fire circuit wires, and the incoming power wires (on both red and black). This mix is specifically designed to suppress RFI at the relevant frequencies/bands (7MHz/40m, 14MHz/20m, 21MHz/15m and 28MHz/10m). I’ve verified they’re suppressing these frequencies 21-32 dB. With the ferrites installed, the problem appears to be solved for 20m, 15m and 10m, but I’m still getting tamper alerts while transmitting at 7MHz/40m. This is despite the best ferrite suppression (32 dB) being at 7MHz/40m.

I know I’m not the first to have this problem. What’s the fix? The ideal solution would be a setting to disable tamper alerts altogether; I don’t see such a setting. Is a firmware version available which would allow disabling TA’s?

2

Are you able to record a video of the panel when this occurs and send it to us? If you are not able to send it here, you can send it to Support@suretyhome.com

3

I’m unable to post video here. I sent it to the email address. Thank you!

4

I shared the video with Qolsys tech support representatives. They were not sure why it was causing this. They also mentioned that the tamper cannot be disabled on the zones.

They suggested going with a PowerG Takeover Module as the connection is more secure using multiple frequencies and hopping between them.

IQ PowerG Takeover Module only has 8 zones on board but can be expanded with the IQ Hardwire Expansion Card

5

They did move the video and the information you provided higher up in the chain and was told if they figure something out, they will reach out to me.

Let us know if you have any additional questions

Thank you

7

Thank you for your response. You say Qolsys tech reps don’t understand the problem. I can help with that:

The tamper alerts are popping up because a routine in the firmware is evaluating some parameter which is being measured on the zone wires (likely voltage). The measured value is exceeding the programmed threshold value – apparently a hard-coded value which can’t be changed in settings – so the firmware is throwing flags as it is programmed to do.

As I said, I’ve added 32dB of RF suppression, meaning I’m preventing 99.94% of the delta voltage which the transmitter is inducing onto the zone wires from reaching the Hardwire Translator main board. The alarm system is intolerant of the tiny remaining fraction that’s getting through.

This tells us the threshold tamper limits hard-coded into the firmware are very, very narrow. The clear solution is for JCI/Qolsys to provide relief by relaxing that threshold.

It would only take changing a few lines of code to give thousands of ham radio owners that relief. An even better, more customer-oriented solution would be to add a software slider control into settings with the current tamper threshold at one end of the slider range, disabling the tamper feature altogether at the opposite end, with the remainder of the slider devoted to adjusting the threshold sensitivity. Such a control would allow users to find their own unique sweet spot between tamper protection and RFI tolerance.

I don’t understand how the PowerG Takeover Module would help the issue. I can’t find a clear explanation what it exactly does, but it appears to provide a new wireless interface between the existing zone wires and the wireless keypads. It still uses the existing zone wires, where the RF is likely getting in. I think the frequency hopping is only between the Hardwire Translator/Takeover Module and the wireless keypads. That link isn’t the problem.

Ferrite Suppression Chart - 1X Fair-Rite 2631480002 0.200 ID 5 Loops
Ferrite Suppression Chart - 1X Fair-Rite 2631480002 0.200 ID 5 Loops1275×1600 315 KB

8

I will reach out to Qolsys and update them on this.

If it is the tamper caused on the wire side, then the PowerG Takeover module can be used as it has a wider resistor range of 1K to 10K Ohm resistance(5.6K is UL) vs the IQ Translator of 4.7K. You can also program the zones inputs to be Normally Closed instead of SEOL(Single End-of-Line). This would most likely eliminate the tampers caused by the radio.

9

Thank you. To clarify, are you telling me this will fix the problem, or are you suggesting I buy two of these and see what happens?

10

I’ve been waiting years for someone to post this issue.

Although I’m still laughing about your statement “I know I’m not the first to have this problem.”, because you’re not.

However, I predict you won’t be the last, although I’ll be thrilled if a solution is discovered.

I experienced the same problem many years ago when converting from an ADT system to Qolsys. I didn’t have service with Surety at that time so I contacted Qolsys. They had zero interest in assisting. And that was when they were an independent company with motivation to succeed.

Environment:

Qolsys 16-F hardwire

Qolsys panel 2

lots of wired sensors from original ADT system

a few wireless sensors added in recent years

some wireless smoke detectors not linked to Qolsys.

All wireless devices function fine.

All wired devices exhibit the problems you described.

Homeowner is the ham and a very senior citizen.

I’m the “attic boy” and have had that assignment for many decades.

I’m also the “roof guy” when a hurricane approaches.

etc etc,

However I’m not an electronics guy or a ham.

Attempted fixes (from memory):

We tried various ferrite and choke experiments, all of which had no effect.

Installed new alarm wire with shielding, did various experiments, again all with no effect.

  • shield to known earth ground

  • shield to ground on 16-F circuit board

  • shield back to transmitter and related equipment

Finally concluded the problem was the RF directly entering the 16-F. (Again I remind you I’m not a RF or electronics person.)

Our resolution was to use a DPDT relay (plus switches and led status) to remove power (both wall and battery) from the 16-F while hamming.

Of course this requires manual operation by the ham. In my situation the ham is likely older than anyone you know, so his remembering has become a problem. To assist with memory we also added a wire from the relay back to contacts on the panel-2 and created an automation rule when the 16-F has been powered down for an extended period. (Since you have a panel-4 you would need a wireless sensor with auxiliary wired inputs.)

A couple years ago I asked Surety about an automation rule of “AND”, ie when sensor1 AND sensor2 are triggered then take an action. (All existing rules are based on “OR” logic.) Surety forwarded the suggestion to ADC and it probably sits in a similar folder as your inquiry. I assume that folder is labeled “When Pigs Fly”

11

For a non-RF guy, sounds like you have a pretty good grasp of the problem.

Yeah…I was really surprised I couldn’t find any existing threads on this issue. I feel pretty safe thinking a whole lot of HF operators have this problem and had it long before me.

I have no illusion Qolsys might issue a firmware revision to solve a problem reported by only one person, even though it’s proven to result in a call to the fire department on occasion. Such revisions require a lot of testing, involve lots of paperwork and are expensive. I will, however, hold some hope it might find it’s way into a future revision being issued for some other reason.

Thank you for the list of the options you tried. That’s helpful. Some of my zone lines (I haven’t checked them all) have foil shielding, but they’re not tied to ground. I considered doing that. Good to know that didn’t work; that’s crossed off the list.

Next, I’m going to try putting a small capacitor across each zone’s terminals, red to black, in parallel with the zone wires. Maybe that will drain off the last of the RF on the red wire to ground. Did you try that one?

After that, I’ll look into Mix 75 ferrites, either standalone or in series with a Mix 31 ferrite. They’re good for lower frequencies.

You may be right about the RF path from antenna direct to the 16-F main board. I think the only options there are to remove the 16-F contents from the plastic enclosure and put them in a metal one (AKA a Faraday cage), or to put the whole plastic enclosure into a metal one. And then ground the metal enclosure and maybe seal with electrically conductive tape.

As a hail mary, I might look at optic couplers or something similar to electrically isolate the zone wires from the 16-F while still passing the signal. I have no idea what feasibility, complexity or cost look like.

Last option: I’ll install a switch to turn off the alarm system like you did. That’s the sledgehammer approach. Nothing elegant about it, but it’s 100% effective.

12

We didn’t try any capacitors.

A couple other tidbits. My environment had somewhat older coax so I was concerned about leakage. Additionally, some coax runs were in the attic above the 16-F. An experiment idea for you, can you take the 16-F, 1 foot of alarm wire with one sensor, and move everything to a different location XX feet from its current location.

Our 16-F is in a metal box (it previously held the ADT board).

I can’t recall whether we tried grounding the box.

I do recall that nothing we tried made a difference, hence the “sledgehammer approach”

Perhaps Qolsys never tested the 16-F in a HF RF environment or perhaps they simply chose to ignore the results.

I don’t know whether Qolsys has a FCC or UL or etc requirement to test and certify their equipment, if so they are probably trying to run out the clock and declare the 16-F as end-of-life and then say oops we didn’t know about the problem.

When I had to solve my problem the PowerG Takeovers didn’t exist so there were no alternatives to the 16-F

Today If it were me (or perhaps when its me again). I would ask myself, do I want to get back to hamming or do I want to pound this problem into submission?

(Once again remember I’m not a ham, so “I” don’t want to ham, but the actual ham did. And yes I’ve pounded my share of problems into submission just to prove a point, because that’s how engineers + scientists drive society forward.)

Then I would sell the 16-F on ebay to a non-ham, buy a PowerG Expansion Module and hope for the best.

If the interference problem remains you at least have a modern design to battle and DSC will have to own the problem and defend against their list of certifications + approvals “UL | FCC | ULC | IC”

From the earlier responses to this thread its clear that the front line representatives at Surety and Qolsys don’t have experience with your environment or HF RF and therefore will not be able to offer you definitive answers.

1 Like
13

Another clue. The system usually - but not always - stops adding new tamper alerts to the list once the count gets to 25. (I’ve had as many as 61.) Why would it stop? Does that suggest the system is setting a bit or internal flag to prevent entering the tamper detection routine after the 25-count?