Several target attempts failed during the session with an autoguiding failure, that is best illustrated by looking at a sequence of 4 x 180s frames from Hickson 54. Similar problems affected image attempts on U Gem, Hickson 39, 40, 47, 64, 67, 72, 76 & 80 and C/2017 S3 (in part). It would seem that PHD2 Autoguiding failed to lock onto a suitable guide star or lost it during imaging and sent a series of invalid guide corrections to the mount leading to a series of zig-zag star traces on the resulting image frames.

Not only were the targets not successfully observed , but some 2.3 hours worth of imaging time was wasted.

Problem began on the 31st target of the night. This was after the start of unattended operation and continued for the rest of the night. The failed targets are interspersed with a few targets where autoguiding was successfully achived which show that there wasn't a total failure of the guiding software or the telescope facility to perform guide corrections.

The most likely diagnosis is that temperature drift occured over the course the session which has caused the TS 80mm Guidescope to become sufficiently defocused that it became difficult for the PHD2 to find & maintain a suitable guide star (particularly in relatively dim star fields typical of Hickson Galaxy Clusters)

Sequence of Frames from Hickson 54

CCD Images (50% size) 4 x 180s exposure,  3x3 binning, C Filter 2019-01-03 01:22 UT (#647320-23) 12" LX200R (at f/10.4) + ST-10XME Auto-guided attempt using TS 80mm APO, ZWO ASI178MC & PHD2

Typical log files from one of these failed targets :

Activate Guidescope Guiding   Ok        Using PHD2 (ZWO ASI ASCOM Cam)
  Guide Exposure:             Ok        Exposure 2s
    Send Guide Request
    Guiding ...               Ok        Guide Request Returned
    Lock Position             OK        X: 2090.0, Y: 82.0
    Star Selected             OK        X: 2090.0, Y: 82.0
    Lock Position             OK        X: 2080.0, Y: 76.2
    Guiding ...               Ok        Guiding Started
    Settling Begun            Ok        
    Star ...                  Fail      Star lost - mass changed
    Star ...                  Fail      Star lost - mass changed
    Star ...                  Fail      Star lost - low SNR
    Settling...               Fail      Error: timed-out waiting for guider to settle
    Review Guiding ...        Fail      Guiding failed to start within Settle Period

  Using C filter...
  Taking 180s image (C)...    Ok        [00647311] 00:51:09 (UT)  Full 3x3 180s C
    Guide Stats  rms error    11.0"     9.3" / 5.9", SNR: 18.8, SM: 1926, Guide: 75% (Lost: 25%), N: 36
  Taking 180s image (C)...    Ok        [00647312] 00:54:14 (UT)  Full 3x3 180s C
    Guide Stats  rms error    34.9"     25.3" / 24.0", SNR: 16.4, SM: 1617, Guide: 42% (Lost: 58%), N: 31
  Taking 180s image (C)...    Ok        [00647313] 00:57:20 (UT)  Full 3x3 180s C
    Guide Stats  rms error    21.1"     14.1" / 15.6", SNR: 32.4, SM: 44777, Guide: 79% (Lost: 21%), N: 34
  Taking 180s image (C)...    Ok        [00647314] 01:00:33 (UT)  Full 3x3 180s C
    Guide Stats  rms error    4.0"      3.8" / 1.4", SNR: 28.2, SM: 38347, Guide: 66% (Lost: 34%), N: 41
  Taking 180s image (C)...    Ok        [00647315] 01:03:38 (UT)  Full 3x3 180s C
    Guide Stats  rms error    4.7"      4.0" / 2.5", SNR: 31.9, SM: 43239, Guide: 56% (Lost: 44%), N: 39

  Guiding Results             15.6      mins (elapsed)
    Guide Stats  rms error    16.6"     12.0", 11.5", SNR:26.4, SM: 28178, Guide: 64% (Lost: 36%), N:181 (65)

PegasusAstro Power Supply (12V, 10A, 2.5mm) arrived today from AstroShop.EU

This is sealed and certified switching power supply unit that is promoted as being the perfect match for the Pegasus Astro Products. It can provide 12V and up to 10Amps. (120W of total power). Low ripple and noise are meant to ensure that it provide the required and correct “electric juice” to one's precious equipment.

Specification:

• Output Voltage: 12V
• Loading: 0-10 Amps
• Max. Power : 120 Watt
• Input Voltage Range: 90-264V
• Frequency: (47-63) Hz
• Sealed / Protected Enclosure (humidity / dust cannot enter)
• Safety Agency Requirements and EMI/EMS Certified
• Efficiency level (ErP) : VI
• CE and FCC certificate acquired

Protections:

• Over current/ Short protection: The power supply will self-protect any output to ground & auto recovery when abnormal circuit faults remove. An output short circuit is defined as any output impedance less than 0.1 ohms.
• Over Voltage: The power supply will be auto recovered when faults remove Input protection: F1:6.3A 250V Fuse. The power supply shall be protected against power line surges and any abnormal condition
• No Load protection The power supply is provided with no load operation to prevent the power supply and system from damage.
• Protection class I, (ITU-T K.21 Surge 6KV )

The new 10A Power Supply will replace a 5A  12V supply that originally supplied power to my old manual dew heater controller and more recently powered the UPB Power box for a couple of months during its commissioning phase. The old 12V supply was noisy (with an incorporated fan), of probable high electrical noise and of insufficient power for future requirements using the UPB (such as powering the LX200 telescope and future equipment)

Extension Cable Issue (1). The cable on the Power Supply is too short to reach the UPB mounted on the scope and therefore an extension cable will need to be used. It is proing difficult to find a cable with 2.5mm male plug that fits securely into the power-in port on the PowerBox. The cable that I bought for the purpose (and other cables that will eventually become available) has a 2.5mm/5.5mm plug that is too loose and produces power disconections to the UPB if the cable moves in any way. This is a particular issue as the placement of the powerbox on one of the arms of the LX200 Fork Mount means that it is always prone to some movement even if taped.  Until a suitable extension cable can be found, the current extension cable is being used with a small piece of wood and vinyl to wedge the plug in a 'as secure as possible' manner.

(See notes below on Observatory Cabling Changes & Daytime Tests

Extension Cable Issue (2). Once the PowerBox was used to power the LX200 mainscope it became evident that a regular (thin wire) 12V extension cable (2.5mm male to 2.5mm female) was generating significant voltage drops to the UPB.   With dew heaters on full power voltage would drop to as lower as 10.5V and produce short-circuit messages in the UPB software.
This was eventually resolved 2019-04-22 by the introduction of a new 16 AWG Extension Cable to reduce the voltage drop going to the UPB powerbox, allowing dew heaters to be run at full power whilst still providing 11.9V input voltage to the UPB (see Pegasus UPB - 16 AWG Extension Cable, 2019-04-22)

Cabling Changes

A number of cabling changes were made in the observatory today

- Removed old 5A 12V Dew Heater Power Supply and cabling (including extension)
- Removed old RS232 cable and Serial -USB Adapter for LX200 telescope (a new Serial Cable with embedded USB adapter is already in use)
- Removed old power supply and cabling used for old AllSky Laptop (new power supply & cabling for new AllSky Laptop is already in use)

- Added new 12A 12V Pegasus Power Supply and cabling (including extension)
- Added 2.1mm to 2.5mm 12V cable to output power port on Pegasus UPB (including extension)

Daytime Tests

With new 10A Power Supply and cabling to Pegasus UPB in place the LX200 scope was powered up and a series of slew tests were made including moving the scope to extreme positions (just east of North and just west of North).  

Previous tests had shown potential issues with USB and Power Cable to the UPB and the Serial Cable to the LX200 being pull tightly across the front of the LX200 base when the scope is moving westwards to positions just west of North. As a result a no-go area (between 340 and 360 deg) was implemented in the Observatory Control program.

Whilst moving the scope westwards to the Due North and just beyond Due North there was a loss of connection to the UPB and consequently a loss of connection to the LX200 Scope. Checking show that the USB plug on the cable to the Pegasus UPB had been pulled sufficiently far out of its USB input port that comms to UPB stopped.

It was already noted that the 2.5mm plug on the 12V cable going into the UPB sat fairly loosely in its power port and some movements of the scope would cause sufficient power outage to the UPB that communications with the UPB to fail.

Operational Issues (2019-01-08, Day Time Tests)

• Critical Issues (4)

 [ Prev | Next ]

Critical Issues

• Cable Pull.   The USB and Power Cable to the UPB and the Serial Cable to the LX200 (and in future the Power Cable between UPB and LX200) are are pulled tightly across the front of the LX200 base when the scope is moving westwards to positions just west of North.
  Fixed 2019-01-12 (Cables were reconfigured so that the bundle no longer pulls across the front of the LX200 panel (Notes))
   
• USB Cable pull.   The USB cable to the Pegasus UPB is pulled too tightly when scope move just West of north and eventually pulls the USB plug out of its port on the Pegasus Powerbox
    Fixed 2019-01-08 (cables going up into the Pegasus UPB or going down to the LX200 Mount Base were tightly taped to the Scope's Fork Arm) which eliminates/significantly reduces the potential movement of the USB Cable going into the UPB.)
   
• Power Plug issue and UPB power outage . The 2.5mm/5.5mm plug on the power extension cable to the UPB fits too loosely in powerbox's power input port and causes the UPB to reboot or otherwise loose connection with the Observatory PC.
  Fixed 2019-01-08 ( temporary fix - a small piece of wood and vinyl were used to wedge the plug in a secure as possible manner)
                   Fixed 2019-01-12 (a new cable with a tighter fitting 2.5mm plug was fitted instead) 
   
• Loose fitting USB Plugs.   Both the Observatory PC and AllSky PC seem to suffer from loose fitting USB Plugs, such that a  movement of the either Laptop or a small knock on the USB cables causes attached devices to Disconnect/Reconnect This is a problem because it some cases the connection to the device will be lost for longer time due to change in associated COM Port numbers or upset of the connected USB Hub. Both computers are fairly old and  2 metal retaining  'springs' in each port have weakened.   (YouTube video shows how these can be fixed https://www.youtube.com/watch?v=B_ruqSrkxNU )
  Fixed 2019-01-08  (metal springs in the USB ports on Observatory PC was pushed 'out'  in order make the USB plugs fit more tightly,  the fix was subsequently made to the USB Ports on the AllSky PC on 2019-01-12). (See USB Port Repair note)
  

Annotated Picture showing Cabling to Pegasus Power Box , the positions of the USB In and Power In ports, and the newly added taping used to stablise the cable connections (note the cable bundle from the PowerBox was later reconfigured to descend from the  back of the fork base rather than descend directly from the fork arm

Cabling Changes

Both the Observatory PC and AllSky PC seem to suffer from loose fitting USB Plugs, such that a small movement of the either computer or a small knock on the attached USB cables causes the attached devices to Disconnect/Reconnect. This is a problem because in some cases the momementary disconnection causes a change in associated COM Port numbers or upset of the connected USB Hub or connected device. Both computers are fairly old and the 2 metal retaining  'springs' in each USB port have become flattened & weakened. 

After watching a YouTube video ( https://www.youtube.com/watch?v=B_ruqSrkxNU ) a repair to the Observatory Computer was made by pushing 'out'  the metal lugs/spring in order make the USB plugs fit more tightly.

(The  fix was subsequently made to the USB Ports on the AllSky PC on 2019-01-12)

It is unclear if the slackness in the USB port had played any role in COM Port switch events that can occur whilst the observatory is unoccupied, however the Observatory equipment has been now (2019-01-18) running now for a full week without any COM Port Switch events.

Two of the three USB ports on the Observatory PC  Each port has a couple of small metal lugs which have gradually become flattened loosing the grip on any insert USB Plug.  These having being given rise to disconnection events when computer is moved or the cables are accidently knocked.  There are actually a further pair of metal lugs at the top of the USB and these were lifted down to again tighten the USB Port's hold on any inserted USB plugs

Fixing the USB Ports with a very small screwdriver Tip of the screwdriver is used to slightly lift up the metal lugs

Humidity Sensor from Pegasus UPB ( a combined external Temperature/Humidy Sensor) has failed and has been returned to supplier for a replacement yesterday.

 

Nov 2018 . Humidty values from sensor not to be reading higher than than of an oregon scientific humidty sensor also situated in the observatory
( see 5 day chart comparing different sensor readings - Nov 2018)

Dec 2018.  Humidty values noticed to be reading 99% for 12-24 hours at a time or otherwise reading considerably higher than the Oregon Scientific sensor.
(Tried the Pegasus sensor in a number for locations but problem persisted.  The reading of 99% would imply the sensor area might be dripping in condensation but the area was plainly still dry. Contacted PegasusAstro about the problem (16th Dec) but had no reply.  A plot comparing the Pegasus Humidity value with Oregon Scientific Humidities is shown below.

 

Jan 2019.  Humidity values reading 99% for 3 weeks now. Contacted AltairAstro about the problem on 2019-01-07 and returned the sensor for a replacement by mail on 2019-01-11. ( see 5 day chart comparing different sensor readings - Jan 2019)

Progression in failure of Humidity Sensor from Nov 2018 to Jan 2019 is shown in the following picture.

Screenshot of the Pegasus PowerBox software showing 99% RH readings

Sensor.   Examining the bottom of the sensor before sending it away for replacement shows that it is ASAIR AM2301 Temperature/Sensor with stated precision of +/-3% RH and +/- 0.5 degC. It seem similar to other products known as SONOFF AM2301 (available for £4.38) and AOSONG DHT21 / AM2301

Technical details for AM2301 Sensor

• During risk assessment for unattended operation of the Observatory it was identified that there was a need for automated closure of the Dome Shutter in the event that either my Observatory Control Program (AstroMain) locks up or the Observatory Computer itself freezes/dies and were consequently unable to command the Dome to close in the event of rain.
  
  [ My AstroGuard program provides some protection in the event that the AstroMain program doesn't command the shutter to close when it starts to cloud over or rain begins and my AstroProtect program provides protection in the event that the Observatory Computer automatically restarts after a computer crash.  However neither are effective if a) the Observatory Computer freezes or totally fails  or b) if the COM connection to the Dome Controller goes down or otherwise fails. ]
   
• It was identified that there is a protective Relay port on the bottom of the Dome Controller which could provide the required additional protection if it could be hooked up with the protective Relay output from my Eurotech Cloud Sensor.
  
  Photo showing base of Pulsar Dome Controller
     
  
  Eurotech CloudSensor (left) including Rain & Light Sensors
  
   
  
• The Eurotech Cloud Sensor manual provided some information about it's Alert Relay
  
  
  
  
  The manual also describes and the setting up of thresholds (in terms of Rain, Sky/Clarity and Light) and the enabling/disabling of the Safe/Unsafe Relay for each element  (It would seem that the Safe/Unsafe Relay probably operates at the lower thresholds (Clear/Cloudy, Dry/Wet, Dark/Light) rather than the higher threshold (Cloudy/V.Cloudy, Wet/V.Wet, Light/V.Light)
  
  
  
   
• The Pulsar Observatories Dome manual and Automation manual (as at 2018) appear to be totally devoid of any information about the Dome Controller's relay facility .  The pop-up help on the Relay settings in the version of the Pulsar Dome Software that originally came with the dome was of little help (and as it turned out the Settings Setup was missing some critical setting options).  
  
  The Pulsar Observatories technician was contacted for assistance, as a result of which I recieved and updated the Dome's software  which gave access to Relay settings that was unavailable with the previous version
   
  • Dome Software & Drivers were updated using the  'Pulsar_Observatories_Package 1.0.32.0.exe'  installer
  • Dome Rotation Driver updated from 1.30 to 1.39
  • Shutter Driver updated from 1.17  to 1.22
     
• The available Relays settings for the Pulsar Dome are shown below along with the associated Pop-Up Help description for each setting (Note that pressing F1 didn't provide any more help).
  
  
  Note that 'Polarity' has to be set to the 'NO' option for it to get the correct replay state intended by the observatory's CloudSensor.
  
  
  
  
  
  It would seem that the best settings to use would be
  
  AutoOpen - Disabled (This is disabled as I would want the opening of  Shutter to be under full control of my Observatory Control Program, operating in either Manual or Automated Mode or under my direct manual control using the Dome Controller panel)
  
  Polarity -    NC or NO   (Best choice to be assessed by experimentation)
  
  Change -  Anytime (Would want protection to always be available, so Dome would close if it started raining whilst Dome was Slewing)
  
  Delay - 10 or 15 Seconds (Ideally I would want the Observatory Control Program to recognise the Rain /Cloud condition and respond accordingly with the Relay acting as a backup protection, but without too much of a delay otherwise the dome interior & equipment could get damaged in a sudden downpour )
   
• A Connector for the Pulsar Dome Relay Port was purchased from RS Components Online (see product page )
  
  The connector is a 2 way/Pole with a clamping-yoke screw system and came as a pack of 5 plugs (the long terminal block shown in the picture on the product picture is misleading)
   
• A 2 wire cable was connected to a Relay Plug with sufficient length to reach Cabinet Bay 1 that contained the Cloud Sensor relay wires
  
  
   
  
• Relay Plug was then connected to the Dome Controller
  
  
   
  
• Using a breadboard the 2 relay wires from the Pulsar Dome,  the 3 wires from the Eurotech Cloud Sensor and 2 DC wires from a 5.5v PowerSupply were arranged into different circuit configurations and tested by forcing the Cloud Sensor into Safe & Unsafe states (by disabling & enabling the requirement for Dark Conditions) and then examing the behaviour of the Dome Shutter when using NO and NC Polarity Settings.
  
  (Important Note: It was established later that the 5.5v supply in the circuit wasn't required as the relay is already powered by a 12.8V supply coming from the Dome Controller. This was missed as the DC reading part of the multimeter used in testing had unknowingly failed)
   
  
     
  
   
• Two to three hours were spent looking for Relay Settings and Wiring Configurations that gave the required Dome behaviour, whereby  :
  
  - the Dome shutter could open and would stay open when conditions were 'Safe' 
       (according to the criteria that have previously been saved to the Cloud Sensor)
   
  - the Dome shutter could not be opened when conditions were 'Unsafe' 
       (i.e. the opening of the shutter would  automatically abort  before being fully opened and close again)
   
  - the Dome shutter would close when conditions were 'Unsafe'
  
  It was thought that if I use the White (Nornally Closed) wire in the circuit then I would need to use the NC (Normally Closed) Setting in the dome's Relay Settings  (or, if I use the Brown (Normally Open) wire then I would need to use the NO (Normally Open) setting in Relay Settings)
  
  However the opposite proved to be the case and  I ended up using the White (Nornally Closed) wire with the NO (Normally Open) setting in Relay Settings.
  
  It is believed that the discrepency is a difference in terminology. The Cloud Sensor's description of 'Normally Open/Normally Closed' relates to an Active Alert (e.g it is raining), whilst the Pulsar Dome's description of 'Normally Open/Normally Closed'  relates to the absence of an Alert (e.g. it is not raining). This explains why NO Settings works with the NC wire. (Presumably NO setting would work with the NO wire)
  
  
  (Important Note: It was established later that the 5.5v supply in the circuit wasn't required as the relay is already powered by a 12.8V supply coming from the Dome Controller. This was missed as the DC Reading part of the multimeter used in testing had unknowingly failed)
   
• Happy with the solution found the wiring circuit was then carefully duplicated using a 4 pole terminal block (forming a relay connector) and the functionality again tested.   The wires where then taped up to secure them and the 'relay connector' carefully tucked away beneath the AllSky/Weather cabinet.
   
  
  (Important Note: It was established later that the 5.5v supply wasn't required as the relay is already powered by a 12.8V supply coming from the Dome Controller)
   
• Finally the relay cable going to the Dome Controller was inserted into the conduit going to the Dome Controller and then all cables associated with the Controller tidied up as much as possible.
   
  
   
• It should be noted that when working on the Shutter / Shutter Drive it is important to deactivate the relay otherwise the Shutter could shut when one is not expecting it to close.  Of course it should be remembered to reactivate the relay circuit once the work is completed in order to maintain the expected back-up protection.
   
• It is important that the Relay Delay is not se to 0s.   It seems that spurious signals / momentary values when delay setting was set to 0s led to the shutter instantly and unexpectedly closing even though the sky was completely clear. This might occur up to 5 or so times in a session.  Including a delay (20s or 30s) stops these spurious/unexpected closures and allows Observatory Software to gracefully suspend operations and begin to close the shutter before the relay is activated by the hardware.
  
  
  Update: Oct 2023
  
  The currently used Relay Setting are shown in the picture below (from screen capture of Pulsar Dome Settings, 2023-10-28)
  

  Note that 'Polarity' is set to the 'NO' option for it to get the replay state intended by the observatory's CloudSensor.

  
  

Following earlier Cabling Changes (2019-01-08), a tighter fitting 2.5mm power extension cable was fitted to the Pegasus Ultimate PowerBox to solve the risk of UPB disconnection events that earlier extension cable was prone to.

The bundle of 4-cables from the Pegasus UPB (comprising 12V Power & USB going to the powerbox and 12V power & serial connection going to the LX200 Mount) was reconfigured to descend from the back of the fork base ather than descend directly from the arm. This is prevent the bundle being pulled across the front of the LX200 Panel when scope is in the NNW-N position and to provide slightly more protection against cable being wrapped around the mount. However to eliminate the risk of the bundle being caught behind any of the 3 knobs on the Wedge, shaped foam inserts were placed under each knob.

A new set of daytime slew tests were conducted to ensure that the Slews could be safely made.

Picture showing the reconfigured cable bundle from Pegasus UBP PowerBox

During risk assessment for unattended operation of the Observatory it was identified that there was a need to reduce or eliminate the risk of telescope cable getting snagged or otherwise getting hung up as the telescope slews or rotates round at sidereal pace. Beside the risk to successfully imaging of a target, there is the more significant risk of damage to cabling, to telescope and equipment ports and potentially to the telescope motor and electronics.

One particular risk (and believed to have occurred during one particular session) which caused disconnection of the SBIG camera) is the snagging of cables from the back of the scope (a USB cable to the ZWO Camera, a power cable to SBIG Camera and a serial cable to the TCF-S focuser) to become snagged on the pier bolts when the scope is pointing at high altitudes. ( This was not a risk in my previous roll-off observatory as the pier bolts lay below floor level. In the new dome observatory the pier bolts are above the floor surface )

To eliminate this risk shaped foam inserts have pushed into the gaps between the pier and the pier bolts. Other options were considered involving make a protective circular shuttering, but the form inserts was the simplistic method.

Picture showing the protective measure to eliminate hang-up of telescope cables on pier bolts

Another risk that has been introduced since the installation of a Pegasus Ultimate PowerBox is the snagging or hang-up of it's cable bundle (comprising 12V Power & USB going to the powerbox and 12V power & serial connection going to the LX200 Mount) behind any of the 3 control knobs on the Wedge. To eliminate this risk shaped foam inserts have been placed under each knob. This is the simplest method to stop cables getting into places they could get trapped in.

Picture showing the protective measures to eliminate hang-up of cables on wedge control knobs
Right Side of Wedge		Right Side of Wedge (close-up)
Left Side of Wedge		Rear Side of Wedge

Pegasus UPB Software was updated to 1.4.10 today. I

Earlier in the week ASCOM UPB Switch Driver was updated to version 1.4, however testing shows that it is still unable to be used whilst the UPB Software is running & connected to the UPB and thus cannot work at the same time as the ASCOM UPB Stepper Focuser and ASCOM UPB Observing Conditions drivers.

During earlier repositioning of the Dome's Rotation Drive Unit, the spring that holds the encoder off the dome wall & against the roof rim was accidently damaged. This happened when the two parts of the Drive Unit where separated without first disconnecting the spring. The spring was irrepairably overstretched and a length of elastic tape has been used in the meantime to perform the function of the spring.  

A replacement spring was finally fitted today and the elastic tape bush fix removed.

The spring is mounted onto the encoder arm by means of a small bolt with round head (with hexagonal slot for taking an allen key), washer and self-tightening nut.  Removing the bolt and nut, and then putting them back with the new spring is very fiddley as the space for working is very confined and one almost needs 3 hands to do the task.  After trying multiple times (with either the spring, the washer, the bolt, the nut, the spanner or the allen key falling to the ground) the front part of the rotation drive with control panel was removed to give a bit more working space.

Pictures showing the replacement of Encoder Arm Spring
Over-stretched Spring on Encoder Arm (spring on encoder arm that became irrepairably overstretched when front motor / driver controller was removed from back motor plate without unhooking the spring)		Temporary Bush Fix (elastic loop wrapped around the encoder unit to keep  the encoder wheel tensioned against the roof flange)
Rotation Drive Motors with the Front Part of Drive Unit removed to provide more space		New Spring Fitted to Encoder Arm
Comparison of the new spring with the overstretched, non-functional spring		Rotation Drive re-assembed with Spring attached between the Encoder Arm and the Front Part of the Drive Unit

Whilst replacing the encoder arm spring on the rotation drive unit it was noticed that head of one of the rotation driver motors was somewhat loose and its grub screw was partially unscrewed/loose. Opportunity was taken to tighten the grub screw and ensure that the motor head was secure.  It was fortunate that the problem was caught before it caused a complication during observatory operation.

Rotation Drive Motor (from front part of Drive Unit)		Close Up of Drive Motor Head showing the grub screw that was loose (picture taken after grub screw was tightened)

A suite of 3x3 Dark Sets were acquired at -25 degC (average CCD Cooling 71%)

Bin|Num|Exp |
3   15    0.12
3   15    0.2
3   15    0.5
3   15    1
3   15    2
3   15    3
3   15    4
3   15    5
3   15    8
3   17    10
3   17    15
3   17    20
3   17    30
3   17    45
3   17    60
3   17    90
3   17    120
3   17    180
3   17    300
3    9    600  Set terminated early


Operational Issues (2019-01-19, Dark Frames)

• Major Issues (3)
• Minor issues (2)

[ Prev | Next ]

Major Issues

• Dark Suite Run Stopped by NightDate change.   The run stopped at 09:00 when the NightDate switched from 2019-01-19 to 2019-01-20.   This involves the ObsManager killing CCDSoft in order to reset ImageSaveNum to 1.  This causes the Dark Frame executor to stop  with an "Object variable or With block variable not set" exception. Was this was luickily during the final 600s set, it prevented the acquisition of 2x2 and 1x1 darks that were scheduled.
    Fixed 2019-01-20 (Code modified to delay switch to new NightDate Session if an  aThread (like one for  RunTakeDarkSet) is still running
   
• Ethernet Connection to/from AllSky-Weather Computer failed and attempts to automatically restart the connection by AstroWeather program failed. Problem was resolved following morning by visiting the observatory and running the "Reset Ethernet" routine in AstroAllSky tools.   The problem stopped a potential observing session (skies clear after a long run
    Fixed 2019-01-20 (The critical file 'ResetEthernet.bat 'was added to the AstroWeather program folder - it was missing for some reason)
   
• Error writing to Monitor File.   Writing to MonitorFile failed at around 02:41 with the errors message
  "Exception Writing to Monitor File. Error: Cannot write to a closed TextWriter."   Message continued to be output to logfile at 2 min intervals until end of session.  This is an intermittant problem but annoying when it does occur. Look into problem again (logfile indicates that file was reopened at 02:41:32.39 with write errors beginning almost immediately at 02:42:51.15 . This followed a seemingly normal program shutdown at 02:38, and seemingly normal program restart at 02:41.)
  Resolved 2019 (Closed on Nov 2020)

Minor issues

• ObsViewer Showing "CCD   -25°C" when it should be showing "CCD  --".   ObsViewer should revert to showing "--" after disconnecting the camera.
    Fixed 2019-01-20 (Code fixed)
   
• ObsViewer Showing "Stars -99" when it should be showing "Stars --".  
    Fixed 2019-01-20 (Code fixed)