Multiple MLX sensors on one Arduino

Excellent video Bill. Very good explanation on the TCA.

Posted by: @davemorris

The information has been very helpful.  I am looking at either using the TCA9548A to add more I2C addresses or I may use an Arduino sketch that I found that will reprogram the address of the sensor directly.  Either way it looks like I can do what I am trying to accomplish.

It sound like you don't even need the multiplexor. If you readdress the sensors through I2C(assuming it's directly connected and not going through the AT328) it should be fine. But if you do it through the AT328 then you need to make sure you wipe/reupload a different sketch to it or you will be writing to the sensors EEPROM every time it powers up. That will wear it you really quick.

Oh for the want of either openable/closable solder pads, or mini-dip-switches tied to addressing pins...  There is a reason the world's NICs have globally-unique MACs.  Mass-production of items with duplicate addresses is a bad idea.

Hi @lydara,

  You have raised a valuable discussion point, but with respect I am not sure if I agree. I should say, this point is more about the general system approach than the original query, so apologies for the digression. However, it seems like an example of system design worth exploring.

Whilst I sympathise with the simplicity of a dip switch or similar, extra pins means more expensive devices, more board space, cost of switch and so on. And whilst unique MAC addresses are probably needed in a system connected to billions of other nodes, they increase software complexity, packet size, and so on, compared to a localised network that only needs a few fixed addresses.

Assuming there is a relatively simple and inexpensive procedure to 'readdress' each sensor before installation in the final system, and of course,  that the final system allows the readdressed sensors to play nicely with distinct identities, isn't that almost as convenient and generally preferable?

I suspect if you were going to buy thousands or millions, you would get them 'custom programmed' and boxed accordingly, at the factory. By contrast, having more than 1 part number at every distributor, where the difference is only the reprogrammable code, would increase manufacturing, handling and stocking costs... all of which are passed on to the end customer. Plus when you wanted one with address 6, your preferred distributor would have a dozen with address 7, but none with address 6!

Thus, my hypothesis is that the adopted approach is actually a good example of supply chain and system design.

Of course, my third paragraph has a couple of crucial assumptions, and if either of those are unfounded, then the rest of my argument falls flat on it face.

But most of all I hope the final Arduino system works without problems!

@davee  Valid points.  However what I was baiting someone to point out was "virtual MAC" assignments.  The world is swimming in VMs!

Posted by: @lydara

Oh for the want of either openable/closable solder pads, or mini-dip-switches tied to addressing pins...  There is a reason the world's NICs have globally-unique MACs.  Mass-production of items with duplicate addresses is a bad idea.

Lets be real about a lot of the products we use. Although some components/products are mass produced for actual products, we often find and use products and components that are really just built for us to play around with; we are the intended market. I always know when this is the case though(unless it says Adafruit or Sparkfun, obviously). I'm sure if an EE wanted to have an array of these sensors, they would probably either design a way to section it off and program or use a product(at an extra cost for manufacture) that will program them in parallel.  But in this case we are really talking about a product that was meant for us(the evaluation board). They actually did a fairly good job of letting you use it either way(use the micro or use use the sensor if wanted, although I think it was intended for you to buy the individual sensor). As for the sensor itself, the choices are vast for an EE to pick what suites their product. If programming through EEPROM is a problem, there are other products for that.

Also, addressing them individually before sale you be very expensive for them to produce. You would have many different SKUs to track and manage. Putting aside I2C protocol, unique is not even an option, how would a mass produced product know what it has in it? It sounds like it would need a custom program for every board you use it in. There are protocols that instead of a common bus, it  is wired in series and allows you to address the first device and then pass along to the next one to get it's address and so on(think Neopixels/5050s).

@davemorris

