>Rather than create a whole new protocol, check into existing ones.
I agree.

I think the CAN bus is very interesting.
Bit-by-bit arbitration, hardware adress filtering, CRC, automatic
detection-disconnect on lot of errors, high speed, one signal (normally
twisted pair, and some drivers kan work with failure on one line etc), lot
of chips.  There are already lot of higher level protocols built on top of
the CAN, bridges to ethernet, PC-cards with CAN controllers, diagnostic
programs etc.

Mchip will probably release a PIC with CAN later this year, which will be
perfect for the master unit.

For the cheap low-end units i think it is possible to implement CAN in
software in a standard cheap PIC, that have interrupt on port change.

We just have to run the bus slow enough, but we don«t have high speed
requirement, so 1kpbs is porbably much more than needed.

I«ve been thinking on running a system with a single pair or coax, with 48
or 60 VDC supplied, that runs to DC/DC converters in the high power units
(isolated converter if needed).  It will then be possible to get enough
power for servo motors, lots of magnetic valves etc!  

Very simple nodes like fire detectors do not need isolated power nor signal
and can use cheap zener voltage regulator and only cap and protection zener
for signal.

All power is connected through inductors, and the signals through small
caps (and signal transformer if isolation needed, or some bidirectional
optocoupled driver)

One very nice feature aboput CAN is that it was made with thought of
transformer coupling: There is a maximun of five successive bits of same
"polarity" (high or low), or else the transmitter inserts one of opposite
polarity, and the recievers delete the same.  It is built in in the protocol!

The protocol is rather complex, but as it is highly specified and widely
used it is easy to specify as a common standard.

And if someone/a group of us develop a CAN include file, then almost all
work is done, as it even includes error detection, retranslit, bus state
control etc.

Aditionally we only have to specify how to set speed, adress ranges for
different usage etc.

Electically we also have to specify contact configuration, cable impedance,
drive amplitudes etc.

But we can leave that for later as we better (IMHO) first must aim at using
CAN to the basic standard on a spearate twisted pair (driver/reciever
buffers is available for CAN like as for RS232 etc) , and either we decide
for our own how we like to run the power as somebody maybe inly need
totally one watt, but the system I am dreaming in must run an large servo
at 120W... (sun panel rotate)

If we use only the high speed coming PIC with hardware CAN, it is even
possible to get one audio channel (maybe two or more bad quality) to work
as well as the normal control.  So, we can implement a intercom phone, door
phone or whatever :).  Another idea is to transfer pictures from a simple
CCD camera from the door way to see who is knocking, or store to get images
of thieves...

Just my couple of cents summed from a bunch of notes (whishes) on my desk
/Morgan
/  Morgan Olsson, MORGANS REGLERTEKNIK, SE-277 35 KIVIK, Sweden \
\  mrt@iname.com, ph: +46 (0)414 70741; fax +46 (0)414 70331    /