jimcarter

When I get a minute I'll do one. I've just re-read this. Just to confirm. The Maintex is fine when being used via the Broadband link, but times out via the radio path? I'll have this checked out. It's possible its something to do with the restricted bandwidth on the radio path, coupled with packet loss and the number of re-tries permitted.

True, but for us its a reflection on the market. We have very few locations that use DCM. Its old, its clunky and has some very suspect limitations. Such as an inability to signal alarms whilst a UDL session is in progress. So we made a conscious decision to keep it off the board; its an expensive solution to manufacture as standard. I've seen it working JW.

Dial Capture...it may be worth reading the last blog I did on the subject (time I did another I guess). There is expansion capability on the Nano and we are looking at re-spinning the current Dial Capture module so we can use it with the Nano platform, which should not take long to complete. The expansion is there for Wifi, as whilst the Nano in its current form is single path 3G, it will have dual path capability when the Wifi Module becomes available (Broadband with 3G backup). Whilst we expect a large number to be used in UDL only or Grade 2 type monitored systems there is no reason why it cannot be configured for the shorter reporting times of higher risk sites later.

When we create products we have innovation, engineering and the future at the heart of our thinking. Our WebWay Pro and Mini range of signalling devices are designed for the Enterprise and Business markets so we're excited to announce the launch of WebWay Nano, our wire free signalling device for UDL and alarm signalling for home and low risk solutions. Nano is engineered for engineers. Easy to install, reliable, powerful and future proofed. Available from www.webwayworld.com in July 2015. Pocket Rocket When installing a third party signalling device in a Grade 2 intruder or fire panel, size is everything. WebWay Nano is just W72 x L113 x H16 (including plastic mounting base) draws 55mA and requires only a three wire connection to leading alarm panels for UDL and SIA. Great service WebWay Nano can be purchased on line at www.webwayworld.com in July. Priced inclusive of 12, 24 or 36 months WebWay World platform access, Grade 2 polling, UDL and extended hardware warranty. Contact your ARC for a Site ID and activate alarm signalling any time. Great connections Serial buses We've got great connections with all the leading alarm panel manufacturers. We've integrated the Contact ID, SIA, UDL and ARM protocols of Castle CareTech, Cooper, DSC, Gaurdhall, HKC, Honeywell, Menvier, Pyronix, Risco and Texecom. Nano has individual RS232, RS485 and TTL connections on board. 3 wires and no need for additional comms modules and you have a high speed, radio only secure signalling system. Extendable inputs and outputs Every Nano has 8 inputs and 2 outputs which can operate in parallel with the serial bus connection. Using WebWay Remote Pins you can add another 32 channels and 12 outputs for fridges, fire and more. 3G & Roaming eSIM First time installation, secure, fast and reliable communications are at the heart of the Nano. The Nano has an eSIM built directly into the PCB design. eSIM is a SIM within a microchip, which improves manufacturing, streamlines administration and adds security to the solution. WebWay eSIM is registered to all 3G, EDGE and GPRS networks and selects the best available service automatically. And finally ... Every WebWay Nano is ready for the future. Not only does the Nano have the same fast processor and large memory as our Pro and Mini platforms, Nano can also be upgraded to Wi-Fi/3G dual path signalling. In the second half of 2015 we'll release a Wi-FI module for Pro, Mini and Nano devices. Configurable via WebWay World, plug on or extendable antenna options.

