0

TSL2561 and Raspberry Pi
Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.

Re: TSL2561 and Raspberry Pi

by vannimb on Thu Feb 12, 2015 3:09 pm

Dear Mike,
i made a new test with another raspberry unit and fresh clean raspbian.

same result:
pi@RASPBERRY-B1 ~ $ 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: -- -- -- -- -- -- -- --

even if i boot the raspberry without the sensor connected the result is the same...
Soldering has been reworked as you suggested... i am afraid i broke the sensor... how can i test if the sensor is broken or not?
Many thanks for your support
best regards

vannimb
 
Posts: 11
Joined: Thu Jan 29, 2015 4:52 am

Re: TSL2561 and Raspberry Pi

by adafruit_support_mike on Thu Feb 12, 2015 11:09 pm

Post a photo of the reworked sensor and we'll take a look.

adafruit_support_mike
 
Posts: 55956
Joined: Thu Feb 11, 2010 2:51 pm

Re: TSL2561 and Raspberry Pi

by f1vnc on Tue Feb 17, 2015 10:11 am

Hello All,

I’m a newbie here, but I’d like to add my experiences with the TSL2561 and the code suggested on here for driving it.

Firstly, my system. It’s a Raspberry Pi B with I2C support enabled and the TSL board is an Adafruit “5V safe” model.

I connected the board OK and it showed up with the correct address of 0x39.

I then ran the Python code suggested on this thread (Thank You!), but got some puzzling results.

The 3 Lux values (Gains @ 1, 16 and auto) gave non-consistent values. I would have expected the Lux values for all 3 to be roughly similar (allowing for the lower resolution of the gain 1 value). However, the results differed quite wildly.

For example in moderate light conditions I was getting for the final Lux values :-

(high gain) 7.17
(low gain) 26181.75
(auto) 0

I switched on the debug mode and could see that the hex register values for the three readings shown above were :-

(high) 0x9D3D
(low) 0x09E4
(auto) 0x9C9E

These seemed to make more sense - the gain 16 values being roughly 16x the low gain value.

So I then switched off the call to reverseByteOrder and this gave me :-

(high) 412.53
(low) 414.10
(auto) 410.65

.. which at least were consistent.

Now I don’t possess a proper Lux Meter, except for a cheap gardening device and an app on my iPad. These gave readings of 250 and 380 in the same situation - so again (given the highly logarithmic behaviour of light intensity) would seem to be in broad agreement.

Now I don’t understand why this appears to work? Both RPi and Arduino are little-Endian and so I think reverseByteOrder is needed, but calling it seems to mess up the values.

A few final points :

1. The TSL2561 has two gain modes, 1 and 16. The “auto” mode in the Python code chooses one of these after measuring at both gains.

2. I put in a “try” to protect the line ratio = ( IR / float(ambient)) from divide-by-zero

3. I think there’s a bug in the reverseByteOrder routine in the Adafruit_I2C class. It doesn’t seem to reverse the bytes if the most significant is 00. For example 0x00EF returns 0x00EF

Anyway, apologies if I’ve been TL;DR, but those are my experiences.

f1vnc
 
Posts: 5
Joined: Tue Feb 17, 2015 10:05 am

Re: TSL2561 and Raspberry Pi

by adafruit_support_mike on Tue Feb 17, 2015 7:17 pm

@f1vnc: Please start a new thread. Trying to debug more than one hardware issue in a single thread just invites confusion.

adafruit_support_mike
 
Posts: 55956
Joined: Thu Feb 11, 2010 2:51 pm

Re: TSL2561 and Raspberry Pi

by f1vnc on Thu Feb 19, 2015 10:46 am

Fair enough I suppose, but I was referring to a post in this thread (albeit one from a while ago)

I'll depart with a couple of points :

1. There's a bug in reverseByteOrder in the Adafruit_I2C Python library on github. It fails when the most significant byte is 00, for example it will (correctly) return 0xCDAB when given the argument 0xABCD, but it (incorrectly) returns 0x00AB when given the arg 0x00AB. This could cause havoc with leading-zero values if byte-reversal is required. I think the problem is caused by returning the wrong length in the offending situation. However I couldn't be anchored fixing it, because ...

