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.

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

Michael, the number of serial connections is a max. of 6.

However, as part of the requirement, a unit may communicate with the base unit directly or indirectly through another unit. the physical and logical topology are congruent, in the case of this project. but why is this a confusing point? true! I mentioned star as the topology I was suggesting. Could you, however, draw a rough sketch to show the point more clearly?

You still are not answering the key question  - what is the maximum number of nodes in the system ?

With a parallel physical connection ANY logical topology is possible. Any device can talk and all devices have the option of listening - the only requirement is that only one device talks at a time. If one device takes the data from another, processes it and then transmits it again this is exactly the same logical effect as one node passing data directly to another node which then passes it to a third.

MK

@karim think of it like those folding plate puzzles (Rubik's magic). Many physical topologies are possible but they are still all connected using the same string (wires). Or think of squares with the same connection brought out to all four sides.

@karim think of it like those folding plate puzzles (Rubik's magic). Many physical topologies are possible but they are still all connected using the same string (wires). Or think of squares with the same connection brought out to all four sides.