If you have been in data communications as long as I have you will know that remote diagnostics and maintenance are nothing new. I remember back in 1992 watching in awe as our technical director (Phil Meredith) was stood next to some ISDN Back-up kit hooked up to a monitor running a windows application. On the screen, a cursor flicked over the menus and it was obvious somehow the system was being configured. “How are you doing that Phil?” I asked. “I’m not, its one of the support guys in Germany”. A more extreme example of remote maintenance occurred on the 19th December 2014. BBC news reported that International Space Station Commander Barry Wilmore was in need of a ratchet socket wrench. “Made in Space” is the company who supplied a 3D printer that is installed in the ISS. They heard about this and set about drawing up a solution on their CAD machine. They emailed the drawings up to the ISS and Commander Wilmore duly printed out a useable wrench! Upload; Download. A phrase that is used in our industry to describe the remote connectivity and programming of an alarm panel; comprised of a remote signalling device connected to a data network and software loaded onto the users PC that manages the panel configuration. All sounds pretty simple but more complex in communication terms, especially when using low bandwidth data networks such as dial-up PSTN or 2G/GPRS. Indeed its not just the communications networks that are the problem. For the designer of a signalling device there are many challenges, especially where hardware is concerned. The vast majority of installed panels have a PSTN dialler capability and this has been seized as an opportunity to use what is commonly termed “Dialler or Modem Capture”. In this method the communicator will have an interface that emulates a telephone line, presenting dial tone and line voltage. The panel modem “thinks” it is connected to a telephone line. The interface will “capture” any transmission from the panels modem and convert it to a digital signal and transmit over the alternate network. This is usually an IP connection over radio or Broadband. Whilst quite “neat” it is a technique that is suited to older panels that do not support a data interface. However there are a number of problems to overcome when designing a dial capture interface. Alarms & UDL Combined Panels that utilise a PSTN modem for communication cannot transmit alarms whilst a UDL connection is in session. So there needs to be a mechanism where the panel will “tear down” the UDL session if there is an alarm to transmit. This will take time and may add a delay in transmission time that puts the solution outside the ATS delivery requirements. Transmission time Modems have to “train” with their counterpart modem at the far end of the connection in order to transmit data. This can take a number of seconds and there is an inherent delay before the SPT has processed the alarm through the DCM mechanism and prepared it for transmission. This time delay could also fall outside of the permissible alarm transmission times associated with high-end security ATS requirements. Alarm Acknowledgement The panel has an alarm to send. It dials via its modem and the SPT picks up the alarm through the Dial Capture mechanism. The SPT will even acknowledge that it has the alarm, so as far as the panel is concerned alarm delivery has been successful. However the alarm is still with the SPT. What if the SPT cannot send the alarm because one or more of its circuits are down? How does the SPT tell the panel that the alarm has not gone anywhere? In ATS terms, if all routes to the ARC are down, they should know about it when the reporting time has been reached. You can use clever mechanisms like removing dial tone or line voltage from the DCM, but how quickly should this be actioned by the SPT and how should it report to the panel? Technology Modem design has evolved over many years and is generally handled in “soft modems” these days. Indeed the hardware components are becoming increasingly scarce and in danger of obsolescence, which in turn increases the cost of manufacture. The range of protocols both standard and bespoke in modem communication design is vast. The Dial Capture Interface has to mimic a “local exchange” and support a compatible “receiving” capability. The sending of alarms is not too difficult to achieve but UDL is a completely different matter. If you end up with an incompatibility between the sending and receiving modem, the solution simply won’t work. Over the years Alarm Panel manufacturers have developed their own transmission protocols in order to provide security and an ability to communicate with their own maintenance software. This means when transmitting data in a UDL session the developer will need to have obtained, understood and enabled the communicator to identify these different protocols in order to utilise them. This is not a simple exercise. The real difficulty is coping with all these variants, because if you want a truly generic modem capture that covers all panels then your communicator will have to accommodate a vast library of protocols. This requires memory, and lots of it, as well as processing speed. If you don’t have these in your SPT, then you will end up producing individual comms devices for individual panel manufacturers. Serial Data Connection A Serial data interface to the panel is my preffered solution. However the designer of the communicator must include a number of hardware interfaces (the most common being; RS485, RS232 and TTL a derivative of RS232) as well as understanding the individual panel protocols. One would expect the speed to increase in a UDL session but this is not always the case. Where panels have changed little in their communication techniques over the years we find data buses that still run at archaic speeds. For example our SPT will run up to 115k in the serial bus, but invariably the panel bus is as slow as 9600. It is worth noting that some panels suffer from the same inability (as PSTN) to transmit alarms when a UDL session is running when connected to the serial data bus and it is advisable to check whether this is the case. Once the integration with a panel is complete one may expect that’s “job done”, onto the next. But that is not the case. Collaboration with the panel manufacturer at the development level is crucial. If either party updates the production software of their device there should be a period when the solutions are tested before release. In reality there are many instances where this may not happen and incompatibilities creep in. Managing these is complex and the development team has to be right on the button to deal with any problems, quickly. From my point of view, being able to support both Dial Capture and a Serial bus connectivity should be standard for any SPT. Wherever possible the Serial connection to the panel has to be favoured over dial capture as it is more elegant but less complex and overall more reliable for our critical data applications. Dial Capture will not go away anytime soon but it could be argued that if the panel only supports PSTN, then it may well not be compliant and needs replacing anyway.

