tedyapo / arduino-mlx90393 Goto Github PK

x- (and sometimes y-) scales are incorrect. Seems to vary across resets - may be some uninitialized data.

delay time should be set from datasheet equations, allowing for a healthy safety margin

     Hi i need to use the Adafruit MLX90393 board in burst mode in order to increase my sampling rate. The procedure it is not clear to could someone provide a clear overview on the steps needed starting by the available libraries?

Thank you

Trying to design a joystick using the MLX90393.
Using the code in this library, I converted core code to Python/raspberry pi.
Communicating with the device using SPI, I can get a x/y angle of +/-30degrees from joystick tilt.
Problem is with the corners, the angle gets reported larger than 30degrees, which creates spikes outwards.
Does anyone know why this happens?

Hello,

I'll preface this by saying I'm very new to Arduino and I2C communication, so I apologize if I'm missing something obvious.

I have a MLX90393 sensor bought from Adafruit Industries last spring. I was able to get measurements using their example code and library (which only supports Single Measurement Mode). Using Single Measurement Mode in a loop with no delay only gives about a 21 Hz sampling rate, but I see in the data sheet that over 400 Hz is possible when the sensor is set to Burst Mode. I tried to modify their library to set the sensor to Burst Mode, but this caused the initialization of the sensor through their begin() function to fail, and after not receiving answers on their forums I looked for other libraries with burst mode support and found this.

My problem right now is that I can't even get Single Measurement mode to work with this library. I've been trying to test/debug using the following code:

#include <Wire.h>
#include <Arduino.h>
#include <MLX90393.h>

MLX90393 sensor = MLX90393();

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

  while (!Serial) {
    delay(10);
  }

  Wire.begin();

  if (sensor.begin() == 0)
  {
    Serial.println("Sensor connected successfully.");
  }
  else
  {
    Serial.println("Error occured.");
  }
}

void loop() {
  MLX90393::txyz data;

  uint8_t status1 = sensor.readData(data);
  Serial.println(status1, 4);
  Serial.println(data.t, 4);
  Serial.println(data.x, 4);
  Serial.println(data.y, 4);
  Serial.println(data.z, 4);
  delay(1000);
}

I have no problems getting begin() to be successful (it always returns 0), but the displayed data is very obviously incorrect. For example, the temperature value is 459.792, and the magnetic field values are -0.15 or -0.24, and they don't change when I put a magnet near the sensor. I checked to see where there may be an error occuring in readData, and found that checkStatus(status1) (status for startMeasurement() returns 0 in the serial monitor, but checkStatus(status2) returns 3333 (status2 itself is 302). checkStatus(status1) | checkStatus(status2) also returns 3333.

I think the strangest thing is that there was one time where I actually got believable measurements (that responded to a magnet placed near sensor), but when I reuploaded the sketch it reverted back to the previous issue.

My questions would be, do my issues stem from using the Adafruit product, and if so what might I need to modify in the library to get it to work with this product? Also, is it even worth trying to get Burst Mode working with this sensor (I saw elsewhere that readings in Burst Mode often fail)?

Thank you for any help with this.

HALLCONF (Hall plate spinning rate adjustment) parameter should be exposed as part of low-level API

New datasheet has different values for scaling parameters. Update constants in header file and scaling code to reflect these.

Hi Tedy - thanks for writing this lib.

I think I've found a bug:

During a .begin, a reset() is issued. Immediately after, setGain() is issued. setGain fails ~80% of the time (returns 255) because the lib immediately tries to read the first memory location

uint8_t status1 = readRegister(GAIN_SEL_REG, old_val);

and it can't because the IC is still resetting. This causes the .begin to return 255 (error).

POR is 1.6ms max. Software reset time limit is not specified. We could poll register until it reads correctly, but I did a bit of a hack in the reset() function:

uint8_t
MLX90393::
reset()
{
  invalidateCache();
  uint8_t cmd = CMD_RESET;
  
  sendCommand(cmd); //Device now resets. We must give it time to complete
  delay(2); //POR is 1.6ms max. Software reset time limit is not specified. 2ms was found to be good.
  return sendCommand(cmd);
}

This works well for me. I'll try to issue a pull request in a moment.

I had some trouble with several MLX90393 modules (problems were unrelated to this library), but part of my diagnostics including using the MLX90393_Debug_Helper.ino sketch in this library. Great utility, BTW!

