HI folks,
A little history first...
https://forum.allaboutcircuits.com/threads/home-automation-network-protacol.134415/#post-1121743
https://forum.allaboutcircuits.com/...rordcast-packet-protacol.134588/#post-1122189

Much useful advice in these, followed by much more reading and thinking.
Now I think I have a plan and would apriciate a critique.

Sailiant points.
1. I want something simmilar to I2C in multi master mode. Simmilar because I dont actually want to address any hosts.
2 The Passive pull-up used by I2C is not going to work for me as my lengts could be considderable.
3. A star topology is my goal so some sort of hub is going to be required to avoid reflections and multiple paralell terminations.
4. I am unsure how / if multi master is implemented properly in the Arduino wire lib but It may be useful as a starting point.
5. I2C line drivers are not cheap especially when you considder each host needs two, on on board and one at the hub.
6. Given that I plan to use a hub each device will essentally be P2P so I can use push pull drivers
6. I dont need to talk to standard I2C devices
7. I dont want a single master or to have to program hosts when changes are required.

I think I have a plan now but would apriciate comments, good or bad.

The idea is to have all the hosts, 20 or so, host soft devices that may be inputs or outputs. These will be virtual devices and a host could, and will, carry several of them in many cases.
When a devise has something to say it will say it, see collisions/scheduling later, and everything will listen.

There are two active lines lines and a ground, implemented as two pare, TX and RX, relative to the hub.
A host can drive its TX low or high, actively, and the hub will respond by driving all RX lines to a reciprocal state.
In addition the hub will drive the RX lines with a free running, asymmetrical clock.
Data will be encoded by clock stretching which will work with bipolar signals because the hub, internally, will be using passive pull-ups.
The clock pulse will be 25%, 0's 50% and 1's 75% of the clock frequency. Stop will be encoded with 0's with a null between them for 5 cycles.
I have yet to decide on error checking but that aside...
Any host can transmit a devices data after a stop and 3 null clock pulses or n seconds of quiet buss.
Every message will start with a priority code, initially 1 and a device address in n bits, I haven't decided how many yet, sent MSb first. Obviously there will be occasions when two hosts attempt to transmit at the same time. Since each hosted device will have a unique address and the hub will echo whatever a device sends two devices will continue to transmit, synchronised by the clock untill one of them detects a 1 when it sent a 0 at which point it will abort an increment its priority code. This will ensure that only the device with the highest priority code and device address combination, in that order will send a full packet and any devices that have failed to send will now have a higher priority than a device that has completed a packet.
If several devices start taking simultaneously, all with a 1 priority the one with the highest address will prevail.

Given that even the most proliffic devices will only be reporting data, temperature, light level and the like, every few seconds I do not think this strategy will create much latency. And of course I a device has something critical to report once in a while it can start with an enhanced priority in the first place, switch events for example.

Every host will maintain a table of device mappings that will define which device is passed data from that arrives based on the address of the sender.
This table will be a device in its own right and will listen for commands from the programmer, a tablet probably, that will update the table or report its contents. to get the data from the tablet onto or off the bus a master protacol converter/buffer will sit in the hub and use 232 over bluetooth, or wifi tcp raw packets, to comunicate with the tablet/HMI allowing it to show the status of all devices, command anything and modify device mappings.

What am I missing?
Anyone have a better plan or an enhancement?
Anyone up for a bit of colaberation?

Timescales are not tight but I am keen to make a start, once I have read through any advice and ordered a few parts.

I was planning on using totempole drivers, 2904/2906 BJT's for the drivers but I am up for suggestions if anyone can offer a chip, provided we are talking p not £. I will use ULN2003A's for the recievers at the hub and probably single transistors for the one on each host.
Physically I have RJ45 sockets and breakout boards. Power will be on pare 1&4 with the data on 2&3