Are you asking me about the Honeywell? If yes then the following applies: GD - Connect to Bus 1 (must be bus 1), using A, B terminals on SPT and the corresponding on the Galaxy. Comms Mod 4 in menu 56, emulating an Ethernet module at SIA III. Set your trigger events - make sure set/unset (option10) is turned on and same applies for Zone restores (option 18). Make sure in Alarm reporting you have one gateway address entered (can be anything, loopback address of 127.0.0.1 will do) and an Account Number. As long as the Galaxy has something in these then you will be fine. Remote Access should be turned on with access at anytime. With the G2 (yes we support UDL), you wire & programme the same but there is a quirk in that the G2 has an option for Hardware Priority, this needs to be set for an Ethernet module. Programming guides can be found on our website and I am sure I loaded as download here at some point. For RSS connectivity you will need our Remote Manager S/W, PM me and I'll sort that out Monday. Any problems, get in touch. If you comment was not for me....ignore all that. JC

Buster has raised a query in respect of a particular site and I have carried out some investigations this morning which I hope he does not mind I share with you. The device is configured for a Grade 3 reporting time. The decision process that marks a path "bad" can take up to 5 hours to determine that a path has failed. The recovery process is initiated by the successful delivery of recovery polls, and in a Grade 3 deployment these polls can be sometime apart. The recovery process can be speeded up by restarting the SPT which will initiate a recommission of the device. I suspect that this was the case on Christmas Eve. Why? First here is a snapshot of the radio status this morning from the SPT. You will see that the signal is poor indicated at "2" (on a scale of 1 to 10), and whilst the device has a 3G capability the device is using the 2G network. I suspect that either 3G is down or not available on this cell. 10:06:41 GSM SIM Status: Waiting Roaming SIM - Auto Reg. Status: Roaming Signal Level: 2 Cell Technology: 2G Frequency Band: 0 1: 23410 = "O2 - UK" - Available (GSM) 2: 23415 = "vodafone UK" - Current (GSM) 3: 23430 = "EE" - Available (GSM) 4: 23433 = "EE" - Available (GSM) 5: 23420 = "" - Available (GSM) ------------------------------------ Looking at the history over the past two weeks, the signal quality has been especially poor. Whilst signal is not significant in a 3G environment, it is in 2G operation. You can see that the signal has never been above 3 during this period and both data and GSM registration has been lost on occasion. Recommendations in a situation like this:- Single path radio does not appear suitable at this location, even with the longer reporting time of G3 An alternate path would be desirable (Broadband primary or PSTN backup) Antenna placement - HG antenna with external installation In reference to the Texecom, the protocol requires the SPT to inform the panel of a loss of all communication. The SPT has completed this function correctly in this instance. I expect this will continue as long as the signal quality remains poor, the likelihood is that further disruptions in signalling are likely. Kevin (Belfast) - Looking at your sites, they are all Grade 2; so this would certainly explain the longer recovery times and a reboot would have the same effect as I mention above.