Serial network

Forum 2005-2010 (read only) Hardware Development
1

Hey all

I'm currently working on a project which needs around 20 networked arduinos.

e.g. There is 1 master and 20 slaves.

each of the 20 slaves has a piece of data it needs to give to the master based on its sensor readings (about 40bytes per slave).

my current plan is:
attach the TX of the master to the RX of all the slaves. This is the 'request channel'
connect the TX of each slave through a relay (per slave), and then connect together to the RX of the master. This is the 'reply channel'

The master will call out the ID of each slave one by one, e.g.
call on request channel: "ID 0"

then slave #0 will reply. It will engage its relay so that its TX is connected to the masters RX. then it will send its data, and return the relay to unconnected state.

Then the master asks for ID1's data, ID1 replies, etc etc

is this a sensible enough way to go about things?
is there enough current in the arduino's standard TX to feed 20 RX's, or do i need to use a transistor here?

also is the relay even necessary, or can multiple TX's be connected simultaneously to 1 RX?

do i need to allow some time for the different TX's to sync with the master's RX when each one is connected?

speed isn't a huge issue. this only needs to be performed once. ideally all 20 slaves can be read within 5 seconds. also this operation will only be performed once or twice per day.

i think the broadcast ID, reply through a relay is quite an easy solution, if not entirely the most elegant.
I2C looks like maybe another option, but i dont understand it entirely yet. (reading through http://www.neufeld.newton.ks.us/electronics/?p=241).

opinions? :slight_smile:

2

I am thinking i2c would be a better solution. Then you can address each one individually.

You set up one as a master, then set up all the rest as slaves, give them an address etc. Then the master 'connects' to an address and the slave replies with the data requested. It's not difficult once you know how :wink:
There are many examples around.

Mowcius

3

one issue with i2c seems to be short range (afaik, it's generally designed for internal systems to communicate with each other)
these units are going to be up to 5-8m away from the master.

does anybody have any experience with pushing i2c that far?

regards
Elliot

4

If you need distance and an addressable capability, have you looked at rs-485?

5

afaik, rs232 is good up to 300m, and rs485 is good up to around 1000m

i need about 10m so rs232 is perfect (especially because an atMega168 already supports it)

i understand that also the multipoint protocol of rs485 would be nice, but it would be more complicated to implement (and because of the balanced signal, require more data lines).

thanks for the suggestion though. good to keep eyes out on other options.

does anybody have any opinions about the modified rs232 method that i proposed with relays? i.e. is there any reason why it wouldn't work?

6

Well if want to try and eliminate the relays (cost money, takes up space, slow, etc) you might consider just using diodes on the slave transmit pins. Wire a diode at each slave with the cathode lead towards the xmit pin, wire all the diodes anodes leads together with a say a single 5k pull-up resistor to Vcc and the common diode leads wired to the master's rec pin. This makes a large 'wired-or' gate and as long as only one slave at a time will respond it should work fine.

Lefty

7

Hmm... control of the relays, would that be left to each slave to operate?
Then make sure that there is a timeout, where it will release the relay, or you could end up with two slaves trying to talk at the same time.

rs-485 requires two wires, and 32 units can be connected to those two wires. I'd recommend that you look into it further.

8

ah interesting.

i've been thinking about this a bit more.
and because of the topology of the system (everything in the system is held by 3 metal structure elements), it would be great if we could use the structure elements as the power and signal.

however, this would mean that we'd need a 1-wire communications protocol. I saw this one

that uses 2 wires total. 1 is power and signal, the other is ground. which isn't what i want, because i have to have an arduino performing the communications which wouldn't be powered by the 1-wire protocol.

it seems that rs485 could use 1 wire theoretically. (by removing the balanced signal and sending everything down 1 line). this would of course make it a bit more vulnerable. perhaps with our 5m range it would be ok though..?

tanks for all the help so far. i appreciate it a lot :slight_smile:

9

With TTL/USART (and also RS-232) you can have multiple receivers, but only one transmitter. So this would be a limiting factor for your project. Short range, duplex, moderate speed, susceptible to noise.

Dallas 1-wire needs two wires (data and ground). Power is optional and would not be relevant for your setup. There is a 1-wire master library available for the Arduino. This would probably work without additional hardware, but you may have to write the client side yourself. Short range, simplex, low speed, susceptible to noise.

Rs-485 needs two wires (preferably a twisted pair). You need a terminating resistor at each end of the cable. Each Arduino will need a transceiver. These are available in low cost 8-pin packages and are easy to interface. You can have 32 devices on the bus. Long range, simplex, high speed and virtually immune to noise. Seems like a perfect fit for your application.

10

The main attraction away from RS-485 was to reduce the number of necessary connections. Anyway, that's not an issue anymore so i'm proudly putting my RS-485 pants on.

One thing that's come to my attention, is that the network 'clients' are mostly just reading values from phototransistors. In fact, the rest of their functions (some maths) can be moved to the master. Which suggests looking at a network of RS-485 ADC's.

Does anybody know any chips that can perform this function? Preferably need 8-16 channels. I guess controlling multiplexers with this kind of method would get complicated.

and just to let you know. google wasn't a very good friend so far for this one. :slight_smile:

11

sorry. i'll summarise that
does anybody know of any networkable ADC's over rs485 or another protocol
essentially I need each slave to be an ADC with 8 or 16 channels.
I need about 12 slaves that can be individually read from 1 master

12

No way I'd use relays, the thing would be clacking away like an old typewriter :), not to mention reliablity issues after 1,000,000 activations (OK maybe not with 1-2 times per day) and the size of the relay + transistor + diode to drive it.

What about LIN transceivers, they only use 1 signal wire (ie not balanced but noise immune enough for vehicles). Some LIN transceivers also have a tx timeout feature that stops a slave from killing the bus. Your original "protocol" will still work but instead of controlling a relay you just transmit after being told to. No delays will be required but if it's important information you're dealing with you need more error checking etc than you've mentioned.

RS232 cannot be tri-stated so not much use for a multi-drop system, unless you connect them through some relays :).

it would be great if we could use the structure elements as the power and signal.

That will only work if the metal structure alements are electrically isolated. But in general I think it's not as reliable to use a chassis for power, and to use it for both power rails is leaving you wide open for a massive flash-bang when someone drops a screw driver. If you have to run one wire you may as well run a 3-core.

I'm not aware of any "networkable" ADC's as such, but depending on your resolution requirements most modern uCs have inbuilt ADCs so they are affectively what you need (just add programming). If you need a serious ADC then add an 8-pin uC to read it and talk to the network.

13

"PS2" (pre-USB) keyboards and mice use I2C.

You sure about that? They look similar, especially electrically, but the protocol is different. PS/2 has start, parity, and stop bits in addition to the 8 data bits, where I2C has 8 bits and the ACK bit.

-j

14

You sure about that? They look similar, especially electrically, but the protocol is different. PS/2 has start, parity, and stop bits in addition to the 8 data bits, where I2C has 8 bits and the ACK bit.

They don't use i2c...

15

This local lab has a 100m i2c cable. The key is sheilded wire and data redundcy.