Finally! A $20 USB logging luxmeter

The other month I came across something that sounded too good to be true: the Benetech GM1020. $20 Chinese luxmeters are nothing new, but meters that can log are usually ten times as expensive.

At $20-$30 a pop you can pick up a spare or two. What does a flashlight reviewer need spare meters for? Those low modes that keep going for days or weeks. Now you can run those tests without tying up the main meter.

As I feared, the software it came with was both Windows-only and completely terrible. With a few days of prodding I reverse engineered the communication protocol and wrote a cross-platform python script.

Here is Benetech's page for the GM1020: http://www.benetechco.com/en/products/digital-lux-meter-gm1020.html

The script is hosted on github at https://github.com/parametrek/gm1020

Some observations on the hardware:

The specs and build quality are on par with any other $20 meter.

It will draw power from USB, giving it unlimited runtime. Current consumption over USB is next to nothing. Under 10mA for normal operation. Sending a USB command wakes up the Prolific chip and the power draw will jump to 70mA. Closing the serial connection does not reset this. Thankfully unplugging and replugging the USB will, which will happen anyway if you move the meter from your computer to a powerbank. Looking at the datasheet it might be possible to add a jumper and a pushbutton to make it go back to sleep. But the datasheet also says it shouldn't draw more than 25mA and that closing the COM port should automatically suspend the chip. I'd like to figure this out but 70mA isn't a big deal.

The meter gives fairly different values from my "nice" luxmeter. However my "nice" meter has no thermal compensation and I can't trust it. The GM1020 does measure temperature so one would hope it is using the information. I would appreciate it if someone with a good quality meter could do a comparison.

At first I was annoyed that there was no cable between the sensor and the body. It is much easier to build an integration box with one. However that doesn't bother me any more. The meter is not very usable as a standalone by repeatedly tapping and holding the three buttons. For all practical purposes the USB cable is always plugged in and I only operate the meter by computer.

I do still wish there was a tripod mount. I might epoxy a 1/4"-20 nut somewhere.

The USB connection only supports a sluggish 19200 baud and there is only 4KB of EEPROM. The non-volatile memory can only hold 1900 samples, which take 0.6 seconds to transfer. At the fastest 1-second sampling rate the memory will fill in 30 minutes. At the slowest 1-hour rate it will fill in 11 weeks. Of course 19200 baud is more than enough for live monitoring.

Some comments on my script:

It should work anywhere the PySerial module can be installed. I've written the script for python3 but it runs okay in python2 as well. The defaults are for a linux system. Windows users will have to install the Prolific USB driver that comes on the CD-ROM. Windows and OSX will also need to tweak the port name. In the future I would like my script to automatically detect the OS and choose the correct defaults for it.

With the script you can do everything the Windows software did, except for make terrible graphs. Instead the script logs data to a tab separated file and then you can use whatever plotting software you are comfortable with. It is very easy to automate too. The script has a lot of options. I'm not going to copy them here, run "--help" to see it all.

The best way to use the meter is to plug it into a Raspberry Pi, set it in a corner and forget about it. With live monitoring it will log 2 samples per second forever. Multiple meters per computer is fine too. You could probably run a hundred of these meters from a single computer with enough USB hubs.

Alternatively it can log to EEPROM. Keep the meter plugged into a USB charger so it can run forever. Every couple of hours or days (depending on the logging rate) you'll have to plug the meter into your laptop, then download and wipe the data. It isn't quite as convenient but it doesn't require a dedicated computer.

Next I'd like to get more feedback from people using the meter. At least in three weeks when your new meter finally arrives If you have any questions about the meter or the software, please fire away.

And I should do a teardown of the hardware too. Expect photos of that soon.

Looks good. thanks for the heads-up.

Bookmarked. I do need a good luxmeter but the best ones are too pricey.

On the other hands, if the 4KB EEPROM is indeed on the SPI bus, that would be a blessing in its right as I have a few magnetic RAM chips in my part box, unused. The biggest I have is about 512KB, and if it's I2C, that again is no problem as I have a piezoelectric FRAM memory too. On the other hand, that may be a problem for some peoples as those memory chips aren't cheap (still, infinite rewrite endurance is worth it). Providing the firmware isn't held on the EEPROM, but rather the on-die flash inside the microcontroller.

Amazing find! Ordered two from ebay.

edit: Your python script seems to run nicely under Windows 10 Ubuntu after installing the Python Serial. Ubuntu already comes with Python installed. Great stuff!

parametrek said:

The other month I came across something that sounded too good to be true: the Benetech GM1020. $20 Chinese luxmeters are nothing new, but meters that can log are usually ten times as expensive.

Click to expand...

FWIW, the Uni-Trend UT382 isn't 10x the cost. Of course it doesn't support anything newer than XP with the USB drivers and it has a 20k lux limit, but more options are always good.

And here are some quick photos of the PCBs. I'm sorry the chip markings are not legible. Here's a summary of them:

• Two thin wires are for the thermister.
• 4 trim pots (1 multiturn)
• Unpopulated 2-pin header "BT1"
• 1 jumper point (J2)
• +20 test points (all unmarked except for +5V, Vss, reset)
• Where did U7 and U8 go? No idea.
• IR filter over the photodiode? I might upgrade the photodiode.
• There is no reason for the USB port to be in the head.
• Yes, the USB goes through 8cm of plain hookup wire.

