GalaxyGuy

Honeywell only provide firmware to installers.

I think it must be a part number mistake, as there's no mention of any SPI bus on the Flex in any documentation. Some PCB's have the SD slot populated, but it hasn't been carried in the design. There's no low level firmware recovery option for standard users. Your problem may even be hardware.

I'm not sure what you mean. Can you post an image or link of the 'programming key' you are talking about ? I haven't seen a programming key for the Flex. I did see an SPI key offered on SecurityWarehouse, but not sure where that plugs in, as there's no socket apart from USB. I had just assumed that it was a mistake on SW.

If the panel LED goes straight to ON, then the bus is not starting up, so there will be no communication with _any_ keypads or USB. So no point in trying device addressing or RSS. You cannot perform any operations on the system, as it will not boot far enough. If the panel LED was flashing, then yes it may be a peripheral address, but the fact that it's going straight to solid means that there's a low level problem that's stopping the panel even booting. OP, you haven't confirmed if the LED goes straight to ON at power up when all other connections are disconnected. You need to do that. For information, this is what the Flex should do when booting up. 1. When you connect power to the PCB, the LED on the PCB gives a very quick single flash (while the redboot boot loader is loaded). 2. After about 15 seconds, the LED on the PCB comes on (the bootloader has loaded the operating system). 3. After about another 25 seconds, the LED on the PCB will give a continuous repeated quick flash - as per Galaxy bus devices (the operating system is running and the Intellibus and Galaxy busses have started up and should be talking to devices). If you disconnect all connections, then plug in the DC power connector and do not get stages 1 to 3, then it's likely the board has a fault. Prepare for replacement.

Under programming option 51.17 there are several options. One of them is shutdown and it performs an orderly shutdown of the panel operating system, flushing any config settings from memory to filesystem before you power off. It's not guaranteed that this is the issue. It could also be component failure. Was it an eBay purchase, or under warranty? Just ensure that you disconnect all external connections and power up just to confirm that it's the panel and not some other external factor.

If the led illuminates immediately and remains on, then the board is faulty. How long was the panel installed for? Since the Flex is running an operating system with a JFFS file system for storing panel settings etc, it's important to use the 51.17 shutdown procedure. Normally, if JFFS gets corrupted it will recover itself, but there's always a chance that it may not.

So, when you powered up, the LED gave a quick flash, but then instead of going constant, then flashing shortly after, the LED just stays on constant ? Is the panel voltage showing +12V from aux ? It does seem too much of a coincidence that you were making a change, then experienced an issue afterwards. Did you power down the panel when making the change. Did you use the 51.17 shut down / halting procedure to power down in an orderly manner ? Try disconnecting all external connections - keypad Etc. and if it still does this, then it sounds like the board. If within warranty, return to the vendor.

Sounds like the panel has crashed. Power off mains and disconnect battery momentarily to reboot. If it happens again, replace the panel. Take care when connecting the Flex battery leads. If you get the polarity wrong, you will destroy the board.

Okay, understood. Thanks for responding.

Does anyone know if the Texecom Ricochet wireless expander can be used to drive a Ricochet sounder from a non Texecom panel ? The literature shows the expander being connected to non Texecom panels via a relay interface, but I cannot find any technical detail to show if an output can be driven and tamper / fault status returned?

The serial number is different if you switch the device from V2 to Alpha and vice versa.

I'm not sure where Alpha 2 is used. The jumpers are correct. Peripherals should be configured for Alpha where possible, as it has better supervison. To conserve battery life, the detectors will back-off from reporting every event when constant motion is detected.

I think you will see a couple of business models in play. The first, a minimal unsupported free / no SLA service that's provided in order to check the box of 'free apps' when customers are selecting the product. The other will be various levels of up-selling the basic offering at a cost. Ie. Where you pay for support and added functionality. It's pretty much how 'free' software works.

Agree with SWB. Learn basic electronics. Transistors, gates, flip flops, RC timers, Etc. There used to be project kits with many circuit possibilities years ago - they were basic, but very good. The Tandy 200 in 1 was my dream x-mas present when I was 9 y/o. I don't think I ever played with any toy more than that. After that, skip the alarm circuit and jump to Raspberry Pi I/O. You'll find it easier to learn/modify programming rather than the example alarm circuits, but you still need the grounding (no pun intended) in basic electronics.

No, just 4000 series chips. Pretty old technology and similar to the circuits posted earlier, but will give you a better understanding of the electronics if you can build and debug the circuit. The microprocessor based stuff these days works by multiplexed analog to digital conversion. The zones are analog potential dividers, with the resulting voltage (from the zone) being converted to digital and read by the CPU.

What type of problems ? Anti mask ?

Yes, the pyroelectric sensor detects infra red radiation. It also detects the pattern of the surrounding ambient environment. If a flying object manages to disrupt that environment across the planes/zones, then the device will trigger. The closer the object is to the element, then the bigger the disruption to the planes/zones. So, a flying object that doesn't perfectly match the background temp of each plane/zone can trigger the PIR. The object doesn't need to be hot, just not a match for each individual plane/zone. As above, still not a reliable detection method. You've gone for a dual tec, but probably wanted a microwave only or multi-beam active IR detector, as dual-tec devices will not trigger on microwave detection alone.

Detection of a flying brick with a standard PIR, although possible, will not be 100% reliable. PIR's work by detecting differences in heat across planes and zones. Since the brick has no heat, you are relying on it changing the thermal pattern of the room. If the brick is far from the sensor, then it will have less impact on the pattern. You could always employ all three types of detection as a belt and braces approach.

Yes, they can be. http://www.security.honeywell.com/uk/hsw/documents/FG-1625TAS_InstallGuide.pdf

The dual technology sensor is not designed to be more sensitive, but less so. It's designed to reduce false alarms by requiring both PIR and Microwave technologies to trigger together in order to activate the zone. You need to look at break glass or vibration sensors to detect the brick. The Honeywell Flexguard glass detectors and Viper vibration sensors are decent devices. Most alarm detection devices are 12v DC with clean contacts, so are interchangable. Only the wireless devices are vendor specific due to the varying protocols and frequencies being used.

Yes, I was talking about the control panel LED. The keypad needs to be on the bus at a valid address when the panel boots and scans the bus looking for devices. With the Flex, you can add devices and scan for them with menu 72, but you need that first keypad addressed on the bus in order to use the menu to tell the control panel to rescan.

Al, the network card is on a different bus. The intellubus on the Flex. Have you seen that stop the keypad boot?

Just to confirm this: It should be a single quick flash at power up, then the LED should go off for about 20 to 30 seconds while the firmware boots. After booting, the LED will then light constant, then after scanning the bus it will pulse quickly.

Flashes straight away at power up ? If so, then sounds like a faulty board.

What does the LED on the panel board do? When initially powering it should give a quick flash. It should then light up constant after about 30 seconds, then after that it should give a quick flash every 1.5 seconds. If this was a sold as seen panel and it does not do as above, then it's faulty.