Testing results

[ldorogi]

I have tested today with my Seestar in rhe room, as outside was 100% cloud cover it was a real simulation :-).
I was expecting that after first tries the system will recognize that there is no star visible and will break the workflow. This does not happened...in log file (orchestrator.err, enclosed) is visible that plate solving was not successful, despite the capturing has ben started.

What was positive?

1. The workflow was executing without any syntax error, preflight has been started immediately after Sun went below -18 degrees
2. Fits were captured and saved on SSD
3. Darks were captured and saved on SSD
4. Log files are written, but .....

What was negative?
1 .... all *.log files remained empty, all logs went into *.err files (is this a bug or a feature?)
2. tonights_plan.json was not newly created on the session start (after Sun went down below -18 degree), it remained from the test run in the afternoon (feature or bug?)
3. Despite in config.toml mission target number is set to 5 in json was only 1 star, but as mentioned before, tonights_plan was not regenerated but remained from the afternoon simulation test
4. My biggest problem was that after first cycle the tonights_plan.json was updated or generated again with the same star and the complete workflow was running agai, and then again, and again... after 4th running I have switched off my Seestar to prevent all night shooting of AU CVn.

If you need more information I am happy to provide.
For any reason I could attache orchestrator.err only as orchestrator.txt

system_state.json
tonights_plan.json
orchestrator.txt

[ldorogi]

After I have slept a night this morning checked a bit in source code. The reason for not generating a new tonights_plan.json is now clear as the date of the file should be older than today(it was false yesterday but becomes true today), so it should be automatically generated today when Sun goes below -18 degrees, and IMPORTANT: Seestar should be turned on, otherwise the generation will not happen because of telemetry error. The sky is promising above me tonight so I will go with Seestar outdoors. I am really interested why I had several acquisition cycles yesterday for one star. Can someone shortly explain why it was taken 40 frames for AU CVn? Because it is too faint? In some MD's I have read earlier that it will be taken only one scientific image per target. Has it been changed in the meantime?

[edjuh]

Uh yes, in Alt/Az mode we can do about 10 seconds per frame.
I have a routine that estimates the magnitude, and then calculates the amount of frames required. We can not go very very deep, mag 14 is about the limit. But that needs to be confirmed.

So the amount of frames depends on the setting of the telescope ( Alt/Az or EQ ) as well as the airmass, as well as the expected brightness. That makes it indeed complicated, code wise, as it needs platesolving, stacking, and darkframes ... etc etc etc
The endresults is one (1) frame, to which the photometric will be applied.

[ldorogi]

Got it, thanks.

In the meantime I have recognized that my system is in state "ABORTED" and if I am not wrong from this state there is no chance to escape (in orchestrator):

def _run_aborted(self):
self._current_target = None
time.sleep(max(1, self.LOOP_SLEEP_SEC))

So I have run

~/seevar/.venv/bin/python ~/seevar/core/preflight/state_flusher.py

After that my system state is again IDLE, so now orchestrator has a chance do prepare my tonight's plan.

Is there any other way to get out from ABORTED state?

[edjuh]

hanks, this is very useful. A few points are expected, and a few are genuine issues.

The multiple frames for AU CVn are expected. In Alt/Az, SeeVar can split one target into many short exposures depending on target brightness, airmass, and rotation limits. Those frames are later intended to become one stacked science result.

The ABORTED state is currently sticky. At the moment, recovery is by restarting the orchestrator or resetting state manually. That should be improved.

Planning currently depends on successful hardware preflight, so if the Seestar is off, a fresh nightly plan may not be generated. That is a real design issue.

The log routing is inconsistent: some installs still send messages into orchestrator.err instead of the main log. That is a service/bootstrap bug.

Repeating the whole target workflow over and over is not intended. For that part, please send me the tail of the orchestrator log around the end of the first run, or systemctl --user status seevar-orchestrator, because it may indicate the service restarted rather than the planner deliberately looping.

[ldorogi]

Hi, just finished the first real test under sky. Much better, but the repeatition of the cycle happened again. I will try to give you what you asked tomorrow, now is to late plus I would like to catch the comet early morning :-)

[ldorogi]

This is frfom today evening's run:

dl@raspiobs:~/seevar/logs $ systemctl --user status seevar-orchestrator
● seevar-orchestrator.service - SeeVar Science Orchestrator
Loaded: loaded (/home/dl/.config/systemd/user/seevar-orchestrator.service; enabled; preset: enabled)
Active: active (running) since Thu 2026-04-16 23:08:50 CEST; 26min ago
Main PID: 442512 (python3)
Tasks: 4 (limit: 4768)
CPU: 1.891s
CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/seevar-orchestrator.service
└─442512 /home/dl/seevar/.venv/bin/python3 core/flight/orchestrator.py

So, you are right, orchestrator. was restarted.

Intresting, darks were subtracted only from first target (AU CVn), then the capturing cycle was restarted.

Here the tail log insert:

[edjuh]

Good to see this, first light for S30-pro and Seevar !!!
Even with darks ... Nice

Your log clarifies two things. First, the 40 frames for AU CVn were expected: in Alt/Az the field-rotation cap reduced 20s frames to 7.5s, which increased the frame count from 15 to 40. Second, the repeated AU CVn workflow was a real bug in that build, not just a restart: the daemon completed postflight, accountant processed the raw frames, and then the same process returned to preflight and loaded the same one-target plan again.

Several of the issues you hit have already been fixed in the current branch:
Stale plan refresh before hardware init, log routing, ABORT/RESET handling, and the postflight parked behavior. Please update and test again. If the same target still repeats after a successful postflight on the latest code, send the new orchestrator.log tail from the first STATE -> POSTFLIGHT onward, because that would indicate a remaining planner/ledger bug rather than the older loop behavior.

I added an abort and a reset button in the dashboard. Just in case.

I am looking forward on adding the cloud detection, and a flat-panel in the future.

Again, thanks for beta-testing !! // Szeretlek //

[ldorogi]

Hi, thanks!

Some additinal details from yesterday's tests.

As expected when the Sun was below -18 degrees and Seestar was on the new tonights_plan.json was generated with 39 targets, because of config.toml settings it was reduced to 5 targets. Also as expected. The real observation has been started around 21:35 and was interrupted around 23:08, one of the targets was not successfully captured, but other 4 yes, the dark frames were taken as well, but according the log these were subtracted only from first target (AU CVn).

Because I have switched off my Seestar (had no better idea) to prevent new cycle with same targets the sstem is now in state ABORTED, so I can't wait to see your new buttons for reset :-).

I will cvome again if the update will cause some problems, but the report, at least a short one is comming after today's test.

A question for the next week: is it makes sense to try shooting in equatorial mode or software is not yet prepared for that

?

Have a nice day!

P.S. Attached the Sun today :-)