Finally! A $20 USB logging luxmeter

[maukka]

Try Prolific's official driver. Their latest version is 1.14.0 while the cd has 1.9.0. It says it has W10 support.

http://www.prolific.com.tw/US/ShowProduct.aspx?p_id=225&pcid=41

I now have a UT382 to play with. I'm alternatively excited and dissapointed with a lot of the features. More on that when everything is working.

Yeah, tried that one already. Doen't work for me

 

[parametrek]

Maukka, I am sorry to hear that. Do you have an old computer or a $30 ARM board to try linux on?

It appears that the UT382 has no way to transfer logged data points to the computer. I'm not sure what the use of a 2000 data point memory is in that case. Additionally there is a completely undocumented "CODE" menu where you can type in a four digit number. That is also a mystery. I will need to do some tests but it appears the UT382 is not temperature compensated either. And it must be manually put into USB mode to do anything with it.

The only good thing about this meter is that it runs at 10 points per second. I would not recommend the UT382 over the GM1020.

 

[Stereodude]

It appears that the UT382 has no way to transfer logged data points to the computer. I'm not sure what the use of a 2000 data point memory is in that case. Additionally there is a completely undocumented "CODE" menu where you can type in a four digit number. That is also a mystery. I will need to do some tests but it appears the UT382 is not temperature compensated either. And it must be manually put into USB mode to do anything with it.

The only good thing about this meter is that it runs at 10 points per second. I would not recommend the UT382 over the GM1020.

Well 2000 data points isn't sufficient for any of the logging I've been doing at 1 sample per second. I use it tethered to the PC and let the software record the data.

 

[parametrek]

One of the use cases I've designed for the GM1020 utility is for just that. It logs frequently and fills up quickly. Then you plug your laptop into the meter, download the data, wipe the memory and reconfigure it to run more slowly.

For example, 1 second sampling fills up in 30 minutes. After 20 minutes you download everything and set it to 10 seconds. Five hours later, download and increase to 1 minute. 24 hours later, download and increase to 10 minutes. This lets you run a test without needing a stationary, always-on computer.

Obviously this is sub-par to non-stop 0.5 second logging. But it does give higher resolution data in the more interesting beginning section.

 

[parametrek]

Stereodude, I've got the UT382 working with linux. It should work anywhere providing that python, pyserial, the CP210x driver and the correct port are all properly set up.

Here is the script: https://github.com/parametrek/gm1020/blob/master/ut382.py

 

[parametrek]

I've updated the gm1020.py script with some basic port autodetection. It should work on Linux, Windows and OSX.

 

[Gauss163]

Are these meters calibrated for LEDs or tungsten, or are they parametrizable?

 

[parametrek]

They don't say. I think you want a much more expensive meter for that sort of thing.

 

[Gauss163]

They don't say. I think you want a much more expensive meter for that sort of thing.

Lux meters calibrated for tungsten won't be very useful for LED lights. A web search will find many expositions, e.g.

http://www.planetextech.com/forum/topics/measuring-led-light-using-an-extech-light-meter
http://www.slideshare.net/theilp/pls-2014-is-measuring-led-illuminance-with-a-lux-meter-accurate
http://www.otc.co.uk/Problem_With_Lux_Meters.php
http://lumeniquessl.com/2014/08/13/light-meter-reviews-comparison-summary/
http://www.olino.org/us/articles/2009/12/07/measuring-illuminance-correctly

 

[parametrek]

I do have a meter that is calibrated for LEDs. The GM1020 responds closely to it for LEDs, but responds very differently in full sun. I think my "reference" meter lacks IR or UV filtering because in sunlight it is reporting numbers twice as high.

 

[Gauss163]

Could you please quantify what "closely" means. How do they compare on tungsten lights?

 

[parametrek]

Within 10%. As hobbyists that is the best we can hope to do anyway.

meter	led	incan
LM-200LED	13.4	12.4
GM1020	14.9	15.0
UT382	13.9	15.8

All units are lux. Setup was a bare 60W (or equivalent) bulb in the ceiling with the meters set on the floor under it. It was interesting to see the LED dim by 15% as it warmed up. These numbers are all too close together for me to be able to draw any meaningful conclusion.

 

[TexLite]

Lux meters calibrated for tungsten won't be very useful for LED lights. A web search will find many expositions, e.g.

http://www.planetextech.com/forum/topics/measuring-led-light-using-an-extech-light-meter
http://www.slideshare.net/theilp/pls-2014-is-measuring-led-illuminance-with-a-lux-meter-accurate
http://www.otc.co.uk/Problem_With_Lux_Meters.php
http://lumeniquessl.com/2014/08/13/light-meter-reviews-comparison-summary/
http://www.olino.org/us/articles/2009/12/07/measuring-illuminance-correctly

They're most likely not calibrated for LEDs. I spoke with Extech tech support about this very subject and was told that if I wanted a meter to measure LEDs specifically, they have a model designed for that, that is to say, designed to read the blue in the LED spectrum more accurately. Was quoted 1-2% for that meter, and around 8% for reading LED's with a standard meter set to Tungsten/Daylight. Incidentally, that LED specific model is one of the more reasonably priced units they sell, around $100, but it's not capable of data logging.

