can i talk to multiple arduinos at the same time with another arduino, in a serial format?

Karim,  further to Peter's reply I have done something similar to what you want to do using RS485 modules bought cheaply from China / Hong Kong. (Have a look on www.yourduino.com for modules and very useful information)  These modules contain the necessary parts to correctly terminate the differential line drivers.  One of the advantages of RS485 is that it can be used to link Arduino's 100's of meter's apart. These modules are easily connected to the Arduino's using either the hardware serial ports or the software ports using softSerial.  There is an Arduino library called EasyTransfer, by using this library you can transmit your data and the address of the recipient Arduino.  All Arduino's on the system receive the transmitted data but only the one with the matching address responds to it.  The RS485 bus is bi-directional so each Arduino can both send and receive data. You can use your own custom protocol as to what information you send.  MODBUS is well supported but was much more than I needed.

Hope this helps

thank you all.

now someone from another department was suggesting the use of Soft Serial ports.

Would anyone here know about this? I have been reading and I found out it is a software approach to creating serial comm with non-serial pins on Arduino. Here is a link:

https://www.arduino.cc/en/Reference/softwareSerial

https://www.arduino.cc/en/Tutorial/MultiSerialMega

now considering that I have already obtained Arduino Micro, I was hoping to know if I can use some of the pins to essentially create 6 simultaneous serial connections? I found the following link for it:

AltSoftSerial Library, for an extra serial port

but there is nothing there for Arduino Micro. I was wondering, on Micro, which pins do I have permission to use for serial comm.?

I very much appreciate your help in this matter.

Regards,

Karim.

the micro should still run the software without an issue but im doubtful if you will get six to run at the same tme, I would think you will run out of memory, RAM etc very fast and have no time to do other things on the arduino

I think you will find that an RS485 aproach or I2C will serve you better and save a ship load of wireing too

another low cost approach would be to use ethernet adapters with each one ot the new and low cost ESP WIFI adapters. All easy to use and can expand way beyond 6 units

I agree with Peter.

I have tried one time only just for curiosity in past and strongly discourage the use of the soft serial method for a good result. Especially in this case that you want to create some kind of network.

Before you make a decision on the kind of networking hardware you need a bit of detail on the spec:

The important things are:

bandwidth - how much data into and out of each data on the network

latency - how long you are able to wait from the time  anode sends out a message to the time it receives a reply from another node

topology - you have drawn a star network with a single master  - is this really what you want

maximum number of network nodes

hardware cost constraints

software cost constraints

distance between nodes

unless you define these things you can't design a good solution

