Script issue

[Jean-Francois]

Hello Jonathan,

One point more ... do you have more than one script in the menu list ?
One of your own coding ?

It is important to understand something ... I needed some time to understand.
If you have several scripts loading in the menu at the start of SharpCap, all are loaded as "one" script.
It is like you copy all the scripts in one file and then load only this file.

If you have several scripts with very different functions but the same name, then you will have problems.
The last loaded function (name) will be used ... by each script.

Other behaviour ... with at the beginning "import xxx".
If one script has a missing "import", but it is loaded after one script that has the "import", then it works fine.
It is not the case if the order of loading is reverse ... you will have an error at the loading of the first script.
This behaviour had made me crazy ! ... on one computer it was working fine, on the second all the time an error.
Only while I loaded the scripts differently.

Regards,
Jean-Francois

[Astrojunk]

Yes, I load up the SHG INTI script on start up too. Maybe it would be easiest to just load them on demand - I'm not going to be doing occultation work in the same session as solar!

I knew you were still working on the occultation script so didn't develop the pre-point code too much as I didn't want to end up with an unmaintainable branch!

As you have spotted, the tracking doesn't stop after the pre-point as the command didn't work. It probably shouldn't anyway as in practice I would do a prepoint, platesolve, prepoint again THEN stop if I were planning on an unattended recording. The initial idea was for a classic drift through observation which meant placing the FoV at the position of the object at the mid-point of the event of course, and that is what it currently does (although I still haven't tested how well it works!). I have been thinking that an alternative would be to restart the tracking for the duration of the recording which would require the FoV to be calculated differently. It's a thought experiment really, I'm unlikely to set up a baseline of unattended scopes anytime soon, but I was part of the SWRi team who put a baseline of 16" Skywatcher Dobs across Pluto's shadow in outback Australia and this script would have come in very handy!

I have a very restricted view in a complex way, so the pre-point has been superb for ensuring I can actually see the target. Fortunately for me, living at -30 degrees places the core of the milky way overhead and gives us a decent number of targets. I started out live at 55 degrees North, so I can quite understand how low things must be most of the time. It was never very dark either in the summer.

[Astrojunk]

I think I'm nearly there. The move to Python 3 has chucked out an issue, or should I say enhancement, with regards to the handling of UTC. Needless to say, the occultation script is heavily reliant on datetime.utcnow() which has been deprecated in favour of datetime.now(timezone.utc). and added to my woes, the date string comes with an added time zone component which needs to be removed (on occasion!) with .replace(tzinfo=None)

All of the other errors that were being thrown out are as a result of this so it's no longer a bug and now a feature

I need to do some live testing and it's unlikely to be clear here for a few days, but will post again when I'm happy that all is back to normal.

[admin]

Hi,

just to note that the very latest version (uploaded this afternoon) now has IronPython 3.4.2 in it rather than 3.4.1 - this may help with some things.

I have also implemented support for 'input()' in the console and updated the code to try to get a Python traceback to display when there is an error inside a custom button handler or in other similar places where SharpCap may handle an error arising from a script.

cheers,

Robin

[Jean-Francois]

Hello Jonathan,

I have a look at the Pre-Point function ... here a small code calculating the pre-point position.
It is not simply calculating the RA coordinate with delta time.
In reality the DEC coordinates change a little bit.

It calculates the pre-point position for a defined target J2000 coordinate and delta time (here 3.0 hours.)
The intermediate step is the Alt-Az coordinates for the J2000 at the event time.
Then it calculates back the J2000 coordinates of these Alt-Az for the pre-point time (in the example 3 hours before event time).

Code: Select all

import datetime
import clr
clr.AddReference("ASCOM.AstrometryTools")
clr.AddReference("ASCOM.Tools")
from ASCOM.Tools import Transform
from ASCOM.Tools.Utilities import DegreesToDMS, DegreesToHMS
from ASCOM.Tools.AstroUtilities import  JulianDateFromDateTime, JulianDateToDateTime
from SharpCap.Base import CoordinateParser, RADecPosition, AltAzPosition, Epoch

t = Transform()
t.SiteLongitude   = 11.8
t.SiteLatitude    = 47.8
t.SiteElevation   = 674
t.SitePressure    = 1000
t.SiteTemperature = 10

event_pos = (10, 20)    # J2000 coordinates of event

t.SetJ2000(event_pos[0], event_pos[1])
print("Event coord.:", RADecPosition(event_pos[0], event_pos[1], Epoch.J2000), " (J2000)")