I tool another look(I am still operating under the assumption that you have the evaluation board since it closely matches your original post), and I see that the I2C lines to the sensor is actually A4=SDA and A5=SCL. That makes sense since the AT328P would use those pins(same as the Uno). I believe that you will need to flash the onboard micro(assuming you don't want to utilize it) with a blank sketch or you will have 2 things trying to control it.

Hi all,

   Just a note to anyone contemplating the MLX90614 device, which strikes me as 'something different' from the usual run of the mill sensors. ( In the past I thought about it for a possible requirement, but not taken it any further.)

This number is the generic part of a family devices. They might or might not all come preset to the same I2C address (I haven't checked.), but they do come with different voltage requirements, different field of view types and so on. See clip below. 

I suspect the ESF-BAA suffix is the most common, but Adafruit list both ESF-AAA and ESF-BAA, Sparkfun just ESF-BAA. If you are interested in remote temperature sensing, then there are more options to consider.

And if you haven't ordered yet, the 'bare device' $ price from Adafruit is near half that of Sparkfun. (No, I am not on commission with either of them, or anyone else. 😀 )

Furthermore, the device has been around a while, so 'by accident' I found data sheets on the Sparkfun site dated 2006 with 35 pages, and 2009 with 44 pages. The Melexis.com site datasheet (which provided the above clip) is dated Sept 2019 and runs to 57 pages! I haven't compared them, so I don't know if the differences are substantial, but I would advise using the latest one unless you know a good reason not to.

I can see that the Sparkfun board version with the 328 chip, is a convenient way to start your learning curve, and if you only need 1 sensor, then maybe reprogram the 328 to do what you want could be the way to go.

AS both I and @madmisha have previously noted, you can connect directly to the sensor I2C lines, providing the  328 chip has been programmed to not interfere, so it should be possible to parallel connect two sensors with different addresses, at least one being on the Sparkfun board, and control with an external microcontroller.

Or maybe:

1. start with the Sparkfun board
2. reprogram the address on the 'onboard' sensor
3. then parallel connect a second sensor, leaving it on the default address
4. reprogram the 328 microcontroller to control both of them for your application

Of course, all of the above are only untried suggestions. Please take time to check any route you take does not have an unexpected flaw.

Both the Sparkfun and Adafruit sites seem to have information - scour both of them!

Good luck to anyone who goes ahead with a project, especially @davemorris to launching the topic!

I truly appreciate all of the help here.  I am planning on using an I2C multiplexer as recommended here to accomplish my goal of using two of the sensors.  To be clear though, I do not have the evaluation board from Sparkfun.  I have the sensor board that just has the sensor broken out for easier wiring.  I am doing multiple things with this project and it is a very good learning experience on the programming side. That part is a bit new to me as mentioned before.

@davemorris

If that is the case, I would still recommend not using the multiplexor. You can easily change the address directly and that would leave you with one less component that could cause problems. Readdress once and done.

Posted by: @madmisha

@davemorris

If that is the case, I would still recommend not using the multiplexor. You can easily change the address directly and that would leave you with one less component that could cause problems. Readdress once and done.

Okay, I will try that first. It certainly can't hurt to simplify things if I can.

So in my next steps to the project adding two MLX sensors, assuming that I do change the address of one of them (I will do that eventually) in the code shown here, how would I send the results of each sensor to the display?  I know how to actually write it to the display, but how do I differentiate between the two? I am assuming I need to specify the address, but what is the syntax?

#include <Wire.h>
#include <Adafruit_MLX90614.h>

Adafruit_MLX90614 mlx = Adafruit_MLX90614();

void setup() {
Serial.begin(9600);

Serial.println("Adafruit MLX90614 test");

mlx.begin();
}

If I set up the object (mlx in this example) I assume I would do mlx1 and mlx2.  Where would I put in their respective addresses?

@davemorris

The Sparkfun library actually looks to be more extensive and has better examples including the change address sketch. https://github.com/sparkfun/SparkFun_MLX90614_Arduino_Library/archive/master.zip

Posted by: @madmisha

@davemorris

The Sparkfun library actually looks to be more extensive and has better examples including the change address sketch.

Using the address change example in that library is actually how I was able to change the address on one of my sensors.  I now have one at 0x5A and one at 0x5B.  I'm trying to find the syntax to know when I read the object temp, which one am I reading it from when both sensors are connected. 

@davemorris

But if you did wan to use the other library, try changing the example to this and call them accordingly.

Adafruit_MLX90614 mlx1 = Adafruit_MLX90614(0x5A);

Adafruit_MLX90614 mlx2 = Adafruit_MLX90614(0x5B);