×

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

Bi-monthly release with minor bug fixes and improvements

Astro-Physics Experimental driver not working properly in KStars 3.4.2

  • Posts: 24
  • Thank you received: 3
Hi Wildi,

Using the cold_start_part1.sh script, and then running the 2nd sequence of tests on my AP900 (GTOCP3, V2 firmware), everything went smoothly, the Park2 and Park3 positions were correctly computed, and the HA angle and the sidereal time were as expected. However, as I am located in the Eastern hemisphere, my test may not be that relevant.
The only thing I could not find in the Indi GUI is the 'Startup' entry. Or is it just a step note to indicate what is going on in the sequence ? So, to workaround this miss, I just wiped the previous ParkData.xml and Astrophysic_Experimental_config.xml files. And let the driver recreate them during the test sequence.

Thanks for the good and promising work.

Dahu
3 years 7 months ago #57767

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

  • Posts: 59
  • Thank you received: 19
Hello Dahu

I welcome any location and report, thank you. This time I specifically wanted feedback for the park positions.

I'm disturbed by your remark that you did not see the Startup Cold, Warm buttons. I attached a screen shot.

Script cold_start_part1.sh copies finally the files to $HOME/indi_cold_start/build and there in you have to execute

./indiserver ./indi_lx200ap_experimental

After that connect with KStars. There is no need to execute cold_start_part1.sh if you can

cd $HOME/indi_cold_start/build

Please let me know your findings, kind regards, bye, wildi
3 years 7 months ago #57788
Attachments:

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

  • Posts: 24
  • Thank you received: 3
Hello Wildy,

Good news, I have sorted out the Startup Cold/Warm issue. I was using Kstars+Ekos, and apparently, the Ekos Indi GUI does not contain this Startup option (maybe, this GUI may be run from a hardcoded location). Switching to CartesduCiel ou Kstars without Ekos fixes this issue, I get the right GUI. So back on rail. But I see various issues :
1- Going through the test sequence, I see some difference in the mount icon location (step 1-6), which is at azimut 87, and elevation -3. Is that considered as negligeable or not ?
2- Also, in step 2, I see a 15 min difference in the sidereal time. I have checked with both Stellarium and CartesduCiel, to make sure I make a valid comparison.
3- And when I run step 6.1, the mount moves by a few degrees. As the mount was supposed to be very close of the Park2 position, I was expecting a very small or negligeable movement.
To eliminate any remnant in the xml file, I have wiped them and re-start the test sequence several times. Same results.

In case that helps, I join a driver log file that mainly covers steps 1 and 2.
Thanks,

Dahu
Last edit: 3 years 7 months ago by Dahu.
3 years 7 months ago #58052
Attachments:

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

  • Posts: 59
  • Thank you received: 19
Hello Dahu
Yes, of course, it fetches the drivers from /usr/bin if not otherwise told.

Since I never saw that please send me the log. Did you read that on the driver's GUI or are these values from e.g. KStars?
This might explain the position difference seen under 1. If sidereal time is wrong, then every position is wrong. Sidereal time depends on location an time both obtained from KStars. I often saw differences of several 5 sec but never 15 minutes. That can be clarified looking at the log.
In step 4) the mount is moved a few degrees and in 5) Main Control 6.1) Parking Park(ed) the mount moves back to where it started after unpark.

Just in case in you have to redo the log, specify under Options all levels.

Thanks for testing, kind regards, bye, wildi
3 years 7 months ago #58056

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

  • Posts: 77
  • Thank you received: 16
Hi Wildi,

I was able to run the second set of tests last week. The procedure ran successfully with the expected results as described in your post.

In my current use case I will be parking to and from the Park 3 position most of the time.

Will you be restoring the Pier Side information as in the original Astro-Physics Experimental driver?

Until your driver is completed may I suggest that the original (previous) Astro Physics Experimental driver be restored in the bleeding edge Git so we have a functional driver until this one is completed. In fact with such a major rewrite of the driver it should have been carried out using a different name and file. At present, I compiled the Michael Fulbright version driver from an earlier INDI (1.8.4 I think, however I need to confirm that) in order to be able to use my equipment with the latest KStars/Ekos . I am using this driver with KStars 3.5.0 Beta as compiled from Git a few days ago. This combination has given me the best and most stable version of the software I have used to date. I have used KStars/INDI/Ekos software since 2016 successfully many times, however this hybrid version I made now works the best so far.

I am grateful you are working so hard to polish and enhance the driver and I will continue to help test this when I am able. My mount is now back on the pier outside so it will be a bit harder to accomplish but will do as I can. Many of us were/are using the Michael Fulbright version of the driver very successfully in fully automated runs for many months, therefore please consider my advice above.

Thank you for all your work!
Last edit: 3 years 7 months ago by Midwest Astronomer.
3 years 7 months ago #58101

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

  • Posts: 59
  • Thank you received: 19
Hello LinuxUser

pier side is back. You can use script cold_start_part1.sh to fetch/compile it from my repo.

You wrote that you completed the procedures successfully. Beyond that did you observe any failures/glitches?

Michael Fulbright's version worked only West of Greenwich but not East as Spartacus pointed out in this forum. Since files lx200ap.cpp and lx200ap_gtocp2.cpp contain the same error:

if (setAPUTCOffset(PortFD, fabs(utc_offset)) < 0)

I'd like to clean up the code and unify the driver for all GTOCPX and firmware versions (I still use D) as my next task.

Concerning renaming/checkout an earlier version I can not do much. That's up to Jasem. But if the current bleeding edge driver does not fail I'm recommending to keep it.