2. Byte reversal isn't needed in the Python code given on (about) page 5 of this thread, because the readU16 routine in the library already returns the correct byte order without the need for reversal.

I haven't had any hardware problems.

I've now managed to read good data from the device using PHP, which better suits my needs.

f1vnc
 
Posts: 5
Joined: Tue Feb 17, 2015 10:05 am

Re: TSL2561 and Raspberry Pi

by vannimb on Sun Mar 08, 2015 4:57 am

Thanks guys! Finally i found the issue... and was a bad wire that i had to replace!
now the sensor is recognized!

pi@RASPBERRY-B1 ~ $ 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: -- -- -- -- -- -- -- -- -- 39 -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

Now i can move on with my project!

vannimb
 
Posts: 11
Joined: Thu Jan 29, 2015 4:52 am

Re: TSL2561 and Raspberry Pi

by vannimb on Sun Mar 08, 2015 9:19 am

Hi All,
on a raspberry pi blank juat images is working fine but on my production one is not....
It is like is not even detected when the unit boots.

pi@RASPBERRY-A1 ~ $ dmesg | grep i2c
[ 12.501151] i2c /dev entries driver

I think is a software issue because replacing the production memory card with a fresh installed new one is working....Any idea what should i check to make it work with my production memory card?

Could it be due to the fact that i followed this guide: https://plot.ly/raspberry-pi/tmp36-temp ... -tutorial/ and installed the additional software?

vannimb
 
Posts: 11
Joined: Thu Jan 29, 2015 4:52 am

Re: TSL2561 and Raspberry Pi

by adafruit_support_mike on Sun Mar 08, 2015 4:10 pm

Recent versions of Raspbian have built I2C and SPI support into the OS. To enable them, you need to use raspi-config and select the 'Advanced options' item.

adafruit_support_mike
 
Posts: 55956
Joined: Thu Feb 11, 2010 2:51 pm

Re: TSL2561 and Raspberry Pi

by vannimb on Sun Mar 08, 2015 4:35 pm

Many thanks Mike! it worked immediately!

vannimb
 
Posts: 11
Joined: Thu Jan 29, 2015 4:52 am

Re: TSL2561 and Raspberry Pi

by adafruit_support_mike on Sun Mar 08, 2015 4:39 pm

Glad to hear it worked for you. Happy hacking!

adafruit_support_mike
 
Posts: 55956
Joined: Thu Feb 11, 2010 2:51 pm

Re: TSL2561 and Raspberry Pi

by IainColledge on Sat Nov 28, 2015 2:21 pm

Saw the Adafruit Pi Python repo didn't have a TSL2561 module so took the code done by schwabbbel changed a few things and added the updates that seemed relevant in the CPP code.

I don't have a Lux meter or working knowledge of CPP so would appreciate if someone could see if the values match up with a known good.

There is also a hack that to address a failure to go from 16x to 1x gain, not sure if this happens in a loop in the CPP code as well.

I've forked the Adafruit code on Github here https://github.com/IainColledge/Adafrui ... ython-Code and when I've got a known good for the TSL code will request a pull so everyone can find it.

IainColledge
 
Posts: 5
Joined: Sat Nov 28, 2015 2:15 pm

Re: TSL2561 and Raspberry Pi

by csatt on Thu Dec 10, 2015 3:35 am

IainColledge wrote:Saw the Adafruit Pi Python repo didn't have a TSL2561 module so took the code done by schwabbbel changed a few things and added the updates that seemed relevant in the CPP code.

I don't have a Lux meter or working knowledge of CPP so would appreciate if someone could see if the values match up with a known good.

There is also a hack that to address a failure to go from 16x to 1x gain, not sure if this happens in a loop in the CPP code as well.

I've forked the Adafruit code on Github here https://github.com/IainColledge/Adafrui ... ython-Code and when I've got a known good for the TSL code will request a pull so everyone can find it.


Hi Iain,

Thanks for doing this - it's just what I was looking for!

