Re: Proposal / RFC: Change xAP wire format

["Daniel Berenguer" <dberenguer@xxxxxxxxxxxx>]

Neil, I guess your desired master-slave architecture is for Home
Automation only. Even though, there are certainly some cases where you need
your embedded devices to not to behave as simple slave. But assuming you
want a master-slave protocol, why re-inventing the wheel? Atmegas, Pics,
MSP430's, are perfect platforms for implementing UART-based interfaces
(Modbus over RS485, CAN, LIN, USB, ...) or low-power RF. For a simple
slave, adding Ethernet would seem a bit overkilled (and overpriced) IMO.
Under this point of view, only your master might be xAP-enabled (so
Ethernet-enabled).


--- In xAP_developer@xxxxxxx, "Neil Wrightson" <neilw@...>
wrote:
>
> My two cents worth,
>
>
>
> 1.       Personally I think all embedded devices should be slaves.
That is,
> they are controlled by a separate master host controller (App on a
PC). They
> do not make decisions on their own. They only respond to packets
directly
> sent to them. Trying to listen to every incoming packet and compare
this
> against an action list uses a lot of resources. Then add a means of
editing
> this list from a remote location, takes up even more resources on the
> embedded device.
>
>
>
> 2.       In regard to embedded Ethernet devices, I have made quite a
few
> (AVR Mega32..XMega128) and they still struggle with the requirements
of the
> xAP message size overhead.
> A smaller version of the protocol would also be useful here.
> Could the two protocols exist on the same network but with say a
different
> port address (say 5000). I realise this opens another can of worms ie
we
> already have a port internationally assigned to us. Another thing
required
> would be an additional gateway app on a PC. Separate standalone app or
part
> of the xAP hub service. On this gateway, it reads all 3639 traffic and
only
> sends through packets destined for a device present in a manually
created IP
> lookup list, and/or created by the embedded heartbeat. Any packets 
received
> from port 5000 would be sent back to the main xAP port.
>
>
>
> 3.       In regard to the serial version, ie RS485. A similar thing
could
> happen to the above embedded Ethernet version. The xAP gateway would
filter
> based on a lookup list and only send packets to the RS485 devices with
a
> matching address.
>
>
>
> 4.       A similar thing could carry through to Wireless devices
(Something
> I plan on making in the near future)
>
>
>
> 5.       My issue is that, I'm good with embedded hardware and
firmware but
> have no idea where to start with making a new HUB or gateway with the
above
> modifications.
> I used to windows program in Delphi (Pascal) and have some knowledge
of C
> and basic but that's it. No idea on how to even compile an existing
xAP app.
>
>
>
> A sample command to an embedded device. Don't care what version, how
many
> hops, what class, where it came from. If you're sending it to me, you
should
> know what I am and capable of.
>
> {
> Dest=FF123400
> }
> {
> OP1=ON
> }
>
> {
> OP2=ON
> }
>
> #13         Always nice to have an end of message delimiter.
>
>
>
>
>
> The heartbeat and status could be similar, same for BSC.
>
>
>
> Regards,
>
> Neil Wrightson   (Australia).
>
>
>
>
>
> From: xAP_developer@xxxxxxx [mailto:xAP_developer@xxxxxxx]
> On Behalf Of Kevin Hawkins
> Sent: Thursday, 1 December 2011 6:38 AM
> To: xAP_developer@xxxxxxx
> Subject: Re: [xAP_developer] Re: Proposal / RFC: Change xAP wire
format
>
>
>
>
>
> Actually there have been several implementations of xAP on low
bandwidth
> networks but I agree it's not ideal / the most compact protocol, human
> readability precludes it. The lower the bus speed and the higher the
> traffic the bigger the problem. There are a host of really compact
> alternative protocols but they of course sacrifice some of xAP's
> features like readability , wildcard addressing etc. If your bus is
> part of a wider bandwidth xAP topology eg Ethernet and it is an 'end
of
> the road' in terms of xAP traffic then you do have options to minimise
> bandwidth.
>
> You could for example :
>
> Tokenise or even 'drop' some of the xAP parameter names .
>
> Implement a bridge that filters traffic such that only relevant
packets
> are passed onto the low bandwidth segment.
>
> In your bridge you could bi-directionally map longer source names to
> shortform addresses - but your bridge would have to manage wildcard
> matching. Wildcard matchingwithin the low speed segment wouldn't be
> impacted.
>
> Using these techniques you can get a very satisfactory implementation
> whilst retaining interoperability with other xAP devices on say
> Ethernet. IIRC both Patrick and Lehane have implemented xAP over
RS-485.
>
> If you are totally standalone then you could use significantly
compacted
> source addresses and not use wildcarding at all, plus tokenise / omit
> parameters. It's really only when you're bridging into a wider world
> and need interoperability that you need to be careful and then you can
> implement a lot of smarts in the bridge. OTOH if you are totally
> standalone and low bandwidth then I am not sure xAP is a sensible
> choice...or what advantage it would offer, or why you would consider
it
> anyway.... !
>
> JSON really offers no benefit for low speed devices so it's a bit of a
> red herring in that respect. What's good is that embedded devices are
> becoming faster, larger in capacity and lower in cost so this is a
> diminishing problem... It would be neat to be able to implement xAP
> on a $5 device though.
>
> K
>
> On 30/11/2011 18:25, Daniel Berenguer wrote:
> > Hi Alan,
> >
> > Having myself integrated xAP (BSC) on several computing
platforms, I must
> say that xAP is maybe not the most compact protocol for very
constrained
> uC's. On the other hand, even if xAP wanted to be network-agnostic,
the fact
> is that xAP is specially suited for IP networks. I'd never recommend
the use
> of xAP on RS485 buses for example (this is my personal opinion). As
result,
> people is usually adding xAP capabilities on IP-capable uC's only.
This
> said, IP-capable platforms usually have the necessary resources to run
a
> basic xAP stack without problems so adding JSON or not shouldn't be an
> issue.
> >
> > Daniel.
> >
> >
> >
> > --- In xAP_developer@xxxxxxx
> <mailto:xAP_developer%40yahoogroups.com>
,
> "hillbillies@"<hillbillies@> wrote:
> >> Hi Patrick,
> >>
> >> I know that this is an old thread but I have been thinking
about posting
> on this for a little while. Having been woken up at 4:11 this morning
by an
> aftershock (that's what happens when you live in Christchurch, NZ!)
I've had
> plenty of time to put my ideas together. I'm new to xAP, only been
playing
> around for a couple of months on AVR devices and I don't have a full
system
> running yet.
> >> I don't want to put down any of the ideas of those that have
been in the
> project for a long time, but I think that I can put forward some ideas
from
> a different perspective.
> >>
> >> Background:
> >> I wanted to monitor my power meter to look at energy
consumption. If I
> was putting some wires in for that I might as well have a play with
home
> automation. I looked around and liked the ideas of xAP, specifically
that is
> was non-centralised and it was agnostic of processor and network. It
is nice
> that a fair amount of work has been put into Linux app which I wanted
to
> use.
> >> I decided to go with the idea of putting the full xAP message
over an
> RS485 2 wire link using J1708 style circuitry. Over the last month
I've put
> together a library for the AVR for carrier sense multiple access with
> collision detection. I wanted a low power network (which is why I
didn't go
> for ethernet) and to keep things simple. The idea for putting the full
xAP
> message over the network (rather than the BAZ485 idea) was that it is
just
> an extension of the UDP network, rather than a load of sensors
attached to
> the PC.
> >>
> >> So coming from an embedded point of view I would like to put
forward some
> points on your idea for a wire format change:
> >>
> >> On the main front page of the xAP website it says:
> >>
> >> -Simple, easy to implement/retrofit
> >> -Suitable for use with a wide range of processing
capabilities, from
> embedded controllers to fully fledged PC's
> >> -Operating system agnostic
> >> -Programming language agnostic
> >> -Network agnostic
> >>
> >> Where to you see xAP going?
> >>
> >> From what I can see most of the development has gone into PC
centric UDP
> messaging applications. I'm coming from a different point of view, the
> embedded world.
> >>
> >> What I do like is the human readable message, I've got to say
that it's
> helped me alot in my development. However in the embedded world with
the
> lack of RAM and processing cycles the passing of redundant data is a
waste.
> >> If you look at the JSON protocol there can be white spaces
and plenty of
> double-quote symbols. What's the point of sending this information?
It's OK
> in a UDP packet on a PC. But if you want to be network agnostic then
you
> need to cater for lower bandwidths. I would be in favor of taking the
> existing 'source=' and turning it into 's='. We know what source is
> mandatory, it's got to be there, the 'ource' is redundant data.
> >>
> >> By reducing the amount of data sent across the link you are
benefiting
> from:
> >> - Less RAM used to hold it while processing
> >> - Reduced processing time to decode the packet
> >> - Less time on the physical network (therefore increase the
number of
> packets you can put across)
> >>
> >> As I said before, where does the group see xAP going. If it
wants to move
> forward in the lower power, lower speed embedded world then maybe JSON
is
> not the right way to go?
> >> If xAP's future is x86/ARM then it's not a problem, but I
guess that the
> protocol has to suit the lowest common denominator. A high speed
processor
> can cope with JSON or any other protocol that is thrown at it, a low
spec
> processor can only cope with simple things.
> >>
> >> What are other peoples views on this - I'm ready to be shot
down.
> >> Like I said earlier, I'm new to xAP and I want to thank
people for their
> development efforts. I'm not trying to push my thoughts, just airing
them in
> public.
> >>
> >> Cheers
> >>
> >> Alan
> >>
> >> --- In xAP_developer@xxxxxxx
> <mailto:xAP_developer%40yahoogroups.com>
, "patricklidstone"<patrick@>
> wrote:
> >>> I would like to propose a fundamental change to xAP -
adopting JSON
> notation for the wireformat. JSON (RFC4627 /
> http://en.wikipedia.org/wiki/JSON
/ json.org for further details) is now an
> established standard, with wide cross-platform and cross-language
support.
> >>>
> >>> A wide array of parsers are available off-the-shelf. It
is very similar
> to the existing wireformat, which pre-dates JSON, and the JSON
manifesto
> incorporates many of the design aims of the original format (such as
XML
> being too complex/too fat for optimal use on embedded devices).
> >>>
> >>> Whilst retrofitting support to existing apps would be
slightly painful,
> the fact that most libraries and frameworks abstract the parsing, and
that
> there are inherent similarities, wouldn't make the switch too bad from
a
> developer perspective, and that burden is outweighed by the adoption
of a
> standard IMO.
> >>>
> >>> Thoughts?
> >>>
> >>> Patrick
> >>>
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>




------------------------------------