The only other enhancement I van think of if to use diferential lines, 485 esque but again drivers seem a bit OTT, comparators perhaps?
Anyone have an opinion as the weather the enhabcenent is worth the effort, cable runs will be less than 20m in most cases but I want to plan for twice that.

I would be interested to know what you suggest RE signal level. Power will be 24, the hub will supply that from a large boost converter fed from my batteries.
I would prefer the signal level to be the same as the supply, or the Arduino supply @5, so that I dont have to go mucking about with a third rail.

Looking forward to being educated...
Al

 

Creating your own electrical protocol for sending data as you suggest sounds like a nightmare.

for $2.00, this little chip solves all your problems, its so easy, reliable, fast and cheap.
https://www.digikey.com/product-detail/en/texas-instruments/SN75HVD3082EDR/296-26659-1-ND/2255092

On the software side, it's just standard serial, so many libraries and tools available.

 

Thanks but that is half duplex 485 so no way to impliment multiple master at least not without an even bigger headache.

I2C is the best match and I could buy drivers for that but both will not do well in a star configuration and I2C will not handle the length because of the passive pull-ups whch is what permits the multi master architecture, along with the clock line that synchronises everything.

There are I2C drivers that use diferential lines at slightly offset voltages so that they dont lock up but they are not cheap.

To be honest I ma not too worried RE software, My strategy is only a collection of bits from other established protacols so finding code snipits shouldn't be so hard if I need then. In fact I suspect the Arduino wire library probably has 95% of what I need already. It will need tweaking to transmit and recieve on different pins and the timing may want a bit of a fiddle but the buffer handling and interupts will be there.

All that is needed is to look at the rising edge of the clock and start a trimer...
Then when the falling edge occurs the pulse lengtgh will tell me if it was a null, 0 or 1.
A bit of extra code to stop the TX if the echo wasn't what was being sent during TX
when a stop is received, and data is checked, alert the main loop to read the buffer and do whatever with the data.
In any other circumstance, timeout bad date.... Set an error flag and dump the buffer.

If I have a soft problem it will be processor speed data rate or more more likely a combination of the two.

What I am much less confident about is relativly fast signals on long lines. And I cant help thinking that there may be a reason that drivers are twice the price of a cheap uP board.

Lastly I like a challenge,. I could simply use RS485 in its classic half duplex master slave/s mode but that wouldn't perform the way I want, would fail if the master failed, or was being updated. And as 485 is a hardware only standard, much like I2C I would still have to use Modbus, or something simmilar, with all the overhead of stuff I dont want to do and a requirement to physically address all slaves.

Dont get me wrong, I apriciate the scope of the task but I have given it a great deal of thought, asked a raft of questions and to date not found an answer that ticks all the boxes.

Ethernet would of course work but the processor overhead is huge even with a dedicated shield/board.
If I went that way, which is an option, I would need something like this... https://www.sparkfun.com/products/765
but I cant find anything even near a cost I am prepared to pay untill I have failed to make it work with a little effort.

I expect that there are cheaper versions and and probably even units that bring out the unused pares so I can impliment POE but to date I haven't found anything That looks promising,.....
OK Just checked and there a several versions on eBay, all with not much info and worrying statements like master or slave.
Worth a bit of reading though now you have prompted me to look again.
Perhaps serial over tcp, I may even be able to program a nano with that, who knows.

Any, I didnt ask to get a pat on the head it was to be questioned and examine my choices, and perhaps I found a second route that I hadnt properly considdered.

Thanks,
Al

 

Doesn't all this ignore the elephant in the room? I mean, the currently commercial home automation market is going wireless. Why reinvent yet another wired scheme? Seems like a lot of work with no forward path.

 

I'm sure it would be simpler to come up with your own software protocol using standard RS-485 as the backbone, rather than the hardware nightmare you are contemplating. It's actually quite easy to cook up your own protocol, with very low "overhead".

Software not working? well... you can debug and fix that.

Hardware and software troubles combined? sooo much harder. Why hurt yourself?

