Help with RS485

Have you thought about using star bus topology? More wire may be necessary with a star than a linear bus so the total capacitance would be greater, thus limiting network speed. But for RS485 drivers this is a rather slow network anyway. You may need several cable drivers at the hub to cover all 75 star points.

 

A pure star would have 75 different network segments, but a star bus could be all one single network segment, or it could be a hybrid somewhere in between.

 

I think I would use a unipolar current signal on a twisted pair in each direction, with an optocoupler receiver - like MIDI but with a much slower data rate (1200~2400 bps standard asynchronous; idle = no current) and somewhat lower impedance and defined termination.

You could use RS-485 for point-to-point (or you could use RS-422) but I think a simple current loop would be cheaper and your data rate is not high enough to justify those other circuits.

With a star configuration, I would have individual path selection for the Master's transmitters, so you would only transmit to one device at a time, selected using about eleven 74xx138s or five 74xx154s.

I'm not even sure you would need isolation. That data rate is low, the 0V rails of the slaves are connected to the 0V rail of the master by the data cable, and the environment is not electrically noisy, so simple unipolar, unbalanced data, with the 0V wire(s) carrying the return current, and some capacitive filtering ought to work. In other words, a simple logic-level signal in each direction. In those circumstances, is there any need to keep return currents contained within a twisted pair?

Another thought would be transformer coupling for power and signalling. Would you gain anything by having a single twisted pair to each slave instead of four twisted pairs? Do the slaves all need to be powered constantly? Or could you just power each one up a short time before you interrogate it?

 

I apologize for joining this discussion so late in the game, but it appears that the Dallas Semiconductor One-Wire conversation has run its course. So, after reading @FuzzyWombatSoup 's last post, I thought I would jump in here. Starting over from the original post:

Serial output ADC is a PITA for networked sensors. Better to poll each sensor for data temporarily saved in a register after each conversion.

If I have interpreted your last post correctly, you have concluded a μP at each star node is the way to proceed with your project. You need just one bi-directional RS485 transceiver at each node. It remains in "listening" mode until that node is addressed by the "master" at the star junction, presumably a PC of some sort.

Sure you do. That's why us old farts invented them. Think of modern μPs as "smart" components, on par with resistors, capacitors, etc. but with more than two leads.

The master node should be one or more RS485 COM port(s) on the PC that is running the show. If your PC needs an RS-232 to RS-485 interface there are USB versions available, for example here and here. IIRC there used to be PC expansion cards available with RS-485 ports. I like the USB version because it installs as a virtual COM port. If no data is being sent or received it presents a high-impedance "listening state". As soon as you send a byte to the virtual UART it becomes active.

I like the idea of using a MAX485 at each node.along with an Arduino μP for local data acquisition and control. If I were going to make 75 of these nodes, I would probably use a Texas Instruments MSP430 series μP with built-in ADC. But that's just a personal preference because I happen to have a few avaiable on USB sticks to play with. I would also design a dedicated PCB that is the same for each node, much like the link in your post.#4 except it would a "smart" node with an RS-485 interface and dip-switch selectable termination resistors.

There is a solution to using RS-485 in a star topology network with 75 nodes. That is way too many nodes for your typical RS-485 transceiver, so make a triumvirate of 25 nodes each. Each remote node CAT5 or CAT6 cable is terminated in a 8P8C modular connector (RJ45) on each end. At the central location of the star "node" each cable plugs into a mating jack that then daisy-chains 25 nodes together on a centrally located jack panel. Since your are using CAT5 or CAT6 cable to each node, and you only require one pair for RS-485 and a second pair for power, a third pair, of the four pairs available, will allow each of the 25 nodes to be daisy-chained back to the star "node" where 24 of the 25 connections there are loop-through to other nodes. The 25th node connects to an RS-485-to-USB converter. You do this three times for 75 nodes. There will be three virtual COM ports communicating with 75 nodes. You can expand this to as many nodes as you desire, providing a different COM port for each group of 25 nodes. Actually, I think you can have up to 32 nodes on each COM port, so the original triumvirate can handle 96 nodes. Depends on the size of the manse I guess.

The daisy-chained RS-485 nodes will need terminating resistors at the far end (the first node of each triumvirate set).

 

Good advice from Hop as usual.

Maxim make several MAX485-alikes with 1/4 unit load so up to 127 of them can be connected on a single bus. See MAX487, MAX1487 and MAX3430.

 

.

Thanks, Kris. I didn't know those parts existed. So @FuzzyWombatSoup can implement his "star" with just one long daisy-chain.

