How about get the setup working without converting to frequency and -then- take that step?
Just show the pulses, your raw data, as you point at darker or lighter things right in the house. That will let you test and debug everything but the convert and I and or others will walk you through the conversion to the best of our abilities?
But you are talking about pulses, the sensor outputs a frequency, that isn´t the same?
is Pulse the time and freq the hight of the wave? And the dutycycle of the sensor is 50%, is that because it ouputs a square wave or something?
I did all the maths in the sketch last night, just to see how things work together like pulses, frequency an so forth. One thing i i stumbled upon is the "Gate time", what exactly is that, because that one is set to 100ms in the sketch, but somwhere on the internets, i read that the Gatetime should be set to 1000ms to get "the true freq of the sensor"?
that's where your mixed-types math is a totally different issue, let's cut that in the attempt to troubleshoot and get back to it when the rest is ready.
#include <FreqCounter.h>
void setup() {
Serial.begin(57600); // connect to the serial port
Serial.println("Frequency Counter");
}
long int frq;
void loop() {
FreqCounter::f_comp= 8; // Set compensation to 12
FreqCounter::start(1000); // Start counting with gatetime of 100ms // CHANGED TO 1000/
while (FreqCounter::f_ready == 0) // wait until counter ready
frq=FreqCounter::f_freq; // read result
Serial.println(frq); // print result
delay(20);
}
The Irradiance responsivity for my sensor is 2.3 kHz/(uW/cm2)
and the integrated photodiode active area is 0.92 mm2 in size
How should the formula look for converting my hz to mW/cm2?
And what gatetime should i use? Martin Nawrath sais that "The Gate Time for the counting period can be chosen in the start() function where values of 10, 100 or 1000 ms are practicable for a resolution of 100, 10 and 1 Hz but any value can be used. The internal resolution of the gatetime is 2 ms so that the time can be varied in the increment of 2."
Does that means that if i use a gatetime of 1000ms, i will be viewing my sensor in Hz, and if i use the 100ms that is used in the freqcountersketch, i will be viewing the sensor in Hz/10?
Does that means that if i use a gatetime of 1000ms, i will be viewing my sensor in Hz, and if i use the 100ms that is used in the freqcountersketch, i will be viewing the sensor in Hz/10?
It means that the larger the sample taken, the less effect any roundoff or error will make, and then you use a convenient unit in pulses / time for storage and calculation and display to desired format for display.
If you choose your units right, the math should fit within the range of type long or type long long.
If neither can cover the necessary range then it's BCD, the Big Number library, roll your own way or floats, those piles of sand....
I gotta go, RL, AFK soon... mates, bar, BBL and deal with the formula, range needed and code.
Ok, i start to understand now, for the long, it can hold 32 bit of numbers, witch is 2 billions something, i think that will do, so for now, i will count Hz.
i also found this formula that seems more logical for me
From candela/m2 to magnitudes/arcsec2:
B=-2.5Log(C/108000) or 12.58-2.5Log(C)
Ok, got a little help from the guys at www.astronet.se
This is the code as it looks now:
#include <FreqCounter.h>
#include <Math.h>
long Msqm;
const float A = 22;
void setup() {
Serial.begin(57600); // connect to the serial port
Serial.println("Frequency Counter");
}
long int frq;
void loop() {
FreqCounter::f_comp= 100; // Set compensation to 12
FreqCounter::start(1000); // Start counting with gatetime of 100ms // CHANGED TO 1000/
while (FreqCounter::f_ready == 0) // wait until counter ready
frq=FreqCounter::f_freq; // read result
Serial.print(frq); // print result
Serial.print(" Hz ");
Serial.print(Msqm);
Serial.println(" Mag/Arcsecond2 ");
delay(20);
Msqm = A - 2.5*log(frq);
return;
}
The formula is A - 2.5*log(frq) where A is the magnitude constant, right now, the "guess" for A is 1Hz at a level 22 mag sky. //not calibrated at all though.
Corpze:
Ok, i start to understand now, for the long, it can hold 32 bit of numbers, witch is 2 billions something, i think that will do, so for now, i will count Hz.
i also found this formula that seems more logical for me
From candela/m2 to magnitudes/arcsec2:
B=-2.5Log(C/108000) or 12.58-2.5Log(C)
Yes. But the variable has to be able to handle the math you will use when scaling and squaring, be able to count much bigger than the numbers used, and smaller.
If I am dealing with kilometers, my work unit might be in millimeters, mm fractions are lost.
To help keep accuracy, instead of 1 float factor like 333.333333 I keep two integers 1000 and 3 and use those as 'x 1000 / 3' in the bigger equation.
When the bigger equation is written out don't be afraid to rearrange the operations (without breaking the algebra!) to push the intermediate value high before dividing.
X = A * (1000 / 3) * (22 / 7) would re-arrange to X = A * 22000 / 21. Note that with FP using factors you get the first.
Once you have your equation, then is the time to see how many digits you need. If A above is big then I need enough for 7000 x the biggest 'A' can be with enough to the right for display decimals.
Using mm I can show 1.234 km or 1.2 km and know I had 2 places round-safe in the math.
You deal with some squares and factors with lots of places? Some of those will be simple as a ratio of integers, some won't. Pi to 6 places is 3141592 / 1000000, to use that in an integer equation adds 7 digits to the digits needed to hold the number being multiplied by Pi to 6 places. There's a price for precision and scale, in digits and bytes.
Thanks, i will try log10 instead, and add a button, one thing i want to add is higher resulotion on the Hz-side, can i use a divider or something like that? Will mHz result in higher res.?
And measure several samples and average them?
Watch out for rounding errors due to integer division as it truncates.
Think for your application you better sample for some time and determine the minimum and maximum.
frequency = 0;
unsigned long minimum = 1000000;
unsigned maximum = 0;
buttonSQM = digitalRead(SomePin);
while (buttonSQM == HIGH)
{
frequency = FreqCounter::f_freq;
if (frequency > maximum) maximum = frequency ;
if (frequency < minimum) minimum = frequency;
buttonSQM = digitalRead(SomePin);
}
now do math with min & max as this gives the range (accuracy) of your measurements.
you can also do average as (min + max)/2;
I am just now building something similar in function, although I'm not interested in measuring dark sky. However, I have a few suggestions for you:
First, think in terms of the area of the sky the sensor is seeing. The shorter the focal length of the lens, the wider the area that impinges upon the sensor. Of course, the sensor is tiny, so that may not be much of a consideration. But it's something to keep in mind.
Second, use an "optical amplifier" to strengthen the signal: a lens. Surplus shops have tons of huge, short-focus lenses that were used in the now-obsolete projection monitors, and you can get a 3" objective for under $10. I found a plastic jar that fit it perfectly, cut the jar up and stuck it on, then mounted the sensor inside it. This thing was extremely sensitive: I was using the TSL235R sensor, which is not as sensitive as the one you describe, I was still getting something like 3 Hz output pointed at a midnight sky. When I realized that I didn't need that much sensitivity, I tore it apart.
GeezerFrog:
I am just now building something similar in function, although I'm not interested in measuring dark sky. However, I have a few suggestions for you:
First, think in terms of the area of the sky the sensor is seeing. The shorter the focal length of the lens, the wider the area that impinges upon the sensor. Of course, the sensor is tiny, so that may not be much of a consideration. But it's something to keep in mind.
Second, use an "optical amplifier" to strengthen the signal: a lens. Surplus shops have tons of huge, short-focus lenses that were used in the now-obsolete projection monitors, and you can get a 3" objective for under $10. I found a plastic jar that fit it perfectly, cut the jar up and stuck it on, then mounted the sensor inside it. This thing was extremely sensitive: I was using the TSL235R sensor, which is not as sensitive as the one you describe, I was still getting something like 3 Hz output pointed at a midnight sky. When I realized that I didn't need that much sensitivity, I tore it apart.
I will use a 20mm 20degree lens, so i will amplify the light
About the rounding errors, i will look in to that, but something i don´t understand is why i should use log10( instead of log( ?
Then, a guy i spoke to said that using that low of freq. can result in really bad accuracy, and pointed out that i might measure the time between two uprising flanks??? and then invert, then i can get accuracy down to the CPU-speed? I have no idea of what he is meaning?
FreqCounter for very low frequencies (below 100 Hz or something) isn't the best thing you can do to count cycles.
As someone told you, you would need to measure the length of the pulse instead (FreqMeasure, FreqPeriod, InputCapture, pulseIn, millis()/micros() ).
Since at dark time it's rare to get more than 10,000Hz with those sensors, I think FreqCounter isn't useful at all for this project.
Am i getting the Hz in "centiHz" now? and why is the values fluctuating that much? i left the sensor in a enclosure with the same amout of light hitting it all the time