I2C is just totally wrong for long distance communications, it can be done, (see app note attached) but it's only done when you are stuck with I2C and you cannot manage translating it to a better protocol.

Note that their solution uses 2 X as many wires in the cable.

 

points, which I think I have addressed...

Wireless, that simple, all devices need power, perhaps with the exeption of the odd thermostat that could potentally harvist it from the environment, so I am running wires anyway.

Now I will concede that lights and switched sockets do have convieniant power but each would need a power supply in addition to everything else and wireless is hardly an easy interface to build get right, particularly when cost is asn issue and wiring isn't.

If I was in an exiasting home with walls and plaster then perhaps I would be looking for a less invasive installation method but that is not the case.

I am aware of several mesh networks that I could potentally have used but for everything else but lights there would be nothing to gain but expense. I may well expand the system at some point in the future with a wireless hub of one form or another, but I see little advantage to basing the entire system on comparativly expensive interfaces.

I'm sure it would be simpler to come up with your own software protocol using standard RS-485asthebackbone

So was I, so much so that I even bought a few 485 interface modules to muck about with, then I thought about it properly.
I will concede that I dont have to use Modbus to make use of, simple cheap, 485 coms modules. but although the diferential line drivers could make life easier nothing else about 485 is of much help. There is no multi master implimentation. and the electrical spec prohibits a star topology.

In short, driver chips... possibly if I use a 4 wire scheme, which I may well do, but everything else simply doesn't fit.

I actually love RS-485, I program PLC's for a living, when I am not designing control panels for hydroelectric installations, and 485 is my 'go to' for anything up po to a km or so where speed isn't a big concern. It even works over standard SWA so can be implimented where dedicated comes were never origionally planned, what's not to love.

Not dismissing your comments but unless I am missing something I think I have considdered the issues.
Sort of wish I was wrong though!

Thanks,
Al

 

Considering MAX488E drivers, limited slew so only 256kb, which is fast enough, but tollerent with it.
Found some at circa £2 on ebay from Germany.
Each chip has one TX and one RX with descrete data and line pins, designed for full duplex, which will work for my application.

Anyone got a cheaper option, or further comments for that matter?

Al

 

In my simple experiences,

Differential is a good idea, but are you going to AC couple the receivers ?
If not, wheres the ground reference ?

Long bits of wire, make fantastic antennas,
more important for you, they pick up very well.

If you have a high impedance receiver, your probably going to see many 10's of volts of common mode noise.
and that's with screened cables, and a ground reference takes down the cable.

This is one of the reasons things like ethernet are AC coupled, with a few Kv isolation barrier.


With mutli master, the big worry is a lock up condition,
especially true when one node might be at fault, or the timing is off.


What clock frequency do you expect to work,
each node will add capacitance, as will the cable , and you will have multiple reflections to consider,
how will you cope with a broken wire, will all the network go down, how will you find it ?

I assume this is a 24/7 system, needs to be reliable / resiliant.
what about the lighting bolt that hits outside, or the cat on the mat esd shock, or the mains spike ?


To debug this sort of system, your going to need a scope,
as its ac waveform from outside is are going to kill you
I can recommend getting a scope , they are very useful, but if you don't have access to one, they are not cheap.


Its a great plan,

experience shows that a fun circuit like this can be made to work,
I used to have something similar as a kid around the bedroom,
but a long term design, with many years of 24/7 reliable working....

a very different story.


Bets of luck,

 

could I also point you at these

https://www.pjrc.com/store/teensy36.html

 

Thanks Andrewmm, all good points I think.

I have a scope, all digital but fairly fast and good memory depth.

Re Common mode noise... I take your point but I wasn't planning on AC coupling, even when I was considdering building drivers, which I have now abandoned as a plan.
Each host will be connected using CAT5E, copper not CCA, with TX and RX on two pair and 24VDC on the other two.
I will buck down to 5V for the uP and drivers and use the 24 directly for relay/FET/Open collector outputs. (ULN2003A buffers)

