TSL2561 and Raspberry Pi

General project help for Adafruit customers

Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.
User avatar
adafruit_support_mike
 
Posts: 67446
Joined: Thu Feb 11, 2010 2:51 pm

Re: TSL2561 and Raspberry Pi

Post by adafruit_support_mike »

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

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

Re: TSL2561 and Raspberry Pi

Post by f1vnc »

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.

User avatar
adafruit_support_mike
 
Posts: 67446
Joined: Thu Feb 11, 2010 2:51 pm

Re: TSL2561 and Raspberry Pi

Post by adafruit_support_mike »

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

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

Re: TSL2561 and Raspberry Pi

Post by f1vnc »

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.

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

Re: TSL2561 and Raspberry Pi

Post by vannimb »

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!

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

Re: TSL2561 and Raspberry Pi

Post by vannimb »

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?

User avatar
adafruit_support_mike
 
Posts: 67446
Joined: Thu Feb 11, 2010 2:51 pm

Re: TSL2561 and Raspberry Pi

Post by adafruit_support_mike »

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.

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

Re: TSL2561 and Raspberry Pi

Post by vannimb »

Many thanks Mike! it worked immediately!

User avatar
adafruit_support_mike
 
Posts: 67446
Joined: Thu Feb 11, 2010 2:51 pm

Re: TSL2561 and Raspberry Pi

Post by adafruit_support_mike »

Glad to hear it worked for you. Happy hacking!

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

Re: TSL2561 and Raspberry Pi

Post by IainColledge »

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.

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

Re: TSL2561 and Raspberry Pi

Post by csatt »

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)

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

Re: TSL2561 and Raspberry Pi

Post by IainColledge »

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

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

Re: TSL2561 and Raspberry Pi

Post by csatt »

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

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

Re: TSL2561 and Raspberry Pi

Post by IainColledge »

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.

User avatar
asciiphil
 
Posts: 3
Joined: Mon Aug 05, 2013 11:27 pm

Re: TSL2561 and Raspberry Pi

Post by asciiphil »

Well, Chris pointed out some bugs in my code, so a straight adaptation of the Arduino code is probably a lot more likely to be correct. I won't feel slighted if my pull request is rejected.

On the other hand, I prefer my code for my own use (go figure). If I'm working with Python code, I prefer to use things that work in Pythonic ways. Aside from the design of the classes and such, one conscious decision I made was to ignore a lot of the bit-twiddling the C code does to keep everything in the realm of integer arithmetic and embrace the fact that since I'm already running an interpreted language, floating-point math shouldn't hurt me too much.

Locked
Please be positive and constructive with your questions and comments.

Return to “General Project help”