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 supportbest regards

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

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.

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.

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.

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.