Elk KPNAV Synchronise does not work?
- Thread starter Mp333
- Start date
BraveSirRobbin
Moderator
Do you have the latest firmware for your Elk and that Navigator?
Mp333
Active Member
BraveSirRobbin
Moderator
What about the M1?
BraveSirRobbin
Moderator
Man, I really don't know what to tell you, other than look for the simple things, address conflicts, terminations settings wrong on the data bus, keypad properly registered via Elk RP.
Hmmm, speaking of which, r u sure this isn't conflicting with any other keypad's address?
Hmmm, speaking of which, r u sure this isn't conflicting with any other keypad's address?
Mp333 said:
That version of M1 doesn't support the M1KPNAV syncronize function. Take a look at the M1KPNAV installation manual.
NOTE: M1 firmware v5.2.8 or later is required in
order for Navigator to synchronize and display the
names of Areas, F Keys, Lights, Outputs, and Tasks.
ElkRP software v2.0.10 is recommended when
programming a M1 system that includes a Navigator.
I wouldn't be surprised if 5.2.8 is listed by now.
As far as whether or not it makes a difference, that is subjective and also determined by who is assuming liability...ie: an insurer that deems as loss is due, in part, to be a fault of the M1 that was determined to be caused by non-UL firmware or settings in the programming, well, that's when it makes a difference. Whether or not you or an insurer is concerned with the level of compliance (or lack of) and if it would be looked into varies. YMMV.
In my case, I've had systems and buildings compromised for whatever reason and the insurer, consultant, investigator, underwriter or what have you, desired documentation and proof and then forensically examined the installation, even in 1 case, so far as to load the panel into a bench panel to see if there was faults or errors in programming. While this is few and far between, the losses were well into 6 digits for personal property and almost 8 digits for the loss as a whole.
As far as whether or not it makes a difference, that is subjective and also determined by who is assuming liability...ie: an insurer that deems as loss is due, in part, to be a fault of the M1 that was determined to be caused by non-UL firmware or settings in the programming, well, that's when it makes a difference. Whether or not you or an insurer is concerned with the level of compliance (or lack of) and if it would be looked into varies. YMMV.
In my case, I've had systems and buildings compromised for whatever reason and the insurer, consultant, investigator, underwriter or what have you, desired documentation and proof and then forensically examined the installation, even in 1 case, so far as to load the panel into a bench panel to see if there was faults or errors in programming. While this is few and far between, the losses were well into 6 digits for personal property and almost 8 digits for the loss as a whole.
Firmware is always an as-is, where-is item. UL certification is a process and they most likely aren't going to submit the firmware to UL to be certified every time a fix or bug is addressed or a feature added...it costs money. All the UL listing for firmware means is that it has been tested with the hardware and performs as intended and within spec. Non-UL firmware may perform, but it has not been submitted for approval or testing that proves such.
What firmware, devices and settings you choose is your perogative, but moving from industry standards is a tough call. Also, there's a difference between a standard install and a UL certificated/underwritten install, which is far to much of a discussion to get into.
What firmware, devices and settings you choose is your perogative, but moving from industry standards is a tough call. Also, there's a difference between a standard install and a UL certificated/underwritten install, which is far to much of a discussion to get into.
BraveSirRobbin
Moderator
Not sure...thought we determined that wasn't the sync problem's cause anyways?
Similar threads
