David's Astronomy - Notes 2025-11-11 (S1374)

Read/Save AutoDewControlOffset to AstroMain Settings. Currently AutoDewControl Target Offset is semi-hard coded with the value 2 (meaning that AutoDew routines will try to hold OTA Temperature a 2°C above the outside dew point temperature). Whilst the user can change the value at start of or within a session. The user value (recently 1) is not saved when AstroMain is closed, and it has be remembered to reenter the user value whenever the AstroMain program is restarted In would be useful if the value was automatically saved. Implemented in AstroMain 3.78.5.
Done 2025-11-11 (AstroMain 3.78.5)
Reduce/Simplify the buttons for Estimating Limiting Magnitude in AstroMain' s ImageSet/More tab. In AstroMain 3.78.4 and earlier versions there were multiple buttons for setting Detection Threshold in the Mag Limit Estimator's group box. Detection Threshold = 2 is now always used and the buttons 3, 8,15,30 etc serve no purpose and can be removed. The button 2 can also removed as well by changing the 'Estimate Mag Limit' button routine (btnEstimateMagLimit_Click) to make the following two calls:
SetMagLimitDetectThreshold(2) EstimateMagLimit()
Implemented in AstroMain 3.78.5.
Done 2025-11-11 (AstroMain 3.78.5)
Modify AstroLaunch's AllSky tab to replace 'Pegasus USB Hub' launch option by a 'Pegasus Unity option. Previously the Pegasus USB Control Hub (UCH) was manipulated via a dedicated Pegasus Astro Software (Pegasus UCH). A limitation was it could not be connected to the Hub when an application like AstroObsCam had an ASCOM Switch connection with the Hub. AstroObsCam had to be closed or suspended in order to use the UCH Control Hub Software. The reinstallation of Windows 11 and all software on the AllSky/Weather Computer provides the convenient opportunity to install Pegasus Unity Platform and use it to access the UCH Control Hub, allowing multi-client connection. Unity Platform has been installed (2025-11-14), and USB Port Names changed to names corresponding to the USB devices that will used the Control Box. AstroLaunch should be modified to allow Unity Platform to be optionally launched from the AllSky tab. Implemented in AstroLaunch 1.14.
Done 2025-11-14 (AstroLaunch 1.14)
Extend AstroWeather to include a USB Control Panel. In order for ASCOM Switch to be used the switches Properties need to be accessed first. Use an ASCOM Device (Switch) Chooser to select the ASCOM.Device1.Switch, Connect to the Hub and select the Pegasus UCH Control Hub via Properties. The panel also allows a particular USB Port to be reset (ie switched off / switched on), should this be required USB Control Hub (UCH). An 'Disconnect' button is also provided. Implemented in AstroWeather 1.29.
Done 2025-11-14 (AstroWeather 1.29)
Modify AstroLaunch to use a revised path to Cloud Sensor III program folder. The CloudSensor program was previously installed at "C:\Program Files (x86)\Aurora Eurotech\Cloud Sensor III\", but the path has been changed to "C:\More Programs\Cloud Sensor III\" as of 2025-11-15 , in order to allow CloudSensor.exe program to be run with normal privileges, rather than elevated privileges. Path names in AstroLaunch needs to be modified to access the revised location of the CloudSensor.exe file in order to get the program's version number (and in future to launch the program without using a scheduler task to run the program with highest privileges). Implemented in AstroLaunch 1.29.1.
Done 2025-11-15 (AstroLaunch 1.14.1)
Modify AstroWeather to operate with revised path to Cloud Sensor III program folder. The CloudSensor program was previously installed at "C:\Program Files (x86)\Aurora Eurotech\Cloud Sensor III", but the path has been changed to "C:\More Programs\Cloud Sensor III\" as of 2025-11-15. AstroWeather needs to be modified to access current Cloud Sensor data. Implemented in AstroWeather 1.29.1.
Done 2025-11-15 (AstroWeather 1.29)
Modify AstroMove to operate with revised path to Cloud Sensor III program folder. The CloudSensor program was previously installed at "C:\Program Files (x86)\Aurora Eurotech\Cloud Sensor III\", but the path has been changed to "C:\More Programs\Cloud Sensor III\" as of 2025-11-15. AstroMove's "Copy WS, CS Files" code needs to be modified to access the new path name to the Cloud Sensor folder in order access monthly csv files. Implemented in AstroMove 1.17, folder path "\\Laptop7\Cloud Sensor III\" changed to "\\Laptop7\More Programs\Cloud Sensor III\"
Done 2025-11-15 (AstroMove 1.17)
Modify AstroObsCam to use Pegasus Unity's 'ASCOM.Device1.Switch' driver. In AstroObsCam 1.11.7 and earlier version , the "ASCOM.UCH.Switch" driver was used for controlling the usb4 port on the Pegasus USB Control Hub, allowing the ObsCam camera to be switched on/switched off, and limit or otherwise the IR light contaminating images taken with the telescope's CCD Imager. After the move to use Pegasus Unity Platform on the AllSKy/Weather Computer the AstroObsCam needs to be modified to use the 'ASCOM.Device1.Switch' driver, this allows multi-clients to use the USB Control Hub. Previously AstroObsCam had to be suspended/closed, if another USB Port needed to be controlled (for example to reset a USB connection). Implemented in AstroObsCam 1.12.
Done 2025-11-16 (AstroObsCam 1.12)
Modify AstroLaunch to launch iSpy with elevated privileges. Since the reinstallation of WIndows 11 and iSpy it is found that iSpy needs to be run as an administrator otherwise it crashes. And if restarted as normal user (or via Current AstroLaunch iSpy launch) the camera configuration is lost. AstroLaunch should be modified to launch iSPy by running a bat file called LaunchISpy.bat in order to run task LaunchISpy' with runs 'C:\Program Files\iSpy\iSpy.exe' with higher privileges in a similar way to have Cloud Sensor is lauched. Implemented in AstroLaunch 1.14.2.
Done 2025-11-16 (AstroLaunch 1.14.2)
AstroMag isn't creating a morning copy of the 'Latest.MagnetometerStackChart.png'. Each morning AstroMag runs a process that saves the current set of magnetometers graphs into a folder with name like 'C:\Data\Magnetometer\Sessions\2025-11-11'. The file called 'MagnetometerStackChart.png' in 'C:\Data\Magnetometer\Local Charts' folder isn't getting saved as 'Magnetometer.20251111.MagnetometerStackChart.png' in the session fold,. It is getting uploaded to website ok as the file "Latest.MagnetometerStackChart.png" where is presented below the Scandinavian Magnetometer Stackplot at the same scale, but it isn't getting archived and therefore wasn't available for illustrating a particular annotation issue with the chart during the Aurora Event of 2025-11-11/2025-11-12', once the live version of the image was overwritten by later updates. The current file is always present in the 'C:\Data\Magnetometer\Local Charts' folder. Fixed in AstroMag 1.5.11.
To investigate 2025-11-11 (AstroMag 1.5.11 )
The TapoCam folder should be reorganised to relocate various work folders into a single Work Folder. The 'C:/Data/AllSky Imaging/TapoCam' folder contains 11 subfolders. It is proposed to reduce the number of folders, by dropping the following subfolders
    'audio', 'video', 'VideoFrames', 'VideoPrep', 'Work (Work1)', 'Work2'
