Go Down

Topic: How to connect 3 boards to read 14 analog entrances?  (Read 1 time) previous topic - next topic

aabm01

Hello

I started a project where I had to read 4 analog and 2 digital signals from sensors. I used a Arduino Yun to read them, and Johnny-five (J5) to code it instead of sketches. The Yun acts as a client running the javascript J5 program with node.js, sending all sensor's information in one object every 30 seconds via wifi to a server.

Now, I need to connect 14 analog and 2 digital sensors, so I need to add 2 arduino boards (every with 5 analog entrances) plus the Yun.

I have thought to connect 2 arduino Uno to the Yun. The thing is that I have not a clear idea how to make it.

The idea is that the 3 boards are connected between them, and receive data from the sensors but all the data has to be treated and sent from the Yun.

Some idea or example about how to make it !!!

PD: If there are another way cheaper to make it, will be welcome. (changing the one boards for another device...)

Thanks

Robin2

A Mega has 16 analog inputs.

Connecting to a Yun can be a PITA because, out of the box, it does not have a spare hardware serial port.

If you are content with 9600 baud you could use SoftwareSerial on the Arduino side of the Yun to connect to a Mega. And note that connecting to one other Arduino would be easier than connecting to two of them.

Another option might be to use an ESP8266 module to add WiFi capability to the Mega.

It is possible, with a bit of effort, to free up the hardware serial port on the Yun - basically by connecting the Linux side to the Arduino side with a USB cable between the USB Host connector and the micro USB connector (and a few other software things).


...R
Two or three hours spent thinking and reading documentation solves most programming problems.

ShapeShifter

If you are content with 9600 baud you could use SoftwareSerial on the Arduino side of the Yun to connect to a Mega.
Why limit it to 9600? I've not done a lot of experimenting, but my understanding is that the faster the baud rate, the less time SoftwareSerial will spend in busy loops processing data. The Software Serial Example used 57600 baud. My current project uses a Yun with two SoftwareSerial ports to talk to a pair of remote Arduino Pros - I'm using 19200 rather than going faster, but only because I don't need faster, and I'm going to have long wires between them so I don't want to push the envelope - the longer the wire, the more capacitance, and the more trouble with fast signals.

Quote
And note that connecting to one other Arduino would be easier than connecting to two of them.
True. I'm talking to two remote Arduinos because they will be separated by some distance so I can't do everything with one board. The issue comes in that SoftwareSerial can only listen to one device at a time: when done with one device, you have to switch to the other SoftwareSerial port and work with the other device: any data that comes in from the inactive port during that time is lost. You cannot keep switching back from port to port to see if anything is available, because the act of switching ports clears the new port's buffer.

Instead, you need to switch to a port and listen for a while, then switch to the other port and listen for a while. The way I handled it was to make the Yun the master, and it polls for data. The remote Arduinos don't speak unless spoken to. The Yun polls each port in turn: first it selects the port to listen, send a poll request, and waits for a response. The remote Arduino listens for the poll request, and in response it sends any available data or a special message to say no more data. The Yun waits for the response or a timeout before moving on and polling the other node.

The description sounds tedious, but it's not as bad as it sounds. the key is that the remote nodes should not always be sending data, they should only send data when they know the Yun is listening (in response to a poll request.)

Quote
Another option might be to use an ESP8266 module to add WiFi capability to the Mega.
Or add a Yun Shield to that Mega 2560. That will essentially give you a single board solution that acts like the Yun, but has the power of the Mega 2560 (more pins, more memory.)

Other options are to stick with the Yun, and add a shield to give the additional inputs. I haven't used any of these, and haven't done an exhaustive search, but some the first few hits after searching for "arduino analog input shield" turned up:

I'm sure there are many other viable options.

Robin2

Two or three hours spent thinking and reading documentation solves most programming problems.

aabm01

    Hi

    Thanks for your answers.

    At this point, I have an Arduino
Yun working with node/Johnny-five, and for your comments I have supposed that the easiest way would be to add a shield.

The Mux Shield II looks a good option, but I have some doubts:

  • If it is compatible with the Yun. I have been looking for some place where they say explicitly the boards compatible, but no luck. In the Arduino page in this link:
    https://store.arduino.cc/product/E000024?language=en
    They say: "The Mux Shield II adds the capacity for up to 48 inputs or outputs on the Arduino and Arduino Mega". I don't know if when they say "Arduino" include the Yun
.


  • I'm not working with sketchs but Johnny-five. To work with Mux Shield II, the library "MuxShield.h" has to be added to the sketch. In my case there are no sketch, there is a Javascript file executed with node, so it's supposed, that I need this library in Javascript, isn't it?
    So how I can use Mux Shield II with Johnny-five?


I have made more search, for more options, but I haven't had too much luck.

Thanks

ShapeShifter

