Multi drop com port

Using Arduino Programming Questions
1

I am wondering if it is possible to make the RS2332 port a multi drop port by making the output Open Collector and providing a pull-up for communication rather that setting the port high internally. It would in my way of thinking allow several devices to share a set of pins which are scarce on an Uno. Spi and I2C are Ideally the ports but both will be busy in the design I have in mind where devices are broadcast to and the software in the 'receiver' reads the ID and then calls the appropriate function to deal with the communication. The same would work for 'Broadcast' communications to peripheral devices. I will have severaal devices that must communicate with the Master device, A scrolling display, X10 Communication from my 'console' and from remote devices, remote collection of termo and hygro information as well as local barometric data. I am using a GPS receiver for time data and because of the receiver limitations might have to be remoted to a better location. Ultimately this thing will also handle a radio and several gigabytes of MP3 files both from my bedside console and from at least one remote. So I have a need for one common radio/serial I/O port, just for communications. Perhaps the I2C would be best but the speed of communications comes close to the capacity of the Radios, whether I use a 4432 based 433MHz based comm link or I use the Nordic devices. I don't quite think those little 433 OOK devices are capable of the task as busy channel arbitration is a big issue to be handled in software... Any Idea's???

Doc

2

You need to draw a diagram to get your thoughts collected & clarified. Your list is too all over the place to follow.
You have stuff that will only respond when queried, stuff that will output all the time, stuff that is wireless, and sounds like multiple processors even.

3