down into a new subfolder called 'Work' as they are all used for building images & building videos, rather than image/video storage.
The original 'Work' subfolder should be renamed as 'Work1'.
This will reduce the number of subfolders to just 7 :
    'Keograms (Day)', 'Keograms (Night)', 'Objects', 'Raw', 'Sessions', 'Videos', 'Work' .
To allow this reorganisation the 'media directory' path for iSpy Storage should be changed to
     'C:/Data/AllSky Imaging/TapoCam/Work'
and AstroNorthCam routines should be modified to reflect new paths to the various work folders
The Media Path used by iSpy needs to modified on Storage tab on iSpy's Settings and iSpy's Camera Settings
On the Development Computer there are additional working sub folders (of which the 'Stars' folder is likely no longer used)
     'Birds Work', 'Fisheye Correction Work', 'Neural Net', 'Stars'
These should also be transferred to the new 'Work' folder. New folder structure and program updates implemented in AstroNorthCam 1.7 and iSpy setting on 2025-11-18 (see Fig 5)
Done 2025-11-18 (AllSky/Weather Computer, TapoCam Folder, AstroNorthCam 1.7, iSpy64 settings, )
Modify AstroObsCam to use less CPU. AstroObsCam 1.12 is consuming 15-22% of computer CPU time which is higher than ideal (and higher than iSpy and AstroNorthCam combined). This is really a bug (small defect) but it be left here as a Continuous Improvement ticket. Can this level of CPU usage be reduced ? Possibly look at allowing the program to operate in 2 modes : fast/work mode when trying to manually optimise camera position by trial & error, and a second mode for normal operations when frequency of camera frames can afford to be lower. This will be quite difficult to do as the CamCapture.vb is a bit of a black box or at least the code is somewhat difficult to follow due to events driven nature, and can easily be unknowingly be broken by certain code changes. The fast mode activation can probably be made automatically dependant on the state of 'Show Centre Line' checkbox.
- Main work is done with the HandleFrameSaved() routine (in Form1.vb) which is called by globals.FrameHandlerLoop() when bTriggerHandleSavedFrame is True. - This is set True by 'Form1.cam_FrameSaved(ByVal capImage As System.Drawing.Bitmap, ByVal imgPath As String) Handles cam.FrameSaved' handling routine. - The cam.FrameSaved event is raised by CamCapture.Tmr2_Tick(ByVal sender As Object, ByVal e As System.EventArgs) Handles TmrSaved.Tick.
One idea is to throttle the setting of bTriggerHandleSavedFrame = True in the cam_FrameSaved() routine, with the code
If cboxShowCentreLine.Checked Or SecondsSince(LastHandleSavedFrameTime) > 5 Then bTriggerHandleSavedFrame = True LastHandleSavedFrameTime = Now() End if
A beta version of AstroObsCam 1.12.1 was tried out. In fast mode a new annotated picture was created every 0.7s as previously. In 'slow' mode a new annotated picture was created every 5s. A side effect was that the program would flag up that the frame was locked (for 0.0 to 6.0s) and after several of these locked cycle (nLockedCaptures >= 6) a Camera Reset would be triggered (and the camera would automatically disconnect/reconnect again). This was worked around with a fudge that effectively disables the lock checking. It was notice that the program would be running at 12% CPU with Services connected but the Camera not connected, suggesting inefficient looping in one of the service threads (ConnectUsbControlHub(), TeleCommsReciever.StartListening(), RemoteControl.StartListening(), CamManagerLoop() & FrameHandlerLoop(). Some changes made to try to reduce this base CPU :
- Thread.Sleep(100) added to FrameHandlerLoop(),
- Thread.Sleep increased from 50 to 100 ms in CamManagerLoop()
(ConnectUsbControlHub() doesn't have a loop and returns once connection to USB Control Hub's ASCOM Switch is made)
(RemoteControl.StartListening() and TeleCommsReciever.StartListening() loops already have an embedded Thread.Sleep(100) )
Making this change reduced the base CPU usage down to 0-2% range, and with camera operating in normal mode CPU usage is now only 5-15%, which is acceptable. Fixed in AstroObsCam 1.12.1, operations will be monitored & especially during next live session to ensure there are no significant side-effects.
Done 2025-11-18 (AstroObsCam 1.12.1)

Update AstroPlan & AstroAllSky Programs to utilise latest version of WinSCPnet. AstroPlan and AstroAllSky bot the WinSCP for automatically uploading 'live' files to the Observatory's WebSite. WinSCP is also used for manually uploading images and webpages to the Website using drag & drop. After downloading and installing a new 6.5.4 version of WinSCP (6.5.4.16408) on the Development Computer, copies of the new WinSCP.exe and WinSCPnet.dll files were dropped into the AstroPlan program folder on the Observatory Computer in an attempt to update it from its existing 2023 file versions. Upon restarting AstroPlanprogram a just-in-time debugger window showed that the program had thrown a 'System.IO.FileLoadException' with the message "Could not load file or assembly 'WinSCPnet, Version=1.12.0.12963 ... or one of its dependencies. The located assembly's manifest definition does not match the assembly reference". When the AstroPlan.exe was compiled it was hard-bound to version 1.12.0.12963 of WinSCPnet.dll. When the newer (1.16.0.16408) version of WinSCPnet.dll was dropped in, the runtime rejected it because the strong name and version didn’t match what was compiled in. The previous (2023) versions of WinSCP.exe and WinSCPnet.dll were dropped back into the program folder and the AstroPlan was able to run again without the earlier exception. To update correctly the new version of WinSCPnet.dll should be copied into the Visual Studio project folder (e.g., AstroPlan\AstroPlan\Libs ), and the old Reference removed and a new Reference added, and the project then rebuilt. Whilst WinSCP .NET assembly is available in a package named WinSCP-X.X.X-Automation.zip on WinSCP download page, and a manual install could be attempted it is not the best way for updating the two program projects. Instead the following workflow is used (for AstroPlan project).
- From inside the AstroPlan project in Visual Studio - Go to 'Project/Manage NuGet Packages.. Go to Browse, Enter WinSCP in the search window - Select WinSCP by prikryl v 6.5.4 which then gives dialog tab with current version (5.21.7) and the latest version (6.5.4). - Clicked Update, and the new WinSCP package is updated (Project's package folder is updated with 'WinSCP ..5.4' folder which replaces the earlier 'WinSCP.5.21.7' folder) - The program's bin folder now contains new WinSCP.exe and WinSCPnet.dll files, with version 6.5.4.16408 & 1.16.0.16408 respectively. - The two new files are copied into program's Progam Folder on the Local Computer and the Observatory Computer. - AstroPlan deployed as per usual use AstroMove.
AstroAllSky was similarly updated, except that the recently installed WInSCP NuGet was used, rather than rebrowsing for WinSCP.
Done 2025-11-19 (AstroPlan 1.44, AstroAllSky 3.26)
Modify AstroLaunch's Form to clearly display what Computer it is running on. When using Remote Connection from the Development Computer, where sometime the will be AstroLaunch running on the Development Computer, AstroLaunch running on the Observatory Computer in a VNC window, and AstroLaunch running on the AllSky/Weather Computer in another VNC, it would be useful to have a clear Title showing the name of the computer where the particular AstroLaunch window is running. This also applies in particularly to AstroLaunch running on the Development Computer where it could be using a 'AllSky' or 'Observatory tab', where it is important for the user t be aware that launching a AllSky or Observatory program is going to be run on the local (Development) Computer and not on the respective computer in the Observatory. This change involves adding a new label field, adjusting position of some other labels/buttons and adding code to the AstroLaunches form_load routine. Implemented in AstroLaunch 1.14.3.
Done 2025-11-19 (AstroLaunch 1.14.3)
Modify AstroAllSky and AstroNorthCam so that 'create video' tasks are hidden and don't show a terminal/console window. When videos are created in AstroAllSky and AstroNorthCam a console windows open in which ffmpeg operations are displayed whilst the video is created. However this covers other windows and creates a new task bar item for as long as the operation takes. It would be perferrable if the terminal window is displayed but remains hidden. The contents can be written to a log file in case of problem diagnosis is ever required. Solution implemented in AstroAllSky 3.26.1, using new RunHiddeFFmpegCommand() routine. Uses new ffmpeg 2025 64 bit executable which has been downloaded to Development and AllSky/Weather computers. The FFmpeg program path in AstroAllSky program settings/video tab is updated to "C:\More Programs\ffmpeg-8.0.1\bin\ffmpeg.exe". Similar code has been built into AstroNorthCam 1.7.1 but in this case the new ffmpeg executable path is hard coded in globals.vb. In both programs the original Shell method of creating a FFmpeg video is still available by unticking the "Use HiddenFFmpegCommand" checkbox.
To do 2025-11-20 (AstroAllSky 3.26.1, AstroNorthCam 1.7.1)
Review strategy for saving Program Settings in AstroMain. Following investigation into and issue where DewHeaterOffset unexpectedly changed from 1 to 2 at 09:00 on 2025-11-17, i was establised that currently AstroMain( 3.78.5 and earlier versions) read the program's setting file and that any settings changed on the AstroMain Main form like the DewHeaterOffset do not automatically find their way into the settings file, and can therefore be unexpectedly overwritten at the start of a new session. This can be resolved by the user forcing a saving of all settings to the Settings File, by opening and then closing the Program Settings form. But should this be down to the user to do or should the program automatically save all settings when the program is about to close a session before it is moved to a new session.
To review 2025-11-19+ (AstroMain, User Awareness)
Each computer should have a 'Backup Strategy' and 'Recovery Kit'. The Development Computer, Observatory Computer and AllSky/Weather Computer should each have a robust back-up strategy and a robust 'Recovery Kit'. The idea is sensible and came about through conversations with CoPilot over the last few days. What is required to restore the computer system back to working order in the event of a failure to boot up Windows or other critical issue, like inability to function properly, speeding up recovery from 4-5 days to less than 1 day. What data files are critical and required to be backed-up.
To do 2025-11-30+ (Development Computer, Observatory Computer, AllSKy/Weather Computer )