You think the USB port would be in the body, since all those wires need to be fed through the neck. I speculate they re-used an older non-USB mold. It would be cheaper to change the smaller head-mold than the larger body mold. So you end up with this monstrosity.

U9 seems to be an I2C EEPROM. How do I know? I have noticed that three pins (pin 1 - 3) on the SOIC-8 package seem to have its I2C addresses tied to the default "0", pulled up to Vss.

Whenever I order this Luxmeter, I'd experiment with installation of the I2C FRAM I have.

Dr. Mario, the 1900 limit is almost certainly coded into the firmware. Updating the eeprom probably won't help there. And I doubt write-endurance will be an issue in normal use.

Stereodude, it looks like the UT382 is $60 or so? If I can find a good deal on it I might pick that up and reverse engineer it too.

parametrek said:

Stereodude, it looks like the UT382 is $60 or so? If I can find a good deal on it I might pick that up and reverse engineer it too.

Click to expand...

There's one left on eBay for $27.86 shipped if you're in the US.

Still, it wouldn't hurt to try. Should it not going as planned, I can re-swap back in old EEPROM. Or I can solder in a burn-in test SOIC-8 socket if I can find one cheaply.

maukka, I think you already have much nicer meters?

Now if the firmware is also in the eeprom, then that would be a huge deal. Writing a custom FW would not be easy but it could become a much nicer meter.

At some point I will have to trace where every pot is connected to. Upgrading the photodiode to something with a better response curve will require a complete recalibration.

Oh, and I forgot to mention: it runs great from a pair of AAA eneloops. A lot of the chinese gear needs 3V, I was pleased to learn this does fine on 2.4 volts. Reports full battery too.

I agree. If the firmware is inside the EEPROM, it would be hard to copy the content onto new EEPROM (or whatever your favorite EEPROM substitute would be) without an I2C scanner on hand. I have FT2322H, however I have yet to figure out how to clone the data from the I2C flash chips. I am also on Linux, BTW. On other hand, I kind of doubt that EEPROM would contain the firmware as 4KB is barely enough for anything, let alone extremely short logs.

It's also possible to modify the firmware, providing any of us know how to reverse engineer the MCS51 (i8051) ISA based firmware ROM pulled from the microcontroller (U5 chip). 8051 MCS-51 is an ancient microcontroller CPU architecture. (I wonder why didn't they go with ARM, as it's actually a lot cheaper and usually can calculate very complicated ADC data. Oh well.)

I don't know how big the eeprom is, but a full 1900 points would require 3.8KB. Plus the 60 "manual points" which are another 120B plus the configuration which is 3-7 bytes depending on how they pack it. I had originally guessed the low 4KB limit was because there was only 4KB free on the chip. According the datasheet it has 32KB of flash on board, so I'm not sure why there would be a dedicated eeprom at all.

Cloning the eeprom is the simplest part of the whole operation. Get a datasheet and a $3 MCU and loop over the address space. No datasheet? Logic analyzer to figure it out.

I'm doubtful about modifying the firmware on the MCU. It is very common to burn the fuse on the loader, making it impossible to read the existing code or flash new code.

That's true. However, 32KB EEPROM is inside the microcontroller, as the datasheet indicated, and the "4" number in I2C EEPROM indicated 4 kilobytes space, from what I know about those EEPROM chips, including those I have used before. I'd not discount the fact that it (the 4KB EEPROM) has the calibration data, it's pretty common to do so in most precision hardware (I doubt this luxmeter is truly accurate due to uncertainty of 8-bit opcode sizes versus the ADC used therein, so accuracy is usually less here, however, with proper calibration procedure, you can get away with that).

parametrek said:

maukka, I think you already have much nicer meters?

Click to expand...

We still buy cheap Chinese keychain lights even if we have some expensive lumen monsters, don't we?

Opcode size has nothing to do with accuracy. It is only calculating 2 things per second. "Wide" 16 bit soft-math isn't too much to ask for.

The ADC is 12 bits. They could get more than 12 bits with averaging, averaging 256 points makes it 16 bits. The slowest ADC sampling rate might be 31Khz. Plenty of time to grab a few extra samples. Though stuff like this is also why I'd want to write my own firmware.

Up to 32 samples per second would be fine. (Some I2C or SPI luxmeter sensors demands to be checked every 1,000th times in a second, however, for simple photodiode luxmeter, you're free to cheat.) However, be aware of 8-bit processor limitation. There's also about 768 bytes of RAM space so it may be okay if you know how to keep certain math stacks as small as possible.

Not questioning you, of course, however, each and every microcontrollers have their own quirks. If I ever decide to pick this luxmeter, I'd be interested in hacking it.

Just got one, but the driver doesn't work under Windows 10. According to the PL2303 manual, there are older chip versions that aren't compatible with Windows 8 and 10. Asked the seller if this was the case.

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.

parametrek said:

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.

Click to expand...

Good luck. Their software only works with a specific driver that doesn't work in any OS newer than XP or XP x64. With your own app or script it may be possible to use it with only the generic USB to serial driver.