The driver chips, MAX488E probably, are protected to 15KV internally and are also slew limited which will help with any cabling issues. Max baud is 256Kbps I think but I doubt I will go that fast. I will not know untill I write the drivers.
Driver common mode voltage is 3V according to the sheet with a tiny diferential offset. They are RS-485 / RS-422 compatible and my experience of that is nothing but good, however poorly its implimented.

Reflections from dead legs or Star connections though I would worry about. So...
I an not implimenting 485 or 422. I will use 1 TX pare and 1 RX pare but still only half duplex.
I need every host to be able to pull on a line, I2C ish, so I can impliment collision detection and host back off during TX.
Since I obviously cant do this with multiple hosts on a single diferential line I will be using a simple dumb hub.

Each host will control its own TX, using clock stretching to encode data. Every TX will connect to the hub.
The hub will OR all TX lines and apply the result to all RX lines, that way all hosts see all TX at RX including their own echo.
This strategy will use slightly more cable but completly sort out the reflections issue as every connection will effectivly be P2P.
A host could provide a clock, but I will probably just put a free running clock in the hub.
All hosts will use the clock on RX for timing and as encoding will be a percentage of frequency, provided the host isn't overwhelmed with interupts the actual clock speed is of little conciquence, within the electrical constraints.

What I am trying to do is pick all the good bits from several schemas and then impliment a protacol with a tiny overhead, processor wise, and do it with standard parts.

As far as I know there are no well defined protacols that essentally broadcast everything. Clipsal CBUS works this way but it is proprietary.
I apriciate I could have implimented a mixture of TCP and UDP but the processor overhead is huge.
X10 does actually work like this but that is 1 bit on every 0 cross at 50 Hz...
The nearest thing to what I think is needed is I2C in multi master mode using broardcast addresses for every packet. However I2C uses a single half duplex single ended data line and a clock line so any significant length or a large number of devices is an issue as is a star topology.
Passive pullup is also used to allow multiple hosts to talk, untill they back off, but that is a poor plan with long cables due to the capacitance increase causing slow rise times.

I know its a big task but its elements, taken in isolation, should be manageable.
The electronics are not complex, and the code for the protacol is well within the capabilities of even the modest modest uP.
In addition, because it will be implimented using basic interupts and timing is not critical it should be possible to port to a huge range of platforms without having to worry about onboard interfaces.

I will be using WIFI, thanks for the link, or bluetooth to comunicate with the HMI/s, android tablets probably, and I may have to impliment Modbus on one host to facillitate that but it will not be a master per se, more a monitoring and configuration gateway so loosing it will not turn off all the lights, heating and vantillation.
In fact, once configured, provided a host controlling a light can hear at least one switch that it is mapped to that light will work, no matter what else is or is not coinnected.
What I do not want to do is build a system that relies on a single God node, controlling everything or even have to worry about what address a new host has. All devices, several within each host, will start with a fixed host address innumerated by the number of devices.
When configured, online, each device address will be set to 8 host bits followed by 4 device bits the latter being hard coded.

I seem to be having some trouble getting folk to view this project positively, which either means I am way off base or a little more imagination is called for in some quarters.

I really apriciate your comments as I think my plan, well outline plan, is worth persuing but I am well aware that a little input and critique will go a long way to making me address all the issues I haven thought of yet.
I am pretty sure that every protacol we have, and there are literally hundreds, fixed a specific issue or even a set of issues and if Square D think that the stock go-to serial networks do not fit well in home automation environments that I am not entirly mad to aggree.

Cheers,
Al

 

I was just about to say that hard wiring a home seems like a lot of work when wifi will do the trick.

 

your having a hard time Ah.

Yes were sceptical,
I guess cause most of us are well used to this stuff
but may be we value our time , and know that if something off the shelf does the job,
use it, its going to be cheapest , both short term and long term
and most reliable.

