martinhendo

Right Guys, a new year and the same old same old. "Happy New Year All".. Another event on @ the stadium and more false activations. All 4 stands fullish and 3 random call points into fire, all 3 on separate nodes and just random. I'm not sure if this is anything to do with the root of the problem, All the external call points are the apollo IP rated versions a stated earlier, I know that Apollo and Discovery are more or less the same thus are able to run together on the same loop but on viewing the config file while on site today I noticed that the loop device data states that all these call points are Discovery, There are 4 plant rooms that each contain an Apollo intelligent call point, in the config these are Apollo, I know there's only 4 but not one of these have caused any issues since our takeover of the system. I'm clutching @ straws here as The sites config was passed to Advanced with details of the parts used, they didn't flag up any anomalies thus I didn't think this would have anything to do with all this.,

James, We took over this site and tbh it's not the best installation as a whole, I could write a book filled with what I've found. This was a brand new stadium, I cannot understand why the installation company used 4 nodes rather than 1 with repeaters. The stadium isn't all that large in footprint after all. I flagged all these earthing issues with advanced and they simply said it shouldn't make all that much difference, that was me told anyway.

The panel is connected to a 2 net Morley ZX5SE system for a one way latching delay signal and one way fire signal. This however has already been taken out of the equation as we have had all I/O's disconnected and still had the rogue devices triggering randomly. Just to add that today only 1 stand was used during the events @ the stadium and there were no devices causing random fires We don't have another event until January 24 so no chance of taking this any further atm. Any further tips may be of use though. Thanks all for the replies.

The Net connections between the nodes are run in SWA the cpc isn't connected to all of them. The loops are run in FP with no cpc connection to the call point face plates, only the plastic back box terminals. We have tried to trigger the call points using manual force, i.e., elbow, screwdriver etc. not one of them has managed to trigger using any of these methods. All call points are open to the elements, top of stairs and lower Vomitories within a rugby stadium, the nodes mare located within heated plant rooms where 1 call point and 1 sd are present. Just a side note, the first year following installation there was no issues with any of the devices, nothing has really changed on the site, no change to original installation etc. We don't have the facilities to remove the rouge devices from site and run them for 28 days unfortunately, Advanced offered to take a couple of them down to Newcastle and run them using the sites config to try and replicate the fault but this was passed to our management and as yet I've heard nothing back. Today I have been on site most of the day for events @ the stadium and as yet the system is sitting all ok, the attendance is nowhere near that of yesterday when the 3 random events occurred. This is just weird, not seen anything like this on any site/system before...

Thanks for the reply James.. This is happening over all 4 nodes, intermittently with no pattern and not the same addresses each time, Site is a stadium with 1 node/loop on each of the stands, yesterday during an event 1 manual call point on nodes 1,3 and 4 caused fire events, no human interaction was involved in setting off these, cctv footage has confirmed this on this occasion and most others. These 3 devices have not been changed as of yet due to not having 3 spares in my van.. When the stadium is empty/not in use no there is never ever a false alarm triggered by any of these manual call points. Each stand has a plant room with a manual call point, (non IP rated) a sounder base and a smoke head, neither of these ever cause any issues either. The rogue devices previously have been deleted from the download and loop learned back on with the replacement, They may or may not fire again but due to the random nature of this I am not sure this would make any difference anyhow. I was on site Friday afternoon carrying out a PPM visit, nodes 1 and 2 tested, all devices fine with no issues evident in the logs of these 2 nodes. There's an event in progress today, all day.. we will see what that brings.

Right, Advanced Mxpro 4, networked x 4, Apollo protocol. Full system has 160 devices split between the 4 nodes All 4 nodes have a selection of XP95 ip rated MCP's (58200-951APO) with clear covers fitted, XP95 Intelligent MCP's (SA900-908APO) with clear covers, XP95 Open area sounder beacons (55000-005APOX95) And XP95 Apollo SD's (55000-600APO). Monday to Friday and in general the site has no issues, but when there's an event on we are getting intermittent call point activations with nobody near them, this has no obvious pattern either, split between all 4 nodes, just random as hell. The activations are only involving the ip rated MCP's, we have sent the complete config and numerous diagnostic logs to advance with much head scratching involved and are no further forward, earth monitoring is on and within tolerance. We have swapped out previous guilty MCP's only for them to come back in again. Any help would be welcome.

New install.. Found out what the problem was, one of the jumpers on the RIO wasn't making a true connection, replaced both jumpers, power cycled and New install.. Found out what the problem was, one of the jumpers Slave/EE on the RIO wasn't making a true connection, replaced both jumpers, power cycled and problem sorted. Really strange, haven't seen that happen before. Every day certainly is a school day. Thanks for the replies.. ?

Haven't looked @ the bus as of yet, not had time. Might give it a shot when back on site, worth a crack. Thanks..

Panel and all Rio's are set to system default, 1K balanced/eol, Having already checked that. Zones 2071 > 2072, 2074 > 2076 and 2078 are all working as expected with exactly the same resistor setup. The 2 zones are also on separate locations.

Haven't tried adding anything onto the existing bus line due to time restraints today Everything looks from the outside, comm's 100% with all Rio's on both lines.. Lines are run in belden. Just haven't come across something as weird as this.

First ever post on here.. Been in and around the F&S installation game for a few years now but have never come across this, maybe one of you guys could shine some light on it. New installation of a 264, Line 1 has 2 x C072's and 1 x P026, no RKP or other modules on the bus, everything is programmed and tested on this line. Line 2 has 5 x C072's and 2 x P026's, along with 1 CP037 RKP and MX4 Prox. Rio's are addressed from 201 > 207, all devices on Rios 201 > 206 have been tested with no issues, RKP and Prox reader function as expected On to the issue, Rio 207 (Furthest away from main panel, power sourced from Rio 205, 23m distance, 680 resistor fitted and link removed in panel) 13.8 v @ Rio 207. On carrying out a walk test on each zone individually, Z2073 a DT along with Z2077 a DC gave no response to the walk test. The other 6 zones had no issues. The zone resistances of Z2073/Z2077 via option 21, 1K ohms when closed, and when resistance rises to 1K9 (roughly) the panel still returns a closed message, all zones are set to default EOL. Replaced DT and DC, and tested cables from them @ the Rio, 1k closed, 1K9 Open (roughly) on each. Tested the cable from the detection end while connected to Rio, shows S/C on panel around 12 Ohms resistance. Swapped the Rio for another that's known to work and the same issue remained.. Honeywell may be getting a call when I am back @ site.. Your input would be appreciated..