Subject: From: Date:

Re: [WARNING - VIRUS SCANNED] [ecs] NOT RECOMMENDED devices by Applied Digital Mark Gilmore Thu, 27 Sep 2007 07:43:45 -0400

---

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

---