BUT

the future is only found by experimentation,

do you have to get this past the partner ?
or can you play ..

I'm only looking at the physical / electrical points,
My thinking in terms of protocol is 'thats just software'. ......

The amount of pickup on long wires always amazes me.
if you have a differential receiver, dc coupled,
and its powered with a ground reference,
then if the two inputs rise to 12 volts, your chip will blow.
unfortunately it might not be immediate, but it will degrade and eventually fail.

As for that 15Kv protection,
thats not "real".. If you wire the input to 20 volts, it will blow,
Thats Human body spec, which is with a series resistance of a few M ohm.
its basically to say its ESD protected, wont blow if you touch the pins with your fingers.
which is great, but wont save you.

RS485 / 422 is great,used it many times,
Your going to be running it over many rooms ?
ground voltage different in each room ?

I'd break this into parts,
the software / protocol is 'easy' , so lets not worry about that

What I'd play with is over the sort of distances our talking about in multiple rooms,
a simple hook up of the tx / rx chips on vero boards ?
long length of cables, multiple power supplies, out with the scope, see how it looks,

 

Cant argue with any of that, well almost any.
Yes I have time, or at least will make time to play and no, just me.
However the point RE long term stability and standard parts is well taken, I dont have unlimmited time.

Somone, actually several somone's, once told me that standard control panel circuits for micro hydro wasn't possible and even if it were it wouldn't be cost effective or worth the effort... I didnt listen.
Now they want standard code blocks and drivers to reduce the engineereing time even further when using my standard panels...
They have even committed to commonality for physical interfaces so I have a fighting chance of writing them!

I like innovating, it give me a real buzz when it go's according to plan, of course it just as big a headache when it doesn't but that is what development time is for.
I am pretty sure that there are plenty of folk here who would tell you you cant connect a 3 phase motor to a single or split phase supply, without even bothering to worry about synchronisatrion and then generate with it, and yet I do it daily, and we are taking about anything up to a couple of hundred kW here not toys. I even worked out how to use a 230/400 machine to generate at 460V single phase. (Split phase), without requireing a custom wind. Its not that I am claiming to be some sort of genious, I just dont see the need to stay in a box for no good reason. Once in a while I make smoke but mostly I make progress, what's wrong with that as a life plan?

Limited testing, definatly, in fact I will do that, looking at signals, long before I start mucking about with code.

Ground ref will be the same for all components, at least it will be the same supply but as the cable length will vary significantly and it is relativly small there is definatly a potential for a ground, and as a result the 5V rail, to be slightly higher on some components than others.
(Components as in system components not at board level.)

That is one of the reasons I decided to go with dedicated driver chips.

RE pickup... The only thing you said that I am not entirly in aggrement with.
I could be wrong but I think that the drivers compensate for that, actively driving each line to a given potential.
That coupled with termination resistors should keep things in check.

I haven't had much cause to go investigating RS-485 as it usually just works, hence my choice of chip, but where I have measured disconnected and driven cables the noisy ones all seemed to get dragged into spec once hooked up.
Obviously I apriciate that there are limits but I haven't found them yet...

I guess I will find out whilst learning a thing or two...

As far as the wires verses wireless argument go's I think wireless definatly has its place but there is a reason you simply dont find M2M applications, beyond the odd HMI using wireless coms.
Is there a potential for me to run in to issues with a wired network, definatly... But the same is true of wireless, particularly given my goals.

If I was to go wireless, an I have seriously considdered it, I would want to be building a PAN Mesh and in multi master mode with the opertunity to define message priorities that requires some considderable effort and clever code.
I know this because they exist and they are anything but cheap.
To be honest I might even considder buying dedicated nodes, if I could find any that were not firmly embedded in an existing system at a silly cost. The wifi module you suggested I look at is very interesting, in fact I intend to buy a couple to play with but I do not know how to go about making a multi master mesh using them unless I simply slow everything to a crawl and give every node a time slot.
Do you know how colisssions are handled on WIFI, I dont... Reading I think.
Of course stuff still needs power so only control would be wireless, worth a look though.
Given that you sound as though you know what you are talking about I would be silly to dismiss out of hand I think.