Fig 1. MagnetometerStackChart (2025-11-11)

Chart illustrating x axis labelling issue when this graph is presented with the rarely used scale of 10 px per 200 nT, that was necessary for this night with very high geomagnetic activity.

The labels +600, +500, +400, +300, +200 , -200, -300, -400, -500, -600 overwrite each other and the reference value. In contrast the intervals +1000 to +600 and -600 to 1000 are unlabelled

Fig 2. KB5068861 (2025-11-12)

Fig 1a. KB5068861 installed

- Microsost Support Topic KB5068861
- Windows Forum Page on KB5068861

Fig 1b. Uninstalling KB5068861

Fig 3 Night Summary Plot showing impact of slow computer performance on AstroAllSky Program (2025-11-12)

AstroMag showing be draw a taking an image and adding a keogram line onto plot every 30s, but instead image was only being taken and keogram line added every 90s or so.

Fig 4 Unexpected jump in OTA Temperature Difference from Outside Dew Point.

Plot shows a clear 1°C increase in the difference between OTA temperature (orange line) and outside dew point (white line). The temperature difference jumps from roughly +1°C to roughly +2°C at around 09:00. This was the point when the '2025-11-16 General Session' finished and the '2025-11-17 General Session' started. This was associated with a change in DewHeaterOffset from a value of 1.0 to a value of 2.0 (evidenced by value in DewHeater Offset's data field on the Observatory tab). This is hypothesized to be due to the Program re-reading the program's settings file, when the new session began, rather than continuing with existing settings.

Fig 5 TapoCam Revised Folder Structure (2025-11-18)

[ Prev | Next ]

2025-11-13

AllSky Computer - Full Windows 11 Reinstall (including all Programs)

Introduction
The AllSky/Weather Computer (a span class="title">Toshiba Dynabook Satellite Pro C50-E-102), which had been has became un-operatable on 2025-11-12 / 2025-11-13. when it began operating very slowly and in particular become unworkably slow for the AstroAllSky Program. This followed directly from a Windows Update & Computer restart on 2025-11-12. Attempts to resolve the problem failed - uninstalling the updates applied on 2025-11-12 failed to resolve the very slow computer operations. A restore to an earlier restore point failed, and left the computer in a position where login to by both user account and admin account would lead to black screens. Rebooting into Recovery Mode / troubleshooter didn't lead to a resolution of the new problem, and a new restore attempt led nowhere as the system said there where no restore points available to restore from.

Finally there was nowhere to go other than to attempt to Reset the PC. This was first attempted using the 'Keep my files' and 'Local reinstall' options. However this failed - after applying the reset, the system would go into a loop of 'Preparing things' and then 'Undoing changes', and eventually the system returned to the existing state which was still giving a black screen after logging into the user account.

In the end it was necessary to perform a full Windows 11 reinstall using a 'Windows 11 Media' disk that was created on a USB drive using Microsoft's Media Creation Tool from the Development Computer.

Copies a selection of files and screenshots of key settings had previously been taken prior to earlier upgrade to Window 11 on 2025-10-28 (see AllSky/Weather Computer - Upgrade to Windows 11)).

