×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

DBUS scripting, set radius in setSolverSearchCoords in Align

  • Posts: 41
  • Thank you received: 6
In the documentation, I have seen that the function setSolverSearchCoords has changed.
api.kde.org/4.x-api/apidox-kde-4.x/apido...gnDBusInterface.html

It seems, that the parameter "radius" for this function has disappeared. However, it's still in the argument-list.
void Ekos::Align::setSolverSearchCoords	(	double 	ra,
double 	dec 
)		
DBUS interface function.
 
Sets the solver search area options
 
Parameters
ra	center RA for search pattern, in hours.
dec	center DEC for search pattern, in degrees.
radius	radius of search pattern, in degrees.
Definition at line 3878 of file align.cpp.
dec	center DEC for search pattern, in degrees.
How can I set the radius of the search pattern?
6 years 11 months ago #16138

Please Log in or Create an account to join the conversation.

well, a few of these dbus functions needed some overhaul. I actually just removed setSolverSearchCoords. Long term solution is the ability to set and store options, but for now, you have:

1. setSolverArguments
2. getSolverArguments

so you can use getSolverArguments and then edit it to change radius and set it again. Please beware this is transient only, it is not stored. For example, if the mount is slewed to another location, the solver settings will be generated again from the stored settings. So you will have to set any custom arguments before you call captureAndSolve. Hopefully I will find a way to provide access directly to the stored options.
The following user(s) said Thank You: Meister Wolf
6 years 11 months ago #16156

Please Log in or Create an account to join the conversation.

  • Posts: 41
  • Thank you received: 6
Ok, thanks for the info.
I changed my script to only work with setSolverArguments(), but due to the clouds here I could only test my script with the simulators.

I found something weird coming from the getSolutionResult(). I get some weird results when using this function.

This is an excerpt from my script:
solvedcoord=ifaceekos.getSolutionResult()		#ra and dec from solved
		RA_solved=solvedcoord[0]
		DEC_solved=solvedcoord[1]

This is what I see in the Ekos log when I do a platesolve with captureAndSolve() from the script:
2017-04-14T21:10:26 Target is within acceptable range. Astrometric solver is successful.
2017-04-14T21:10:26 Target is within  0° 00' 19" degrees of solution coordinates.
2017-04-14T21:10:26 Solution coordinates: RA (07h 33m 02s) DEC (-21° 28' 14") Telescope Coordinates: RA (07h 33m 02s) DEC (-21° 27' 54")

This is what my script output produces (from the excerpt from above). The getstatus() produced value 1 (completed).
2017-04-14 21:10:26,394 Returnstatus: 1
2017-04-14 21:10:26,394 Returnstatus: COMPLETE
2017-04-14 21:10:26,394 RA  solved: 90.001477117
2017-04-14 21:10:26,394 DEC solved: 113.075466756
2017-04-14 21:10:26,395 Solve status: 1
2017-04-14 21:10:26,395 Solve function found a solution
Now, according to the documentation, these numbers are the ra and dec values in degrees. But they don't resemble the ra or dec or even the alt/az even remotely. I wonder.. what are these numbers? :blink:

Oh, and another issue, I've noticed that the sync command of the telescope simulator sometimes crashes/blocks. This is when I execute captureAndSolve(), with the setSolverAction(1) set on value "1" (slew). I tested quite a bit for debugging the script and this happened like 5% of the times. Nothing in the indi/kstars logs; except the command sync is issued. Something minor, but maybe useful to know.
Last edit: 6 years 11 months ago by Meister Wolf.
6 years 11 months ago #16198

Please Log in or Create an account to join the conversation.

Time to create page: 0.489 seconds