Perhaps I am being a little blinkered, if so it is because I am confident I can make a wired solution, even an out of the box solution, work.
Not to say there will not be challanges but the plan is hardly a new wheel, just a few spokes from exiasting wheels that should still add up to a rounded solution.

Off to look at wireless options, just to make sure I haven't missed anything...
Thanks,
Al

 

My Chips,
I agree but it depends on the trick...
Off to check just in case I missed it as it were.

Popular opinion isn't always right but it is always popular for a reason and in this case I will concede that I may have missed something.
That said there are plenty of folk saying, just use this or that wireless solution but I haven't heard a cogent argument that address my project goals yet...

Happy to be proven ignorent here, multi master PAN Mesh using cheap wifi modules anyone...
I would get behind playing with that if I could work out how to do it at all.
Please note though, I am not interested in master multi slave unless there is a very compelling argument to go there.
Some kind of wireless hub to broker messages and schedule things... With fail-over to a redundent hub....
Workable I guess, pitch me a wireless version of that, or simmilar, and my interest will be pricked.
Its not that I think wireless is a poor plan, it is simply out of my comfort zone and I believe brings more complexity than I have to dael with but I am willing to learn if anyone has specific suggestions.

Thanks,
Al

 

http://www.instructables.com/id/Simple-Arduino-Wireless-Mesh/

This saved me a bit of time typing...
Essentally my experience of mesh networks, which is not in the least extensive, is essentally what is described above, timeslots and synchronised clocks, for scheduling messages not data clocks.

Obviously I apriciate that there are better ways but I cant find anything that is fundamentally based on broardcast packets which means every node would need to know where to send a message and would then send a descrete messaage to everything that needed the data.

Considder adding a new light, to brighten an existing zone, to an existing schema...
Using a conventional network aproach every switch, or device event, that operated the existing light would have to be reprogrammed so it also commanded the new light. Or, the origional light would have to be programmed to trigger the new light, as a slave.
Neither being a good plan.
In a network fundamentally based on broardcast packets, only the new light would need programming, to listen for a set of switches or an event from the old light or both.

Am I missing something... Surly the latter aproach is better.

Al

 

Hi

MESH networks, et all,

great idea, many standard modules around, that you talk to just like a serial port.

the modules handle all the timing / protocol etc, you set them up,
like you would say an Ethernet, then you just send / listen to your stream.

this might be of interest

https://electronics.stackexchange.c...-low-power-short-range-wireless-communication

Things like Wizbe / XBee / LoRa / even bluetooth ...

The arduino range is just so easy to use, and low cost, Id be very tempted,

I like the Teensy range from Paul,
the 3.2 is possibly what your looking for as a processor
https://www.pjrc.com/store/teensy32.html

but there are many other options,
if you have not used arduino, strongly suggest you get one and a few leds / switches / variable resistors / speaker to play with
they are real friendly, and have great communities to help you learn.

have a play, and see what you think of them

 

Nasno, well Nano clones,. are my goto although I avoid FDTI based USB because of the none genuine driver issues.

The last lot bought had some odd USB chip that took ages to find a driver of but I got there.

I have now spent ages looking at wireless options and I have to admit there are attractive possibilities at reasonable prices, certainly no more than serial driver chips would be.

However I dont want to be tied to using unicast traffic so thew list is considderably forshortened.
That said simply placing a serial message into a buffer to be sent and letting a module worry about the rest is definatly a realistic and very attractive option.

