Natural Log calculatons, are they possible
LoopyByteloose
Posts: 12,537
I acquired some TAOS·light sensors that compensate by removing the IR from the total light for the sake of more accurate calculation of visible light.
My dilemma is their formula for converting digital readings into commonly accepted LUX values.
It goes something like this:
[noparse][[/noparse]Sensor0-Sensor1]x0.39xe[noparse][[/noparse]0.18Rsquared]
where R is equal to [noparse][[/noparse]Sensor1/Sensor0-Sensor1]
I know that it would be easiest to merely send the sensor reading to a PC and have the PC recalculate, but I would like to consider an off network·microcontroller solution.
Since it implies natural log·look-up tables are required, it would seem to me the SX-48 might be needed.· I guess all the multiplication could be handled with look up tables.· I am not clear on how to impliment a natural log table in binary.
I am also wondering if the natural log creates a greater burden than Base 2 log tables.· If that is the case, can I use Base 2 logs·and insert a constant value for e?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"If you want more fiber, eat the package.· Not enough?· Eat the manual."········
My dilemma is their formula for converting digital readings into commonly accepted LUX values.
It goes something like this:
[noparse][[/noparse]Sensor0-Sensor1]x0.39xe[noparse][[/noparse]0.18Rsquared]
where R is equal to [noparse][[/noparse]Sensor1/Sensor0-Sensor1]
I know that it would be easiest to merely send the sensor reading to a PC and have the PC recalculate, but I would like to consider an off network·microcontroller solution.
Since it implies natural log·look-up tables are required, it would seem to me the SX-48 might be needed.· I guess all the multiplication could be handled with look up tables.· I am not clear on how to impliment a natural log table in binary.
I am also wondering if the natural log creates a greater burden than Base 2 log tables.· If that is the case, can I use Base 2 logs·and insert a constant value for e?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"If you want more fiber, eat the package.· Not enough?· Eat the manual."········
···················· Tropical regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan
Comments
· What is the range of the Sensor0 and Sensor1 variables ?
· Depending on what resolution you need, you might get away with a small table by using interpolation.
· I had the same kind of problem using the Parallax thermocouple with the SX28. But after playing with the data in excel, I came up with a program that used only a small table. I have attached the program.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap used 4-digit LED display with driver IC·www.hc4led.com
Low power SD Data Logger www.sddatalogger.com
SX-Video Display Modules www.sxvm.com
Stuff I'm selling on ebay http://search.ebay.com/_W0QQsassZhittconsultingQQhtZ-1
"USA Today has come out with a new survey - apparently, three out of every four people make up 75% of the population." - David Letterman
You could try the two dimensional lookup table method
or
expand your expression as a series using the series for e to the power x given below:
e^x = 1 + x/1 + (x^2)/2! + ... + (x^n)/n! + ....
then truncate the series to give your required accuracy.
Regards
electronic
The TAOS sensor has a fairly convoluted method of outputing its readings to cover a complete range of intensity, so the range is a bit difficult to explain. I will have to re-read the material in order to get a good idea of what resolution. Just from memory, I think the raw reading are up to 10,000. But I may be wrong, so I'll post real fact tomorrow.
I guess I should take a log at an old fashioned natural log table to get an idea of what range and level of detail.
Expansion requires division. Both the multiplication and division processes are quite demanding of an RISC microcontroller; so converting to logs and doing subtraction or addition and converting back seems more appropriate to me. Either you can use a chunk of EEPROM or your code can hang up in iterations for awhile.
Simply put, the TAOS sensor is quite good quality - but very technically exotic and challenging.
I am interested in it for measuring ambient light in orchid production. Apparently, what is currently being used is not reliable because single photodiodes can be swamped by IR from electrical lighting or heating; and have problems with 50 or 60 cycle hum. This particular sensor claims it does not, so it would allow them to agument heat and agument light with grow lights in a predictable way.
TAOS was kind enough to send me 5 samples, but even the serial interface requires a custom approach.
As it stands, they have their whole automated light control shut down. I believe they are using a photo light meter for spot checks and watching the orchid leaves for appropriate intensity of green. Certainly job security for the greenhouse crew, but the owner would love to at least remotely monitor and confirm they are making optimal evaluations.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"If you want more fiber, eat the package.· Not enough?· Eat the manual."········
why not just use an IR filter in front of the detector like on CCD cameras ?
I do have a photodiode that is compensated for visible light, but requires a few op amps to support it.
The growers enjoy having a few trade secrets about the way they do things, so I cannot be entirely sure that the existing sensors are at fault.
In any event the range appears to be from zero to about 66,000,000. I am a bit taken aback by how complex an approach they have for the sensors. Seems that sending the raw bytes to a PC and doing number crunching there is the best solution. I can do that with RS-422 full duplex.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"If you want more fiber, eat the package.· Not enough?· Eat the manual."········
I settled on the Microsemi light sensors, specifically the LX1973A, for a similar application. It is a photometric response (peaked in yellow to follow the human eye response), meant for control of backlighting in such things as computers and automobile dashboards. It is not meant as a scientific instrument, but with a little calibration it is quite good and much easier to use than the Taos sensor. The output is a single analog current (or voltage) that covers 5 or 6 decades of light level. The curve is compressed to the fourth root of light intensity (in order to get the dynamic range), but with only one variable it is much easier to implement the math and the calibration.
I'm using this sensor at very low light levels, as it is good down to levels of 0.01 lux or even 0.001 lux for night or moonlight, and its natural full scale only goes up to about 100 to 500 lux (bright indoor room light level). But that can be scaled with a neutral filter, or a color shaping attenuation filter if you want.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
If you don't need results millions of times per second, think about doing the math on the chip.
There are integer methods to do log and antilog calculations, for example, www.emesys.com/BS2math3.htm#bitlog. Base conversion is a constant, for example, log_e(x) = 0.69315 * log_2(x). With integer calculations, the problem is usually one of scaling. Light levels can cover many orders of magnitude, nevertheless, for greenhouse work the optimum range is probably within one order of magnitude.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
The Base Conversion to Log_2 would make it more attractive - especially on the Propeller which already has the Log_2 tables on board.
Yes, those 'chord gain settings' seem to be a snag. At least I am learning something about how audio compression techniques can apply to other sensors in order to provide a wider range.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"If you want more fiber, eat the package.· Not enough?· Eat the manual."········