Computer Setup, Stage 1 - Basic Operatability

Windows
- Admin and User Account
- View
- Desktop Picture, Desktop DPI, Icons Sizes
- Taskbar Toolbars: Astro, Comp, Apps
- Control Panel
- Device Manager
-- MS Edge, Google Search Provider.
- ExplorerPatcher

Core Software
- UltraVNC (for Remote Control)
- Kaspersky Internet Security (Firewall & AntiVirus)

General Software
- TextPad 4 (for File Editing)
- ACDSee Classic (for Image Viewing)
- PaintShopPro 5
- Dimension 4 (for Time Sync)

Computer Setup, Stage 2 - Observatory Software (core)
- CCDSoft5
- TheSky6
- Pegasus USB HUb

- ASCOM 7.1
- Starlight Xpress SXV Plug In.dll (to CCDSoft Version 5 / Camera Plug-Ins), for Oculus Camera Access

- AstroLaunch
- AstroWeather
- AstroAllSky

- Aurora Cloud Sensor III (3.2)
- CumulusMX (MX9)

- ffmpeg-win32-static
-- ffmpeg-win64-static

Computer Setup, Stage 3 - Observatory Software (other)
- AstroObsCam
- iSpy
- AstroNorthCam

Steps towards setting new computer up for AllSky/Weather Role

Update 2025-11-13 (Day 1)

Windows 11 (25H2)
- Prepared 16 GB USB using Window Media Creation tool on Development Computerbr>- AllSky Computer booted to recovery mode (using Shift Restart from Login Screen)
- Choose option to install Windows from USB
-- Installed Windows 11
( a problem arose when Windows setup went through its Updating Windows stage, that was overcome by disconnecting USB Cable going to USB Hub / Other devices, which might have been causing conflicts)br>- Set up 'Admin' as main owner.
(when microsoft account asked for, used F-10 to bring up command window and used to set account uop as a Local Account)
- Created 'David' user acccount of type 'Administrator'
- Confirmed that 25H2 version of Windows 11 was installed.
Check computer had Internet Connection via Ethernet Cable to Ethernet Switch / Router
Checked IP address and confirmed that it was unchanged from it normal IPv4 address using 'ipconfig/all'
Logged in as 'David'
Set 'David' as owner of 'Data' and 'More Programs' folders
- initially the two folders appeared as 'Empty',
-- changing ownership of 'Data' took a long time due to very large number of contained files
Personalisation (done)
- Set up Personalisation:
- Set Short Date Format to yyyy-mm-dd,
- Set various Explorer view options to prior, normally used settings
- Disabled Windows docking/snapping t to edge

- Disables the dimmed background and Secure Desktop isolation
- Regedit to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
- Create or find 'PromptOnSecureDesktop' and set value to 0
Brought computer indoors for further setup
Re-checked computer was connected to LAN / Internet via Ethernet connected to 'Ethernet over Powerline' adapater
Default search engine (done)
- Changed default search engine to Google in MS Edge.
Power Options (done)
- set up what buttons do, enable hibernation from Power Button
Pings (done)
- Setup computer to respond to Pings
- confirmed that computer responded to pings from Development & Observatory Computers
UltraVnc (X64) (done)
- installed UltraVNC
- initially installed prior version (1.2.40), but then installed latest version (1.6.4)br> - set up UltraVnc Server, with a connection password.
- confirmed Remote VNC connection from DDevelopment & Observatory Computers
ExplorerPatcher (done)
- configured Propertties with Window 10s style options, small icons, start placed on left etcbr>-- configured TaskBar, and set up Toolbars (reading from C:/Data/Computers/Toolbars)

File Sharing (done)
- enable network discovery and file/printer sharing (private networks)br> - set up Shares (More Programs, Data)
- set up share up Development Computer (Dropbox))

More Programs
- Checked strong>AstroLaunch, AstroAllSKy, AstroWeather, AstroObsCam, AstroNorth programs were present
- Checked CumulusMX9 was present

AstroLaunch (done)
- Checked that AstroLaunch progam would fire up ok.br>-- Added AstroLaunch to start-up programs

Dimension 4 (done)
- Installed Dimension 4 v5.3.1, setup to run as service using ntp2.uk.uu.net, display in system tray

ImageMagicK (done)
- installed ImagicMagicK

ASCOM 7.1 (done)
- installed ASCOM 7.1
- the installation automatically instated Net Frame 3.5 Servic Pack

ACDSee (done)
- installed ACDSee32 and added registration details

CCDSoft5 (proceeding)
- installed CCDSoft from CD/DIsk
- opened CCDSoft as administrator on first opening

TheSky6 (proceeding)
- Installed TheSky6 (from DVD / Disk)
-opened TheSky6 as administrator on first opening

Restore Point (done)
- created restore point ("Post Day 1 Installs")

Update 2025-11-14 (Day 2a)

Continue installation and setups in indoors environment

