Does your Elk M1 have 1367 control restarts in the event log?

sda said:
Arm the system, momentarily short vaux to ground, see what happens.   I know (from experience) that the control will restart.
Click to expand...
 
I'm not comfortable with shorting a power supply directly to ground on a $400 control board. The circuit is most likely protected but I still don't like that idea.
 
Mike.
 
I just rolled my firmware back from 5.3 to 5.2.10 on Elk tech support's advise in response to the control restart. They must be aware of a problem and I'm hopeful.
 
Mike.
 
mikefamig said:
I searched around here and found that version 5.3 firmware caused a lot of systems to have automatic restarts when it was first released. Here is one of the links that I found
 
http://cocoontech.com/forums/topic/26656-bugs-with-530-firmware/
 
DEL I think that you're losing your memory like me, you were involved in the above link.
 
Mike.
Click to expand...
I start blocking it out.
 
Too many sites and too many things going on at the same time. I'm in the middle of getting ready to upgrade a big hospital site (same as a certain school in New Haven) from a Virtual and 2 mirrored physical boxes to a triple redundant VM SAS based system.....balancing too many FW variables and software revisions on top of integrated alarm handling/receivers and integrated VMS platform for about 1K cameras (6-800 IP units alone, less encoders).
 
I've been running the latest version FW since around the holidays with no issues. Maybe you have a bad .BIN image? Was it downloaded within the last month or so?
 
DELInstallations said:
I start blocking it out.
 
Too many sites and too many things going on at the same time. I'm in the middle of getting ready to upgrade a big hospital site (same as a certain school in New Haven) from a Virtual and 2 mirrored physical boxes to a triple redundant VM SAS based system.....balancing too many FW variables and software revisions on top of integrated alarm handling/receivers and integrated VMS platform for about 1K cameras (6-800 IP units alone, less encoders).
 
I've been running the latest version FW since around the holidays with no issues. Maybe you have a bad .BIN image? Was it downloaded within the last month or so?
Click to expand...
 
I hear ya, there's only so much stuff that you can fit in one head and then something has to go to make room. In with the new new, out with the old.
 
Mike.
 
DELInstallations said:
I start blocking it out.
 
Too many sites and too many things going on at the same time. I'm in the middle of getting ready to upgrade a big hospital site (same as a certain school in New Haven) from a Virtual and 2 mirrored physical boxes to a triple redundant VM SAS based system.....balancing too many FW variables and software revisions on top of integrated alarm handling/receivers and integrated VMS platform for about 1K cameras (6-800 IP units alone, less encoders).
 
I've been running the latest version FW since around the holidays with no issues. Maybe you have a bad .BIN image? Was it downloaded within the last month or so?
Click to expand...
To answer your question, my firmware version was from mid summer. I rolled back to 5.2.10 and will let it go for a while to see what happens.
 
Mike.
 
Same with me and I've been running for probably 2-3 weeks with zero stability issues on a pretty loaded system....GE RF, 2 212S', 5 KP's, a pair of XSP's, XEP, DBHR's, 4 expanders and a RB. Pretty loaded down.
 
Only difference I can tell you is I have a pretty early M1, all the way back to the old 1.6 versions of RP. Can't remember what it shipped with, probably a 3.X or earlier.
 
DELInstallations said:
Same with me and I've been running for probably 2-3 weeks with zero stability issues on a pretty loaded system....GE RF, 2 212S', 5 KP's, a pair of XSP's, XEP, DBHR's, 4 expanders and a RB. Pretty loaded down.
 
Only difference I can tell you is I have a pretty early M1, all the way back to the old 1.6 versions of RP. Can't remember what it shipped with, probably a 3.X or earlier.
Click to expand...
 
One difference here is that I have the m1xrftw which is affected by version 5.3 firmware changes. 
 
Mike.
 
Looking at the SPAR's there really isn't that much in the FW that applies to the RF2W and other than that, I would assume the bulk of the data is the same on the bus as I'm willing to wager the heavy lifting is performed by the transceiver. 
 
A lot more SPAR's on the previous FW.
 
DELInstallations said:
Looking at the SPAR's there really isn't that much in the FW that applies to the RF2W and other than that, I would assume the bulk of the data is the same on the bus as I'm willing to wager the heavy lifting is performed by the transceiver. 
 