I have been looking at NodeMCU as a total solution but the ESP8266, suggested earlier, coupled with a Nano is a better fit.
I dont want to get into wireless in this thread, I have another one running, save to say I think I will order some to play with as I will need to impliment multicast UDP, or something simmilar.

Haven't given up on the wired Idea just yet but I am moving that way I think... playing to do though I think.
Still I like signals in wires because you always know where they are and the physical layer allong with colission handling is simple, comparativly spaeking. Not sure I would know where to start debugging WIFI if it wasn't stable... the complexity is astonishing when you start looking under the hood as it were.
Going serial over WIFI seems to make sense though if the modules are stable and perform well, but I will still need a custom protyacol at a payload level.

Thanks all, I said I wanted to be challenged and now that I have I am learning.
Al

 

Your instinct to go wired is a good one- in the long run, it will be much more reliable, wireless is never 100% infallible, when it doesn't work, it can be a nightmare. Everyone has experienced "that one spot" in the house where the WIFI just doesn't work.


Distributing power in the cabling saves cost and complexity as well, with the added benefit is having a nice reference ground for your COM signals.

You have not mentioned how much data, and how fast it all needs to move, without knowing this, it's hard to make hard and fast judgement.
For example, you have stated that star topologies are a no-no with RS-485- well yes and no- if you don't need blazing speed, use nice slow edges and you can make almost any sketchy topology work just fine- run lamp cord around trees if you want, it will work just fine. Reflections are an issue with fast signals, but not if cable runs are relatively short and edges are slow.

 

Honestly, the faster the better, functionally speaking, but in terrms of absolute speed probably not much.
Payload will probably be 16 bits of header and another 16 of data for 'normal' messages.
Configuration data may well be longer, perhaps 32 bits, I haven't written the spec yet.

Even if I TX everything twice, as a simple solid data check, that would be 64 bits for anything that actually matters in terms of system response time.

At 9600 that is about 1 messaage every 6mS, but I would like to go to circa 31000, using PWM as a clock base, because it is simple which is a message every 2mS or so.

Too be honest if a switch took 20 attempts to send its payload at at 4000bps that would still only represent about 320mS of latency which wouldn't be unworkable. Especially as it is very unlikely that 20 priority message will need to be sent in the same second.

Obviously faster is better but there is scope here to handle interupts and wait for contended packets even at very modest clock speeds.

If I use timer 2, so I dont muck up the mills function, the standard PWM frequency is 3921 Hz and can be modified to 31372 without altering the resolution. Using a 2 bit resolution, which still give me a 25% base duty, it will go to 4MHz but the interupts couldn't possibly process that.
The point is I can probably pick a speed that leaves plenty of time to process interupts, for every bit, act on the buffered message and still gat a reasonable system response whilst generating the clock using hardware.

I have a box of CAT5 kicking about so my first test will be sending a pulse streame down the entire coiled 305m length to see exacxtly what is and is not possible. Whatever works in that scenario should work with any cable run I may need...

I apriciate the comments, I was beginning to think I was just being silly or outdated.

It also ocured to me that there is no reason I couldn't impliment wired and wireless coms, with a gateway of some sort obviously, which would offer flexibility and allow me to use either, depending on the circumstances.
Perhaps wired switches and wireless appliences.

The more reading I do the more comfortable I become with the wired option, despite the bunch of cable.
Yesterday I was leaning towards wireless but additional raeding has revieled a raft of potential stability problems, essentally because the wireless option is by design several orders of magnitude more complex and much of that complexity is very hard to muck about with.

The design of my house will place cable ducts within relativly easy reach of every door frame, wall, ceiling and equipment cupboard so wiring, even after we decorate, isnt going to be a huge issue.
I also plan to flood wire from the outset with multiple pares to all room corners allowing audio, video, ethernet data, or anything else for that matter to be destributed.

Signal tests on cable this weekend I think...

Al

 

If you have decided to go with a wired solution, I would recommend RS-485.
This can handle rates much faster than 9600 baud.