Re: Re: PIC testing WAS OSD ALERT

[Frank Mc Alinden]

Hi Steve
Thanks for the feedback....

>I think on the config side that it would be useful to be able to set
>the
>instance so that you have more than one unit running on the network.
>e.g.
>aec-sunroom.tv1 and aec-sunroom.tv2. Of course this could be set a
>the PIC
>programming stage but doesn't allow for later change.

I agree it would be better..maybe when i have more serial experience and
can try
it on PBP instead of ASM.....its a start......

>Also what do aec and sunroom stand for? This should be
>vendor-device.instance e.g. FRANK-TVOSD.TV1
AEC....Armagh Electrical Contractor.......Sunroom is the name of my
computer
room actually a small extension based on a Queensland Sunroom....
AEC is a Vendor name....


>I
>see no reason why a device can't specific that it expects the
>namepairs in
>a specific order as I see this as a operational point of the device
>rather
>than the protocol.

I hope so...give it the seal of approval before Ian looks at it
;-))))..only
kidding...


>hop= ignore for incoming the hub deals with hop counts - outgoing
>message

HOP= is part of my table....but i ignore the value unless it more than a
single
digit...
Source = IS also part of my table but i ignore the rest...

>On a more general note I believe that devices will general fall into
>two
>categories either fully xPL compliant supporting all options or with
>operate with the core values of the protocol but with a few bits on
>the
>edges not being supported. As long as the restriction are clearly
>stated
>in the documentation I see no problems

Thats the big plan ...but i think if you wait till you have a full blown
xPL
Device then it might never happen ....little apples grow big ;-)))

Thanks
Frank

----- Original Message -----
From: <a
href="/group/ukha_xpl/post?postID=ej3Sn8Px8CPWB9D_Gd2qA9S-2VAHLPBASj_moP0M2fAEA5uUGHm2wGLK6--L5YRQR_FLwXJjLVNtGoOv-QB6-lbF">steve.cooper@u...</a>
To: <a
href="/group/ukha_xpl/post?postID=ueFVIPjcLVjSy8zp-kzAABciZSrLghqVvp4Pik_omJI5YArTpQe4yIirLq_C7salwf4g7EG-FxBaYY34xdebyA">ukha_xpl@xxxxxxx</a>
Sent: Tuesday, December 09, 2003 10:51 PM
Subject: Re: [ukha_xpl] Re: PIC testing WAS OSD ALERT



> Can i just explain what i have and havent done and point me in the
> right direction...
> Things which are not being implemented are
> 1:osd.confirm and config
> 2: exclusive / release

I think on the config side that it would be useful to be able to set the
instance so that you have more than one unit running on the network. e.g.
aec-sunroom.tv1 and aec-sunroom.tv2. Of course this could be set a the PIC
programming stage but doesn't allow for later change.

Also what do aec and sunroom stand for? This should be
vendor-device.instance e.g. FRANK-TVOSD.TV1

> Currently the message defaults are
> Row = 5........expecting 1 to 11..greater than 11 = 11
> column = 1......expecting 1 to 27 ?must check not sure if greater
> delay = 20......expecting 1 to 99..greater than 99 = default
> 0 or 00 = timer disable..no time out

Looks good.

> Row ,Column or delay can be optional BUT if any included they must be
> in the proper order as im using a table and its ok to jump fwd but
> to keep jumping back and forth searching would be a pain to keep
> track ...is this ok?? (im using asm) ;-((

The xPL protocol doesn't specifically cater for the order in which the
namepair come so it's best not to rely on it. Having said that though I
see no reason why a device can't specific that it expects the namepairs in
a specific order as I see this as a operational point of the device rather
than the protocol.

> hop =*....??
> Source =.....ignore the rest
> Target =aec-sunroom.tv or target =*

hop= ignore for incoming the hub deals with hop counts - outgoing message
=1
Source = ..ignore for incoming messages aec-sunroom.tv for outgoing
Target = fine with above but you will need to state that the device only
support direct addressing or a full wildcard and not partial wildcards i.e.
aec-sunroom.*. Again I see this an acceptable device restriction.

On a more general note I believe that devices will general fall into two
categories either fully xPL compliant supporting all options or with
operate with the core values of the protocol but with a few bits on the
edges not being supported. As long as the restriction are clearly stated
in the documentation I see no problems.

> Need to incorporate heartbeat and a message timer time out...
> How does this sound ??

Good

S.




___________________________________________________________________________
The information contained in this message is confidential and may be
legally privileged. If you are not the intended recipient, please do not
read, copy or otherwise use it and do not disclose it to anyone else.
Please notify the sender of the delivery error and then delete the
message from your system.
Any views or opinions expressed in this email are those of the author only.
Communications will be monitored regularly to improve our service and for
security and regulatory purposes.
Thank you for your assistance.
___________________________________________________________________________