A lot more SPAR's on the previous FW.
Click to expand...
I looked at the firmware 5.3 release notees and most of the changes have to do with the two way wireless, no?
 
 
April 14, 2014 - M1 Firmware 5.3.0   Evaluated and listed by UL ElkRP Software 2.0.20 or later is recommended with this firmware. This firmware supports ELK’s M1XRFTW Receiver and “Two Way Wireless” products.  Note: When installing a M1XRFTW Receiver it must be setup and enrolled at data bus address 2.  This is necessary for the two-way communications to function properly.  Redundant M1XRFTW receivers (if used) can only be addressed as 3, 4, or 5.

1. Added - Keypad will trouble beep upon RF transmitter low battery or lost transmitter.  UL requirement.
2. Added - M1 will not arm if any RF transmitter is missing.  UL requirement.
3. Added - M1 will speak relative transmission level (1 to 8) for Elk Two-Way wireless sensors during enrollment and during the WalkTest Area function.
4. Added - Pressing keypad “ * ” key can be used to silence local fire alarm sounder.  NOTE: Per UL requirement the sounder in a Elk-6050 Two-Way Smoke Detector may only be silenced by entering a valid User Code at the keypad, and only then if the smoke detector chamber is clear.
5. Fixed an issue that could potentially cause the VALID LED to remain on with M1XRFEG and M1XRF2H Receivers.
6. Added - RF Jam detection on the M1XRFTW.  This is enabled by Programming Menu 14 - Section 1, Option 5. Please Note the following specific operation when the RF Jam option is enabled. Keypad will chirp and display UL Jam if an attempt is made to jam the transmissions. The control will not permit arming if a missing RF Expander is detected. The keypad will start trouble beeping upon loss of any wireless transmitter. The dialer will immediately report zone troubles to the Central Station if a missing RF Expander is detected.
7. Added extended wireless diagnostic data through the RS-232 port (for factory use only) 8. Modem will produce carrier tone for dial-up remote programming session if ### is not detected after a timeout period.
 
Mike.
 
1. No
2. No
3. Yes
4. Yes
5. No
6. Yes
7. No
8. No.
 
The bulk is leaning more for UL changes and CP-01-2014 mandates.
 
ok, an older thread, yes, but this is where the info is.   It's fair to summarize that 1367 errors are due to - power fluctuations causing the system to reset?   Does the extended data refer to the component which is triggering the restart, or a subsystem which is restarting?   I was getting ready to do some coding and decided to look into the log, here's a snippet.
 

2 Tue 3/29/2016 04:00   1367 = SYSTEM START UP Input Exp. 11
3 Tue 3/29/2016 01:00 1 1381 = TRANSMITTER SUPERVISION LOSS Guest Room Door (Zn 26)
4 Tue 3/29/2016 00:00   1367 = SYSTEM START UP Input Exp. 11
5 Mon 3/28/2016 18:00 1 1174 = AREA DISARMED Jarett (User 4)
6 Mon 3/28/2016 17:07 1 1173 = AREA ARMED Jarett (User 4)
7 Mon 3/28/2016 12:00   1367 = SYSTEM START UP Input Exp. 11
8 Mon 3/28/2016 08:00   1367 = SYSTEM START UP Input Exp. 11
9 Sun 3/27/2016 17:16 1 1174 = AREA DISARMED Jarett (User 4)
10 Sun 3/27/2016 16:00   1367 = SYSTEM START UP Input Exp. 11
11 Sun 3/27/2016 13:15 1 1173 = AREA ARMED Jarett (User 4)
12 Sat 3/26/2016 20:00   1367 = SYSTEM START UP Input Exp. 11
 
 
 
 
and in the last month I've had blocks of these events at 4 hour intervals.   firmware is old, 5.3.20, Boot Version is 3.3.6 - but I am not eager to change these if 'everything is working'
 
When my system was restarting like that Elk support had me roll back firmware from 5.3 to 5.2.10 and it corrected the problem. I remember that it was the first iteration of 5.3 and it must have had bugs. There have been a couple of new releases of 5.3 since then but I am leaving well enough alone.
 
Mike.
 
You must log in or register to reply here.

Similar threads

StarTrekDoors
PC Access 3.17.0.843 Update Release Notes
Replies
0
Views
3K
StarTrekDoors
StarTrekDoors
B
1367=SYSTEM START UP Control - after adding expander board
2 3
Replies
36
Views
5K
blueman2
B
A
My M1 experience (long).
Replies
5
Views
2K
AnotherOne
A
Back
Top