An Acknowledge Delay will occur after an antenna cut or loss of communication with the network. An Acknowledge delay occurs when a Packet Acknowledge (P_ACK) is not received for a transmitted Data Packet within the programmed Acknowledge Delay time. (Default Ack Delay Time for the fire subscriber unit is 60 seconds). An Acknowledge delay occurs when a Packet Acknowledge is not received for a transmitted Data Packet within the programmed Acknowledge Delay time.
What it boils down to is either your signal strength is weak (NetCom 6 or higher) or your signal acknowledgements are taking a few seconds to come back. Yes, that can happen even if you have a NetCom of 5. The majority of the ACK Delays generated on the network I help maintain occur because of delayed acknowledgements not NetCom or 6 higher issues.
Some of you might be asking yourselves so what if I have acknowledgement delays my signals report on time in less than a minute and I passed my fire inspection WHO CARES? Well the problem is now that jurisdictions are requiring local notifications of radio faults. The 2016 fire code focuses more on local notifications of radio issues including antenna cuts ac fails acknowledgement delays and other hardware issues.
Aes radios have a J4 Relay the main board that you can set up for normally open or normally close.
ACK DELAY SOLUTIONS
According to AES:
Look for trouble with the antenna or its location, coax, connectors, transceiver, radio or electrical Interference or with the electronics itself. Maybe the subscriber is just to far away
From other devices in the network. The problem could also be with the other Subscribers or receiver it is attempting to communicate with.
That is too vague of an answer. The solutions I have come up with usually work.
(This is our problem on our network usually.) The subscriber can be directly talking to an IP LINK instead of other radio units around it. I know it makes sense that you would want a radio to talk directly to the data node but the problem is data nodes are always busy and can delay signal confirmation. We have some units with remote antennas that jump 20 miles to talk to a repeater on a building 70 stories in the air vs AES units or repeaters closer to its location. A stronger antenna is not always better. To find out if this is happening to you use the NMS Google Earth to view the paths. Right click on a path and it will tell you how far it travels. You can also check the paths using the Linux interface they have for the AES receiver.
NMS example of ack delay accounts
Sometimes or most of the time techs will install the rubber ducky antennas and tighten the washers by hand. The problem with that is the washer does not dig into the can and create good enough grounding. This can cause signal strength issues, NetCom, and ACK Delays.
The AES install manual for 7788 units instructs techs to ground the radio using the Green nut on the right middle side of the radio. That goes to earth ground. I’ve been told by techs on site it has improved their signal strength.
Sometimes ACK Delays are caused when your radio is NetCon 6 or higher. If you have a handheld programmer hit shift + f4 at the same time to get the NetCon rating. It should be at NetCon 5 all the time. If not check the rubber ducky install or battery and or install a remote antenna.
I have noticed that some ACK Delays occur when a radio starts repeating too many signals. It is normal for some Subscribers to repeat RF packets originating from other Subscribers, to convey those packets along their route toward an IP Link. However, excessive packet repetition by a single Subscriber may reduce network efficiency and cause delays. I have witnessed units 5 to 15 miles away talking to specific radios and ignoring many radios around the immediate area. Check in your NMS software for the TOP REPEATERS section.
Sometimes radios are programmed incorrectly and the test interval is off. Each Subscriber normally transmits Check-in messages at regular, pre-set intervals. AES recommends setting the Subscriber Check-in interval to 23:45. A shorter time interval increases RF traffic in the network. When a radio checks in it submits a bunch of data. Once a day is fine but multiple times an hour is a no no.
I think I covered everything that can cause an ACK Delay but if I missed something leave a comment. If this helps, leave a comment.
A man wakes up in the middle of nowhere. He has no money, he doesn’t know where he is and there is absolutely nothing around him, except for a small diner. The man walks towards the diner, where a sign reads “eat all you want, your grandchildren will pay”.
The man walks in, eats like there is no tomorrow and, when he is done, a waitress walks up to him and gives him the bill. “Wait, I read the rules carefully.” says the man.”I know,” replies the waitress “this is your grandfather’s bill.”
A failed cell test basically means that the 7706 was defaulted to potter settings instead of AES potter settings. Yes there is a difference. If you have a 7706 defaulted to the potter settings it turns the radio into a regular 6006 potter fire panel. If you use the AES potter default then your 6006 potter unit can use the pic and send signals on the AES network.
This is how the raw data will look before the automation converts it.
Below is the detailed explanation from AES help desk:
Solution # 0690 – E/R358 001 received from 7706-ULF Account
Subscriber out of network
On at least on one occasion, this was reported due to a bad RJ/Modular cable between the PIC (Panel Interface Card 7764) and Potter panel.
A more common reason may be because the PIC is not properly learned. Be sure to load the AES “7706-ULF AES Default Config.fpcf” configuration file available as a download from the AES Web site especially if the panel was reset to factory or the default Potter 6006 configuration file from the Potter software was used.
An example message is:
13 4321 18 E358 24 C001
Where 13 is Receiver #1, Line card 3.
New Event Code E358
Group or partition 24
Zone or Contact 001
This will be reported with E370 00 C001 from the 7788F portion as well indicating a problem with the Potter Panel or PIC in this case.
You may have heard or read the phrase “Routing Table” when referring to a Subscriber. This solution explains what the Routing Table is and how it is generated.An AES IntelliNet Subscriber maintains a list of ID’s, up to eight for the purpose of passing its messages or data packets through, in route to the head end or Central Receiver. The list is generated by listening. Any transmission by any other device on the IntelliNet network at the same frequency and with the same Cipher code that is passed through the Transceiver and decoded by the Subscriber is evaluated. The Subscriber that hears the transmission will extract values contained in the header of the transmission detected.
The extracted information will include the ID of the device currently transmitting the packet along with its Link Layer / Level (LL), NetCon (NC) and Status or fault code. The signal strength of the transmission will also be evaluated. The signal strength evaluation includes whether the Carrier Detect level was reached (CD) and a value that identifies how readable the data was.Upon decoding a packet header, the extracted values are compared with the current list or Routing Table. If the ID is in the list and the values have not changed the Table is left as is.
If there was a change to a value of an ID in the list, the list is modified. If the ID is not in the list, then it is evaluated to determine if it should be in the list. That evaluation includes the signal strength, Status code and whether the LL is equal to or better than what is currently in the list. If the ID rates a place in the list, the list is modified, the Table is sorted and the Subscriber calculates new LL and NC values.
The important thing to take away from this lesson is that the Routing Table is built by listening. Attempts to communicate back to those ID’s in the list, does not occur until the Subscriber has a Data Packet to transmit and only then, if it progresses through the List of ID’s and reaches that ID in the process of using its Routing Table because others in the list before it have failed to have a packet Acknowledge received.
Back before UL revision 9 came out the NetCom values read 0 to 7. 0 being the best and 7 the worst. After the UL Revision 9 changes the NetCon values changed to 5 to 7. 5 is the best 7 is worst. A NetCom 5 is needed to pass a fire inspection. The detailed explanation is below.
A Subscriber developed before the UL 864 9th Edition Compliant models calculate NetCon differently than the later. Edition 9 compliant Subscribers begin at firmware version 2.6+. The firmware version features typically follows all models. If another model is released with a version 2.6+ or higher, it would include the basic Subscriber functions as any other at that version with specific model variations added as needed. Version 2.6+ was designed to operate in a MultiNet environment and still be able to use NetCon 5 to indicate at least two unique paths exist in the current Routing Table all the way to the MultiNet Receiver/7705i.Earlier firmware than 2.6 was developed around the Single RF head end receiver concept, where they would report their NetCon as 0 if the #1 ID in the Routing Table was reporting a Link Layer/Level (LL) of 0.
RF Head End devices such as the 7003, 7703 or a 7170 IP-Link, are the only devices that can report LL as 0. A pre-V 2.6 Subscriber would report itself as a NetCon of 0, because the ID at the top of the list is a LL 0. In other words, if the #1 ID in the list is the single Stand Alone Receiver, it reports NetCon as 0.A V 2.6+ or higher does not report a NetCon of 0 with a LL as 0 in the #1 position. This prevents the reporting of NetCon 0 when a single IP-Link is at the top of the list. Two IP-Links are required to establish a NetCon of 5. Two IP-Links would in fact constitute two unique paths all the way to the 7705i. A third IP-Link would provide three unique paths, but NetCon would still be calculated as 5 adhering to the Edition 9 algorithm’s rules.
How can there be several IDs at the top preference locations in a Routing Table, which have a Good Signal Quality (SQ) and yet have a NetCon of 7? If NetCon is 7 and there are what appears to be Good SQ IDs at the top of the list, then there is something else that is preventing the Subscriber from considering the ID as Good.It may be that the NetCon of the #1 listed ID has itself got a NetCon of 7. A Subscriber can’t be better than the best (#1) ID listed in its routing table. It may be that there are some faults being reported by the ID, which are not displayed in the information presented to you.Signal Quality is only one factor in determining if a listed ID is “good” to decrement NetCon.
The list of what is considered good:
Signal above a threshold. (SQ=Good) No Faults reported. (i.e. low battery, AC fail) Link Layer better than current LL of this Subscriber. NetCon is less than 7
I have 6 years experience troubleshooting and programming AES radios and just want so share some information with you guys. This will cover radio model numbers 7788/7744 , 7706 and 7058. Explaining how NetCon works does get detailed so I broke it up into 8 parts. Make sure to scroll all the way to the bottom of this page to see the rest of the parts.
Following is a general explanation of how NetCon is calculated by an AES UL 864, Edition 9 compliant model Subscriber (7744F or 7788F).
Look at your routing table. What is the Level/Link Layer (LL) of the #1 ID in the list? Is its Signal Quality (SQ) = Good? How many IDs are in the list at the same LL as #1 with a Good SQ? Subtract that number from 7. That should be the NetCon based on that routing table. On Edition 9 compliant units, NetCon will not be lower than 5 even if there are three units at the same Level that are good.Generally, if the SQ is not good, then it is quite possible that the Level was incremented by 1 for the purpose of sorting lower in the list. Sorting is primarily done on the LL. If there are no Good SQ or all IDs have faults, then the NetCon will be 7.
With one ID at LL 1 and SQ = Good the Subscribers LL should be 2 with a NetCon of 6.With two IDs LL 1 and SQ = Good the Subscribers LL should be 2 with a NetCon of 5.With one IP-Link ID at LL 0 and SQ = Good and another IP-Link ID at LL 0 or 1 with SQ = Marginal the Subscribers LL should be 1 with a NetCon of 6.
With two IP-Link IDs at LL 0 and SQ = Good the Subscribers LL should be 1 with a NetCon of 5.
7788F/7744F Rev 1.64Z5 also considers other ID’s in a table listed at a higher Level if it’s NetCon