However, it wouldn't work for me consistently. I got a lot of failures and read errors among the MLX90393 modules I was trying to use. So much so, I purchased more thinking they were bad (they weren't).

The problem? The sketch is missing wire.begin(). Add that to the setup() and it reads my modules every time. No errors.

Currently there is no implementation for the nop command. However this is the only command that would allow to read the status flags without any side effects. I suggest to add the command.

Should _i2cPort->begin(); been added to MLX90393::begin?

Hey,

I am trying to use two MLX90393 boards vie I2C simultaneously (eventually I will need to use four). I have a script that yields what I believe to be believable measurements from both of the sensors. An issue arises though in that I print the status of both the boards on begin and more often than not they read 255 - we have yet to see both statuses return 0 at the same time and it is fairly normal for one to return 0 while the other returns 255. I do not know how much of an issue this really is since, as I mentioned, they seem to give valid measurements despite the status regularly reading failure.

What's more is that if we call the individual methods of the begin function and print the return (ie. mlx.checkStatus(mlx.reset()), mlx.setGainSel(7), etc.) those all return 0.

Here is the setup excerpt from the script:

#include <MLX90393.h>

MLX90393 mlx1;
MLX90393 mlx2;

void setup(){

  Serial.begin(9600);
  Serial.println("hello");
  
  Wire.begin();

  delay(1000);
  uint8_t status = mlx1.begin(0, 0);
  Serial.println(status);
  uint8_t status2 = mlx2.begin(1, 0);
  Serial.println(status2);
}

wondering if you are polling the interrupt pin for a reason, or if is more of a placeholder function? I'd like to map it to a hardware interrupt on the esp32 (or STM32 which I havn't tried yet.

BTW i bought 2 of these from ali express for $6 each. the part is CJMCU-90393. I think you had asked in a previous post.

In the header file there are enums which are useful if the (public) low level functions are called. Would it be possible to shift them into the public part of the header file?

Hi
I been testing this new board for quite a while. I been using different code to communicate with arduino. I found your library to be much better as it has all the functions needed for setting-up the MLX90393 chip like Hull-config, oversampling, digital filtering..etc. The concerns I have here are noise level in the raw data and some other issues.

1. I don't know how much of the 16bit ADC is usable when filtering all the noise from the board using digital filtering? and does that reduce resolution? In the data sheet no matter what OSR (over sampling) you use the noise level stay the same like in 10ms (conversion time) = 10 stdev and that if OSR = 1,2, or 3. they are all the same with little or no deference.

2. When sitting DigitalFiltering = more than 0, OCR need to be 0 or you will not get any reading from the sensor. Can you explain why this happen? In the data sheet it says DIG, FILT and OCR related to each other. if HALL-CONF = 0x0C then DIG, FILT of 0 and 1 with OCR of 0 and 1 is not allowed but other are allowed. So how come when I increase DIG, FILT to 2 and OCR to 2 or 3 I still not get any reading?