I have been looking for some place where they say explicitly the boards compatible, but no luck.
I don't think you will ever see a definitive list like that, as there are so many variations between different Arduino boards and Arduino clones. Fortunately, most of the differences don't matter, it usually comes down to whether it will physically fit, and that narrows it down to the standard Arduino footprint, or the expanded Mega footprint. A majority of the issues with shield compatibility comes down to interactions with other shields because they may use the same pins. When it comes to the processor board, the actual processor chip may cause some incompatibilities if the associated library uses some specific hardware access methods and it doesn't support that particular processor. This is most often an issue with the more sophisticated boards that don't use AVR processors. The Yun uses a '32U4 AVR processor which is compatible with most libraries.

Quote
In the Arduino page in this link: https://store.arduino.cc/product/E000024?language=en
They say: "The Mux Shield II adds the capacity for up to 48 inputs or outputs on the Arduino and Arduino Mega". I don't know if when they say "Arduino" include the Yun
That link doesn't work for me, it immediately redirects to store-usa.arduino.cc which doesn't seem to carry that shield. I'm basing the following from the information at the SparkFun link I posted earlier.

Looking at the schematic and user guide, I see no reason why it wouldn't work with the Yun. You basically have a few digital outputs to select which signal to access, and a few analog inputs to read that signal.

Quote
I'm not working with sketchs but Johnny-five. To work with Mux Shield II, the library "MuxShield.h" has to be added to the sketch. In my case there are no sketch, there is a Javascript file executed with node, so it's supposed, that I need this library in Javascript, isn't it?
If you are currently reading analog inputs, there MUST be a sketch involved. I'm not familiar with Johhny-five, but it sounds like it is running on the Linux side of the Yun. The processor that runs Linux has no connection to the shield connector pins, and cannot read/write any digital I/O or read analog inputs on its own. Any shield hardware access MUST be going through a sketch. Even if most of the processing is happening on the Linux side, there must still be some sort of sketch running on the AVR processor that is reading the analog inputs and sending the information to the Linux code. That sketch is the one that would be using the library.

Now, if you are using something like Firmata as your sketch, which is a general purpose sketch that lets the Linux side generically read/write digital I/O and analog inputs, then you have a couple choices: implement the functionality of the MuxShield library on the Linux side, or modify the sketch to include the ability. Neither of those options should be a major obstacle.

If you read the user manual for the shield, you can see that there are several cuts/jumps you can make on the board to simplify operation:
  • Follow the instructions to free up pin 8: cut SJ1, and add a solder blob to the blue side of SJ5. This forces all I/O rows to be inputs, and eliminates the need to drive pins 8, 10, 11, and 12. Cutting SJ1 isolates pin 8 from the shield and allows it to be used for any purpose.
  • Follow the instructions to free up pin 10: cut SJ2, which isolates that pin from the shield, and frees it up for any purpose. There is no need to add a solder blob to SJ6, as the freeing up pin 8 overrides that selection.
  • Follow the instructions to free up pin 11: cut SJ3, which isolates that pin from the shield, and frees it up for any purpose. There is no need to add a solder blob to SJ7, as the freeing up pin 8 overrides that selection.
  • Follow the instructions to free up pin 12: cut SJ4, which isolates that pin from the shield, and frees it up for any purpose. There is no need to add a solder blob to SJ8, as the freeing up pin 8 overrides that selection.

So now you have simplified the operation of the board, and you don't really need the library to control it. It is now a 48 line input board, set up as three groups of 16. You only need to control the digital pins D2, D4, D6, and D7, and read analog inputs A0, A1, and A2. To read a particular input of the shield, set the digital pins as shown in the table below, and then read the indicated analog input:

MuxInput |  D2  |  D4  |  D6  |  D7  | AnalogIn
---------+------+------+------+------+---------
 I/O1-0  | LOW  | LOW  | LOW  | LOW  |   A0
 I/O1-1  | LOW  | LOW  | LOW  | HIGH |   A0
 I/O1-2  | LOW  | LOW  | HIGH | LOW  |   A0
 I/O1-3  | LOW  | LOW  | HIGH | HIGH |   A0
 I/O1-4  | LOW  | HIGH | LOW  | LOW  |   A0
 I/O1-5  | LOW  | HIGH | LOW  | HIGH |   A0
 I/O1-6  | LOW  | HIGH | HIGH | LOW  |   A0
 I/O1-7  | LOW  | HIGH | HIGH | HIGH |   A0
 I/O1-8  | HIGH | LOW  | LOW  | LOW  |   A0
 I/O1-9  | HIGH | LOW  | LOW  | HIGH |   A0
 I/O1-10 | HIGH | LOW  | HIGH | LOW  |   A0
 I/O1-11 | HIGH | LOW  | HIGH | HIGH |   A0
 I/O1-12 | HIGH | HIGH | LOW  | LOW  |   A0
 I/O1-13 | HIGH | HIGH | LOW  | HIGH |   A0
 I/O1-14 | HIGH | HIGH | HIGH | LOW  |   A0
 I/O1-15 | HIGH | HIGH | HIGH | HIGH |   A0
