Hi all,

I have just pulled and re-compiled the latest code of indi. And the good new is that the latest commit on the indi repo (d3e66830369ca1b569119e0e92f0680c4717e791) seems to have fixed the issue. Using either Ekos or CCDCiel, I have been able to capture images with my QSI camera.
Warm thanks to those who made that happen.

Dahu

Read More...

Hi Jasem,

Here are the logs. As far as I understand, there is a segmentation fault somewhere.

Best regards,
Dahu

PS : ekosdebugger is really a helpful app. Thanks for that.

Read More...

Hi all,

Having recently upgraded my pillar PC to Ubuntu 22.04, and updated the indi packages accordingly, I am currently facing a blocking issue with the indi_qsi_ccd module : it always crashes at the end of image acquisition. The camera (QSI-632) seems to work correctly, as I can see the shutter open and close for the scheduled duration.

To make sure, I have also compiled the indi library and its third-party modules, but I get the same faulty behavior. and I also get the very same error when using the CCDCiel indi client.

Maybe related, there is another issue, as the log reports :

Error: put_BinX() failed. 0x80040409:Invalid Bin Size.
I have wiped the "QSI CCD_config.xml" file to get a brand new one, but no luck.

Attaching a few logs just in case.
Dahu

Read More...

Hello Wildi,

Thank you for having looked in depth at my logs. I have done some more trials.

Regarding the "Can not change park position while slewing or already parked..." error issue, it happens ... or not. I mean, either there is no error, and writing park data works correctly. In the opposite, if this error appears, then there is no way to workaround it, even by waiting for minutes hoping for the mount to "stabilize". I suspect that I felt in the "noisy" value trap. Maybe a "if (dx < 1e-3 && dy == 1e-3) " parking condition may fix that, or something similar.

For the Park3 final issue, I have not been able to reproduce it clearly. So we may forget about it.

Regarding the timezone, all my set-up (PCs, software, AP mount handset, etc..) is always set in UTC time. This simplifies greatly all the configuration. The AP sidereal time is identical to my software ones, no inconsistency.

Kind regards,
Dahu

Read More...

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

Read More...

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

File Attachment:

File Name: indi_lx200ap_experimental_142029.log
File Size: 13 KB
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

Read More...

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

Read More...

Hello wildi,

Thanks for your answer. I am located in the French Alps area. So East longitude (approx 6 deg E) and North latitude (approx 45 deg N)
Best regards,

J.

Read More...

Hello wildi,

Using a GTO CP3 with a recent firmware (V2) driven by the AP experimental driver, I see 2 problematic usecases that should be considered and fixed (if possible, of course) :
- Case 1 : The mount is initialized and properly set (precise time and location), and the Park positions are processed by the driver. Slewing to Park3 position is fine. Then I slew to a real star, far away from the celestial pole to improve the precision. I sync the mount on that star. Re-slewing to the Park3 position, the mount does not come back this park position, but may be off by many degrees. I suspect the Park3 error is the same as the star position error before I sync the mount. So maybe park positions should be re-processed each time the mount is sync'ed.
- Case 2 : A star is located in the eastern hemisphere, not very far from the meridian. By that time, I properly initialize the mount. As I want to track this star whenever it is in the western hemisphere (so after it has crossed the meridian) I just sit and wait until say 15-30 min after the actual crossing (to make sure the crossing has occurred). Then, if I slew the mount to that star, the mount moves to that star, but goes on the wrong side of the pier, with the counterweight up. Maybe the mount internal time is not updated, or ... I do not know. If, after this sequence, I restart the entire Ekos process, re-initialize the mount, slew to that star, then the mount behaves normally by going to the correct side of the pier.

I hope my explanations are clear enough. It would be fine if you could reproduce and fix these issues.
However, thank you for your time and good work.

J.

Read More...

Hello,

Using the Astrophysics experimental driver, I would like to slew my AP900 CP3 mount to a star located in the south-east part of the sky (say 10 degrees east of the meridian), with the counterweigth somewhat above the scope, so that when the star crosses the meridian, the counterweight will move lower than the scope, with no need of a meridian flip, and no disruption of the imaging session. I can do that manually using the handset (AP documents that feature very neatly), but would like to use the indi driver to achieve the same.
1- Using the Indi gui, one can set a meridian delay decimal value. What is the unit of this value ? Hours, tens of degrees ?
2- Apparently, the value are constrained between 0 and 3. So which correct value should I enter to move the 'apparent' meridian to 15 degrees east of the real meridian (i.e. one hour of HA angle) ?

Regards,

Jacques

Read More...

Dahu replied to the topic 'Initialization of Sesto Senso' in the forum. 3 years ago

Here is the requested screenshot.



Read More...

Dahu replied to the topic 'Initialization of Sesto Senso' in the forum. 3 years ago

I can confirm that this new flavour of the driver works very well, including the initialization procedure.
I noticed the temperature is only displayed if the sensor is plugged, which seems logical. And it is updated every 10 seconds or so.
Thanks a lot for that great work.

Read More...