Hello I'm new on forum. I have this sensor and I uploaded example sketch, and always return 0. I can read data from Sensor Part ID register and I receive ok value. But when i read data registers, I get always 0. Arduino give warning, but is compling and uploading ok.
And how is your wiring? Post a wiring diagram! If you connect that sensor to an UNO you may fry it (it's a 3V3 sensor and the UNO runs on 5V). I doubt you're using that sensor directly, so post a link to the breakout board you bought.
hey my friend why you don't understand post. I connect correctly this sensor beacause I can read partID register. I don't use arduino board, i make own pcb with this sensor(yes I have pullups on clock and data line)
hey my friend why you don't understand post. I connect correctly this sensor beacause I can read partID register. I don't use arduino board, i make own pcb with this sensor(yes I have pullups on clock and data line)
Is that a reason to not publish the wiring diagram?
Have you changed the gain and integration time settings? The default in the example needs a very bright light to get useful readings.
I know this was an old, and somewhat contentious topic. I am experimenting with the LTR-303ALS sensor, too. I am having the same issue as the OP. I am using the code and hardware hookup found in the repository as an Arduino library (GitHub - automote/LTR303: An Arduino library for the digital light sensor breakout boards containing the LTR-303ALS-01 IC). I have played with it enough to know that I am 'talking' to the sensor, as I get correct part and manufacturer IDs out of it. I can also read flags on settings, and everything looks just fine. However, go to read data from the sensor, and it gives all zeroes. It responds that those are 'good' readings, but according to the datasheet, the zeroes indicate sensor saturation, but then again, it doesn't matter if it is in bright light or complete darkness. Query the sensor, and it will give you correct responses on the part ID, though. I'm a bit stumped. Has anyone successfully worked with this sensor?
Can do later on, but be advised, I have it wired and coded exactly as noted in the library. Wiring diagram is in there. As stated above, communications are good, as it gives value responses, just no data.
Wrong, there is simply a description of the wiring and that one is wrong for most boards. It seems that a wrong wiring doesn't stop the communication but it might influence the analog part of the chip, it even may have destroyed it.
Can do later on
So we might decide to help you later on. Why are you asking for help here if you know it better?
Actually, I fixed it. It was a code issue in the library's start up sequence. I will post up later when I am thoroughly done debugging all of it.
My hardware was correct, as it turns out. I understand your questions, but honestly, that attitude is a bit uncalled for, and while I am sure you get tired answering questions all of the time, it isn't helpful. If you had information on the hardware that you thought was pertinent, why wouldn't you share it?
BTW, I did not apply 5v to the sensor, and it is very much intact.
it isn't helpful. If you had information on the hardware that you thought was pertinent, why wouldn't you share it?
Because you didn't tell us what hardware you're using. As we always expect users the have an UNO if they don't tell us something different I simply expected you to also use an UNO. If you connect the UNO as the comment in the example suggests you're outside the datasheet specs and the chip might behave differently than expected. In my experience wiring errors are much more frequent than library errors although this library was a bit suspicious because of the indifferent wiring tips in the example.
pylon:
Because you didn't tell us what hardware you're using. As we always expect users the have an UNO if they don't tell us something different I simply expected you to also use an UNO. If you connect the UNO as the comment in the example suggests you're outside the datasheet specs and the chip might behave differently than expected. In my experience wiring errors are much more frequent than library errors although this library was a bit suspicious because of the indifferent wiring tips in the example.
Understood. I was thinking more along the lines that the communications lines are all correct. At any rate, I do have it outputting. Unfortunately, the math for the lux calculations also seems to be broken. I am fixing all of that, now, and I will share my work when completed.
The crux of the entire problem seems to be in here in ltr303.cpp:
boolean LTR303::setPowerUp(void) {
// Turn on LTR303, begin integrations
// Returns true (1) if successful, false (0) if there was an I2C error
// (Also see getError() below)
// Write 0x03 (reset = 1 & mode = 1) to command byte (power on)
return(writeByte(LTR303_CONTR,0x03));
}
That little command there to reset and set active? Can't do that at the same time, apparently. It will reset, but not go active. Instead, this here makes the sensor active and start to spit out data:
boolean LTR303::setPowerUp(void) {
// Turn on LTR303, begin integrations
// Returns true (1) if successful, false (0) if there was an I2C error
// (Also see getError() below)
// Write 0x01 (reset = 0 & mode = 1) to command byte (power on)
return(writeByte(LTR303_CONTR,0x01));
}
I'm still working on making the readings make sense. The actual formula is referred to in the library as being found in Appendix A of the data sheet. Unfortunately, the latest version of the datasheet does not include an Appendix A, nor the lux calculation formula.
That little command there to reset and set active? Can't do that at the same time, apparently. It will reset, but not go active. Instead, this here makes the sensor active and start to spit out data:
The datasheet is not very clear about the functionality of bit 1 but one interpretation is that it completely resets the chip, so all registers are reset to there default values which include bit 0, so the chip is in standby mode again.
The library is quite badly programmed, as the setPowerUp() method overwrites any previous gain settings, although the example code pretend something different.
integrationTime is not initialized and not read back as the code describes, so the calculation can be completely wrong even if the formula might be correct. All in all this library gives a quite bad impression.
Totally agree, and I am gutting major parts of it, and re-writing as I go. Without the Appendix A for the device, I am left guessing what the lux calculation really is. I found the calculation for a different sensor, but it does not seem to be working for this one.
Got Appendix A from LiteOn today. I am attaching it here, as well as the data sheet itself, as someone else will be looking for them in the future, too.
Someone else asked me, and I realized I forgot to update here. Attached is a .zip with a modified driver, and an example sketch. Admittedly, I did not test the sketch itself, as I cut and pasted the code from a larger sketch I have, but it looks like it should be OK. The driver is working fine, however. Change the I2C header file for your board!
All are setup for a Teensy 3.6, but should be pretty easy to modify for any other Arduino. Also included are the datasheets.