Sparkfun Triad (AS7265x) connectivity issues

Hallo,

I bought a sensor on your website and connected it according to the instructions.

I also passed the arduino nano and installed up-to-date libraries and examples, but arduino does not want to connect to AS7265.

the jumpers on the back and front sides are open.

I also tried to check it via uart, but it also does not respond to commands (I closed the jumper)

Please help to solve the problem.

Are the board’s LEDs lighting up? Share a few photos of the wiring/setup

link of the video

https://drive.google.com/file/d/1IyoyvB … sp=sharing

It appears to be powered on; try using the other SDA/SCL (top right of this photo https://www.electronicshub.org/wp-conte … Pinout.jpg)

“I changed the SDA/SCL but it’s still not working.”

Also note the Uno uses 5v IO, either swap to a board that uses 3.3v or stepdown the voltage

Another thing to try if that doesn’t work is to disable the i2c pull ups by cutting between traces between the pads in the upper left corner of the sensor board (only if it doesn’t appear after swapping to 3.3v)

at what braud rate sensor is work

Hi, not wishing to barge into the thread, I am having, as far as I can see, the same issue. I bought the sensor in February of this year and only got a chance to begin using it today.

I have tried using it on an Arduino Uno and Arduino Uno R4 WiFi with Qwiic cables (multiple) and Qwiic breadboard jumper cable. All yielding the same result. Lights on but nothing happening.

I’m using the example sketches, the board lights up as above a red power led and a blue stat led.

The sketch never gets a successful sensor.begin()

I’m running at 115200

Again, apologies. I don’t mean to hijack the thread. But the issue appears top me to be the same.

To be more exact the sensor.begin() never returns.

CoreyCow:
To be more exact the sensor.begin() never returns.

Sorry, this is not true, it does return with a 0 - false everytime.

plz. tell me the solution of this error

@joshi_001 I don’t know the solution, but looking int the SparkFun_AS7265X.cpp library file I can see it’s failing to in the begin() method because it cannot find slave 1 and 2

//Check to see if both slaves are detected

uint8_t value = virtualReadRegister(AS7265X_DEV_SELECT_CONTROL);

if ((value & 0b00110000) == 0)

return (false); //Test if Slave1 and 2 are detected. If not, bail.

The value is set to 0, forcing the begin to exit.

I’m hoping someone can explain why that is.

I installed SparkFun_AS7265X version 1.03 (I had the latest version 1.04 installed) and was able to get values back from the Example1_BasicReadings

I also downgraded AS726X to version 1.0.3 also

Are the i2c pull ups disabled? Are you using 3.3v?

no,the i2c pull ups are not disabled & i am using 3.3V

plz. tell me at what braud rate sensor is works bcoz. at 9600 braud rate sometimes it work

The code suggests 115200, it seems.

We can take it back for testing if you like.

Hi everyone,

I recently purchased the Triad and an Arduino Uno R4 WiFi.

I was not able to make it work also because the R4 WiFi apparently uses another Wire to connect to the I2C bus, the Wire2.

So I decided to test an Arduino R4 Minima without success.

Then I took out from the drawer an old ESP8266 board and I managed to make it work.

Still I was not happy as I wanted to use an Arduino and I purchased an Arduino Duo which was proven to work in this nice GitHub repo https://github.com/Scottapotamas/AS7265 … /README.md. I tested and it did not work…

I then started to question whether library versions could be a problem and I was really wondering why the ESP8266 worked.

Note that I was using the latest version of the Triad library, the 1.0.4.

Reading this thread I tried to downgrade to 1.0.3 and on the Arduino Duo it seems to work quite well finally.

I took some time to compare what is the difference in the libraries and it seems the 1.0.4 has checks about the response time of the board.

This is for example what you find in the 1.0.4 version:

void AS7265X::takeMeasurements()
{
  setMeasurementMode(AS7265X_MEASUREMENT_MODE_6CHAN_ONE_SHOT); //Set mode to all 6-channels, one-shot

  //Wait for data to be ready
  unsigned long startTime = millis();
  while (dataAvailable() == false)
  {
    if(millis() - startTime > maxWaitTime) return; //Sensor failed to respond
    delay(AS7265X_POLLING_DELAY);
  }

This same construct is present in few other places in the code and it is as far as I can see the only difference. 
So it would be nice if the developer of the code could check and tell which settings should be used to make the 1.0.4 version work. 
On top of that, since the Arduino R4 WiFi has a QWIIC connector already, it would also be nice that the code examples would be adapted so that one can use that interface. Now on the Duo I am using an adapter cable with individual pins on one side and a qwiic connector on the other that goes onto into the Triad qwiic famale.

If anyone managed to make the Arduino 4 Wifi work with 1.0.3 or 1.0.4 let me please know how.
  //Readings can now be accessed via getCalibratedA(), getJ(), etc
}

and this is what you have for the same function in the 1.0.3:

void AS7265X::takeMeasurements()
{
  setMeasurementMode(AS7265X_MEASUREMENT_MODE_6CHAN_ONE_SHOT); //Set mode to all 6-channels, one-shot

  //Wait for data to be ready
  while (dataAvailable() == false)
    delay(AS7265X_POLLING_DELAY);

  //Readings can now be accessed via getCalibratedA(), getJ(), etc
}

See my other comments to posts related to issues with connectivity and noise. This board will likely never work consistently (or at all) as spec’s in the sparkfun reference docs if you are using a 5v microcontroller. That is an easy thing to fix with a MOSFET power shifter, but good luck without good power management to compensate for signal and power differences between the sensor and microcontroller, if running at 3.3v/5v respectively, even if using the 3.3v pins on the microcontroller.

One quick hack to see if this is your issue is to wire using the native I2c pins on the microcontroller with 330ohm resisters in series on the signal wires. that can drop the single just enough to get things at least connected logically (ie, i2c working). It may be all you need for your use case, but a mosfet is the way to go.