3. In the other code that I have downloaded from here ( http://arduinolearning.com/code/arduino-mlx90393-magnetic-field-sensor-example.php) the raw data goes from -2^15 to +2^15. Do you know how I can change your code reading from ut/LSB to the raw bits? I need to compare the noise level of your code vs the other one. As I feel your code somehow generate more noise while filtering setting is the same on both side.

4. I am trying to use low-pass filtering using 10uf capacitor with 1kohm and 330 ohm resister using this setup (http://forum.arduino.cc/index.php?topic=527478.30) to reduce environment noise. Do you think it will be better to do hardware filtering or software filtering using the library code will also give the same results?

5. The CJMCU-90393 board that I have has 2 pins of 3.3V one is VDD and the other one is VDD-IO. Do I have to connect both pins to 3.3V in order to supply requirement power? In the data sheet it says VDD is analog supply and the VDD-IO is digital supply. I do have reading when one 3.3V is connected but the board needs 3.6V power supply.

6. If I want to connect multiple boards to the arduino how I can communicate with each one of them? In the data sheet is 0x0C, 0x0D, 0x0E... but I don't know how to use them with your library?

7. Do you think a magnetic sensor like A1324LUA-T with external 16bits ADC like ADS1115 give more precision and low noise than the MLX90393? With this level of noise that I have, I think I need to map the raw data to 2^10 to get a stable reading. Is that mean only 10bits is usable?

8. I think magnetic shape and size has effect in the way the sensor returning values in x,y and z axis when spinning the Nd magnet? correct me if I am wrong. I used a rectangular shape Nd magnet and when I spin it the values I get are different when I use a square magnet in the same level and distance.
   Finally, thanks for all your hard working and I hope I get some answers soon.
   Sarwar

Most probably the line

this->dig_flt = (reg_val & DIG_FLT_MASK) >> DIG_FLT_SHIFT;`

should be

this->dig_flt = dig_flt = (reg_val & DIG_FLT_MASK) >> DIG_FLT_SHIFT;

Other platforms (Teensy, etc) have multiple Wire streams (Wire1, Wire2, etc). It would be nice to add an option to .begin() that allows for other I2C streams.

as written the code takes up a lot of flash on the ardunio. Find ways to reduce footprint

Hello,

I am using an Arduino Uno (IDE version 1.8.12) with an MLX90393 magnetometer. My issue is that I can read from the magnetometer just fine if pretty much ONLY do the readData command and print it such as shown below:

void loop()
{
mlx.readData(data);
Serial.println(String(millis())+ ","+ data.x+","+data.y+","+data.z);
delay(500);
}

However, If I add other things to the void loop such as also serial printing the channel I am reading from like this:

void loop()
{
mlx.readData(data);
Serial.println("channel1: ");
Serial.println(String(millis())+ ","+ data.x+","+data.y+","+data.z);
delay(500);
}

It not longer reads my data and I get something like "0.75, 0.75, 1.58" for my three data points each time it samples and the values don't change if I wave a magnet over the magnetometer so I know it isn't actually reading anything. This is just an example, there are a host of other strange things that seem to keep the magnetometers from reading when they are compiled on the board. Also, I have noticed that every time I start the serial monitor, the first data point I get is a nonsense data point such as "0.75, 0.75, 1.58" and then after that it begins giving me accurate X, Y, Z values. As an addition, I am also trying to read several MLX90393s using a TCA9548 and I'm having similar problems when using that because even changing the channel to read from will keep all of the magnetometers from reading data and again they just give nonsense numbers. Any suggestions what could be causing this?

Currently reset will always return error code OK. In my opinion it is possible that the command fails. I suggest to return the status from sendCommand instead of discarding it.

The line

float gain_factor = gain_multipliers[7 - (gain_sel & 0x7)];

and the fact that the datasheet says that gain_sel ranges from 0-7 make me wonder what convertRaw will do in case of gain_sel == 0. I also wonder why you index with 7- gain_sel instead of sorting the array the other ways round.

My conjecture is that the factor "1.0" is missing in the array.

I'm unable to get the sample code working with my wemos lolin 32 board. The values do not update. here is the sketch

#include <Wire.h>
#include <Arduino.h>
#include <MLX90393.h>

// prints Bx By Bz (in uT) and temperature (C) to serial console after receiving a character

MLX90393 mlx;

void setup(){
  // DRDY line connected to A3 (omit third parameter to used timed reads)
  //uint8_t status = mlx.begin(0, 0, A3);
  
  // this seems to un-funk other i2c stuff for esp32.  My board has SDA and SCL 
  //  mapped to these pins.
  Wire.begin(5,4);

  delay(300);
  uint8_t status = mlx.begin(0, 0);
  //uint8_t status = mlx.begin();
  
  Serial.begin(115200);
  Serial.println("setup done");
}

void loop(){
  MLX90393::txyz data;
  if (Serial.available()){
    Serial.read();
    mlx.readData(data);
    Serial.print(data.x);
    Serial.print(" ");
    Serial.print(data.y);
    Serial.print(" ");
    Serial.print(data.z);
    Serial.print(" ");
    Serial.println(data.t);
  delay(100);
  }
}

following is a sample of the output. oddly a few of the values were in fact changed.

load:0x40078000,len:0
load:0x40078000,len:11392
entry 0x40078a9c
setup done
-25679.13 -17812.48 -82857.73 -964.12
-0.78 4224.98 -82797.06 446.15
-25683.84 -17825.02 -82857.73 -907.41
-25679.13 -17812.48 -82857.73 -964.12
-15404.82 0.00 -165675.02 446.22
-25683.84 -17825.02 -82857.73 -907.41
-25679.13 -17812.48 -82857.73 -964.12
0.00 0.00 -165675.02 -998.03
0.00 0.00 -165675.02 -998.03
-25679.13 -17812.48 -82857.73 -964.12
-25679.13 -17812.48 -82857.73 -964.12
-25679.13 -17812.48 -82857.73 -964.12
-25683.84 -17825.02 -82857.73 -907.41
-25679.13 -17812.48 -82857.73 -964.12
-25683.84 -17825.02 -82857.73 -907.41
-25679.13 -17812.48 -82857.73 -964.12
-25679.13 -17812.48 -82857.73 -964.12
-25679.13 -17812.48 -82857.73 -964.05
-25683.84 -17825.02 -82857.73 -907.41
-25679.13 -17812.48 -82857.73 -964.05
-25683.84 -17825.02 -82857.73 -907.41
-0.78 4224.98 -82797.06 446.15
-25679.13 -17812.48 -82857.73 -964.12
-25683.84 -17825.02 -82857.73 -907.41
-25683.84 -17825.02 -82857.73 -907.41
-25679.13 -17812.48 -82857.73 -964.12
-25683.84 -17825.02 -82857.73 -907.41
-25679.13 -17812.48 -82857.73 -964.12
-25679.13 -17812.48 -82857.73 -964.12

the following does work (but not great):

https://gist.github.com/jschoch/779e7aae5205bfbcb93a064da627201e

source for this is:
https://github.com/ControlEverythingCommunity/MLX90393/blob/master/Arduino/MLX90393.ino

Hi Tedy - If I do some work and give you aPR, are you interested in having this repo listed in Arduino lib manager?

Hello,

I recently noticed that my conversion time was not always calculating properly for different DIG_FILT and OSR settings. This led me to find a potential error in cache_t struct in the .h file.

  struct cache_t {
    enum { SIZE = 3, ALL_DIRTY_MASK = 1 << (SIZE+1) - 1};
    uint8_t dirty;
    uint16_t reg[SIZE];
  } cache;

The ALL_DIRTY_MASK reads as binary 1000. I believe it should be 0111, to track the three setting registers, and whether the current cache information is accurate.

Some other hints I found along the way:
Line 70 does not update with 1000:
cache.dirty |= cache_t::ALL_DIRTY_MASK & (1<<address);

Line 78 is always being anded with 0:
cache.dirty &= ~(1 << address);

I changed the struct to:

  struct cache_t {
    enum { SIZE = 3, ALL_DIRTY_MASK = (1 << SIZE) - 1};
    uint8_t dirty;
    uint16_t reg[SIZE];
  } cache;

To get a binary mask of 0111. Conversion at higher data rates seems to be working better for me this way.

@udoklein is there a reason that the simple example was removed in your commit?

In MLX90393.cpp, line 409

In the method convDelayMillis(), the digital filtering parameter is fetched incorrectly:
const uint8_t dig_flt = (cache.reg[DIG_FLT_MASK] & DIG_FLT_MASK) >> DIG_FLT_SHIFT;
should read
const uint8_t dig_flt = (cache.reg[DIG_FLT_REG] & DIG_FLT_MASK) >> DIG_FLT_SHIFT;

Hey Ted,

I have been dabbling with the ALS31313 and rummaged through a drawer and saw one of these MLX90303 sensors. I have been toying with trying to figure out how to read linear position. For the ALS31313 I used some code called "anaQuad" to read ~2mm pitch fridge magnet (and 1mm pole pitch strip) by looking at the Z strength and the X strength which seem 90 degrees out of phase. I'm able to get about 4 ticks per mm for the fridge magnet and 8 on the "high resolution" strip. Seems like I should be able to do better. Since I don't know who else to ask, wondering if you have any ideas on how this should work with either the ALS or MLX sensors? I also have a AS5311 which is great because it outputs an incremental signal but they are expensive and hard to source. I'm guessing the angles are better to use but my math is quite weak.

Feel free to close right away if you don't have any ideas.

I noticed that my datasheet was from 2015. So I tried to download the 2017 datasheet from the Melexis website. However it appears to be encrypted with a password. Do you know this password? Or do you know where to get an unencrypted version of the file?

This one is strange. If I call setTemperatureOversampling and read the register back then it shows that OSR2 equals 0. I added some print statement into the writeRegister function. It appears to me that it is called properly. Reviewing your code I would says the code is correct. This is consistent with the runtime value found by my print statement.

Since it works as expected for the other cases I am inclined to suspect that either

1. the Melexis 90393 does not behave as expected or
2. my instance of the Melexis 90393 does not behave properly.

Did you ever test this function? Did it work for you? Since I do not intend to read temperature at all this is not big deal. So if you have no idea why this does not work do not bother with this one. I will ignore it then as well.

This has never worked correctly. Uncertain if this is a software bug, of if there is some undocumented magic to get the part to perform correctly.

Currently exit takes an uint8_t parameter which is not consumed inside the function. I suggest to remove the paramter.

Hi,
Your library works great. I do have one issue when I include sumotoy ILI9163C library there is a conflict with both libraries. Both libraries work fine on their own.

Please let me know if this can be fixed or if there is a work around.

Compile Error;

n file included from /Users/JimD/Documents/Arduino/libraries/TFT_ILI9163C-master/TFT_ILI9163C.h:135:0,
from /Users/JimD/Documents/Arduino/RewinderTS/RewinderTS.ino:11:
/Users/JimD/Documents/Arduino/libraries/TFT_ILI9163C-master/_settings/TFT_ILI9163C_registers.h:6:22: error: expected identifier before numeric constant
#define CMD_NOP 0x00//Non operation
^
/Users/JimD/Documents/Arduino/libraries/arduino-MLX90393-master/MLX90393.h:38:5: note: in expansion of macro 'CMD_NOP'
CMD_NOP = 0x00,
^
/Users/JimD/Documents/Arduino/libraries/TFT_ILI9163C-master/_settings/TFT_ILI9163C_registers.h:6:22: error: expected '}' before numeric constant
#define CMD_NOP 0x00//Non operation
^
/Users/JimD/Documents/Arduino/libraries/arduino-MLX90393-master/MLX90393.h:38:5: note: in expansion of macro 'CMD_NOP'
CMD_NOP = 0x00,
^
/Users/JimD/Documents/Arduino/libraries/TFT_ILI9163C-master/_settings/TFT_ILI9163C_registers.h:6:22: error: expected unqualified-id before numeric constant
#define CMD_NOP 0x00//Non operation
^
/Users/JimD/Documents/Arduino/libraries/arduino-MLX90393-master/MLX90393.h:38:5: note: in expansion of macro 'CMD_NOP'
CMD_NOP = 0x00,
^
In file included from /Users/JimD/Documents/Arduino/RewinderTS/RewinderTS.ino:14:0:
/Users/JimD/Documents/Arduino/libraries/arduino-MLX90393-master/MLX90393.h:65:12: error: expected unqualified-id before ')' token
MLX90393();
^
/Users/JimD/Documents/Arduino/libraries/arduino-MLX90393-master/MLX90393.h:116:1: error: expected unqualified-id before 'private'
private:
^
/Users/JimD/Documents/Arduino/libraries/arduino-MLX90393-master/MLX90393.h:138:3: error: expected unqualified-id before 'private'
private:
^
/Users/JimD/Documents/Arduino/libraries/arduino-MLX90393-master/MLX90393.h:141:1: error: expected declaration before '}' token
};
^
exit status 1
Error compiling for board Adafruit Feather M0.

As per new version of datatsheet, scaling values should be adjusted based on value of HALLCONF parameter

My MLX is a MJMCU-90303
Board is a Elegoo Uno R3 and a Teensy 3.6 (tried both)

I am an absolute novice at anything and everything programming and microcontrollers so I may be missing something extremely simple. I am using the example code from sparkfun.com

https://www.sparkfun.com/products/retired/14160

In the sketch, as soon as it calls the mlx.begin() function it hangs. I have inserted Serial.print() messages between each line of code to isolate what is causing the problem and verified it is the mlx.begin(). Strangely, it will even stop the arduino from printing the "MLX90393 Test" message that takes place 6 lines prior. It will print out "ML" and then nothing else. If I add a delay(500) prior to the mlx.begin() call, it will print everything prior to the call in the serial monitor. I have also tried adding a delay(1000) after the mlx.begin() to see if it was just having a tough time trying to print something while the begin function was still trying to finish. Has anyone else had this issue or know what may be causing it?

Wondering in general how you go from these x,y,z numbers to a position for a diametricaly opposed magnet. The x, and y numbers appear to roll over when turning. Kinda hard to test since my pins on my breakout are magnetic :( Any help appreciated.