The library is very useful (thanks) but I have a suggestion to improve it slightly.
Attempting to read the colour temperature using the CalculateColorTemperature function with the sensor in complete darkness results in a divide by zero error at about line 200 of Adafruit_TCS34725.py.
Whilst it is possible to trap this error it would be better if the library returned zero under these circumstances.
Improvement suggestion for the TCS34725 colour sensor librar
Moderators: adafruit_support_bill, adafruit
Please be positive and constructive with your questions and comments.
- Iwprof
- Posts: 7
- Joined: Sun Mar 15, 2015 10:28 am
- tdicola
- Posts: 1074
- Joined: Thu Oct 17, 2013 9:11 pm
Re: Improvement suggestion for the TCS34725 colour sensor li
Thanks for checking out the TCS34725 and suggesting the fix! Great point about the potential divide by zero issue in the color temp calculation. Looking a little bit into color temperature I don't think we want to return a 0 value because that might be interpreted as a color temp and it would actually be on the red side of the spectrum from what I understand. Instead of returning a value let's just return the 'None' value which means no result in python. That way folks can catch if there isn't enough light to determine the color temperature and decide what to do for themselves.
I just updated the Raspberry Pi python code for the TCS34725 if you want to grab it again from github and try it out. I also updated the simple example with it to show catching the None case and printing a message. Thanks again the suggestion!
I just updated the Raspberry Pi python code for the TCS34725 if you want to grab it again from github and try it out. I also updated the simple example with it to show catching the None case and printing a message. Thanks again the suggestion!
- Iwprof
- Posts: 7
- Joined: Sun Mar 15, 2015 10:28 am
Re: Improvement suggestion for the TCS34725 colour sensor li
Thanks for the rapid response - I'll download the updated library and give it a try.
Zero has the advantage that it requires no special handling simplifying the code in, for example, a logging application.
My understanding is that colour temperature corresponds to the emitted light at the specified temperature so as the temperature falls it drops through red at around 1000K to infra-red and finally no emission at absolute zero. (Think of heating a lump of metal)
Having said that, zero being a bit of a special case, 'None' is perfectly sensible as well as long as we know to expect it.
Zero has the advantage that it requires no special handling simplifying the code in, for example, a logging application.
My understanding is that colour temperature corresponds to the emitted light at the specified temperature so as the temperature falls it drops through red at around 1000K to infra-red and finally no emission at absolute zero. (Think of heating a lump of metal)
Having said that, zero being a bit of a special case, 'None' is perfectly sensible as well as long as we know to expect it.
- Iwprof
- Posts: 7
- Joined: Sun Mar 15, 2015 10:28 am
Re: Improvement suggestion for the TCS34725 colour sensor li
Having just reinstalled the library on a new raspberry Pi 2 I've run into a couple of problems.
Firstly the fix for the divide by zero error contains the line (x + y + z) but it should be (X + Y + Z).
Secondly (and possibly with quite a few knock-ons) the i2c library code incorrectly identifies my raspberry Pi 2 as revision zero instead of revision three. Amending the getPiRevision function to use GPIO.RPI_REVISION instead of trying to guess it from the cpuinfo data solved the problem for me.
Firstly the fix for the divide by zero error contains the line (x + y + z) but it should be (X + Y + Z).
Secondly (and possibly with quite a few knock-ons) the i2c library code incorrectly identifies my raspberry Pi 2 as revision zero instead of revision three. Amending the getPiRevision function to use GPIO.RPI_REVISION instead of trying to guess it from the cpuinfo data solved the problem for me.
- tdicola
- Posts: 1074
- Joined: Thu Oct 17, 2013 9:11 pm
Re: Improvement suggestion for the TCS34725 colour sensor li
Oh thanks for catching the error with casing--ack, that's what I get for changing the code without have the sensor handy to test with. Just fixed it up so it should work now. Grab the library again and let me know if you run into an issue with it still though.
That's odd about the I2C bus detection though. On my Pi 2 the bus detection finds it as a revision 2 and picks I2C bus 1. If you're getting a revision 1 board with bus 0 do you mind running 'cat /proc/cpuinfo' (without quotes) and grabbing the output? That can help check if there's something unexpected with the output.
Great point about checking the GPIO.RPI_REVISION variable though--perhaps we can just switch the library over to use that instead.
That's odd about the I2C bus detection though. On my Pi 2 the bus detection finds it as a revision 2 and picks I2C bus 1. If you're getting a revision 1 board with bus 0 do you mind running 'cat /proc/cpuinfo' (without quotes) and grabbing the output? That can help check if there's something unexpected with the output.
Great point about checking the GPIO.RPI_REVISION variable though--perhaps we can just switch the library over to use that instead.
- Iwprof
- Posts: 7
- Joined: Sun Mar 15, 2015 10:28 am
Re: Improvement suggestion for the TCS34725 colour sensor li
My cup info is as follows. As you can see the revision doesn't follow the normal pattern. (Though apparently cou revision codes can vary):
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 57.60
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5
processor : 1
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 57.60
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5
processor : 2
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 57.60
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5
processor : 3
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 57.60
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5
Hardware : BCM2709
Revision : a01041
Serial : 00000000376e6c27
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 57.60
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5
processor : 1
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 57.60
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5
processor : 2
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 57.60
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5
processor : 3
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 57.60
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5
Hardware : BCM2709
Revision : a01041
Serial : 00000000376e6c27
- Iwprof
- Posts: 7
- Joined: Sun Mar 15, 2015 10:28 am
Re: Improvement suggestion for the TCS34725 colour sensor li
Having pulled the updated version I can confirm it now works as intended.
(After I'd corrected the version code in the I2C library to work with my odd PI 2, of course)
I realised after posting that, whilst being the closest thing to an official solution, GPIO currently needs root access which makes it a little inconvenient so possibly the following is a good compromise:
Edit: added details of I2C revision fix
(After I'd corrected the version code in the I2C library to work with my odd PI 2, of course)
I realised after posting that, whilst being the closest thing to an official solution, GPIO currently needs root access which makes it a little inconvenient so possibly the following is a good compromise:
Code: Select all
try:
with open('/proc/cpuinfo','r') as f:
for line in f:
if line.startswith('Revision'):
rev = int(line[9:].lstrip(':'),16)
return 1 if rev < 0x0010 else 2
except:
return 0
- tdicola
- Posts: 1074
- Joined: Thu Oct 17, 2013 9:11 pm
Re: Improvement suggestion for the TCS34725 colour sensor li
Thanks for grabbing the details and showing your I2C revision function. Actually can you grab the Raspberry Pi Python code from github again? It looks like you might have an older version of the Adafruit_I2C.py class--the current code uses a little regex to detect the version now instead of looking at the last digit of the revision. Here's what the code should look like:
That regex version should pick up your revision as a later one since your revision ends with 1041 and not 0000, 0002, or 0003 like the earlier revisions. Let me know if that function is still giving you a problematic revision though, thanks!
Code: Select all
def getPiRevision():
"Gets the version number of the Raspberry Pi board"
# Revision list available at: http://elinux.org/RPi_HardwareHistory#Board_Revision_History
try:
with open('/proc/cpuinfo', 'r') as infile:
for line in infile:
# Match a line of the form "Revision : 0002" while ignoring extra
# info in front of the revsion (like 1000 when the Pi was over-volted).
match = re.match('Revision\s+:\s+.*(\w{4})$', line)
if match and match.group(1) in ['0000', '0002', '0003']:
# Return revision 1 if revision ends with 0000, 0002 or 0003.
return 1
elif match:
# Assume revision 2 if revision ends with any other 4 chars.
return 2
# Couldn't find the revision, assume revision 0 like older code for compatibility.
return 0
except:
return 0
- Iwprof
- Posts: 7
- Joined: Sun Mar 15, 2015 10:28 am
Re: Improvement suggestion for the TCS34725 colour sensor li
I've pulled the latest code from github again and the Adafruit_I2C.py class I'm using, which is the one in the TCS34725 directory, definitely still has the old code. The main Adafruit_I2C folder contains the updated code.
I'm relatively new to python and the Pi so possibly I should have installed something to put the correct driver in the path - I'm just running the code from the directory without installing anything (Other than the normal I2C tools, python environment etc.)
On a probably unrelated note I'm also having trouble with the DHT driver which doesn't seem to be able to use the Pi version 2 extended GPIO pins (29, 31, 32, 33, 35, 36, 37, 38 and 40) - it accepts them but isn't able to communicate with the device. (Pins 7, 11, 12, 13, 15, 16, 18 and 22 all work correctly)
Edit: The DHT library I'm using the the updated one from https://github.com/adafruit/Adafruit_Python_DHT
I'm relatively new to python and the Pi so possibly I should have installed something to put the correct driver in the path - I'm just running the code from the directory without installing anything (Other than the normal I2C tools, python environment etc.)
On a probably unrelated note I'm also having trouble with the DHT driver which doesn't seem to be able to use the Pi version 2 extended GPIO pins (29, 31, 32, 33, 35, 36, 37, 38 and 40) - it accepts them but isn't able to communicate with the device. (Pins 7, 11, 12, 13, 15, 16, 18 and 22 all work correctly)
Edit: The DHT library I'm using the the updated one from https://github.com/adafruit/Adafruit_Python_DHT
Please be positive and constructive with your questions and comments.