I have been struggling way too long to get it working properly. The first curveball was the "odd" I2C address - 0x1C as the datasheet clearly states 0x53. The 0x1C address was confirmed by my I2C scanner.
Upon closer inspection of the module I noticed that the module also includes a uC... I assume which give you the option between UART and I2C operation. This explains the I2C address picked up by the scanner and mentioned in datasheet of the module.
I implemented the code as explained but the Wikipage, included (what I believe to be) all necessary dependancies and was happy to see the sensor initialise successfully. This happiness was short lived though as the output was clearly incorrect...
This output stays constant regardless of the light/UV level in the room. The code seems straight forward.
#include "../lib/LTR390UV/src/DFRobot_LTR390UV.h"
DFRobot_LTR390UV ltr390(/*addr = */LTR390UV_DEVICE_ADDR, /*pWire = */&Wire);
void setup()
{
Serial.begin(115200);
while(ltr390.begin() != 0){
Serial.println(" Sensor initialize failed!!");
delay(1000);
}
Serial.println(" Sensor initialize success!!");
ltr390.setALSOrUVSMeasRate(ltr390.e18bit,ltr390.e100ms);//18-bit data, sampling time of 100ms
ltr390.setALSOrUVSGain(ltr390.eGain3);//Gain of 3
ltr390.setMode(ltr390.eUVSMode);//Set UV mode
}
void loop()
{
uint32_t data = 0;
data = ltr390.readOriginalData();//Get UV raw data
Serial.print("data:");
Serial.println(data);
delay(1000);
}
There is also voltage buck regulator onboard reducing voltage to 3V3 as the LTR390 has max input voltage of 4V. Looking at the schematic below, my further assumption then is that the uC also acts as a 3V3/5V logic converter??
The reason the I2C address is different is that the DFRobot board has a cheap ARM Cortex MCU (CS32L010) on it. The I2C bus on the Particle side is listed as 0x1C in the DF Robot documentation, which is what you are getting. I'd use that instead of serial.
The LTR390 sensor is connected to a secondary I2C bus on the CS32L010. That bus has pull-ups to 3V3, which makes sense because the LTR390 is 3.3V only.
The CS32L010 is 5V tolerant, so you can directly connect it to a 5V Arduino and run VCC at 5V. However you must not do that on a Particle Gen 3 device as the Particle GPIO are not 5V tolerant. Only connect the DFRobot VCC to 3V3.
It's not clear what else the CS32L010 is doing. Presumably it's doing the UART to I2C translation if that's enabled. Not clear what it's doing in I2C-to-I2C mode, other than changing the address.
The number 4294967295 is the unsigned representation for -1 (a typical error code).
So I guess the library is trying to tell you that something is gone wrong inside.
You may need to have a look what circumstances lead to a return value of -1.
About the I2C address: From the schematic you provided it appears that the actual sensor communicates with the µC on your breakout via I2C using its native address, what your controller sees is the I2C address of the µC on the shield, not the sensor itself.
Thankfully I at least grasp the change in I2C address part. Thank you for pointing out the "-1 something has gone wrong" part. I will look through the library and see what I can find. Oh what a joy... hehe
Feedback as promised. Received email from their support, maybe makes more sense to either of you than it does to me
We all so sorry to hear that you have not had success using our sensor. But after we checked the information about Particle Photon 2, we found that it is an STM32 board. And it's not in our compatibility support list.
I asked them what is the cause of this "incompatibility", below is their response.
LTR390 only have the I2C interface, so we set a MCU, which is the CL32L010 as a data transmitter on the board. So when you communicate with our Gravity: LTR390-UV module, you do not directly communicate with the LTR390, but communicate through the MCU (CS32L010) on the module. In I2C mode, CS32L010 communicates with your external MCU as an I2C slave (Address of the CS32L010 is 0x1C). So the standard LTR3xx code (or the code you wirtten based on the datasheet of the LTR3xx chip )on the Particle Photon 2, we donot think thank will apply to the Gravity LTR390 UV sensor. We recommend that you read our ArduinoC code and use it as the reference when rewriting your code.
I have used their code though (and several others) but without much success. Guess this one is going to the bin
The STM32 is not relevant, that's the Photon 1 not the Photon 2.
However, the second part is something I was wondering about. You need to use the DFRobot Arduino library, not the LTR3xx library. Even though their board contains a LTR390, their firmware running on CS32L010 is using I2C slave mode so you need to use their I2C API, not the LTR390 I2C API.
I am indeed using their library and example code. I now know why no other library on GitHub will even initialise the sensor. Their library at least gets to that point, but I still get the 4294967295 return.
There is something else bothering me... There are two "squizzlies" in VSC even though it compiles.
In addition to that, Hardwareserial.h is one of the seemingly many dependancies which I commented out, but I initially thought it is not needed as I was using I2C.... now I am unsure
I just wanted to ask if you ever managed to get this sensor's output to work. I am currently about to use it for a project and stumbled upon your post as I was studying what to place in the lines for the sensor's address in the sample code. Thank you so much and keep safe!
First and most important, Welcome to Particle. I am pretty sure you will have a great time here and there are plenty of very friendly and knowledgeable people in this forum
Onto business, I am happy to say I did. Please see the link on the SmartPot Particle Photon 2, it has the working code you require. You can simply delete the code you do not want to use. Here is a link to the Github repo with all the code.
Thank you for the warm welcome, Particle really seems like a great resource to have stumbled upon as I start work on my Thesis project.
I'll check out the link you sent, glad it's also working well for you now! I was really worried a while ago after reading through this thread and ended up immediately ordering an Adafruit version of the LTR390 as a failsafe. Guess I won't have multiple paperweights on my hand after all.
Also, apologies for mistyping your name in my initial query Friedl
)