Kind regards, bye, wildi
3 years 7 months ago #58144

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

  • Posts: 77
  • Thank you received: 16
Hi Wildi,

Thanks for adding pier side back to the driver. I'll use your script as usual, fetch/compile and test. I will run with logs and note any difficulties if I have any.

I understand that Michael Fulbright's version does not work East of Greenwich, however in order to get some imaging done I went back to what works for me here until your new driver is at a working stage. I will also fetch and compile the latest bleeding edge KStars/INDI and test with your driver there and let you know how it goes. I have SD cards specifically for this type of testing so I can keep my "production" version as is.

I hadn't realized the Greenwich/UTC error was in other lx200 code bases, however this would follow since the Experimental driver hooks to the lx200ap code set. It is good that you are cleaning and unifying the driver.

Jasem mentioned in a reply to me in another post here indilib.org/forum/ekos/7460-kstars-3-5-0...ion-issue.html#58121 about your driver merge in Git so as mentioned above I will also test this. Again, you are correct that if this bleeding edge driver works then let's keep it.

Thank you!
3 years 7 months ago #58149

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

  • Posts: 77
  • Thank you received: 16
Hi Wildi,

I tested the latest Git including your driver there. The logs are attached. Here is the test and outcome:

1. The mount is turned on and ready. The bluetooth to serial interface is on and connected to rfcomm0.
2. I select and start my test profile in Ekos (Astro-Physics Experimental driver and simulated CCD)
3. Then connect to the profile which connects the mount and CCD
4. The driver connects and properly identifies my GTOCP3 and V2 firmware
5. On my first start I do a "Cold" initialize
6. Set unpark from as Park 3, set Park To as Park3
7. Try to unpark the mount and just get error message about parking first, etc. (see logs)
8. After several attempts I am unable to proceed. Cannot get past the error messages.
9. I did try to do a goto several different times, however the mount just did not move.
10. Perhaps the mount is not initialized properly or ? (I do not see any messages in the INDI driver window about initializing. I do get this feed back from the old driver such as mount initialized and the site location and time was sent to the mount.)

I wasn't expecting this fail since my earlier tests on your driver completed OK.

I did not test your latest driver with the pier side information added although I did pull it from your Git using your script.

I hope the logs will help to identify what is happening.
3 years 7 months ago #58216
Attachments:

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

  • Posts: 24
  • Thank you received: 3
Hi Wildi,

I have re-run the entire test sequence #2, and things go better as, this time, the driver sidereal time was in sync with some independent sources. I cannot figure out what is different from my previous test run that may explain that fact. Kind of a mystery for me.
However, I still see 2 glitches :
- In step 5.2, when writing the park position data, the driver returns a "Can not change park position while slewing or already parked...". Despite the mount was not slewing nor parked, it was in tracking mode.
- After the last step (I.6), I parked the mount (to Park3) just after having unparked it from the 'Last Unpark" position which was supposed to be the Park3 one. So I was expecting the mount to move for a tiny movement, but it slewed by a few degrees (5 or 10 degrees, hard to evaluate precisely). May this related to the issue I got in step 5.2 ?
I attach the 3 log files (with full options) for each 3 sub-test sequence in case that helps.
Thanks for your time and dedication,

Dahu
3 years 7 months ago #58257
Attachments:

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

  • Posts: 59
  • Thank you received: 19
Hello LinuxUser

I'm digging into your logs today.

Kind regards, bye, wildi
3 years 7 months ago #58270

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

  • Posts: 59
  • Thank you received: 19
Hello Dahu

I found this message only in log file with timestamp 154110. To your surprise the driver was indeed still in state SLEWING although I'm sure you could not see any physical movement. In the log

DEBUG 131.307478 sec : Slewing... currentRA: 19.1491 dx: -0.000361111 currentDE: 6.43194 dy: 0

dx is always non zero while dy is. Looking at the condition when slew is considered complete:

// Wait until acknowledged
if (dx == 0 && dy == 0)

If important: this line is still and was there before I began (see commit 91438a0eda6d87bce96b06afda9ce2432b52f475). What me makes feel uncomfortable are the lines

double dx = lastRA - currentRA;
... a bit further down
lastRA = currentRA;


which indicate "noisy" value(s) at every readout. The dx values corresponds to about 19.5 arcsec.


In the logs I find only unpark/park from/to park 2 (two).

Reading file 154110 I conclude that there was no valid park data present (ParkData.xml) and the mount unparked from park 2 (Az=90, Alt=0, RA = 19:42:16 Dec 0:00:00). Then a slew started to RA=19:07:47 and Dec = 06*25:55. When you say "tiny" what did expect?


I found the line

Set UTC Offset 0 as AP UTC Offset -0 is successful.

Since you live in CET/CEST this value must be -2 currently. On what kind of computer is the driver running? Did you set timezone correctly? Was AP's sidereal time correct?


Could you please post the log file of Ekos, because there is the absolute date/time available instead of the relative as it is in the drivers log. That helps me to debug time zone issues. You'll find it under .local/share/kstars/logs.

Kind regards, bye, wildi
3 years 7 months ago #58285

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

  • Posts: 59
  • Thank you received: 19
Hello LinuxUser

I checked the log and found that that the status read back from the mount is from the beginning always

*1*99000210P000

instead of:

*P*00000210P000

The latter is the status Parked. Did you power cycle the mount controller before doing this test?
I checked the first mount status read out in about 70 log files and none has the above value 19...

If during Unpark(ed) an error occurs you'll see these messages and finally if it was successful, too.

Kind regards, bye, wildi
3 years 7 months ago #58293

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

Time to create page: 0.528 seconds