Check rong>DeviceManager
- confirmed DeviceManager can be launched from AstroLaunch
- 3- 3 'Other Devices' listed with problems 'Unknown Device', Unknown Device, USB2.0 CRW
Pegasus Unity (done)
- Installed Unity Platform 2.12, Entered Configuration and set Theme to 'Light'
PaintShopPro (done)
- installed PaintShopPro 5.01 and Animation Shop from Disk,
- setup Screen Capture (full screen with 2s delay) and tested
Access to some folders in Data/All Sky Imaging
CCDSoft updates (done)
- Install updates to raise CCDSoft version to v5.00.201
TheSky6 updates (done)
- Install updates to raise TheSky6 version to v6.0.0.65
Starlight Xpress Drivers (done)
- Install latest Starlight Xpress Drivers
- Download "Signed drivers for 32 and 64 bit Windows 7, 8 and 10 (version 1.3.8.3)"
from Starlight Xpress website ( https://www.sxccd.com/support/resources )
- Ran 64bit/Install Drivers.exe (the 32bit version couldn't be installed)
- copy "Starlight Xpress SXV Plug In.dll" to "C:\Program Files (x86)\Software Bisque\CCDSoft Version 5\Camera Plug Ins" ?
TheSky6 settings (done)
- set up TheSky location, display and virtual settings
iSpy64 (proceeding)
- installed iSpy64 v7.2.6 (note that we do not install iSpy Agent)
- configure iSpy64 to connect to NorthCam (Tapo C325WB), and set up prior settings
- 192.168.1.63
- Connected IP Camera FFMPEG: Other: rtsp://TapoCamxxxxx: pw @192.168.1.63:554/stream1
- check camera connection
- Issue : streams first video frame, save jpg to grabs folder but iSpy then crashes (see iSpy64 - Reinstallation)
VideoLAN VLC (done)
- installed VLC 3.0.21
- confirmed access to NorthCam camera using
rtsp://camera_account_name:password@192.168.1.63:554/stream1
- s- streams NorthCam viedo feed ok
AstroNorthCam (proceeding)
- checked AstroNorthCam can access and use frames saved to grab folder by iSpy
USB-Serial Adapter Driver (for CloudSensor) (done)
- Installed USB-Serial Adapter Driver (for CloudSensor) from CD
- Later on Device Manager showed that 'Prolific USB-Serial Comm Port (COM3) was using Prolific drivers (v3.9.6, date 2024-06-17) and thus must have been installed by Windows, making the loading of old driver from CD unnecesssary.
AstroWeather (proceeding)
- checked AstroWeather imp- importing ObsEnvData from Laptop9 very slow , this was fixed the following day
CumulusMX / Ekowitt Weather (proceeding)
- Check CumulusMX / Ekowitt Weather Station
- Initial attempts failed to run CumulusMX.exe, (the Terminal Window failed to open. EventViewer showed error eventsp; "A .Net application failed (for ../CumulusMX.exe). You must install .NET to run this application"
- Downloaded and install .NET 8.0 Runtime (v8.0.22) Windows x6 Installer
- Rerun CumulusMX.exe (from 'More Programs/CumulusMX9') and it open ok
- Local host:8998 showed connection to Ekowitt Weather Station
- C- Checked that WeatherStation service started up and operated in AstroWeather and data seen in AstroPlan on Observatory Computer.
Pegasus USB Control Hub (done)
- connected USB Control Hub to computer>- started Pegasus Unity Platform
- confirm that Hub's firmware (1.3) is latest
- e- edited/saved USB Port Names corresponding to USB Port 1 to USB Port 6
AstroLaunch (updated)
- modifed AstroLaunch program so that previous Pegasus UCH Hub launch button on AllSky tab is now associated with Pegasus Unity
- released AstroLaunch 1.14 and installed on AllSky Computer
Restore Point (done)
- created Restore Point ("Post Day 2 Installs")

Update 2025-11-15 (Day 3)

Moved computer to observatory and hooked up to power supply, ethernet cable and USB cable to USB Control Hub
CumulusMX / Weather Station Data
- Connected USB cable from Ekowitt Gateway Hub to USB Control Hub (for power).
- Started Cumulus MX, and confirmed Weather Station connection via localhost:8998
AstroLauch (updated)
- Installed update version of AstroLaunch (1.14, with launch 'Pegasus Unity' option)
AstroWeather (updated)
- Installed updated version of AstroWeather (1.29.1, with USB Control Hub panel/tool)
G Drive (done)
- connected External Drive to USB Control HubConnect (in usb5).
- drive appeared as 'Drive (D:)' in 'This PC - Devices and drives'
- changed drive letter to G: in 'Disk Management / Change Drive Letters and Paths'
DeviceManager (warnings)
- USB Serial Port (COM4) ( FTDIBUS\COMPORT&VID_0403&PID_6015) is listed - is this the USB Control Hub ?
- No handles are actively using the Port at present. Probable idle
-This aligns with it being FTDI FT231X USB-to-Serial UART chip, and is consistent with it only being
    periodically used by Pegasus Unity or when command program toggle USB Ports or queries status.

- 3 Other Devices again listed with problems 'Unknown Device', Unknown Device, WD SES Device USB Device
   - Unknown Device (USB\VID_8087&PID_0A2A) corresponds to Intel Bluetooth 4.0/5.x hardware
     (need appropriate 'Intel Wireless Bluetooth driver')
   - Unknown Device (ACPI\INT33D5) corresponds to 'Advanced Configuration and Power Interface' / Intel HID Event Filter driver
     (need appropriate 'Intel HID Event Filter driver')
- WD SES device refers to a communication channel on a Western Digital external hard drive
    that enables features like password protection, LED controls, and the ability to read the drive's label)
CloudSensor (done)
- connected Cloud Sensor's Serial-USB cable to USB Control Hub (usb3),
Prolific USB-to-Serial Comm Port (COM3) appeared in Device Manager
- installed Cloud Sensor III by running AuroraCloudSensor-Setup-V3.2.41.exe
(initally installed at 'C:\Program Files (x86)\Aurora Eurotech\Cloud Sensor III' and but later reinstalled in 'C:\More Programs\Cloud Sensor III\'
- encountered some issues that had to be diagnosed and fixed but finally got the program running
- modification made to AstroLaunch (1.14.1) to be able to successfully launch CloudSensor III
- modification made to AstroWeather (1.29) to be able to access data files from program folder 'C:\More Programs\Cloud Sensor III\'
- see CloudSensor III - Reinstallation
Eaton UPS Companion (done)
- Installed Eaton UPS Companion 2.1 by running 'euc_win_2_1_028.exe'
- Plugged in UPS cable from UPS UPS Box
- Waited for UPS to be found. Updated Settings to those previously used. Exited the Companion UI and confirmed that UPS Icon (on utility) was present in the System Tray.
Oculus AllSky Camera (done)
- Download "Signed drivers for 32 and 64 bit Windows 7, 8 and 10 (version 1.3.8.3)"
from Starlight Xpress website ( https://www.sxccd.com/support/resources ) and unzipped
- Ran 64bit/Install Drivers.exe to install SXCCD drivers (note the 32bit version couldn't be installed)
- Connected USB cable from Oculus Camera to USB Control Hub (usb1)
- 'Starlight Xpress CCD' appears in 'Universal Serial Bus devices' section of Device Manager.
- Examined Driver File details from Properties and noted 4 dll and 2 sys files, including
'C:\WINDOWS\system32\DRIVERS\UNDF\SXCCD.dll'
- Copied 'Starlight Xpress SXV Plug In.dll' to 'C:\Program Files (x86)\Software Bisque\CCDSoft Version 5\Camera Plug Ins' folder
- Opened CCDSoft and selected 'Starlight Xpress SXV Series' camera on Camera Control's Setup tab.
- Checked Camera Properties (Imaging Mode : Automatic (Any), Camera: SuperStar)
- Set Image Reduction to 'None' on Take Image tab
- Took a short exposure and confirmed Camera was operating ok
AstroAllSky (carry forward to Day 4)
- Opened TheSky6 and CCDSoft programs
- Open AstroAllSky with automatically began services and started AllSky run.
- Program entered into daytime weather monitoring mode and operated on a 30s cycle with no overruns
- Program began to automatically uploads files to Observatory's web site
- Program entered night time imaging mode at 2025-11-15 16:03 and took 51 FITS images between 16:04 & 16:28 which is roughly consistent with a 30s cycle time.
- AllSky and Panorama pictures created and uploaded to website ok (last website pictures have a 16:21:11 timestamp). Last pictures in Server folder awaiting upload have timestamp of 16:27:45
- Whilst FITS images saved to disk ok and Latest AllSky pictures, Latest Panorama pictures, Latest Summary plots were created ok. Individual JPG picture frames weren't saved to disk. This is unexpected. There is no error or warning messages written to the log file. This problem went away after later restart of the computer and restarted AstroAllSky Run.
- 16:29:03.89 | Imaging has unexpectedly stopped. Exception encountered in TakeAllSkyFrameJobs
- There was a serious error which was only caught by the program's outermost loop and caused the program to exit or possibly crash
Error during Defect Pixel Repair Exception has been caught by MyExHandler, see logfile for details Imaging has unexpectedly stopped. Exception encountered TakeAllSkyFrameJobs (master Try block) : System.Runtime.InteropServices.COMException (0x800404B5): Error: memory error. Error code = 205 (0xcd) at globals.vb:line 15952. . There was then a System.IO.__Error.WinIOError at \globals.vb:line 29803
- Logs copied to 'C:\Data\Computer Work\AllSky Computer Rebuild Nov 2025'
- Event Viewer indicates there were a number of crashes at 16:29:13 and 16:29:15
- AstroAllSky.exe .(NET Runtime), Procmon64.exe, dwm.exe (core windows process for Desktop Window Manager), AstroAllSky.ex - - AstroAllSky seems to operating fine following computer restart.
iSpy64 (proceeding)
- iSpy64 continues to crash after accessing first frame
- but running iSpy64 as administrator works without crashing (see iSpy64 - Reinstallation)
AstroNorthCam video (pending)
- a full check of AstroNorth with have to wait until after the issue with iSpy6's frame capture is resolved
- in meantime Create Video operation was checked and confirmed to function, demonstrating that the ffmpeg program was accessible.
CloudSensor (done)
- Cloud Sensor is still running as at 22:30
Restore Point for Day 3 (done)
- created Restore Point "Post Day 3 Installs"

(cmd/administration examples )
vssadmin list shadows             ' Shows each restore point with creation time, ID, and volume.
vssadmin list shadowstorage ' Displays used, allocated, and maximum space per volume (totals)
vssadmin list providers             ' Shows installed VSS providers (e.g., Microsoft Software Shadow Copy Provider).
vssadmin delete shadows /for=C: /oldest   ' Delete oldest shadow copy

Update 2025-11-16 (Day 4)

AstroAllSky (done)
- confirmed that AllSky and Panorama Videos are being successfully created and uploaded to website in morning.
- used Show Inventory on a starry AllSky Fits image (acquired last night) to show that the default Source Extraction Settings are not picking up expected number of stars and explains the zero Star Count values produced last night.
- change source extraction to
Magnitude zero point: 0 Aperture diameter in pixels: 6 Detection Threshold : 2.5- show inventory now detects all significant stars
- defining an image set from last night (2025-11-15) and running 'Process Folder' produces
AllSky Pictures and NightSummaryPlot containing the expected number of stars.
AstroObsCam (done)
- updated AstroObsCam to use Pegasus Unity's 'ASCOM.Device1.Switch' driver.
- released AstroObsCam 1.12 to AllSky/Weather Computer
- opened AstroObsCam and confirmed that it is able to connect to USB Control Hub, and Camera ok
- Minor Issue: AstroObsCam consumes 15-22% of CPU, higher than ideal. Can the program be better optimised.
iSpy64 (done)
- AstroLaunch (1.4.2) modified to Launch iSpy with elevated privileges via bat file & Task LaunchISpy (see iSpy64 - Reinstallation)
- iSpy now operating ok
AstroLaunch (updated)
- AstroLaunch 1.14.2 installed with a modified method for launching iSpy with elevated privileges.
AstroNorthCam (done)
- AstroNorthCam Imaging is working fine (with iSpy64 running as Administrator)
- Minor Issue : The timestamp drawn by iSpy is too small. Fixed in iSpy Camera Settings: Font Size changed from 8 to 12.
Restore Point for Day 4 (done)
- created Restore Point "Post Day 4 Installs"

Update 2025-11-17 (Day5)

Restore Points (updated)
- Discovered that Windows has automatically purge restore points to just the last two points
- Post Day 4 Insttalls
- Pre-Intel BlueTooth Driver
System Image Backup (done)
- created a system image backup to G Drive (434 GB) in folder 'WindowsImageBackup'
CloudSensor (follow-up)
- removed the 'CloudSensor III' share , as it no longer required, since program's transfer to C:/More Programs which is already shared.
- deleted C:/Program Files (x86)/Eurotech/CloudSensor III"

Lessons

Not all settings had been taken, which caused some issues during the recovery post reinstall .
The entire process to make the Window Reinstall and reinstall and reset up programs took 4 days.

It would be helpful to create a System Image Backup of the C:/ partition to make the recovery operation easier and quicker.

Other Notes:

vssadmin - command tool for listing restore points & backups volumes
(cmd/administration examples )
vssadmin list shadows             ' Shows each restore point with creation time, ID, and volume.
vssadmin list shadowstorage ' Displays used, allocated, and maximum space per volume (totals)
vssadmin list providers             ' Shows installed VSS providers (e.g., Microsoft Software Shadow Copy Provider).
vssadmin delete shadows /for=C: /oldest   ' Delete oldest shadow copy

Created a script C:/Data/Computer/Scripts/ListRestorePoints.bat that lists the restore points that have been created on the computer.

2025-11-16

Pegasus Astro USB Control Hub & new Unity Platform

Introduction
A Pegasus Astro USB Control Hub (UCH) was installed in the observatory back in 2021 (2021-10-16) where it replaced an existing standard 4 port USB Hub attached to AllSky/Weather computer. All 6 USB ports on the UCH Hub are occupied.

The Hub has been used via Pegasus UCH Control Software and ASCOM driver (ASCOM.UCH.Switch) through not both at the same time. ASCOM was used to control the USB4 port in order to turn off/turn on a USB Camera as part of the AstroObsCam program. But if there was a need to reset another USB port, the ASCOM Connection / AstroObsCam had to be closed before the UCH Control Program could be successfully connected. After use the connection had to be manually closed and ASCOM connection restarted. So operation was not that convenient.

The Pegasus Unity Platform, which is already in use of the Observatory Computer since installing a UPB Powerbox V3 on the telescope in July 2021 (see New Powerbox - Pegasus Astro UPB V3 (2025-07-13) & Pegasus Unity Platform 2.12 & UPB v3 1.6 Firmware (2025-11-09) ) offers the capability to offer multi-client access to the UCH box and gets around the previous limitations.

With the associated with full reinstallation of WIndows and all applications on 2025-11-13 to 2025-11-16, it was decided that the previously installed UCH Control Software and ASCOM driver would be replaced by the Pegasus Unity Platform and its new ASCOM driver (ASCOM.Driver1.Switch).

This was done on 2025-11-15 with the new setup looking like this

The upper section is used to enter names of the USB devices using each USB Port, and to individually turn off/ turn on USB ports.
- In my setup all 6 ports are used, however usb6 for 'Ekowitt Station' is just used for supplying 5v power to Ekowitt Gateway Hub (it is not used for data comms to the computer, that is provided instead by means of ethernet cable to Observatory's Ethernet Switch & LAN.)

The lower section is used to specify which ports are enabled (on) when the USB Control Hub is started or reset.
- In my setup all 6 ports are specified to be enabled (on) when the USB Control Hub is started up.

In order for the ASCOM driver to be available. The driver has to be selected through an ASCOM chooser and the properties of the Switch Driver need to be accessed in order to select the UCH Control Hub. As this was an extra step (which AstroObsCam didn't have to formerally do) I had to add a means to do this.

It was decided to create a Tools tab in the AstroWeather program (v1.29) to do this task.

Choose is used to access the ASCOM Switch Chooser and after selecting 'PegasusAstro Switch 1' (to get the ASCOM.Device1.Switch driver) the Properties button is used to select the picture of USB Control Hub. Finally Ok button is clicked to complete the process.

Optionally a connection to the USB Control Hub can be made at this point to bring up a virtual view of the USB Hub from where USB Ports can if required be individually turned off/turned on, without opening the Unity user-interface.

Beside the change to AstroWeather (1.29) changes also had to be made to other programs:
- AstroObsCam (1.12) - modified to use Pegasus Unity's 'ASCOM.Device1.Switch' driver instead of ASCOM.UCH.Switch
- AstroLaunch (1.14) - modified with option to launch 'Pegasus Unity (instead of former 'Pegasus USB Hub Software' )

Update 2025-11-18

An issue has arisen involving the USB Control Hub. :

"After restarting the AllSky/Weather Computer the AstroObsCam program couldn't connect to USB Control Hub Switch"

Twice now the AstroObsCam client program couldn't connect to USB Control Hub via ASCOM after restarting the Computer, and PegasusAstro Unity UI couldn't find the USB Control Hub (UCH). AstroWeather's new Tools tab has an ASCOM Switch Chooser and whilst it was to open Properties for the ASCOM Driver and get an PegasusAstro Unity dialog box it was just a blank dark grey dialog, without the expected UCH picture icon. Although there was no connection to the USB Control Hub, all the USB devices using the Hub were all working (obviously pass-through USB connections to the computer worked).

On the first time this happened the problem was resolved by disconnecting the Control Hub's USB Cable from the Computer and then connecting it again. This is inconvenient as it involves stopping all the software that use the end devices and going out to the observatory and physically resetting the USB cable connection to the USB Control Hub.

On the second occasion a different strategy was used, which was to Disable the 'USB Serial Port (COM4) in Device Manager and then renable it. This worked and both Unity Platform and AstroObsCam were able to be to find the USB Control Hub again, and there was no impact on connected USB devices. So a sufficently adequate solution or workaround.

It is possible that the problem occurs because AstroObsCam didn't disconnect from the ASCOM connection to the USB Control Hub, before the program was closed. This may need to be action taken by the user before restarting the computer or a modification to the program itself to force a disconnection during program exit. Details s about issue have been sent to Pegasus Astro for their thoughts. They provided a link to the USB Tree view tool and suggested that it may help to investigate any USB/COM port assignment issues on the PC before ASCOM or any other driver kicks in.

Whilst UsbTreeView hasn’t yet been used for that precise purpose, a baseline USB Tree View picture for the AllSky/Weather Computer has been captured and is shown in a S1375 Session Notes (see AllSky/Weather Computer - USB Tree View (2025-11-20)).

CloudSensor III - Reinstallation

Introduction
CloudSensor III has been run on the AllSky/Weather Computer for several years where it has had the role of operating the CloudSensor Head and collecting rain, clarity and light sensor data, which is then read by and distrubuted onwards by AstroWeather program to several other Observatory programs : AstroAllSky (also running on AllSky/Weather Computer) and AstroMain & AstroGuard (running on the Observatory Computer). It has been run on Windows 10 and later on Windows 11, with the program installed in 'C:\Program Files (x86)\Aurora Eurotech\Cloud Sensor III'.

Following a computer issue on 2025-11-12, the Windows 11 Operating System had to be fully reinstalled, and all software reinstalled & re-setup.

These notes describe the reinstallation of CloudSensor III and various problems encountered, and their solution or mitigation, some of the issues relate to memory loss over how the CloudSensor III was originally installed and operated.

Initial Reinstallation (2025-11-15 am)

Cloud Sensor's Serial-USB cable was connected to USB Control Hub (via the usb3 port)
'Prolific USB-to-Serial Comm Port (COM3) appeared in Device Manager'

- Device properties showed Prolific 3.9.6.0 driver, dated 2024-06-17, signed by Microsoft Windows Hardware Compatibility Publisher
(This overrode the Prolific driver that was installed from the support CD that originally came with the CloudSensor the previous day)
CloudSensor III was installed by running AuroraCloudSensor-Setup-V3.2.41.exe,
with an install path specified as 'C:\Program Files (x86)\Aurora Eurotech\Cloud Sensor III' (i.e. same path as previously used)
Ran CloudSensor III (possibly from the installer, when the installion was completed and the Launch checkbox (ticked) appeared.
Set Sensor Serial POrt to COM3 and check Sensor Head settings

Started Cloud Sensor service in AstroWeather and confirmed that Clarity, Rain and Light data values were coming through from CloudSensor.
Confirmed that data values were coming through to the Observatory Computer
Found an issue : Cloud Sensor III program immediately shuts down when started by AstroLaunch (bat) or by the User directly
Program seemingly needed to be started using 'Run as Administrator'.

CoPilot analysed the Event Viewer log and believed that there is possibily some issue with Visual C++ 2010 Redistributable that CloudSensor III is dependant on and recommended reinstalling them:
- this might be a red herring as the CloudSensor III did fire up and run ok when first started via the Installer program.
- but anyway, downloaded and installed x86 (vcdist_x86.exe) and x64 vcedist_x64.exe) versions from www.microsoft.com/en-gb/download site
- and later downloaded x86 version of Visual C++ 2008 Redistributable SP1 from Microsoft)
- noted that old versions of vcdist_x86.exe and x64 vcedist_x64.exe are placed in subfolders in the Program Folder by the installer
Established that the issue with that prevented CloudSensor.exe was due to it being run without elevated privileges.
and seems to be due to the program being installed in 'C:/Program Files (x86)' folder area
(even though that was where it was located prior to the Windows 11 Reinstall on 2025-11-13)

New Reinstallation (2025-11-15 pm)

Reinstalled CloudSensor program at 'C:\More Programs\Cloud Sensor III\'.

- Install CloudSensor program
- Copied previous set of monthly.csv data files into the new program folder

Program then had issues were it would unexpectedly exit after a few minutes (no reason evident in ProcMon trace)
- SerialPortMonitor opened and set to monitor the COM3 port, and left running which showed continuous readings coming through from the CloudSensor Head
- Made changes in Power Options / Advanced to disable the "USB selective suspend setting".
- Made changes in Device Manager to uncheck "Allow the computer to turn off this device to save power" in Power Management tab of USB Root Hub and other devices
AstroLaunch (1.14.1) was modified to look for program in 'C:\More Programs\Cloud Sensor III\' and gets it program version

However AstroLaunch was still not successfully launching the CloudSensor program despite the attempted fixes.
- a command terminal window briefly appears and then disappears.
- investigating code showed AstroLaunch is submitting a batch file that runs the line "schtasks /run /TN LaunchCloudSensor >Launch2.log"
- it is now clear that it was doing this in order to run the CloudSensor.exe with elevated permissions,
- however it fails to do this as the Windows Schedular lost its list of Tasks when the complete re- install of Window 11 was made on 2025-11-13
- with hindsight there is is actually a note from 2020-09-01 (Replacement AllSky Computer (2020-08-23, 2020-09-01) that refers to this set up: "LaunchCloudSensor and LaunchVws tasks exported from old AllSky/Weather computer and loaded on the new computer" in a section

Fix (2025-11-15 pm)

New 'LaunchCloudSensor' task was set with action to run 'C:\More Programs\Cloud Sensor III\CloudSensor.exe'
Issues finally resolved and CloudSensor finally seemed to operate fine following a computer restart.

It is unclear if it was necessary to go through all the above steps to get CloudSensor III working but the new location for the program makes more sense and removes the necessity of setting up a special Share to the CloudSensor III program folder as it can be accessed via the "More Programs' Share.

It is possible that with the program's new installation location that the launch program via Task method may not actually be required, and a simple Launch Application would work ok from AstroLaunch.
AstroWeather (1.29) was modified on 2025-11-15 to look for CloudSensor data files in 'C:\More Programs\Cloud Sensor III\' folder
( instead of the earlier 'C:\Program Files (x86)\Aurora Eurotech\Cloud Sensor III' folder )

iSpy64 - Reinstallation

Introduction
iSpy64 has been run on the AllSky/Weather Computer since Nov 2024 when it began to be used for accessing video stream coming from the Observatory's NorthCam Camera - a Tapo C325WB low light colour camera - used to monitor for and record Aurora in the northern sky.

(iSpy64 is more useful for me than the more recent iSpy Agent Software, or other products like VLC, as it provides more convenient means for providing jpg pictures that can be picked up by my own AstroNorthCam program)

iSpy64 has been run on Windows 10 and more laterally on Windows 11, with the program installed in 'C:\Program Files\iSpy\'

Following a computer issue on 2025-11-12, the Windows 11 Operating System had to be fully reinstalled, and all software reinstalled & re-setup.

These notes describe the reinstallation of iSpy64 and the various problems encountered, and their solution or mitigation.

Reinstallation (2025-11-14)

Installed iSpy64 v7.2.6 (note that we do not install iSpy Agent)
-
Configure iSpy64 to connect to NorthCam (Tapo C325WB), and set up prior settings
- IP Camera, IP 192.168.1.63
- Camera Stream : rtsp://account:password@192.168.1.63:554/stream1
Checked camera connection had found a show stopping Issue
- Issue : first video frame streams to iSpy64, and first frame's jpg is saved to relavant 'grab' folder but iSpy program then crashes

Continued Efforts (2025-11-15)

iSpy64 continues to crash after accessing first frame
Determined that running iSpy64 'as administrator' works and allows the program to run ok without crashing.

Problems relate to permissions in some way
(this was not a problem following the original installation in Nov 2024, but it is now for some unknown reason)

Fix (2025-11-16)

AstroLaunch modified to Launch iSpy via bat file & to run a newly setup Task called 'LaunchISpy' that launches the iSpy64 program with elevated privileges.
A minor issue was noted once AstroNorthCam began working with images supplied by iSpy and that was the timestamp drawn by iSpy is too small.
This was fixed in iSpy Camera Settings by changing Font Size changed from 8 to 12.
Issues finally resolved and iSpy / AstroNorthCam finally seemed to operate fine.

This Web Page:	Notes - Session 1374 (2025-11-11)
Last Updated :	2025-12-05
Site Owner :	David Richards
Home Page :	David's Astronomy Web Site

	2025-11-13

	Session Aims & Highlights
	- Observing Result - Night Summary Plot - Session Event Log

	Operational Issues
	- Critical Issues (1), Major Issues (3), Minor Issues (5), Small Defects (8), Continuous Improvement (17)
	- Figures (5)

	Images from 2025-11-11 >>

	AllSky Computer - Full Windows 11 Reinstall (including all programs)

	2025-11-16
	Pegasus Astro USB Control Hub & new Unity Platform
	CloudSensor III - Reinstallation
	iSpy64 - Reinstallation

David's Astronomy Pages
Notes - Session 1374 (2025-11-11)

Session Aims & Highlights (2025-11-11)

Operational Issues (2025-11-11 S1374)

2025-11-13

AllSky Computer - Full Windows 11 Reinstall (including all Programs)

2025-11-16

Pegasus Astro USB Control Hub & new Unity Platform

CloudSensor III - Reinstallation

iSpy64 - Reinstallation

David's Astronomy Pages Notes - Session 1374 (2025-11-11)

Session Aims & Highlights (2025-11-11)

Operational Issues (2025-11-11 S1374)

2025-11-13

AllSky Computer - Full Windows 11 Reinstall (including all Programs)

2025-11-16

Pegasus Astro USB Control Hub & new Unity Platform

CloudSensor III - Reinstallation

iSpy64 - Reinstallation

David's Astronomy Pages
Notes - Session 1374 (2025-11-11)