Subject: From: Date:

Re: [WARNING - VIRUS SCANNED] Re: [ecs] [ecs] NOT RECOMMENDED devices by Applied Digital Mark Gilmore Thu, 27 Sep 2007 16:02:36 -0400

---

signals can also be learned by the stargate and homevision.
but the ocelot is *much* cheaper and it works great.
so i still highly recommend it for IR, X10, and relays.

At 03:51 PM 9/27/2007, you wrote:
>I was not aware of the IR issue, I did not remember seeing it 
>mentioned in the ECS documentation...could have missed it. As far as 
>I remember from the ECS documentation, the Ocelot is the only 
>interface that support ECS learning and saving the signals instead 
>of the hardware device performing this function, like the Homevision.
>
>  I was considering investing in some Applied Digital hardware for 
> my system, but their lack of response on these bugs is a deal 
> breaker. Plenty of other options for analog and digital I/O with ECS.
>Thanks for the detailed follow-up.
>Bill
>
>Mark Gilmore <mark3@OmnipotenceSoftware.com> 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:
> >
> >
> >BobCat (ADICON, not
> >recommended due to a bug in module's firmware) /
> >Applied Digital
> >" SECU-16 (ADICON, not
> >recommended due to a bug in module's firmware) /
> >Applied Digital
> >" SECU-16I (ADICON,
> >not recommended due to a bug in module's firmware) /
> >Applied Digital
> >
> >Best regards,
> >Bill
> >
> >
> >Take the Internet to Go: Yahoo!Go puts the
> >Internet
> >in your pocket: mail, news, photos & more.
>
>Mark Gilmore
>http://OmnipotenceSoftware.com
>
>
>
>Luggage? GPS? Comic books?
>Check out fitting 
><http://us.rd.yahoo.com/evt=48249/*http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz>gifts

>for grads at Yahoo! Search.

Mark Gilmore
http://OmnipotenceSoftware.com

---