I have played with your code, and there are a couple bugs and some other
more cosmetic issues. I'll post these comments on GitHub too.

Bug #1: The class name has the middle two digits transposed

Adafruit_TSL2651 should be Adafruit_TSL2561

Bug #2: The read8 and read16 methods (functions) call the I2C readS8 and
readS16 methods respectively. They should call the readU8 and
readU16 (i.e. unsigned) methods.

==> This is why you needed the hack that you added. The readS16
method was returning a negative number when the register had
its upper bit set. You can remove the hack when this bug is
fixed.

Other minor issues:

- Adafruit_I2C.py should not be a file; it should be a symbolic link to
../Adafruit_I2C/Adafruit_I2C.py

- The trailing */ on comments should be removed (vestige of C++ code)

- Add space char after "=" in constant definitions at the beginning of
the class

- In __init__ constructor, use TSL2561_ADDR_FLOAT instead of 0x39

- You changed "enableAutoRange" to "enableAutoGain". I prefer the new
name but perhaps in the interest of keeping the port from the C++
code as pure as possible it should keep the old name.

- The code in enableAutoGain is odd. Couldn't it be just one line? i.e.:
self._tsl2561AutoGain = enable

- Some methods have debug printing xxx_end after the return statement
(e.g. read8)

- It would probably be better to put the comment preceding each method
into a docstring at the beginning of the method definition (low
priority)

- Python purists wouldn't like all the unnecessary parentheses used in
if/elif/while statements (it doesn't bother me though)

csatt
 
Posts: 4
Joined: Thu Feb 19, 2015 6:49 pm

Re: TSL2561 and Raspberry Pi

by IainColledge on Thu Dec 10, 2015 4:40 am

Hi,

Thanks very much and perfect as this was a rush job of pulling things together and getting it in the Adafruit libs. I'll update the code (unless you want to fork and generate a pull so you're in the git history) and also probably add the example files as well then make another pull request to Adafruit to update their lib although it seems a few days before another person made a TSL module too and we're both waiting for pull request acceptance.

So like busses we have two TSL2561 modules arrive at once! :)

I got to test it against a 10 UKP Lux meter off of Amazon and they were within 10% of each other during a days light range so am pretty happy with the result.

Incidentally I wanted something quickly as am writing Nagios scripts to interface to a SAAS monitoring solution, https://dataloop.io/ , if anyone is interested have started blogging about it here http://uk.linkedin.com/in/iaincolledge and the code is on GitHub https://github.com/dataloop/plugins-iot as well as my own.

Thanks again
Iain

IainColledge
 
Posts: 5
Joined: Sat Nov 28, 2015 2:15 pm

Re: TSL2561 and Raspberry Pi

by csatt on Thu Dec 10, 2015 1:36 pm

Hi Iain,

You can make the changes yourself.

This thread is over 3 years old. How ironic that two people submitted pull requests for Adafruit_TSL2561 modules within a couple days of each other!

I looked at the code submitted by asciiphil but haven't tried it yet. What I like about your implementation is that it is a very faithful direct port of the Arduino code, which presumably has been tested heavily. On the other hand, asciiphil's implementation looks to be more elegant and "pythonic". I'll try that code hopefully later today.

For anyone else interested, here's how to get the asciiphil code:

git clone -b tsl2561 https://github.com/asciiphil/Adafruit-R ... ython-Code

- Chris

csatt
 
Posts: 4
Joined: Thu Feb 19, 2015 6:49 pm

Re: TSL2561 and Raspberry Pi

by IainColledge on Thu Dec 10, 2015 2:18 pm

I know Chris, I laughed when I saw his pull request.

When I was going through this thread the fact it was a direct port attracted me to it and from a very quick skim the Arduino code seemed to match up pretty much to the datasheet which makes an easy sanity check. Will be interesting to see if they both pretty much agree in terms of readings.

Given that there are 25 pull requests outstanding on that library then it's good to have the links here to whichever version people want to use.

IainColledge
 
Posts: 5
Joined: Sat Nov 28, 2015 2:15 pm

Please be positive and constructive with your questions and comments.