If you can put up with low bandwidth (a few kbit/s per node,) short distances, latencies of a few mS but must have very low hardware cost then a star or parallel connected soft UART based approach will work. If the distances are short you don't need any additional hardware at all. (I've used a soft UART on an LCD display controller talking to another micro a few feet away (did use hardware buffering for EMC reasons) at 2400 baud - many 10s of thousands of them made and works fine but takes far more software effort than using  a hardware UART (we were using an old micro and it's real UARTs were all used for other things.))

If you need long distances and/or 10kbit/s or more data rates  then you need to think about UARTs. The Arduino has a single UART so perhaps your cheapest mid performance option is a a parallel 2 wire bus, using driver chips if longer than  few metres distance between nodes. (See Peter's suggestion.)

So, as is usually the case, provide a bit more information and you'll get much better help.

MK

Thank you Michael,

Here is a topology, as per your suggestion, that could happen. So, I have tried to show that any form of connection may exist between and among Arduinos.

These units are going to be snapped (and stuck) together, so the distance is zero (d = 0).

Communication involves constant transfer of sensor values.

As long as within a few milli secnds, the delay is likely not a problem.

There could be anything from 2 to 10 or 11 nodes in a network. Virtually there should not be a problem in adding more units (other than the increase in delay).

Thanks,

Karim.

Thank you Michael,

Here is a topology, as per your suggestion, that could happen. So, I have tried to show that any form of connection may exist between and among Arduinos.

These units are going to be snapped (and stuck) together, so the distance is zero (d = 0).

Communication involves constant transfer of sensor values.

As long as within a few milli secnds, the delay is likely not a problem.

There could be anything from 2 to 10 or 11 nodes in a network. Virtually there should not be a problem in adding more units (other than the increase in delay).

Thanks,

Karim.

What is the maximum number of nodes connecting to a single Arduino ?

If you thinking like a dice then 6 but if a flat plane then probably 4, one on each side

I am assuming then this is going to be som ekind of educational toy / kit like lego bricks concept ? or like playing scrabble but with physical connections

Peter

Peter, the max. number of nodes connected to a single one would be 6.

so, i am thinking of a swarm of units (like a swarm of robots, or in my case a swarm of sensors).

well it is a bio-medical (tactile sensing) collection of units.

Please advise.

Karim.

Are you going to mix and match sensors where you could have more than one of a specific type on the same node ?

sensor nodes would not necessarly need a microcontroller, you can have a controller that you add sensors too and this could drastically simplify the design

Sensors can be connected via SPI or even easier I2C

leaving only controller to controller communications to be done over the serial and this would be far simpler design

Perhaps if your willing, you can share a little more detail of what your trying to acheive, as currently we are somewhat uessing what would be best for you and this will not be the best way to get good help

Peter

it is quite of a simple concept: you have multiple units that you can mix and match to pave the way for an assistive surface for tactile sensing, which is modular. so the units may be added/removed from the swarm or replaced with another one, with no difference in the performance of the system. as a result each unit (node) consists of a microcontroller that processes the sensors' input, and transfers those values, along with its own ID, to the one directly connected, and ultimately to a base unit. I am hoping this clarifies...hence the sensors are needed, as well as all 6 serial communication with other units. would it be possible for me to make 6 soft serials out of the pins of Arduino Micro? 6 RX, 6 TX, 1 VCC and 1 GND?

Peter,

your suggestion has sense but.

If the nodes should be absolutely distributed on more than few arduino units as we are thinking, I suppose that in this biomedical application there is somethng like the need of a contemporary needs for reading. So the fact that some sensors will work without Arduino it is true but in the meantime I can't see how the sensor data can be processed - near simultaneously - if there is not a microcontroller. If a single Arduino board should dialogate with other six in the meantime the delays can be considered meaningless with the I2C bus interconnecting the units. But still a delay exist.

In a grid like the one decised by karimkarim if every board has a small fixed number of board to dialogate with, it is replicated at least for every central node board. So the small delay of a single board, expands in a topography of this king creating a meaningful delay when there are more "six groups nodes" connected together. There are two possible changes that I will adopt in if I were Karim:

The first is to change the topology to reduce the hierarchy of the boards, adding more cross connections to the board. If every Arduino is connected with all the proximity boards there are more links per board but with a resulting global faster distribution of the data flow as the number of effective delays are reduced; take a look to the modified topology scheme in the following image:

Adding few more links (the dashed lines) to the original topology designed by Karim (the straight lines) the paths are drastically reduced and the average delay to send a generic data package between two board is reduced too. For example, a data packet sent from the board A2 to the board D1 in the original topology should follow the path

[A2] -> [A] -> [B] -> [C] -> [D] -> [D1]

While including the dashed connections to the grid it can be reduced to

[A2] -> [A1] -> [D1]

This kind of topology has also the advantage to offer in most cases different paths for the same extreme points with the following advantages:

1. If the immediately next board when needed has the bus busy (is working with another board) the path can be dynamically changed starting from that node.
2. There is a more balanced distribution of the data charge between nodes.

For example supposing that in the second example, when the data packet arrives from [A2] (starting point) to [A1] (better next node). The next better node to reach [D2] is [D1]. If it is busy, instead of waiting for the bus freed the destination point [D2] can also be reached with the alternative (longer) path [B] -> [C] -> [D] -> [D2]

This kind of nodes communication is similar to the node distribution strategies of the network and the algorithm to find the next better node from every node is not difficult to calculate (we should think that these are microcontrollers).

The second not less important thing that I will change is to adopt the ChipKit alternative with a board faster (80MHz instead of the max 20 of the arduino) with a similar price and a reduced number of boards needed. This last suggestions is just to improve the global speed and performance but maybe it is not needed, we have no idea of what should be really done by Karim.

Enrico

Almost certainly the best way (cheapest and easiest) to implement this network is with a single RS485 link connecting all the devices together. This will allow you to use the hardware UART on the Arduino.

One of the devices needs to be a master but all the bus information is available to any connected device.

I don't think any standard protocol will work that well so you will need to invent your own.

If we do the sums for 32 nodes it looks like this:

115200 baud communications, 32 nodes, = approx 360 bytes per second per node, let's assume that we due to switching overheads and timing guard bands we only get  256 bytes/ per mode per second, so if each message is 8 bytes long you could have 32 messages per node per second - if one byte of the message is ID and another is a check sum  you get 6 bytes of data per message - if this isn't enough you can increase the baud rate to 250000 but you will have problems if you try to go much faster.

Roughly the way the protocol would work is that the master would send out a synch message every 'frame' time (about 32 times per second in this example) and the slaves would each transmit their own little packet of data at their allotted time (which they could calculate from knowing their address) - this way only one slave ever talks at a time, each slave only needs to listen for a short time when it expects the frame synch message from the master (or at other times too if it wants more data.) So each slave only needs 2 interrupts per frame time - or 64 per second which will be a much lower software overhead than trying to run 6 software UARTS.

You'll need to spend quite a lot of time working on the protocol to get it right but you can re-assure yourself that it is viable in principle since a similar scheme is used with supermarket shelf edge labels (using very low power radio links not wire) in systems with thousands of nodes. One of the issues you need to resolve is network discovery - when you switch the system on the master needs to work out how many nodes are attached and what their addresses are.

I don't know why you are using an Arduino for this - it totally not the ideal processor - you would be far better off using an ARM Cortex based chip which would give you much more processing power for similar cost.

MK

Thank you Michael,

Unfortunately the conditions I explained above should stay intact.

As a result, there is very little I can do with modifying the problem itself, instead need to solve it straight, as it is.

One thing I thought was worth mentioning is that the processing of the sensor data is not a big deal. The Arduino only needs to take the analog sensor data, and at the max, convert it to digital form. So then it only needs to have its ID, its MAC, and sensor data ready at its serial ports...

A few milli seconds of delay (even if more, as the delay is propagated) is not an issue, and of course the distance is zero between every two units.

Karim.

I don't see how the solution I suggested doesn't meet the requirements - each node can have several pairs of signal contact for connecting to other nodes - all that is needed is that all the nodes connect in parallel to the same pair of data lines.

Any node can talk to any number of other nodes.

You should be able to get this to work with Atmel AVR processors like you find in Arduinos since it only needs one UART and one timer per node and the processing burden is way less than you could hope for with multiple soft UARTS.

If you need to establish the position in the mesh of each node automatically you will need additional connections on each side of each node but these would not need to operate all the time or fast.

I'm not clear as how big the mesh might be - what is the maxim size it can grow to ?

MK

well may be I am misunderstanding your point. but what you are suggesting is a main bus line with units connected to it. However if i may give a more complete diagram of the problem, here it is:

now please consider the fact that this system is a mesh, not a bus,not just a star.

You are confusing the the physical topology with the logical topology.

My suggestion is that the devices are physically connected in parallel (not star !!!) and they can be logically connected any way you like (depends on protocol.)

But you still need to say how many nodes you might need (parallel connection has a limit on the maximum). A physical mesh network has no physical limit to the number of nodes but will run n into issues with the time taken for data to propagate through it and the volume of data running through "pinch" points in the mesh.

Mesh networks can work well when most data transfer is between devices which are close together. If most of the data goes from nodes to base unit then the mesh network performs worse than the parallel bus connection - the data flow is limited by the speed of a single link but the processing overhead is much greater.

MK