> Mr.Jathm

I think Barker's script is useful for adding a parking function to a mount without a Park function.

Currently I use AdvancedVX (hand controller serial) with CerestronGPS driver.

There is no Park function in the hand controller function of AdvancedVX, but the Park function can be used with the INDI driver.
(The hand controller has home commands and custom home settings, but the driver does not have that setting.)

The park function needs to set the latitude and longitude of the current position, the park position of the mount, the alignment information, the current time and the tracking function to off, but the setting of the INDI driver inputs the latitude and longitude information It is that. Celestial body.

It is very dangerous to set a park point using only absolute position without alignment information, latitude / longitude information of current position, current time information.

There is no problem if the driver has the information necessary for the park function like EQMOD, but for drivers who do not have the parking function on the hand controller, I think that problems will arise in the current park setting.

> Jathm

Another mount I use is the SynScanAltAz driver that uses Skywatcher Virtuoso, but this driver will not work until I press the ParkOFF button, but pressing this button moves the mount in an unexpected direction. (I am pushing the stop button immediately.)

Even if you press the park button, unexpected movement will occur. . .

I want to operate the system immediately at home position (Arctic), but I can not set the park's initial value from the driver.
(Everything except the Park function works well)

One idea,
Can I set the EkosPark function based on Mr. Barker's script by excluding the parking function from the mount driver that does not have the park function?
Ekos has an alignment model, and we can also acquire the relative position of the mount from Kstars, so I think we can realize a trouble free park function.

In order to realize the park function at the driver level, I think that it is necessary to add the Park function of the EQMOD driver to other drivers.

Sorry for delayed reply it was clear here so priority went to photon collection!

Firstly Jasem,
The SS2K serial commands I used to 'park' (since park doesn't exist only 'Land') are in the code extract I gave in #28610 which works but needs more tests, the LX200 codes are published online (i.e. github.com/syntheticminds/raspberrysky/blob/master/telescope.py.

Here is key points extracted from my code:-
command = "#:AL#" (set mode to Land)
command = "#:MA#" (slew to AltAz coordinates previously given )
command = "#:Q#" (halt the scope) followed by with "#:hN#" (like sleep)

Even if I get this code working/hardened it requires dedicated serial connection using pypi serial, so its not a good INDI solution, hence I'm trying to implement using pyindi. I'm having some ON_COORD-SET Switch issues that I'll send in separate post for checking.

For T-studio,

I'll keep working on a PyINDI solution with my skysensor and simulator setup, if I get it working and hardened we can work on how to integrate it but at present it requires these things:-
a. A know 'park' position to be input in AltAz coords (dms)
b. The precise geodetic EarthLocation (gps, with elevation, locatime is converted to UTC by code)
c. mount setup in accordance with b (obviously will fail if mount thinks its somewhere else, as you say it's dangerous)

> Mr. Barker

In order to start normally even if the power is turned off, I think that the following information will be needed in addition to Mr. Barker's information.

· Mount type (Equator mount or Alt Az mount)
· Home position (mount source information)

In the current INDI specification, regardless of the mount type, only parking position information exists as parking information.
(Park registration information does not exist for each mount)

I am at INDI,

· CerestronGPS (AdvancedVX)
· SkyWatcher Alt-Az (Skywatcher Virtuoso)
· Digital Setting Circle (Homemade BBox)

If you press the park button, the position information will be damaged and it will not function properly.

Oops, since it is ground coordinates, time information on the current location is also necessary.

Since the setting information differs between the driver connected serially from the hand controller and the driver directly connected to the mount by serial, it is described below.

● For a driver to be connected serially from the hand controller

· Mount type
· Latitude and longitude of current location → Send to hand controller
· Time of current location → Send to hand controller
· Location information at park (ground coordinates from home position)
· Home position (origin information of telescope, linked with park information and ground coordinates)

When unparking, the latitude and longitude of the present location, the time of the present location are sent to the hand controller, moved from the park position to the home position, registered as a hand controller as a home position after movement. The motion of each axis is linked with the star map according to the mount type.

Then use the hand controller to perform alignment operation.

If you can not perform alignment with a hand controller by remote operation, we will perform alignment with Ekos mount modeling.

● For a driver that connects directly by serial

· Mount type
· Latitude and longitude of current location
· Time of current location
· Park location information (ground coordinates from home location)
· Home position (origin information of telescope, link between park information and ground coordinates)

When unparking, move from the park point to the home position, set the reference point of the mount, and link the motion of each axis to the star map according to the mount type.

If you can not perform alignment with a hand controller by remote operation, we will perform alignment with Ekos mount modeling.

Additional notes
It is even better if alignment information can be recorded, but it will be difficult if the mount can not read the alignment information.

HI Jasem,

I'm still working on getting pyindi basics working to simulate a 'parking' in mounts without the function.

As you know with python serial I got simulated park working with my skysensor using lx200 codes.

I couldn't get pyindi to work. After many debug cycles I reduced the issue back to telescope_on_coord_set switch explained below.

I attach the debug code (.py as .txt) its focussed on the 2 commands:-

1. telescope_on_coord_set[0].s = PyIndi.ISS_OFF # or ISS_ON
2. indiclient.sendNewSwitch(telescope_on_coord_set)

I attach the output using simulator. You can see the switch cycle ON - OFF but I see no effect in the loop showing RA,DEC. I expect when track ISS_ON to show repeated same RA,Dec values. I get same result in both simulator and real skysensor both local and server.

Could you have a quick look to see what I'm missing?
Andrew

Ok, let's take this a step back. The problem is this: Some mount controllers do not support parking/unparking command natively, so the driver has to implement its own parking functionality. Is this the issue? If it is, then it is easy to solve for the most part as such functionality is already incorporated into a few drivers with no "native" parking support.

Yes Jasem, that is the root issue.
For me park is required to get to a fixed point to take flats and let the scope 'sleep', for other there are different reasons.
Andrew

So I added preliminary parking functionality to the sky sensor driver. After installing the nightly PPA tomorrow you can test parking. From KStars, select a point to park to from the sky map, and you should have an option "Slew to and Park here". After parking, it is set to LAND mode so hopefully that is enough to stop it from tracking. Try then later to unpark, it should put it to EQUATORIAL mode. I'm not sure if any of this would work so give it a go.

Mr. Jasem

Rather, the opposite.
Installing a park on a mount without a parking function will not function safely unless the above items are satisfied.

Otherwise it will be a very dangerous function.

My SkyWathcer Alt-Az is currently not working properly with both park and park off buttons.
The initial park setting of the driver is not functioning properly.
If you press the park button, the controller operation will not be performed properly.
So, I use it without using the buttons in the park.

The most problem at present

1. INDI has only one park setting file. (Using the same configuration file for EQ mount and Alt - Az mount is a source of trouble.)
Each driver needs its own park setting file.

2. The home position as the reference value is not registered in the park file. (I think that calculation is required for each of EQ mount and Alt - Az mount.)

The mount that the park normally uses memorizes the necessary information of the hand controller, so you can safely use the park function.
(I think that EQMOD has the information stored by the hand controller by software.)

As with Barker's suggested script, the driver needs to have information that can use the park safely.

The number of people using INDI, Ekos will increase more and more in the future.

Many of them expect to introduce it in expectation of a complete remote environment.

If you use a mount without a parking function, using this function increases the possibility of destroying the mount.
(If trouble occurs using the park by remote control, it is after trouble occurs that it notices ...)