> The networking part is another story. Apparently, the first barrier is
> the network and the protocol. Without a clear description, I don't think
> we can start with the hardware design (what to use for physical layer?).
Much of the software will be the same whatever the bottom layers do,
so we don't have to wait to make progress on other fronts.
> I browsed the CeBUS manual a bit, and I could not find a layer 1 & 2
> definition.
This is part of good design. The protocol described will work over
anything. There is a recommendation to do mains-borne signalling in
accordance with some pre-existing EIA spec, but I haven't looked it
up yet. We can do the same.
The three good things I got from reading the CeBUS document were the idea
of multiple physical layers, the idea of ``contexts'' and thoughts about
some problems we have to solve, like keeping distributed data (time,
state information) synchronised. There were also a few cases where I
thought ``*ugh*, what a terrible way to do that''---like the overloaded
and too short unit address code and the complicated routing rules.
I'm sure we can tackle some of these immediately. If we are careful
to make all our decisions expansion-proof, we don't have to worry about
changing our minds later.
For example, we could specify an addressing scheme now. Have
variable-length addresses; allocate the top 4 bits of the first
address byte to specify x, the number of extra bytes in the address,
and the bottom 4 bits to specify t, to distinguish between different
addressing schemes of the same length. Then we can embed existing
IPv4 or IPv6 addresses, MAC addresses, X10 house/unit codes, CeBUS
manufacturer/serial-number or whatever in the scheme and avoid the need
for yet another central registry of unique numbers. Keep a few values
reserved for special purposes (say t>=8) and we should be able to cope
with whatever we dream up in future. That accomodates the case where
sensors and the like don't need to be bothered with global uniqueness, but
we can still cope with the amazing Foobus when it comes out in 2038:-)
> Maybe an interesting device for powerline communication is the Philips
> TDA5051? Can it be used if the protocol has a CSMA/CR scheme? (bit
> dominance)
According to the data sheet:
http://www-us2.semiconductors.philips.com/acrobat/datasheets/TDA5051_2.pdf
the device keeps receiving even in transmit mode, so could be persuaded
to do this.
> The ultimate question is: do we adopt some existing communication
> standard (ease of use, compatibility, devices in silicon) or do we try
> to design our own (based on something known? are we capable?).
>From my searching so far, I don't think anything is ``standard''
enough for us to adopt unaltered. But we can borrow good bits from
existing standards. For example, the X10 physical layer is worthy
of consideration. There must be chips which implement this layer
conveniently (is the 5051 suitable?), or we can use published and tested
stuff like the PIC design I mentioned above to implement it.
If we are just after convenient pre-built stuff, there are several
complete mains transceiver modules around (http://www.hth.com/plm-24),
or almost-complete implementations in silicon (just add a transformer
to the LM1893 http://www.national.com/ds/LM/LM1893.pdf).
Until one of us has actually built something and got it going, we have
few firm reasons to select one design over another. But we don't have to
settle on just one physical layer: I fully expect to have at least four
(mains, IR, radio and dedicated wire) to cope with different situations
(existing wiring, mobile or awkwardly-placed devices, new installations
or high-speed tightly-coupled exchanges), and there is no particular
reason why (say) the 110V contries shouldn't have a different mains
system than the 220V ones. All of these should hide near the bottom of
the protocol stack where they can be freely interchanged.
> Until we clear this out, I think we're stuck at zero.
Not at all. We can get the protocol organised without the hardware, and
the hardware without the protocol. I've already started fiddling with
a radio link using some cheap 418MHz modules intended for car alarms and
made some enquiries about borrowing the LM1893 stuff I mentioned earlier.
I can try these out and pass dummy packets about, make measurements
and quantify bit error rate. Similarly, I can think how my proposed
addressing scheme and (as yet unformulated) protocol might work in various
situations and write a software-only network simulator.
I think my big problem is not knowing how much I want the system to do.
I am in danger of making my mental model of the system so complicated
that it will never get built! Still, I'd rather over-engineer in the
early stages; it's easier to leave things unimplemented than kludge
extra functions on later.
I made a start listing the things we thought the system should do
in http://ha.ro.nu/hypermail/0013.html which I have excerpted in to
http://ha.ro.nu/discussion/applications.html . Contributions welcome.
> PS: Where is everyone. I thought my mailbox would flow over during my
> absence
I've been busy with HA research:-) I don't think we have quite reached
critical mass yet to sustain discussion, but Zeb's recent post to
comp.home.automation will surely help things pick up. We have 5 new
members already, taking the total to 15, and we are already seeing
benefits---I have added some of Adam's excellent suggestions to the
applications list.
And another one joined while I wrote this lengthy message (hi Philip)!
Robin.
-- R.M.O'Leary <robin.at.acm.org> +44 7010 7070 44, PO Box 20, Swansea SA2 8YB, UK