Question for parametrek: What are the chances the program you wrote will work with an Extech meter on OSX? I have one that's been in storage a while and after digging it out recently but realized I no longer have a PC to run the software. I could try using Parallels and run Windows on my Mac but I've never had much luck with that.

-Michael

 

[StandardBattery]

I had bought one of these for simple relative measurements so I didn't have to pull out my more expensive photographic meters, and today I had a call to use it (which I don't often these days). Out of the box it was defective, and would not power up.

However, I found it did power-up when connected to USB so I used it like that. After I made my observations and was done I came here again to see if there was any trick to get it to power-on. I saw the spring contact method used for the battery bay in the teardown and decided to take mine apart. I lifted the battery bay contacts a little off the housing as they were flush and fastened the unit back together. It worked; battery capability restored.

This meter will be used very infrequently by me, so I'm actually quite happy that it can be USB powered. It uses the now mostly abandoned mini-usb connector rather than the now almost ubiquitous micro-USB connector, but that's OK. So if anyone has an issue with the AAA battery source they may want to do the 5min fix. A better fix would probably be to solder on some larger contact pads, but I'll see if this holds up as I don't plan to use built-in battery option.

 

[Budda]

I got mine without any software.
I looked for it on the internet without any luck. I contacted benetech and I'm waiting their answer.
Any chance any of you could share his copy? Thanks.

 

[parametrek]

Question for parametrek: What are the chances the program you wrote will work with an Extech meter on OSX?

Zero. Every meter probably uses a unique communication system. The script might work for meters made by the same brand.

I got mine without any software.

You are not missing anything, it is terrible. Assuming you are on windows, here are some links to the other bits and pieces you need to run my script:

• http://www.prolific.com.tw/US/ShowProduct.aspx?p_id=225&pcid=41
• https://www.python.org/downloads/windows/ (you want 3.5.2 right now)
• https://pypi.python.org/pypi/pyserial

Do not use Ubuntu For Windows! USB and serial ports are a huge mess with that.

Maukka has done some more testing with his two GM1020 meters. One was very good, within 3% of a good meter. The other was more off.

 

[parametrek]

One of the reasons I liked the GM1020 versus the UT382 was the range. The UT382 maxes out at 20k lux, the GM1020 goes high enough to measure direct sunlight.

I hadn't really tested this feature much, but I gave it a workout yesterday. It did extremely poorly. The situation was a 10 lumen flashlight. I was interested in how the flashlight did when the battery was nearly dead and the output weak. So to maximize the sensitivity I set the flashlight on top of the luxmeter, at point blank. This produced a reading of around 25k lux and should let me measure the output down to the last few millilumens.

The runtime plot was disappointing. Note that there are no connecting lines between samples. Each measurement is a single dot. The Y axis is the measured lux and the X axis is the sample count.



The behavior above 20k lux is terrible. First, it is noisy. It jumps all over the place by about 10%. Second, it has no resolution. See the horizontal bands? The meter simply can't measure a value between the bands. Third, the transition to the lower range has a discontinuity and jumps from 20k to 19k.

These flaws don't mean it is a bad meter. You will never see 20k lux in your integration sphere. Even for candela measuring, it only happens with the brightest throwers at close range. (Use a 90% neutral density filter or put some more distance between the meter and the light.) Keep it under 20k lux and the readings are solid.

 

[Mark4931]

One of the reasons I liked the GM1020 versus the UT382 was the range. The UT382 maxes out at 20k lux, the GM1020 goes high enough to measure direct sunlight.

I hadn't really tested this feature much, but I gave it a workout yesterday. It did extremely poorly. The situation was a 10 lumen flashlight. I was interested in how the flashlight did when the battery was nearly dead and the output weak. So to maximize the sensitivity I set the flashlight on top of the luxmeter, at point blank. This produced a reading of around 25k lux and should let me measure the output down to the last few millilumens.

The runtime plot was disappointing. Note that there are no connecting lines between samples. Each measurement is a single dot. The Y axis is the measured lux and the X axis is the sample count.

/snip/

The behavior above 20k lux is terrible. First, it is noisy. It jumps all over the place by about 10%. Second, it has no resolution. See the horizontal bands? The meter simply can't measure a value between the bands. Third, the transition to the lower range has a discontinuity and jumps from 20k to 19k.

These flaws don't mean it is a bad meter. You will never see 20k lux in your integration sphere. Even for candela measuring, it only happens with the brightest throwers at close range. (Use a 90% neutral density filter or put some more distance between the meter and the light.) Keep it under 20k lux and the readings are solid.

That is a great graph showing the limitations of the meter above 20k lux. Are there any artifacts that you can find on the lower end? I'd be curious to see if the zero point could change with temperature. I don't have any experience with lux meters so I find this fascinating.

 

[parametrek]

No, the rest of the range appears to perform flawlessly and without any artifacts.

This meter is actually temperature compensated. My old meter was not. It was painfully obvious during long runs. There would be a triangle wave pattern that followed the day/night temperature fluctuations. And that meter cost four times as much as the GM1020!