TSL2561 and Raspberry Pi Moderators: adafruit_support_bill, adafruit

[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.

[csatt]

Here's my comparison of the two proposed Adafruit_TSL2561 modules.

APIs:

- The IainColledge module has an API that maps directly to the API
for the Arduino C++ code

- The IainColledge module provides class methods to set modes,
configure the device, access measurements, etc., after object
creation

- The asciiphil module allows more configuration at object creation
time (i.e. its constructor method has more parameters)

- The asciiphil module provides class properties (as opposed to
methods) to set modes, configure the device, access measurements,
etc., at runtime

==> I think there's some benefit in having an API that is similar
to the Arduino code since there may be cases where code is
ported from one platform to the other.

Math:

- The IainColledge module uses the integer math approximation from
the data sheet for the lux calculation ("Simplified Lux
Calculation")

- The asciiphil module uses the floating point math equations from
the data sheet for the lux calculation

==> The floating point math should be more accurate, BUT the
difference is in the noise compared to the +-40% accuracy of
the sensor itself (see last entry in table on data sheet p.4),
so this is really a wash

Coding style:

- The IainColledge module is not very object-oriented (only class is
the Adafruit_TSL2651 class itself)

- The IainColledge module is not very "pythonic"; it is pretty
obvious that it is translated C++ code

- The asciiphil module is much more sophisticated python code. It is
truly object-oriented. It uses properties, decorators, docstrings,
dictionaries, indexed lookups, exceptions, etc. It has better error
checking.

==> The advantage of the IainColledge style is that it is easy to
understand even for a novice programmer, and that describes the
majority of this community. If the goal is to have code that is
easy for this community to understand, debug, and
modify/enhance then the IainColledge style is preferable. But
if the goal is to have code that this community might actually
learn to be better coders from, then the asciiphil style is
better.

Features:

- The IainColledge module can be run standalone

==> Not necessary, but nice. Easy to add.

- The IainColledge module has an auto-gain feature

==> The auto-gain feature is very useful, so I think it should be
added to the asciiphil implementation

- The asciiphil module has a "continuous mode" feature (which is
actually the default)

==> Not sure how important this is to most people and it uses more
power

- The IainColledge module returns a lux value of 0 when the sensor
saturates

==> This matches the Arduino code, but is undesirable (IMO) since
0 is a valid value. I'd prefer that it returned a negative
number.

- The asciiphil module throws an exception when the sensor saturates

==> This crashes the caller unless they know how to properly catch
and handle exceptions. This is ok, but there should be example
code for novice users

- The IainColledge module has an average lux calculation feature (not
in Arduino code)

==> Nice, but not necessary. Easy to add externally.

- The asciiphil module automatically determines the package type from
the ID register

==> Nice enhancement if anyone uses this code for anything other
than the Adafruit TSL2561 breakout

Conclusions:

- With the bug fixes both of these implementations work fine

- I do think adding automatic gain selection to the asciiphil
implementation is important

- Each (but especially the asciiphil version) could benefit by
including a module of example code showing how to:

- Instantiate the object
- Set modes
- Get the lux value
- Handle saturation cases

- Personally I would like to see both of them committed
(e.g. Adafruit_TSL2561.py and Adafruit_TSL2561_alt.py)

- Forced to choose, I would go with the IainColledge implementation
because I think having a direct map of the Arduino code could be
important for some people

[IainColledge]

Thanks for the writeup Chris, have started making some changes to the code I lifted from this thread for a next release, I'll also link to Phil's one too in the comments.

Will probably put in a logger too instead of debug prints and so on. Ideally putting in some better practices but still making it easier to follow.

Incidentally the average lux calc is just there in case you're measuring in a flickering light source say one with a 50/60hz flicker and to smooth out noise in the readings.

BTW This is a blog post I made on what I'm doing in case anyone is interested https://www.linkedin.com/pulse/measurin ... n-colledge

[csatt]

Thanks for the writeup Chris, have started making some changes to the code I lifted from this thread for a next release, I'll also link to Phil's one too in the comments.

Will probably put in a logger too instead of debug prints and so on. Ideally putting in some better practices but still making it easier to follow.

Incidentally the average lux calc is just there in case you're measuring in a flickering light source say one with a 50/60hz flicker and to smooth out noise in the readings.

BTW This is a blog post I made on what I'm doing in case anyone is interested https://www.linkedin.com/pulse/measurin ... n-colledge

Hi Iain,

Of course the average lux calc can be useful. It just seems like a simple enough thing to do externally (unlike the automatic gain selection), so I wouldn't penalize Phil's code for not having it.

BTW, the bulleted feature list at the top of the data sheet says "Automatically Rejects 50/60-Hz Lighting Ripple". That's the only mention, however, and I wonder if it is true in the 13.7ms integration time mode since 50Hz is a 20ms period and 60Hz is a 17ms period. It's also notable that they say "ripple" and not "flicker".

- Chris

[IainColledge]

Have updated the code using the inspection capabilities in PyCharm and SonarQube so at least it looks like Python now, there are three things that need looking at which I've flagged with TODO's but will have to look at them some time in the near future.

Thanks for all the help

[Swiftdb4]

I just received my sensor, going to try your code this weekend,

[andrew76]

Hello!

I've been looking through this thread and other sources trying to get my TSL2561 to work with a RPi...

All the programming details stated in this thread go way over my head... I was hoping to find something that 'just worked' :-)

This git seemed promising: https://github.com/seanbechhofer/raspbe ... TSL2561.py

However it refers to an Adafruit_I2C library that isn't maintained anymore. Even if I download the old library, I can't seem to get it to work... The TSL2561.py program always errors out with:

Code: Select all | TOGGLE FULL SIZE

Traceback (most recent call last):
  File "tsl2561.py", line 10, in <module>
    from Adafruit_I2C import Adafruit_I2C
ImportError: No module named Adafruit_I2C

I'm thoroughly stuck and would be very grateful for a nudge in the right direction.


Andrew

[andrew76]

okay... this is a bit embarrassing... even though I haven't been able to get the AdaFruit_GPIO /-I2C libraries to work, I finally thought to expand my google search beyond the 'AdaFruit Universe' and found this post (in german):

http://www.mogalla.net/201502/lichtsensor-tsl2561-am-raspberry

The short code listed there only uses the

Code: Select all | TOGGLE FULL SIZE

time

and

Code: Select all | TOGGLE FULL SIZE

smbus

libraries and worked right off the bat (well, almost... I changed the sensors address form 0x49 to 0x39 (probably a typo on the author's page)).

Thought this information may be useful to someone...


Best regards,
Andrew

[nardev]

This one worked for me...in BeagleBone

Just make sure that you determine your i2c bus number correctly


https://github.com/ControlEverythingCommunity/TSL2561


C and python works..