On a slightly different note...

One of the nice things about having a μP at each node is you can easily program the address of each node. There are zillions of ways to do this. My personal preference would be to use a Dallas Semiconductor or Maxim DS2401 three-terminal "silicon serial number" device at each node. The master would record the node serial numbers in a file, along with configuration information appropriate to that node. In poling the devices on the network, the master sends an ASCII string containing the node serial number and only that node responds. Timing is completely under the control of the program interrogating the nodes.

Nodes with slowly changing data could be polled at longer intervals, but it is possible some nodes would need to request immediate attention... fire and smoke alarms, intrusion detectors, water flooding sensors and the like come to mind. Since there is a spare pair of wires in the four-pair cable, it would be fairly "easy" to implement a daisy-chained interrupt request for all nodes. This is not as easy as it sounds because of the asynchronous nature of interrupts. There has to be a mechanism to "lock out" nearly simultaneous interrupt requests from multiple nodes, which can occur in the time interval between when a particular node asserts an interrupt request and the master responds to that request. Ethernet solved this problem a long time ago with variable time delay collision avoidance algorithms. The timing required is a function of the round-trip time from interrupt assertion to interrupt acknowledgment, which depends on how long the cables are. It's a fun problem to solve.

 

Yes, there are lots of approaches and it's interesting to think about. The easiest one is to avoid the need for slaves to initiate communication! That's fine if the data rate, and the polling rate for the whole population of slaves is high enough that critical events are detected in an acceptable time. Specific critical slaves can be polled more than once each time through the loop to improve their response time (at the expense of delaying others).

Collisions could be avoided by having the Master transmit a "slave transmit opportunity" character or message; each slave measures the time from that message and is allocated a transmit window. A slave will start transmitting during its transmit window if it has urgent information to send and provided that no other slave transmitted anything during earlier transmit windows. When a slave transmits, other slaves cancel their transmit opportunity and wait until the transmitting slave's message finishes; the Master must then issue another slave transmit opportunity. This could allow one slave to hog multiple transmit opportunities and prevent later ones from transmitting; this can be avoided in various ways.

As long as there's a multi-drop bus and all devices can receive all data on it, these systems can be retrofitted if necessary after the basic poll-response system is working. Broadcast and multicast can also be retrofitted.

 

Yeah, let's get the wheels attached and the motor running before worrying about the bells and whistles. Sorry I digressed. Time to go to bed.

 

Hi again and sorry for the delay getting back to this thread!

I've reviewed the thread and I don't see how full duplex would help. All it means is that you could transmit data in both directions at the same time. Since you would probably use a poll and response protocol anyway, the only advantage of full duplex is that you could transmit the next poll while the previous device is sending its response. You would need some way to prevent the next device from starting its response until the previous device had finished. So apart from increasing your bandwidth, I don't see any advantage, and the expense is two extra wires in the daisy chain. I don't know what the "interrupt issue" is.

Quick response to slave-detected conditions might be difficult to build into the protocol. I would favour using a higher data rate to give a guaranteed maximum delay. What time frame are you expecting? For example, say you use a data rate of 230,400 bps, asynchronous, that's 23,040 bytes per second, divided by 75 slaves is 307.2 bytes per second per slave. If a typical message exchange is, say, 20 bytes maximum, including framing, with minimal delays between messages, you should be able to poll the whole lot of them ten times per second. Would a 0.1 second alarm delay be good enough? If so, a lower data rate would be easier to handle.

I recommend the AVR for the slave micro end. A good match looks like the ATtiny441 (http://www.digikey.com/product-detail/en/ATTINY441-SSU/ATTINY441-SSU-ND/4437432) which has a 10-bit ADC with up to 12 inputs, two UARTs, and three timers, in a 14-pin SOIC, at USD 1.55 for 1-up or USD 1.12 at 100-up from Digi-Key. The AVR serial port can interrupt on transmit complete, not just transmit data register empty, which is good for RS-485 because you get accurate control of transmit disable at the end of the frame. They also contain EEPROM for setting the RS-485 bus address (or you could use the "silicon serial number" IC suggested by Hop earlier).

Yes you could split the RS-485 network into several subnets to increase the bandwidth. I also like the idea of having a module between the PC and the RS-485 networks to handle the RS-485 bus timing requirements; I would recommend this even if you don't split up the RS-485 network. The processor on this board would need to be more powerful than an AVR though. An MSP430 would be a good fit, and their serial ports have DMA capability, so the data can be sent and received automatically at high speed, but they only have four ports maximum. You could use external UARTs but you might not get DMA capability.