date_utcnow = datetime.datetime.utcnow()
date_event  = date_utcnow + datetime.timedelta(3.0/24.0)

t.JulianDateUTC = JulianDateFromDateTime(date_event)

AltAz_Pos       = AltAzPosition(t.ElevationTopocentric, t.AzimuthTopocentric)
print("Alt_Az      :", AltAz_Pos)

t.SetAzimuthElevation(AltAz_Pos.Azimuth, AltAz_Pos.Altitude)

date_utcnow = datetime.datetime.utcnow()
t.JulianDateUTC = JulianDateFromDateTime(date_utcnow)

print("Date event  :", date_event)
print("Date now    :", date_utcnow)

prepoint_coordinates = CoordinateParser.Parse(str(t.RAJ2000) + ";" + str(t.DecJ2000), True)
print("Pre-point   :", prepoint_coordinates, " (J2000)")

t.Dispose()

Code: Select all

>>> 
Event coord.: RA=10:00:00.0,Dec=+20:00:00  (J2000)
Alt_Az      : Alt=+48:13:59,Az=118:21:16
Date event  : 2025-08-13 09:11:42.585000
Date now    : 2025-08-13 06:11:42.586000
Pre-point   : RA=06:59:24.6,Dec=+19:54:47  (J2000)
>>>

Regards,
Jean-Francois

[Astrojunk]

Fantastic, yes I could see that the simple offset was too good to be true!

I had a brief night of clear sky and fixed most of my utc issues, the last remaining being what happens if the GPS time is not read - if it is read the script is fine fortunately.

[Jean-Francois]

Hello Jonathan,

I'm working a little bit on the Pre-Point in my script.

I have today without additional function:

Occultation_PrePoint_test.jpg (54.86 KiB) Viewed 845 times

It is similar to the "Capture" tab, but with some differences:

• the idea is that the telescope can wait at a park position until the unpark time (delay before the start of the capture)

• if not at the park position, then the telescope is waiting at the event position without tracking

• it is not clear if the observation will be done with or without the tracking. With a motorised GOTO telescope, it has no reason not to use the tracking.

• in this tab, the script will do more automatic processes:

- move the telescope to the target position
- perform a Plate Solve and centre the telescope
- maybe adjust the exposure time or gain of the camera, depending on the background illumination or other parameter (S/N)


If you have other idea, please say me now.

Regards,
Jean-Francois

[Astrojunk]

That's looking really good.

Pre-pointing brings so many complexities. The simplest is the traditional, non-motorised set and forget drift through style which is a positional offset from the current time.

As you say, why do a drift through when you have a drive? and I agree. The modern version of the pre-point can well re-animate the scope at a prescribed time before the event with the target centrally positioned. That way we get the benefit of not relying on tracking or guiding to stay on target for several hours unattended, which is particularly difficult with a dobsonian, yet having an easier capture file to analyse of the event itself.

That second method seems to be the better, especially for permanent sites, but introduces the risk that a user may prepoint at the drift through location then swap methods to the point and track method and in the process forgetting to re-position the scope, something to be wary of.

I haven't much considered altering exposure and I have always stuck to 300 gain or 10 bit. It seems quite high but was on recommendation by Marc Buie who also noted that binning could usually rescue a change in circumstances. My greatest issue at the moment is the persistent dampness of the rain forest behind me which clouds my corrector quite quickly - I may have to double or triple my dew straps and really cook it!

[Jean-Francois]

Hello Jonathan,

My idea is to have something a little bit more automatic.
And maybe a first step to finalise the "List" tab in my script for the automatic observation of several events.

The PrePoint can be used without a motorised mount.
I need to add the code for testing the presence (or not) of a motorised mount.
But the main use is with a motorised mount.

What I will try to program is to set the observation in advance and then the mount/telescope/camera will do the job later.
My plan is to have two observation location ... one at home and a second mobile.
The home mount/telescope will then check the position and the capture parameters before doing the capture.
If the target drift, then it will be recentred. If some thin clouds appear, then the camera could change some settings (in +/- defined range) .

Yesterday I code all the timer (one additional "Unpark" countdown timer).
One small problem seems to appear ... not all mount will have all the ASCOM functions.
Example: for SkyWatcher mounts ... SynScan and GSS drivers have a SlewToAltAz() function, EQMOD has not this function (yet).

If an automatic cover is installed ... it could be opened/closed by the script too, what can help to keep the corrector/lens dry.

Jean-Francois