Subject: From: Date:

Re: [ecs] Re: [WARNING - VIRUS SCANNED] [ecs] NOT RECOMMENDED devices by Applied Digital Dan Carrington Thu, 27 Sep 2007 19:17:06 -0700

---

Just a check on what I have done.  I used to have lots or problems with 
my Ocelots.  I found a few fixes.  First, I used sheilded twisted pair 
for the data lines, wire in a daisychain, put the Ocelot at one end, & 
put a 120hom or 150ohm terminator on the last module opposite the 
Ocelot.  Also, some SECU modules ship with a different firmware 
selection.  You need to look at the C-Max parameter under "Module 
Utilities" and check the modules parameter 4.  It should be set to 0.  
Some ship with it not set  to 0.  Reset it to 0, and power cycle the 
set.  I also put a check logic on the analog inputs where another item 
is set to the analog input's value unless it is 0.  Then I watch the 
other item.  Otherwise, I have had very good luck with the units.  I use 
8 modules on the Ocelot and X10.  But I am still using the old version 
of ECS, if that has changed the problems with the Ocelot.

dan




Mark Gilmore wrote:

> Hi Bill,
> A detailed description of these problems follows.
> I have sent this info to Applied Digital 3-4 times during the past few 
> years (the latest being a around a week ago).
> They have never conveyed a significant interest in addressing them.
> Regards,
> Mark
>
>
> Ocelot problem #1:
>         NOTE: THIS problem IS CRITICAL, as it will cause the host 
> software (e.g. ECS, HomeSeer, etc)
>         to interpret the inserted FF as the 1st byte of the I/O-data 
> array.
>         Hence, the entire array will be skewed and *every* digital 
> input state will be corrupted.
>         If these inputs are used for security, numerous/erroneous 
> alarm conditions could/will result.
>
>         The problem scenario is as follows:
>
>         Note: During init, host pgm (ECS) issues a WT_CPUXA_PARAM_DATA 
> cmd,
>         which tells the Ocelot to report I/O changes (via FF byte).
>
>         1) Ocelot detects an I/O change on a digital-input and sends 
> FF to ECS to denote same.
>
>         2) ECS issues a GET_LATCHED_IO cmd to read the updated inputs.
>
>         3) Ocelot sends cmd ack (6/0/6) with I/O data *to follow*.
>
>         4) At this precise time, the Ocelot *asynchronously* detects 
> another I/O change and sends FF to ECS.
>
>         5) Ocelot sends the requested I/O data.
>
>         Now the host software cannot determine whether this "inserted" 
> FF is to
>         be interpreted as I/O data or an I/O-change report byte.
>         It *could* check the remaining # of bytes of the serial FIFO 
> and assume
>         an I/O-report byte if the total is 1 greater than the data 
> response.
>         But what if additional async data (such as X10 data) followed ?
>         Not pretty.
>
>         This problem could be corrected by blocking the transmission 
> of the FF
>         until the *complete* response to any given cmd is transmitted.
>
> Ocelot problem #2:
>         Ocelot occasionally sends a triad of 3 zero bytes (which have 
> no meaning per the protocol spec).
>         Example packets (both lead with the 00 00 00 triad):
>                 00 00 00  fc 9d 00  fc 9d 00 (00 00 00, followed by 2 
> transmissions of my TV-Volume IR signal)
>                 00 00 00  fb 01 01  fb 01 12 (00 00 00, followed by 2 
> A/DIM X10 transmissions)
>
>         As I generally send the volume signal numerous times and X10 
> DIMs are also frequently sent numerous times,
>         I strongly suspect that this problem is related to the 
> *multiple* transmission of IR signals and X10 cmds.
>         Perhaps the 00 00 00 was intended to be one of these, but was 
> zeroed out somehow ?
>
>         This problem is not of the same priority/importance as #1 (as 
> it will not trigger any significantly harmful results).
>         However, the fact that bytes are being zeroed-out could be 
> indicative of a more serious (internal) problem.
>
> Ocelot problem #3:
>         Ocelot occasionally reports a 0 for some analog-inputs:
>         Incorrect (0) response (see val in asterisks):
>                 Get SECU ani data
>                 8/04 07:29:45 TX: 2a 00 00 8b b4 00 a4 78
>                 8/04 07:29:45 RX: 2a 00 00 8b b4 00 29 00 27 00 fd 00 
> fd 00 *00* 00 ff ff ff
>         Correct (36/x24) response:
>                 Get SECU ani data
>                 8/04 07:30:46 TX: 2a 00 00 8b b4 00 a4 78
>                 8/04 07:30:46 RX: 2a 00 00 8b b4 00 29 00 27 00 fd 00 
> fd 00 *24* 00 ff ff ff
>
> At 08:47 PM 9/26/2007, you wrote:
>
>> I noticed that the following supported devices on the ECS home page 
>> are annotated "not recommended due to a bug in module's firmware".  
>> Does anyone know the background on this bug? I was under the 
>> impression that some of the ECS users were using these devices. Here 
>> is the excerpt from the ECS home page:
>>
>>
>> <http://www.appdig.com/adicon_new/bobcat.htm>BobCat (ADICON, not 
>> recommended due to a bug in module's firmware) / 
>> <http://www.appdig.com/>Applied Digital
>> " <http://www.appdig.com/adicon_new/secu16.htm>SECU-16 (ADICON, not 
>> recommended due to a bug in module's firmware) / 
>> <http://www.appdig.com/>Applied Digital
>> " <http://www.appdig.com/adicon_new/secu16i.htm>SECU-16I (ADICON, not 
>> recommended due to a bug in module's firmware) / 
>> <http://www.appdig.com/>Applied Digital
>>
>> Best regards,
>> Bill
>>
>>
>> Take the Internet to Go: Yahoo!Go puts the 
>> <http://us.rd.yahoo.com/evt=48253/*http://mobile.yahoo.com/go?refer=1GNXIC>Internet

>> in your pocket: mail, news, photos & more.
>
>
> Mark Gilmore
> http://OmnipotenceSoftware.com
>
>

---