ECS Home Automation and Security Archives
  learn more | view messages for this month | NetBloc® | terms of use | search

Google
 


  subject (prev) or (next) | time (prev) or (next) | author (prev) or (next) | view more subjects

Subject:
From:
Date:
Re: [ecs] Fwd: RE: Ocelot problem
mikehughes
Fri, 23 Jan 2004 12:52:40 -0500

I am trying to re-register my software but something appears to be wrong
with the email address.  I'm getting a message back that it was
undeliverable.  Is there a new email address that I should be using?
----- Original Message ----- 
From: "Mark Gilmore" <mark1@markgilmore.net>
To: <ecsl@netbloc.com>; <ecs@netbloc.com>
Sent: Thursday, January 22, 2004 11:27 AM
Subject: [ecs] Fwd: RE: Ocelot problem


> Hi everyone,
> If you are using an Ocelot with digital-input modules (SECU-16/SECU-16I),
> and have ever seen "suspicious" Digital-Input values, you need to be aware
of
> the following:
>
> >Date: Thu, 22 Jan 2004 08:21:33 -0800
> >To: "Reynolds,Martin" <martin.reynolds@gartner.com>
> >From: Mark Gilmore <mark1@markgilmore.net>
> >Subject: RE: Ocelot problem
> >Cc: adiinfo@appdig.com
> >
> >WOW - You have a good eye !
> >And now I think I know what's happening:
> >A lone FF denotes that an "I/O change has been detected".
> >My money says that this FF and the "extra" FF below are one in the same.
> >To speculate further: An Ocelot interrupt-service-routine is transmitting
this
> >byte without waiting for the completion of the packet currently being
> >transmitted.
> >It may not even be looking to see if a packet transmission is in progress
> >at all.
> >This looks like a very serious bug, as it corrupts all module states
> >reflected in the corrupted packet.
> >And you may be the first to find it, given your large number of modules.
> >I am forwarding this to Applied Digital.
> >Please follow up by telling them what modules you are using (and what rev
> >of the Ocelot).
> >
> >Here is a snapshot of the problem (for Applied Digital):
> >
> >GOOD response:
> >ExCmd:TX: c8 32 0 0 0 0 0 fa
> >ExCmd:RX:
> >InpSrv: 6 0 6 a6 0 9e 0 8f 0 a6 0 a2 0 ac 0 ab 0 af 0 5f 0 ff 0 ff 0 ab 0
> >b3 0 0
> >          0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> > 0 0 0 0
> >          0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> > 0 0 0 0
> >          0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> > 0 0 0 0
> >          0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> > 0 0 0 0
> >          0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> > 0 0 0 0
> >          0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> > 0 0 0 0
> >          0 0 0 0 0 0 0 0 0 0 0 0 0
> >
> >BAD response (FF inserted after 6 0 6):
> >ExCmd:TX: c8 32 0 0 0 0 0 fa
> >ExCmd:RX:
> >InpSrv: 6 0 6 ff a6 0 9e 0 8f 0 a6 0 a2 0 ac 0 ab 0 af 0 5f 0 ff 0 ff 0
ab
> >0 b3 0
> >          0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> > 0 0 0 0
> >          0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> > 0 0 0 0
> >          0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> > 0 0 0 0
> >          0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> > 0 0 0 0
> >          0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> > 0 0 0 0
> >          0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> > 0 0 0 0
> >          0 0 0 0 0 0 0 0 0 0 0 0 0
> >
> >
> >At 07:53 AM 1/22/2004 -0800, you wrote:
> >
> >>Agreed. I see now that there is an extra FF inserted into the stream,
> >>immediately after the 6-0-6 header (i.e. at byte 4). I'll start chasing
> >>ADI. It has to be either a firmware problem inside the Ocelot, or a
> >>communications link issue.
> >>
> >>Thanks for the help, the loggin on the Ocelot is really useful.
> >>
> >>-----Original Message-----
> >>From: Mark Gilmore [mailto:mark1@markgilmore.net]
> >>Sent: Thursday, January 22, 2004 7:37 AM
> >>To: Reynolds,Martin
> >>Subject: Re: Ocelot problem
> >>
> >>Hi Martin,
> >>I haven't taken the time to parse this packet, but if the "suspicious"
> >>devices work at all,
> >>then ECS is parsing the packets properly (and hence, the Ocelot is
> >>really reporting some as "Off").
> >>It's the same logic for all: If it works once, it works always.
> >>I think there is a failure or bug in the Ocelot or SECU-16.
> >>You might try removing all modules *but* the problematic SECU-16.
> >>If it then fails, the SECU-16 is the #1 suspect.
> >>If it then does *not* fail, then the Ocelot firmware is suspect (as it
> >>may be having problems servicing "too many" modules).
> >>
> >>
> >>---
> >>Incoming mail is certified Virus Free.
> >>Checked by AVG anti-virus system (http://www.grisoft.com).
> >>Version: 6.0.560 / Virus Database: 352 - Release Date: 1/8/2004
> >
> >Mark Gilmore
> >http://OmnipotenceSoftware.com
>
> Mark Gilmore
> http://OmnipotenceSoftware.com
>


----------------------------------------------------------------------------
----


>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.560 / Virus Database: 352 - Release Date: 1/8/2004
>



  subject (prev) or (next) | time (prev) or (next) | author (prev) or (next) | view more subjects




Services provided by [NetBloc]®! NetBloc Solutions Inc.
Terms of use. Indexing software (c) 1999 Lin-De, Inc
.