[Message Prev][Message Next][Thread Prev][Thread Next][Message
Index][Thread Index]
RE: Re: Proposal / RFC: Change xAP wire format
------=_NextPart_000_015B_01CCB048.C1A4D200
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
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
>
>
>
>
------=_NextPart_000_015B_01CCB048.C1A4D200
Content-Type: text/html; charset=US-ASCII
Content-Transfer-Encoding: 7bit
<head>
<style type="text/css">
<!--
/* start of attachment style */
.ygrp-photo-title{
clear: both;
font-size: smaller;
height: 15px;
overflow: hidden;
text-align: center;
width: 75px;
}
div.ygrp-photo{
background-position: center;
background-repeat: no-repeat;
background-color: white;
border: 1px solid black;
height: 62px;
width: 62px;
}
div.photo-title
a,
div.photo-title a:active,
div.photo-title a:hover,
div.photo-title a:visited {
text-decoration: none;
}
div.attach-table div.attach-row {
clear: both;
}
div.attach-table div.attach-row div {
float: left;
/* margin: 2px;*/
}
p {
clear: both;
padding: 15px 0 3px 0;
overflow: hidden;
}
div.ygrp-file {
width: 30px;
valign: middle;
}
div.attach-table div.attach-row div div a {
text-decoration: none;
}
div.attach-table div.attach-row div div span {
font-weight: normal;
}
div.ygrp-file-title {
font-weight: bold;
}
/* end of attachment style */
-->
</style>
</head>
<html xmlns:v="urn:schemas-microsoft-com:vml"
xmlns:o="urn:schemas-microsoft-com:office:office"
xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml";
xmlns="http://www.w3.org/TR/REC-html40";><head><meta
http-equiv=Content-Type content="text/html;
charset=us-ascii"><meta name=Generator content="Microsoft
Word 14 (filtered medium)"><!--[if !mso]><style>v\:*
{behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#1E66AE;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#1E66AE;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
code
{mso-style-priority:99;
font-family:"Courier New";}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
tt
{mso-style-priority:99;
font-family:"Courier New";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
p.attach, li.attach, div.attach
{mso-style-name:attach;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:9.0pt;
font-family:"Arial","sans-serif";}
p.bold, li.bold, div.bold
{mso-style-name:bold;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:10.0pt;
font-family:"Arial","sans-serif";
font-weight:bold;}
p.green, li.green, div.green
{mso-style-name:green;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:#628C2A;}
p.replbq, li.replbq, div.replbq
{mso-style-name:replbq;
margin:3.0pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.ad, li.ad, div.ad
{mso-style-name:ad;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.underline, li.underline, div.underline
{mso-style-name:underline;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.yshortcuts
{mso-style-name:yshortcuts;}
p.ad1, li.ad1, div.ad1
{mso-style-name:ad1;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.ad2, li.ad2, div.ad2
{mso-style-name:ad2;
mso-margin-top-alt:auto;
margin-right:0cm;
margin-bottom:7.5pt;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.underline1, li.underline1, div.underline1
{mso-style-name:underline1;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman","serif";
text-decoration:underline;}
span.yshortcuts1
{mso-style-name:yshortcuts1;
font-family:"Verdana","sans-serif";
font-weight:bold;}
span.yshortcuts2
{mso-style-name:yshortcuts2;
font-family:"Verdana","sans-serif";
font-weight:normal;}
span.EmailStyle34
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1116800107;
mso-list-type:hybrid;
mso-list-template-ids:-597150598 201916431 201916441 201916443 201916431
201916441 201916443 201916431 201916441 201916443;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1
{mso-list-id:1374768168;
mso-list-template-ids:-1527372986;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body
bgcolor=white lang=EN-AU link="#1E66AE"
vlink="#1E66AE">
<!-- **begin egp html banner** -->
<br><br>
<!-- **end egp html banner** -->
<div class=WordSection1><p class=MsoNormal><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>My
two cents worth,<o:p></o:p></span></p><p
class=MsoNormal><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p
class=MsoListParagraph style='text-indent:-18.0pt;mso-list:l0 level1
lfo2'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>1.<span style='font:7.0pt "Times New
Roman"'>
</span></span></span><![endif]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Personally
I think all embedded devices should be slaves. That is, they ar
e 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 agains
t 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. <o:p></o:p></span></p><p
class=MsoNormal><span lang=EN-US
style='color:#1F497D'> <o:p></o:p></span></p><p
class=MsoListParagraph style='text-indent:-18.0pt;mso-list:l0 level1
lfo2'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>2.<span style='font:7.0pt "Times New
Roman"'>
</span></span></span><![endif]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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.<br>A smaller version of the protocol would also be useful
here.<br>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.<br><br><o:p></o:p></span></p><p
class=MsoListParagraph style='text-indent:-18.0pt;mso-list:l0 level1
lfo2'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>3.<span style='font:7.0pt "Times New
Roman"'>
</span></span></span><![endif]><span
style='font-
size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>In
regard to the serial version, ie RS485. A similar thi
ng 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.<br><br><o:p></o:p></span></p><p
class=MsoListParagraph style='text-indent:-18.0pt;mso-list:l0 level1
lfo2'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>4.<span style='font:7.0pt "Times New
Roman"'>
</span></span></span><![endif]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>A
similar thing could carry through to Wireless devices (Something I plan on
making in the near
future)<br><br><o:p></o:p></span></p><p
class=MsoListParagraph style='text-indent:-18.0pt;mso-list:l0 level1 l
fo2'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>5.<span style='font:7.0pt "Times New Rom
an"'>
</span></span></span><![endif]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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. <br>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.<o:p></o:p></span></p><p
class=MsoNormal><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p
class=MsoNormal><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>A
sample command to an embedded device. Don’t care what version,
how many h
ops, what class, where it came from. If you’re sending it to me,
you should know what I am and capable
of.<o:p></o:p></span></p><p
class=MsoNormal>{<br>Dest=FF123400<br>}<br>{<b
r>OP1=ON<br>}<span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p><p
class=MsoNormal>{<br>OP2=ON<br>}<span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p><p
class=MsoNormal><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>#13
Always nice to have an end of message
delimiter.<o:p></o:p></span></p><div><p
class=MsoNormal><span lang=EN-US
style='color:#1F497D'><o:p> </o:p></span></p><p
class=MsoNormal><span lang=EN-US
style='color:#1F497D'><o:p> </o:p></span></p><p
class=MsoNormal><span lang=EN-US style='color:#1F497D'>T
he heartbeat and status could be similar, same for
BSC.<o:p></o:p></span></p><p
class=MsoNormal><span lang=EN-US
style='color:#1F497D'><o:p> </o:p></span></p><p
class=MsoNormal><span lang=EN-US style='color:#1F497D'>Regards,
<o:p></o:p></span></p><p
class=MsoNormal><b><span
lang=EN-US style='font-size:13.5pt;color:#1F497D'>Neil
Wrightson (Australia).</span></b><span
lang=EN-US style='color:#1F497D'>
<o:p></o:p></span></p><p
class=MsoNormal><span lang=EN-US
style='color:#1F497D'><o:p> </o:p></span></p><p
class=MsoNormal><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p></div><div><div
style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm
0cm'><p class=MsoNormal><b><span lang=EN-US
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
lang=EN-US
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
xAP_developer@xxxxxxx [mailto:xAP_developer@xxxxxxx
] <b>On Behalf Of </b>Kevin
Hawkins<br><b>Sent:</b> Thursday, 1 December 2011 6:38
AM<br><b>To:</b>
xAP_developer@xxxxxxx<br><b>Subject:</b> Re:
[xAP_developer] Re: Proposal / RFC: Change xAP wire
format<o:p></o:p></span></p></div></div><p
class=Mso
Normal><o:p> </o:p></p><p
class=MsoNormal> <o:p></o:p></p><div
id=ygrp-mlmsg><div id=ygrp-msg><div id=ygrp-text><p
style='margin-bottom:12.0pt'>Actually there have been several
implementations of xAP on low bandwidth <br>networks but I agree it's
not ideal / the most compact protocol, human <br>readability
precludes it. The lower the bus speed and the higher the <br>traffic
the bigger the problem. There are a host of really compact
<br>alternative protocols but they of course sacrifice some of xAP's
<br>features like readability , wildcard addressing etc. If your bus
is <br>part of a wider bandwidth xAP topology eg Ethernet and it is
an 'end of <br>the road' in terms of xAP traffic then you do have
options to minimise <br>bandwidth.<br><br>You could for
example :<br><br>Tokenise or even 'drop' some of the xAP
parameter names .<br><br>Impl
ement a bridge that filters traffic such that only relevant packets
<br>are passed onto the low bandwidth segment.<br><br>In
you
r bridge you could bi-directionally map longer source names to
<br>shortform addresses - but your bridge would have to manage
wildcard <br>matching. Wildcard matchingwithin the low speed segment
wouldn't be <br>impacted.<br><br>Using these techniques
you can get a very satisfactory implementation <br>whilst retaining
interoperability with other xAP devices on say <br>Ethernet. IIRC
both Patrick and Lehane have implemented xAP over
RS-485.<br><br>If you are totally standalone then you could use
significantly compacted <br>source addresses and not use wildcarding
at all, plus tokenise / omit <br>parameters. It's really only when
you're bridging into a wider world <br>and need interoperability that
you need to be careful and then you can <br>implement a lot of smarts
in the bridge. OTOH if you are totally <br>standalone and low
bandwidth then I am not sure xAP is a sensible <br>choice...or what
advantage it would offer, o
r why you would consider it <br>anyway.... !<br><br>JSON
really offers no benefit for low speed devices so it's a bit of a
<br>red herring in that respect. What's good is that embedded devices
are <br>becoming faster, larger in capacity and lower in cost so this
is a <br>diminishing problem... It would be neat to be able to
implement xAP <br>on a $5 device
though.<br><br>K<br><br>On 30/11/2011 18:25, Daniel
Berenguer wrote:<br>> Hi
Alan,<br>><br>> 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 wi
thout problems so adding JSON or not shouldn'
t be an issue.<br>><br>>
Daniel.<br>><br>><br>><br>>
--- In <a href="mailto:xAP_developer%40yahoogroups.com";>xAP_developer@xxxxxxx</a>,
"<a href="mailto:hillbillies@...";>hillbillies@...</a>"<<a
href="mailto:hillbillies@...";>hillbillies@...</a>>
wrote:<br>>> Hi
Patrick,<br>>><br>>> 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.<br>>> 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.<br>>><br>>>
Background:<br>>> 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.<br>>> 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.<br>>><br>>> So coming from an
embedded point of view I would like to put forwa
rd some p
oints on your idea for a wire format
change:<br>>><br>>> On the main
front page of the xAP website it
says:<br>>><br>>> -Simple, easy to
implement/retrofit<br>>> -Suitable for use with a wide
range of processing capabilities, from embedded controllers to fully
fledged PC's<br>>> -Operating system
agnostic<br>>> -Programming language
agnostic<br>>> -Network
agnostic<br>>><br>>> Where to you
see xAP going?<br>>><br>>> 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.<br>>><br>>> 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.<br>>> 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.<br>>><br>>> By reducing the
amount of data sent across the link you are benefiting
from:<br>>> - Less RAM used to hold it while
processing<br>>> - Reduced processing time to decode
the packet<br>>> - Less time on the physical network
(therefore increase the number of packets you can put
across)<br>>><br>>> 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?<br>>> If xAP's future is x86/ARM then
it's not a problem, but I guess that the protocol has to suit the lowest
commo
n 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.<br>>><br>>> What are
other peoples views on this - I'm ready to be shot
down.<br>>> 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.<br>>><br>>>
Cheers<br>>><br>>>
Alan<br>>><br>>> --- In <a
href="mailto:xAP_developer%40yahoogroups.com";>xAP_developer@xxxxxxx</a>,
"patricklidstone"<patrick@>
wrote:<br>>>> I would like to propose a
fundamental change to xAP - adopting JSON notation for the wireformat. JSON
(RFC4627 / <
;a href="http://en.wikipedia.org/wiki/JSON";>http://en.wikipedia.org/wiki/JSON</a>
/ json.org for further details) is now an established standard, with wide
cross-platform and cross-language
support.<br>>>><br>
>>> 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).<br>>>><br>>>>
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.<br>>>><br>>>>
Thoughts?<br>>>><br>>>>
Patrick<br>>>><br>><br>><br>><br>>
------------------------------------<br>><br>>
Yahoo!
Groups
Links<br>><br>><br>><br>><o:p></o:p></p></div><div><p
class=MsoNormal><span
style='color:white'><o:p></o:p></span></p></div></div>
<!-- **begin egp html banner** -->
<br>
<br>
<!-- **end egp html banner** -->
<div width="1" style="color: white; clear:
both;"/>__._,_.___</div>
<!-- Start Recommendations -->
<!-- End Recommendations -->
<!-- **begin egp html banner** -->
<img src="http://geo.yahoo.com/serv?s=97476590/grpId=9629476/grpspId=1705007709/msgId=2222/stime=1322718388";
width="1" height="1"> <br>
<!-- **end egp html banner** -->
<!-- **begin egp html banner** -->
<br>
<div style="font-family: verdana; font-size: 77%; border-top: 1px
solid #666; padding: 5px 0;" >
Your email settings: Individual EmailTraditional <br>
<a href="http://groups.yahoo.com/group/xAP_developer/join;_ylc=X3oDMTJmanRkaGFhBF9TAzk3NDc2NTkwBGdycElkAzk2Mjk0NzYEZ3Jwc3BJZAMxNzA1MDA3NzA5BHNlYwNmdHIEc2xrA3N0bmdzBHN0aW1lAzEzMjI3MTgzODg-";>Change
settings via the Web</a> (Yahoo! ID required) <br>
Change settings via email: <a href="mailto:xAP_developer-digest@xxxxxxx?subject=Email
Delivery: Digest">Switch delivery to Daily Digest</a> <a
href = "mailto:xAP_developer-fullfeatured@xxxxxxx?subject=Change
Delivery Format: Fully Featured">Switch to Fully Featured</a>
<br>
<a href="http://groups.yahoo.com/group/xAP_developer;_ylc=X3oDMTJkamc4dmNuBF9TAzk3NDc2NTkwBGdycElkAzk2Mjk0NzYEZ3Jwc3BJZAMxNzA1MDA3NzA5BHNlYwNmdHIEc2xrA2hwZgRzdGltZQMxMzIyNzE4Mzg4";>
Visit Your Group
</a>
<a href="http://docs.yahoo.com/info/terms/";>
Yahoo! Groups Terms of Use
</a>
<a href="mailto:xAP_developer-unsubscribe@xxxxxxx?subject=Unsubscribe";>
Unsubscribe
</a>
<br>
</div>
<br>
<!-- **end egp html banner** -->
<div style="color: white; clear:
both;"/>__,_._,___</div>
</body></html>
------=_NextPart_000_015B_01CCB048.C1A4D200--
xAP_Development Main Index |
xAP_Development Thread Index |
xAP_Development Home |
Archives Home
|