My thoughts weren't well expressed, all the connected devices will be queried (I do understand babel).
The link will broadcast time globally and other information locally, all devices will have a set of conditions or device parameter list so that information goes where it is intended.
The transmissions will be short requests/commands and short data streams @ 9.6Kbaud from those devices that collect data.
It is very possible 2 different radios will be used as one of the task's is to monitor a small greenhouse about 100 meters from my room (Temp humidity and intrusion and possible lighting control). Multiple processors? likely.
I really don't think that any of the communications except time are of prime importance so any other comm can fill in the open periods when time isn't being broadcast to the units that use it.
I bought 2 16MHz 5V Pro Mini's (10.00 ea I coulldn't pass them up) for peripheral control like the outside monitoring and I own a Mega as well but I'd rather not use that until I have to. The real reason I got it (besides it was free) was the number of serial ports... but that makes no difference... really as only one port can be used at a time.
I have both the Nordic nRF24xx series radios as well as some SI4432 433 mhz Programmable radios that could do the tasks as well or be used for sidebar or secondary stuff like the intended X10 control functions.
Scattered as it might sound it is actually a project I have been thinking about for 5 or 6 years, I got the germ of an idea from one of theose weather station things that have 2 or 3 external sensors for temp and humidity.
At the same time I had a complete BSR X10 controller/clock that I really liked, My wife and I used it to great success to cool our house. I used it to turn on 3 big fans in the windows on a second floor apartment. It worked Very well... So still having several of the switch boxes I bought the modem to make another one (actually three, I bid on one I thought I would never get and bought another for the same amount as the first two... I was really hoping my ridiculously low bid would get over bid... got all three NEW too for $55.00 ($59.00 retail ea.).
I don't think that If all the transmissions have proper headers and that If I implement a don't speak until spoken to concept that it will be an issue... But I wanted a second or third or... opinion

Doc

4

"If I implement a don't speak until spoken to concept "
Can you do that with GPS? I was under the impression they just sent data out continuously.
I suppose you could buffer its output to the Rx pin, keep it off the bus when you want to receive something else.

5

Of course you can implement RS-232 with open collector, but then of course it's not RS-232 :slight_smile:

Spi and I2C are Ideally the ports

Not good for long distances though and you can't multi-drop with SPI.

handle a radio and several gigabytes of MP3 files both from my bedside console and from at least one remote

If you mean streaming this over the network that is a whole different ball of wax. Not practical with this sort of scheme.

I would add a processor at every node with interfaces to other IO devices as required and also use them for wireless "gateways" to another network in the shed, etc. This gets around the problem of a GPS expecting to just blurt it's crap out whenever it likes.

I have been thinking about for 5 or 6 years

And I for about 3. Have a look here for my version.

http://busnet.robgray.com/index.php

If you can wait another 5-6 years I may even get started on it :slight_smile: Actually I've just bought some hardware to make a start.

As for the protocol I favour a publish/subscribe model where everyone transmits their information when they like. That way you aren't dependant on a single master to run the system.

I can send you the current design doc if you're interested. Email me if you want to look at it.

Rob

6

Of course you can implement RS-232 with open collector, but then of course it's not RS-232

You're right, it's not RS-232.

It's RS-485 :stuck_out_tongue:

7

First as usual, I wasn't too clear, the multidrop was preferable because of software serial. All the communications are in one small box. "Bus Drops", items are things like the clock... And Yeah it spits out a lot of crap But there is no necessity to do anything but transmit it once a second... on the "Bus". it ends at a radio and what ever other services that need the clock as required can listen as required.
Not RS232 because of open collector?... ??? If there is an external pullup... Who will know??? It still works the same... But without the "Driven" output there is no bus contention... because the "Resistor" is asserting the "Bus" not the transceiver (RS232 Device). The other protocols (I2C and SPI) can be done with twisted pair or it's equivalent... For short low speed runs that are pulled up hard enough, 470R to 2K2 max pull-ups will enable 6 to 8" runs of wire. THe smaller the value of pull-up the greater the noise immunity or longer wires (Lower impedance) more current and because of the higher current longer wires can be well tolerated without compromising noise immunity.
Majenko..., I always thought RS485 took 3 wires, two for "Differential Data and one as ground... All three required... RS232 only requires two Tx OR Rx and ground.... Maybe you know something I don't?.
Busy arbitration is Most easily done. it is only necessary to listen long enough to be sure it's free, wait a small but random amount of time, recheck busy and transmit... Or one could provide a status line... Pull it down or up and wait for 50 mS, transmit your message and then de-assert the busy line for the next process
I have 10 or 15 RS485 Transceiver chips of several different flavors and I just don't want to add to the complexity. If one uses "open collector logic" then any transmitter can pull down the Tx line down and the receiver has no way to distinguish that from de-assertion of the bus by the transmitter... So in theory a multidrop comm link for short bits of data (3 to 5 bytes @ 9.6K buad) are very readily possible.
Music later... Yes, Streaming, NO NOT EVER. More like a remote control where a request is transmitted to the "Player" and the Player... plays the "Request", Same for Radio although that is a great deal easier... in that there are devices like that Teac TEA5767 chip that is a fully synthesized stereo FM receiver. It is a module that I will add when I get more experience with the code...
The hardware end I know about... Fairly well or at least I should, having spent most of my working career repairing and later designing electronics equipment, Very successfully I might add.

Doc

8

I did prototyped something similar a couple of years ago. I used open-collector comparators (LM393?), it all worked pretty well and the comparators provide some protection for the processor.

I dropped the idea in favour of LIN and then RS-485. 485 is the industry standard for a reason and you can wire the transceivers in "open collector" mode to do the same thing. LIN transceivers are open-collector and readily available but they have a wire length limit that may be an issue.

So, given that it's a given that you will never connect a processor directly to a long network wire, and that RS-485 can be used in "open collector" mode, I don't really see any good alternative.

Not RS232 because of open collector?... ??? If there is an external pullup... Who will know??? It still works the same

Of course it matters not to the software, but RS-232 is a electrical specification, if you aren't conforming to that it ain't RS-232. Whatever physical level you use it's asynch comms at the software level.

Rob

9

Majenko..., I always thought RS485 took 3 wires, two for "Differential Data and one as ground... All three required... RS232 only requires two Tx OR Rx and ground.... Maybe you know something I don't?.

Three wires between the transceivers, but only 2 wires between the transceiver and the Arduino (at that point it's normal TTL RS-232).

But hey, there's no reason why you can't have multiple stations listening on a wire at the same time, as long as only one actively drives the line at a time. You could do it easily with no driver hardware whatsoever - just a bunch of Arduinos. When an Arduino's IO is in input mode it's high impedence - not quite like open collector, but close enough. Switch to driving the line for one station only at a time, and while open collector is not strictly needed (only one station driving a HIGH or LOW), it's a cleaner implementation. Alas the Atmel chips don't do open collector (or open drain as it should be - mosfets y'know - I hate the Atmel culture of misnaming things).

Yes, there are dedicated chips around for this sort of thing, and obviously using a higher voltage transmission system, like TIA-232, will result in longer distances and better noise immunity, but for short runs at low speeds that's fairly irrelevant (remember, TIA-232 can work at up to 300m or so with low capacitance cables).

RS-485 (EIA-485/TIA-485) is primarily designed to use a balanced line communication system, yes. However, there is no reason why you shouldn't take the principles of the operation of it and remove the balanced line portion of it. It just ends up as a simple serial stream with open drain transceivers on it which spend most of their time in listen mode.

As you well know, you can make any IO line an open-drain output by just slapping an N-channel MOSFET onto it, but making it bidirectional so it can read as well is more tricky. I find the easiest way is just to use a second IO line as an input, so you have send and receive always available - read from one port and write to another (just remember to write a 0 to the transmit line after you have finished). Yes, again there are dedicated chips, bi-directional open drain buffers, but for a single communications line there's little point in dedicating an entire chip with say 8 buffers in it, wasting 7 of them.

10

You could use SIM20 transceivers " One network could have maximum 255 nodes. " and I am getting 500 meters range with them ...