The circle in the middle is the sensor. Putting anything close enough to the PCB to push down on it will change the amount of light reaching the sensor.
Have you tried using the Adafruit library for that device? https://github.com/adafruit/Adafruit_TSL2561
TSL2561 and Raspberry Pi
Moderators: adafruit_support_bill, adafruit
Please be positive and constructive with your questions and comments.
- adafruit_support_mike
- Posts: 67485
- Joined: Thu Feb 11, 2010 2:51 pm
-
- Posts: 2
- Joined: Mon Feb 17, 2014 12:02 pm
Re: TSL2561 and Raspberry Pi
Thank you for your reply Mike! The sensor doesn't only returns random values when I place my finger on the sensor (in addition to the previous post, place would be better than push as I apply no pressure on the sensor whatsoever), but it also returns unrealistic values (lux values of 30000 in a dark environment). Personally I get the idea that somehow my finger allows a current to flow through the sensor. I will test this hypothesis tomorrow and report back.
Thanks again for your reply.
Thanks again for your reply.
-
- Posts: 1
- Joined: Sun Feb 23, 2014 4:00 pm
Re: TSL2561 and Raspberry Pi
I have never used this site or have a good idea of what products I need. I would like some help on what equip. or products I would need to transfer pictures from a micro USB port or a SD port to my phone or email. The ports are on a device that is powered by batteries. I have some security cameras and would like to get real time pictures. I was told that raspberry could be a tool that used for that. I want to make this devise external from the camera and be able to plug it in, I don't know if this is even possible. Any information would be helpful. Thanks Mark
- static
- Posts: 188
- Joined: Thu Dec 23, 2010 6:21 pm
Re: TSL2561 and Raspberry Pi
Mark,
You may want to start your own thread. This thread is really about interfacing a light sensor with the Raspberry Pi. While I think what you are looking to do is possible, it's going to involve a different skillset than is represented by the folks here.
You may want to start your own thread. This thread is really about interfacing a light sensor with the Raspberry Pi. While I think what you are looking to do is possible, it's going to involve a different skillset than is represented by the folks here.
- oxidizer
- Posts: 7
- Joined: Thu Nov 15, 2012 1:56 pm
Re: TSL2561 and Raspberry Pi
I've been comparing various python code for the TSL2561 and I'm scratching my head regarding this definition:
I'm a bit confused on the reverseByteOrder( ). Is it necessary to reverse the byte coming out of the sensor? Without the line the IR and Full values from different gains/integrations do not scale. But if I include the reverseByteOrder() then the values seem to scale well. I understand all the rest of the code, but I just don't know about this part. Any thoughts?
Thanks.
csalty
Code: Select all
def readWord(self, reg):
"""Reads a word from the I2C device"""
try:
wordval = self.i2c.readU16(reg)
time.sleep(self.pause)
newval = self.i2c.reverseByteOrder(wordval)
if (self.debug):
print("I2C: Device 0x%02X returned 0x%04X from reg 0x%02X" % (self.address, wordval & 0xFFFF, reg))
return newval
except IOError:
print("Error accessing 0x%02X: Check your I2C address" % self.address)
return -1
Thanks.
csalty
- adafruit_support_mike
- Posts: 67485
- Joined: Thu Feb 11, 2010 2:51 pm
Re: TSL2561 and Raspberry Pi
It depends on how the device transmits the data. Some start with the most-significant bit and work down, others start with the least-significant bit and work up, some send the low byte then the high byte.
Check the TSL2561 datasheet to see how it arranges things: http://www.adafruit.com/datasheets/TSL2561.pdf
Check the TSL2561 datasheet to see how it arranges things: http://www.adafruit.com/datasheets/TSL2561.pdf
- oxidizer
- Posts: 7
- Joined: Thu Nov 15, 2012 1:56 pm
Re: TSL2561 and Raspberry Pi
Thanks for the clarification. I'm not very good at finding this information in the datasheet. This is the only thing I could find about bits being reversed on page 10:
So maybe that is why the byte needs to be reversed.During a change of direction within a transfer, the master repeats both a START condition and the slave address but with the R/W bit reversed. In this case, the master receiver terminates the transfer by generating a NACK on the last byte of the transfer and a STOP condition.
- adafruit_support_mike
- Posts: 67485
- Joined: Thu Feb 11, 2010 2:51 pm
Re: TSL2561 and Raspberry Pi
Well, the datasheet won't say "reversed", because each piece of hardware thinks its way of doing things is the right way around.
The diagrams in figure 13 show that the TSL2561 sends the low byte of a 16-bit word before sending the high byte, and that's byte-reversed from the way a 16-bit integer would look in a microcontroller's memory.
The diagrams in figure 13 show that the TSL2561 sends the low byte of a 16-bit word before sending the high byte, and that's byte-reversed from the way a 16-bit integer would look in a microcontroller's memory.
- oxidizer
- Posts: 7
- Joined: Thu Nov 15, 2012 1:56 pm
Re: TSL2561 and Raspberry Pi
That makes sense. And thanks for pointing out those details. That's really helpful.
-C
-C
-
- Posts: 4
- Joined: Fri Jan 21, 2011 11:13 am
Re: TSL2561 and Raspberry Pi
I've been playing with a TSL_2561 with an Arduino for a "weather station" type installation, and I think the weird daylight readings are due to the hard-to-notice "Note 6" on page 5 of the data sheet.
The problem is that the device will saturate at different numbers depending on the integration time. For example, at 100ms integration, the saturation value is 37177, not 65535. Because ch0 hits saturation first (since it has the broadest spectral response) it'll peg out at 37177 when ch1 is only about 1/3 of that value, at about a lux value of 40,000. After that point, increased amount of light will only lead to an increase in the ch1 readings. Because the calculated lux value essentially is "x*ch0 - y*ch1", this means the increased ch1 readings lead to a lower calculated lux value. At some point, both channels saturate at 37177 which results in a lux value of 805.
The net effect is that as the sun comes out, it records an increasing lux value up to 40,000 which then decreases down to 805 and then stays constant.
Note that a shorter integration time does not solve this problem, because the device is count rate limited. Shrinking the integration time to 14ms also lowers the saturation count value to 5047 counts and will not help in handling stronger light. (You just get the measurement in a shorter time.)
It is my impression that the only way to handle full daylight is to add a neutral density filter in front of the sensor to cut down on the light value the sensor sees. But that will of course also limit the ability to measure low light levels.
The problem is that the device will saturate at different numbers depending on the integration time. For example, at 100ms integration, the saturation value is 37177, not 65535. Because ch0 hits saturation first (since it has the broadest spectral response) it'll peg out at 37177 when ch1 is only about 1/3 of that value, at about a lux value of 40,000. After that point, increased amount of light will only lead to an increase in the ch1 readings. Because the calculated lux value essentially is "x*ch0 - y*ch1", this means the increased ch1 readings lead to a lower calculated lux value. At some point, both channels saturate at 37177 which results in a lux value of 805.
The net effect is that as the sun comes out, it records an increasing lux value up to 40,000 which then decreases down to 805 and then stays constant.
Note that a shorter integration time does not solve this problem, because the device is count rate limited. Shrinking the integration time to 14ms also lowers the saturation count value to 5047 counts and will not help in handling stronger light. (You just get the measurement in a shorter time.)
It is my impression that the only way to handle full daylight is to add a neutral density filter in front of the sensor to cut down on the light value the sensor sees. But that will of course also limit the ability to measure low light levels.
- adafruit_support_mike
- Posts: 67485
- Joined: Thu Feb 11, 2010 2:51 pm
Re: TSL2561 and Raspberry Pi
Good catch.. I'll have to go back and reread that section of the datasheet.
Thanks for posting the information! ;-)
Thanks for posting the information! ;-)
- yz88
- Posts: 3
- Joined: Mon Dec 29, 2014 10:01 am
Re: TSL2561 and Raspberry Pi
Hi all, I'm a newbie in sensoric with raspbery pi. I bought two TSL2561 sensor, and connected them to my raspberrypi. Now I'm looking for a python script to work with the two sensors.
Do anybody have a complete running python script for the TSL2561?
Thx a lot
Do anybody have a complete running python script for the TSL2561?
Thx a lot
- vannimb
- Posts: 11
- Joined: Thu Jan 29, 2015 4:52 am
Re: TSL2561 and Raspberry Pi
Hello,
i purchased a TSL2561 and i connected it to the PI. (following the instructions, gnd, 3v3, sda to the pi sda pin, scl to the pi scl pin)
i load the modules:
sudo modprobe i2c-dev
sudo modprobe i2c-bcm2708
as mentioned at https://www.safaribooksonline.com/libra ... ping_Table
when i run sudo i2cdetect -y 1
i get:
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- UU -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
and from what i understood UU means "Device or resource busy".
am i doing something wrong?
by mistake in the initial wiring phase i connected the VCC to 5 volt, could have this damaged the sendor and explain the output i receive?
Many thanks for your support!
i purchased a TSL2561 and i connected it to the PI. (following the instructions, gnd, 3v3, sda to the pi sda pin, scl to the pi scl pin)
i load the modules:
sudo modprobe i2c-dev
sudo modprobe i2c-bcm2708
as mentioned at https://www.safaribooksonline.com/libra ... ping_Table
when i run sudo i2cdetect -y 1
i get:
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- UU -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
and from what i understood UU means "Device or resource busy".
am i doing something wrong?
by mistake in the initial wiring phase i connected the VCC to 5 volt, could have this damaged the sendor and explain the output i receive?
Many thanks for your support!
- oxidizer
- Posts: 7
- Joined: Thu Nov 15, 2012 1:56 pm
Re: TSL2561 and Raspberry Pi
Did you check your raspi-blacklist.conf file to make sure you commented out the i2c statement?
My conf file is located at:
My conf file is located at:
Code: Select all
/etc/modprobe.d/raspi-blacklist.conf
- vannimb
- Posts: 11
- Joined: Thu Jan 29, 2015 4:52 am
Re: TSL2561 and Raspberry Pi
Dear Oxidizer,
i modified the file as you suggested and now looks like:
# blacklist spi and i2c by default (many users don't need them)
blacklist spi-bcm2708
#blacklist i2c-bcm2708
blacklist snd-soc-pcm512x
blacklist snd-soc-wm8804
However after loading:
sudo modprobe i2c-dev
sudo modprobe i2c-bcm2708
the result is always the same:
pi@RASPBERRY-A1 ~ $ sudo i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- UU -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
any other hint/idea?
Many thanks for your cooperation.
i modified the file as you suggested and now looks like:
# blacklist spi and i2c by default (many users don't need them)
blacklist spi-bcm2708
#blacklist i2c-bcm2708
blacklist snd-soc-pcm512x
blacklist snd-soc-wm8804
However after loading:
sudo modprobe i2c-dev
sudo modprobe i2c-bcm2708
the result is always the same:
pi@RASPBERRY-A1 ~ $ sudo i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- UU -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
any other hint/idea?
Many thanks for your cooperation.
Please be positive and constructive with your questions and comments.