I have a question in the networking section discussing protocols so I don't want to get into that here.
To the honest it raised as many questions as it answered but that may be a good thing....

So electrically speaking I want to have some/many devices on a buss of some sort.
It needs to be using cat5 which will carry data, one pair, audio, one pair and power, two pair.
The power can be used as a reference if needs be.

Now Obviously I could use 485 and buy tranceevers but from what I have read I don't believe it will work in a star topology basically because I can't keep weddings termination resistors.
I may have only understood the highlights but I think I understand that unterminated legs will reflect and generate issues.

Could I buy / build a 485 hub to fix this and if so would it be transparent ore would it device and then subsequently retransmit packets?

I am working with Arduino... Could I simply, ok perhaps not simply, build a bus using line drivers and if so given that I will want modest distances, perhaps as long as 50m, what electrical considderations are there.
Should I considder keeping TX and RX discriminated so that all buffers are one way. 232esque.

I may want to colossian check bit by bit - Is a high pulled low a practical solution to potentially having multiple drivers talking, even if it is only for part of an address word.

Should I be thinking about current or voltage... I assumed that there could be significant delay whilst a couple urgent pulse rises against parasitic inductance but I also realise that there is always current. I suppose what I am. Asking is how to minimise rise time on long legs.

As I said I realise that the hardware is only part of the story but the software is more flexible so it seemed reasonable to look purely at signals Jon this question as opposed to getting into protocol layers.

RE protocol, just to clarify,
Everything needs to listen to everything all the time.
Something, as they undecided, will prevent more than one device talking at a time.

Is there a hardware spec that will do this already? I ask because buying drivers may be a sensible option.

Is there any reason I can't simply pull up a line, in the hub and at its termination, and then pull out down with an open collector output when encoding data. would doing this with reciprocal lines and detecting Colossians using LoLo have any advantage, electrically.

I realise that the protocol will have an effect on these answers but I have to start somewhere so begining with some decisions, or at least options, for the hardware layer seems a reasonable plan.

Lastly, I suppose in absolute terms this does not need from be fast but I would like to explore predoctoral speed limits once I have a shortlist of possibilities.

Thoughts?
Thanks,
Al

 

1) Attempting to put audio on the same CAT5 cable is asking for trouble. You are going to pickup digital cross-talk from the digital comm.
If you must transmit audio, then digitized the audio and send it digitally using delta-modulation.

2) If you insist on a star configuration then that brings you back to a hub and there is nothing wrong with that.

 

Very good point RE analogue audio, that would be two cables then... I wasn't thinking about data on the audio, just that the audio probably wouldn't muck about with the data... Silly me.

I am fine with a hub and to be fair if I am freeing up a pair then I can split TX and RX which massively simplifies the hub.

Star... It isn't so much insist as layout and practicality.
I did consider a single line but came to the conclusion that I would still need many devices at the end of cable runs so that would either be 2 cables or a feed and return pair in one cable... either way the lengths go up quickly even in a small space.

Additionally I want to supply power DC to each device POE Esque and a single circuit for that simply dosent add up.
It may work with sensors and switches but driving anything chunky would become an issue.

I have to say that if device cost wasn't an issue I would probably go with ethernet, the problem is the overhead and the hardware required to handle it... not give up on that yet though, it has too many attractive points to simply dismiss.

The annoying thing is that what I need/want, functionally, isnt that taxing, juts just that for the most part networks are designed for devices to talk to speciffic peers and not to form a fluffy space into which many devices push data.

Of course for home automation that is exactly what you need... push a switch and a message go's out foe anything interested in that switch to act on.

Anyway enough with the protacol... thasts a different thread.

Any thoughts RE synchronous data, could I utilise a fixed clock and vary the pulse width to encode 1/0's
I am asking because it woule be a neat solution to collision detection without loosing data.
TX lines would need to be pulled high, or low, passivly, and then driven from 1, or some, nodes to encode data.

I was planning on using 30 odd V for the power, is trhere any advantage, or disadvantage, to lifting the data that high.

Cheers,
Al

 

I am pretty sure I will go with I2C, probably slightly modified to add a broadcast address.
The standard supports multi-master and uses almost the mechanism I envisaged, at a device level to handle master conflicts.

I am closing this thread to ask a more specific question RE signal levels.

Thanks all...