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:
Fwd: RE: Ocelot problem
Mark Gilmore
Thu, 22 Jan 2004 08:27:13 -0800
Thu, 22 Jan 2004 08:27:13 -0800
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
.