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.