RE: Your Opinions please

["Kevin Hawkins" <lists@xxxxxxx>]

Just a comment here...

xAP ( and therefore xPL ) were both created as a way of controlling
and exchanging information between disparate devices typically found in a
Home automation scenario. A sort of glue that holds everything together. In
order to make this as easy (and understandable) as possible we used human
readable messages, and ensured every device could hear every other device.
This has a huge benefit in naming and displaying values - for example 50%
shows as 50% not say x80 and a volume control shows as 'Volume'. We used
English text as our common denominator such that messages became non
proprietary and were not encoded. This also means that configuration and
linking one device to another becomes very understandable to the end user.
However English is not compact or efficient space wise. We could
have called xap-header x-h or target t but it would have detracted from the
readability. Certainly when used on slow links (300 baud say) xAP - and xPL
would be the wrong choice for the message size reason and the fact that
they
are broadcast protocols in nature. True, xPL messages are a little smaller
but they do not provide the orders of magnitude changes that would make the
protocol suitable for slower links. In these applications only bit stuffed,
encoded and proprietary protocols cut the mustard. This is essentially what
most 'efficient' protocols choose to do and why we have the very problem
that xAP is there to solve as it creates the scenario where no device can
talk to another manufacturers without having specific support being coded
in. :-(
I think it's fair to say that xAP therefore does require an overhead
in message size that pushes it's need up the scale for a standard serial
link - certainly if the link provides your whole network and therefore
broadcast data is on the same wire. Typically a xAP router / bridge may
restrict broadcast traffic though and low power devices may be implemented
to handle minimal data traffic. Off the top of my head I am guessing 2400
or
possibly 9600 would be advised.
However speed on interconnects is ever increasing - not because
RS232 is improving but because different transports are becoming
commonplace
at attractive costs, wired Ethernet or radio based 802.11 as an example.
xAP
is network agnostic and can be implemented on any physical layer. In a HA
environment lots of usage will probably be made of Ethernet and as a packet
size of some 1500 bytes is incurred then both xAP and xPL sit really nicely
here. One of the beauties of a xAP message is that it can transfer any form
of data that a device might provide like text or - even pictures - however
it is by no means suitable or intended as a streaming protocol for large
bandwidth data . It is a control/status mechanism in intent but supports
text information nicely - as in the various weather, news, callerID and On
screen display applications.

Kevin


PS	This is not the forum for a xAP vs xPL debate but I do just need to
pick up on the (factually incorrect) comment you made John that xAP does
not
support Targeting of messages . xAP introduced this (v1.2) before xPL ever
existed and the way that targeting and broadcast works within both xPL and
xAP is essentially the same. xAP has an added level of wildcard based
filtering on long address hierarchies that xPL has chosen to simplify to
reduce address lengths. xPL is fundamentally broadcast as is xAP - it needs
to be to support the 'boardroom' type analogy where everyone can hear
everyone else although typically conversations can also happen between
individuals.
True however is that xPL identifies it's message intent within the
first few bytes, whereas within xAP you have to wait for the class header
arriving a few bytes later. However no other message can overlap so your
parsing routine still has to run to watch for new messages, any time saving
is minimal.


> -----Original Message-----
> From: John B [mailto:home-automation@xxxxxxx]
> Sent: 02 September 2003 09:29
> To: ukha_d@xxxxxxx
> Subject: RE: [ukha_d] Your Opinions please
>
> Hi Dave,
>
> > Excuse me for being a bit cynical, but 160 bytes just to switch
on a
> light
> > is a bit heavy going. Having not really looked at xAP in too much
> detail,
> > mainly because I am working on my own CAN bus based system, I
find it
> hard
> > to believe it takes so many bytes. With my protocol I use a
single 29
> bit
> > identifier for the sender, receiver and ID with 2 bytes in the
> message to
> > indicate what to do with the output. Same for the reply.
>
> This is one of the main reasons why the xPL protocol was created.  xPL
> offers similar functionality to XAP (and a few things that XAP doesn't
> support fully, such as targetted messages) and does so using a much
> smaller message footprint.
>
> In your example of turning on an X10 device, an xPL message to do this
> would require roughly 86 bytes.
> Whilst this is still far from being the most efficient protocol in the
> world, it is approximately half the size of it's XAP counterpart.
>
> > My main reason for asking is how you accommodate such a large
> telegram with
> > small microcontrollers? Some of the devices I use only have 2K
bytes
> of
> > programme space. Maybe Ian Bird could enlighten me to how he has
been
> > getting on with this?
>
> Ian Lowe has been doing some embedded xPL development, and many of the
> features of the xPL spec were specifically aimed at making it easier
to
> write xPL-enabled embedded software.
>
> For example, if your device is only interested in command messages
(and
> is therefore not interested in status or trigger messages) it only
> needs to read the first 5 bytes of the xPL message to determine
whether
> to discard it or continue processing it.
>
> In contrast, each XAP message begins with "xap-header",
which doesn't
> tell you anything about the message, and IMO is a waste of 10 bytes
> which could have been put to a better use.
>
> > Maybe I should look at it again and see if I can come up with a
xAP
> to CAN
> > bus gateway as this would allow me to use some of the excellent
> hardware you
> > guys have been building/creating. In fact I tried to find the xAP
> website on
> > sourceforge just now but it was not there... Has this been moved
> elsewhere?
>
> If you are interested in seeing what xPL has to offer, check out the
> official project site at http://www.xplproject.org.uk/
> There is also the UKHA_XPL discussion group on Yahoo.
>
> Both XAP and xPL are excellent initiatives which have the potential to
> vastly improve integration in the home automation world, and both
> protocols have their strengths and weaknesses.
> The best advice is to look at both protocols and decide for yourself
> which one best fits your needs.
>
> Regards,
>
> John
>
>
> ** UKHA2004 BE THERE! ** - start planning now.
>
> http://www.automatedhome.co.uk
> Post message: ukha_d@xxxxxxx
> Subscribe:  ukha_d-subscribe@xxxxxxx
> Unsubscribe:  ukha_d-unsubscribe@xxxxxxx
> List owner:  ukha_d-owner@xxxxxxx
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/