---------+------+------+------+------+---------
 I/O1-0  | LOW  | LOW  | LOW  | LOW  |   A1
 I/O1-1  | LOW  | LOW  | LOW  | HIGH |   A1
 I/O1-2  | LOW  | LOW  | HIGH | LOW  |   A1
 I/O1-3  | LOW  | LOW  | HIGH | HIGH |   A1
 I/O1-4  | LOW  | HIGH | LOW  | LOW  |   A1
 I/O1-5  | LOW  | HIGH | LOW  | HIGH |   A1
 I/O1-6  | LOW  | HIGH | HIGH | LOW  |   A1
 I/O1-7  | LOW  | HIGH | HIGH | HIGH |   A1
 I/O1-8  | HIGH | LOW  | LOW  | LOW  |   A1
 I/O1-9  | HIGH | LOW  | LOW  | HIGH |   A1
 I/O1-10 | HIGH | LOW  | HIGH | LOW  |   A1
 I/O1-11 | HIGH | LOW  | HIGH | HIGH |   A1
 I/O1-12 | HIGH | HIGH | LOW  | LOW  |   A1
 I/O1-13 | HIGH | HIGH | LOW  | HIGH |   A1
 I/O1-14 | HIGH | HIGH | HIGH | LOW  |   A1
 I/O1-15 | HIGH | HIGH | HIGH | HIGH |   A1
---------+------+------+------+------+---------
 I/O2-0  | LOW  | LOW  | LOW  | LOW  |   A2
 I/O2-1  | LOW  | LOW  | LOW  | HIGH |   A2
 I/O2-2  | LOW  | LOW  | HIGH | LOW  |   A2
 I/O2-3  | LOW  | LOW  | HIGH | HIGH |   A2
 I/O2-4  | LOW  | HIGH | LOW  | LOW  |   A2
 I/O2-5  | LOW  | HIGH | LOW  | HIGH |   A2
 I/O2-6  | LOW  | HIGH | HIGH | LOW  |   A2
 I/O2-7  | LOW  | HIGH | HIGH | HIGH |   A2
 I/O2-8  | HIGH | LOW  | LOW  | LOW  |   A2
 I/O2-9  | HIGH | LOW  | LOW  | HIGH |   A2
 I/O2-10 | HIGH | LOW  | HIGH | LOW  |   A2
 I/O2-11 | HIGH | LOW  | HIGH | HIGH |   A2
 I/O2-12 | HIGH | HIGH | LOW  | LOW  |   A2
 I/O2-13 | HIGH | HIGH | LOW  | HIGH |   A2
 I/O2-14 | HIGH | HIGH | HIGH | LOW  |   A2
 I/O2-15 | HIGH | HIGH | HIGH | HIGH |   A2
---------+------+------+------+------+---------


Note that this is all theoretical, I have never used that shield, and have no personal experience with it. However, the schematic looks fairly simple, especially after the jumpers have been modified as I noted above. I see no reason why it shouldn't work.

This shield is actually overkill for your purposes. If you're willing to build some hardware, you could make a 16 analog input version of this on a protoshield using a single 74HC4067. Something like the attached. In this case, you would set D2, D3, D4, and D5 with the binary equivalent of the channel number you wanted to read, and then read the analog input A0 (of course, you could use any four digital outputs, and any analog input.)

aabm01

Hello

Thank you very much for your extensive and clarifying answer. It has been very useful.

Quote
Now, if you are using something like Firmata as your sketch, which is a general purpose sketch that lets the Linux side generically read/write digital I/O and analog inputs, then you have a couple choices: implement the functionality of the MuxShield library on the Linux side, or modify the sketch to include the ability. Neither of those options should be a major obstacle.
You are right I'm using the Firmata for Yun as Sketch. I have visited the page of Johnny-five and they have some javascript controllers for some expanders like MCP23017 and MCP23008 so you are right that to work in the right way has to be implemented the funcionality in Javascript, but as you said probably simply  including an #include <muxShield.h > in the firmata code could work.

In some way I have to ask in the J5 web if this would work.

In the meantime When I asked about the compatibility between muxShield II and J5 the say that are going to implement a controller see this link.

Probably the best solution is as you commented the 74HC4067, but as the muxShield II there isn't a controller for J5 yet.

Thanks again.

PD: I am looking for a pressure transducers sensors with a range from -2000 to 2000 pascals (They could be -1500 - 1500 pa), Do you know where I can find them? 


sonnyyu

...
Or add a Yun Shield to that Mega 2560. That will essentially give you a single board solution that acts like the Yun, but has the power of the Mega 2560 (more pins, more memory.)
...
1+, It seem to be logic solution.



Go Up