CamTracker does not always produce logs

[dostuffthatmatters]

On systems mc/md/me, CamTracker logs into the LEARN_Az_Elev and SunIntensity files, whenever the system is tracking the sun. You can see this on the files last modification date.

However on system ma and mb, these files are not kept up to date even though we have usable data.

[patrickjaigner]

It seems like that CamTracker is at least logging into the SunIntensity.dat Logfile.

From my master's thesis:

About SunIntensity.dat:
In Table 11 a sequence of SunItensity.dat is shown. In the first and in the second
’line’ column is not present in SunIntensity.dat and is ignored) timestamps are given in Julian and Gregorian (GD) calender dates. GD is the known time format of todays western world. It was introduced by Pope Gregory XIII in October 1582. The file is updated every six to seven seconds. The third column shows the sun’s intensity ("The solar intensity is calculated as the average intensity of the pixels between the small and the big ellipse (the irradiated area), divided by the exposure time for normalization" [Bruker Optics/Bruker Optik GmbH, 2014]). Dependent on the cloud coverage the value changes. With more clouds blocking the sun the intensity value decreases, until it changes to ’nan’ (as shown in line 7). In correlation to that the fourth column shows either ’good’ or ’bad’. For this a specific threshold is deter- mined dependent on internal CamTracker settings and the sun’s radiating power on the day. In live tests we found that the fourth column will log ’good’, if ’both the fit for the solar rum and the fit for the field stop opening gave good results (radii and eccentricities ranges)’

About SunPosOffset.dat
Lines 21-26 (Table 11, column ’big and small obj good’) show a good sun detection. The sun is locked in the middle and the tracking is stable. This corresponds to line 6-14 (Table 12). It also shows us, that small fluctuations (line 6-10, table 12) can be ignored. In line 5 (Table 12) a bigger drift compared to the other lines is present. After taking a closer look we found that between line 4 (UTC 10:09:54) and line 5 (UTC 10:11:46) 172 seconds passed without logged data. During the same time period Table 11 shows bad conditions starting from line 4 (JD 2457591.923623) to line 20 (JD 2457591.924861). During this time no ellipses were detected. This happens, if there is too little radiated area or no sun at all.
In Pyra SunPosOffset.dat is not used, because it offers no additional information and follows no regular update cycle.

I don't have further info for the LEARN_Az_Elev.dat file for now. I will keep looking.

[patrickjaigner]

The logic is probably something like this:

• Sun Threshold is fulfilled, and the automation decides to start everything up
• CamTracker starts up and initializes the tracker due to the -autostart option
• CamTracker should find the sun as Helios checked the sun previously
• The cover is mirroring the angle of the CamTracker position via (I think) an HTTP request to the EM27

Now I see that CamTrack starts to initialize but doesn't find the sun for some reason and, therefore, doesn't start logging.
It now turns back and stays at 0 degrees. Therefore, the cover follows and also stays at 0.

Now I would guess that CamTracker stays infinitely at initialization at 0.

Nevertheless, the SunIntensity.dat should be logging since startup.