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....

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?

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 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.