RE: bsc questions

["Ian Davidson" <ian@xxxxxxxxxxxxxxxx>]

Kevin,

Thanks for the reply. I hadn't realised I could restrict the target
length and still be compliant. I should have a little time again next
week so I'll see how it goes coding again.

When I mentioned targeting via UID I don't think I explained well enough
what I meant. If there was a UID target field, the device it was
intended for could read this field and know to act on the message. The
usual target line could still be populated with an address but the small
micro would not read it. However other devices on the network would be
allowed to ignore the UID target field and otherwise treat the message
as standard even though not directly targeted to them, such as a display
or speech type interface. Sorry for the confusion I should not have used
the word exclusive as I did realise all UID's must indeed be unique

Ian D


-----Original Message-----
From: xAP_developer@xxxxxxx
[mailto:xAP_developer@xxxxxxx] On
Behalf Of Kevin Hawkins
Sent: 12 May 2006 01:46
To: Ian
Subject: Re: [xAP_developer] bsc questions

Ian Davidson wrote:
>
> Hello
>

Hi Ian
>
> It's my first email to the developers group but I'm struggling to get
> to grips with some aspects of xAP. I have looked back through the
> archives but still can't quite get to grips with some of the concepts.
>
> If I have understood things correctly then the BSC part was aimed at
> lower spec'd devices to be able to utilise xAP.
>
Yes and no, BSC was aimed at providing a straightforward schema to
interact with simple devices. It supports devices that have binary,
analogue or textual inputs or outputs, which in fact can encompass the
majority of devices. It was not specifically introduced for lower spec'd

devices (meaning limited memory space). BSC is a fairly powerful schema
and it is definitely possible to create simpler / cruder schema to
achieve xAP control should you wish. BSC however is a fairly core
standard to xAP by which many different devices can interact 'out of the

box' so you would sacrifice that.
>
> My biggest problem is fully understanding the UID part. Within the xAP

> header the UID identifies the source. For an ouput device to use only
> the UID for identification it would mean it could only ever respond to

> messages from one device or possibly a number of known devices.
> Because the device has used the UID to identify rather than the source

> or target then this would also rule out the use of wildcards.
>
This is correct but it is very efficient to store UID's as they only
(currently) occupy 4 bytes (or 3 if you ignore the network field). Hence

you can simply store a table of addresses you want to react to - but as
you say if you are using UID's as your identifier you can't use
wildcards. BTW quick reminder that the UID is expanding in size
shortly........
>
> However if the UID was used for a target address then any device could

> target the new device. The device would only need to look for and
> identify the target UID to know the message is aimed at itself. Again
> wildcarding as currently defined would not be possible.
>
This is the big problem in your idea to allow targeting by UID. It
defeats wildcarding and it breaks every other device's listen ability
(based on target address filtering/monitoring) and hence it is not
allowed within xAP to target by UID.
>
> Even though a target UID had been specified it would not be exclusive
> and there would be nothing to stop other devices receiving the
> information as is current with the broadcast nature of xAP.
>
All UID's must be exclusive on a xAP network
>
> At the moment I can not understand how a low end device could be
> capable of receiving and decoding a BSC message. To start with both
> the source and target can be 128 bytes in length added to this the
> fact that multiple endpoints can be targeted in a single message the
> length could easily be more than could be available in some devices.
>
Bear in mind that you don't have to use 128 bytes for your addresses so
your particular device might only support 16 characters say - hence for
parsing the target line you would then only have to deal with 16
characters max. Also do you need to store the source in your application

? - surely you can discard it . If you want to be able to target other
peoples devices then they indeed could have longer addresses but in
reality most are under 32 characters max I would guess. The reason that
multiple endpoints must be permissible in one messages is to get
coincident changes in a device (or to an extent devices ). Either all of

the message is actioned or none, which means you can avoid related
endpoints getting into conflicting, or indeed dangerous states eg
"Heat"

and "Cool" at the same time .

I don't see the need to keep all of the information in memory at any one

time, you can parse the first block of a BSC message and decide what the

resultant state change will be and pop that in an 'action' queue , then
drop all that data and parse the next block etc etc. When the message is

complete you then look at your action queue and complete them all (at
the same instant if possible) and then before clearing the action queue
you would again scan it and send appropriate BSC event/info messages. I
may be missing something here but multiple block messages don't
significantly increase the memory requirements do they ? As a workaround

(and if your device is acceptable working in this way) you could treat
each block as a new xAP message - although that's not strictly to spec.
I say all this with no regard for the need to buffer the serial data and

I guess based a little on having either enough speed to do things
interleaved with data receipt (drop source address say) or enough space
to store the incoming message or an interrupt driven circular buffer of
some form. You may not have this luxury of course, depending on serial
data speed etc . I have only worked with Ethernet where I have a
complete buffered message presented so I have probably not hit the
issues you have. Lehane will be much better positioned here to respond.

You are also permitted to not support wildcarding should you wish, it
simply makes your device less flexible and perhaps therefore less
appealing to customers. Not having wildcarding in BSC would mean that
the multi block issue goes away. We encourage that wherever possible
people should support wildcarding - and you must always recognise the
>:> and *.> "address everything" type of constructs (to
allow
discovery), but you could treat those as aliases rather than wildcards
if needs be,,,,
>
> Rather than rabbit on at this stage can anyone explain if I have
> misunderstood the BSC specification and what would be the easiest way
> to implement a device using a small micro but with a number of input
> and outputs attached to the device.
>
The Netiom is exactly such a device and fully implements BSC in a
18F4525 - in fact it can be done in a much smaller chip but the Netiom
has all the Ethernet stack and most of the standard (non xAP) protocol
support too.There's a load of space still free I believe as we're
talking about adding some more features. I fully implement BSC and other

lighting schemas (+Ethernet) in a Rabbit based controller but that has
quite generous memory cf a PIC I have not written at the machine code
level though - I use C and based my code around ideas pulled from
Patricks C libraries. - I guess it's a case of saying how small is a
small device ??

Does your device need to target other devices (that are not 'yours') -
if not then why not restrict your address lengths to 16 or even less.
That way you can truncate (or even drop) all messages with longer target

lines, and don't have to store the addresses of things you will be
targeting yourself, plus do you need to even store the source address in

an incoming message - can you not drop that too 'on the fly' . Also you
could maybe parse block by block - as separate messages - which still
protects the 'all or none' feature but doesn't give true coincident
changes.

One other thought - if your device will be targeting other devices made
by you - can you not 'calculate' or rebuild a target address from a
small table entry - eg in a really crude way you could name & target
your devices using target=IanD.Dev.2323:05 where the UID of the device
you were targeting was FF232305, and that source address could be
reconstructed from 3 bytes of storage . More readably you could have a
table indexed by a byte value with an entry for say 05=Lounge and you
then have to only store 05 0A to address endpoint ten on the Lounge
device - and because you are using direct numerical sub addresses in hex

there will be no wildcarding possible in the sub address field. In fact
my C-Bus gateway uses source=UKUSA.C-Bus.Lighting:G08 for example for
Group 8 on C-Bus. You can rename these groups should you wish but the
default is just a calculated number G01 G02 GF2 etc (the G standing for
group but even that could be omited - it takes no storage) - hence no
wildcarding in the sub address portion - except * or >

Kevin
>
> Thanks
>
> Ian D
>
PS If you want a highly efficient protocol you could look at SNAP - big
;-)

PPS Rather late as I'm writing this so may not make a lot of sense...