Hi Ake,

I am running the same hardware as you apart from I am using the latest KStars/indi/ekos nightly build running on RPi4 8GB under Ubuntu 21.04.1 rather than Stellarmate
Parking is still an issue with CEM40 in that the indi gui will show that the mount is parked but ekos shows it is unparked (when in reality it is parked). Pressing park gives a log report that the mount is slewing but no movement occurs even when the mount is away from the parked position (i.e. unparked and tracking). I get around this by using the "go to home" function in the indi gui and this does the same as park.

In my set-up it is possible to take images in the parked position and when not tracking. Everything appears to work well on the current nightly build.

Hope this helps.

Mike

Read More...

I had this problem too and blamed it on a new camera that I was testing. I was not even able to start the PAA process as "start" was greyed out. My FOV was much larger than the minimal FOV so did not make sense.
I was running a nightly build. The next day (26th Sept) I updated the nightly build and tested using my normal camera and at least the start button in the GUI is usable to start the automated process. However the FOV disabled warning persists.
Unfortunately I have not had a chance to test it in the field.
As the latest updates have not resolved the erroneous FOV related PAA disabled warning, the problem is not solved.
Cheers

Read More...

Hi Marcel,

Ok so I am currently running KStars/EKOS/indi build 3.5.5 Stable 2021-09-15T22:15:10Z this is on a raspberry Pi4 8GB running Ubuntu Mate 21.04.1 (Hirsuite Hippo) all updated and upgraded today and I am testing indoors as the weather is changeable.

A good change to the mount behaviour is that you can now power all of your equipment up and connect it all at the same time, mount included. You do not have to wait till it fails to connect anymore :). The mount GUI now pops up fully loaded and connected in the indi gui mount tab.
Ensure that your "unpark from" and "park to" fields are correct for your current mount position (I use park 3 for both). Ensure that KStars is taking your location from whatever source you have decided as the mount will not unpark until this is known. The source of this info can be set in the indi options tab in the KStars settings menu.
Click cold start (the gui popups will warn you about setting parking and about location if this not set.)
Next click "unpark". The mount icon will then appear on the KStars planetarium.

It is normal AP experimental driver behaviour for the mount to stay in the "not tracking" state until you click "track". If you do not do this you can still slew to an object but unless you have started tracking before the slew you will need to start tracking after the slew. Again this is expected behaviour from the driver. Tracking does not occur automatically after a slew unless you have started tracking after unparking in which case tracking will continue until stopped or turned off. I hope that made sense :).

I have not been able to reproduce the odd loss of mount connection you are experiencing but I will leave the mount tracking for a couple of hours to be sure. All I can think of to explain your mount disconnection is that it is important to use a powered hub for all connections. I have mount, scope camera and guide camera, GPS, flip flat and motor focuser all plugged into a USB 3 powered hub and this then connects to the Raspberry Pi4 USB3 port. I have nothing else connected to the Pi so all that gear connects through the single USB3. If your mount is connected direct to USB on your computer I would use a powered hub and see if that helps.

I will have another look through your logs but I could not see anything obvious on a first scan through.

Regards

Mike

Read More...

Hi Marcel,

Glad to hear that upgrading the firmware improved the mount behaviour. The last time I tested the mount I noticed that the start up behaviour had changed likely related to changes in the build. It not longer seemed necessary to start the profile with mount switched off. However, I had intended to do another test today so will update the start up instruction and see if I can replicate the problem you are having. I'll have a look at your log and get back to you.

Mike

Read More...

Spartacus replied to the topic 'Pedestal value for light files.' in the forum. 1 month ago

Hi
That is very interesting. I am using PI 1.8.7 and therefore a earlier version of the WBPP script and have never encountered this info pop up warning. Lenny, what version are you using?
Mike

Read More...

Spartacus replied to the topic 'Pedestal value for light files.' in the forum. 1 month ago

Hi Lenny,

You could be right that light leakage may be the problem. You should be able to spot this easily in your master dark by stretching the image.
I usually perform my darks in a more controlled environment and build up a library of master darks for all the usual exposure times that I use. I am consistent with the temperature that I use (-10) and always use the same gain and offset etc. So this makes a library of master darks pretty convenient and allows more time to concentrate on getting enough lights flats and dark flats etc. Using a cooled camera also makes this really easy.
Good luck

Mike

Read More...

Spartacus replied to the topic 'Pedestal value for light files.' in the forum. 1 month ago

Hi Lenny,

I am not familiar with the scripts that you are using. Maybe my version of PI is a bit old :).
I am always a bit cautious of scripts especially batch pre-processing as if something goes wrong it is difficult to track it down.
I think that the problem is likely related to mismatching between lights and darks (you don't mention if you are using flats as these can introduce problems too). As Wouter suggests things like offset values being different can create the problems that you are seeing.
I think that pedestals can be useful to prevent clipping but clipping often is caused by problems in calibration. I have never found using a pedestal to help much in my image processing.

You may need to give more info. Is this a new problem? e.g. related to a change in your workflow or related to a new piece of equipment e.g. your quad band filter. Or has the camera always been associated with these issues?
The supplied image certainly looks strange. This is a single calibrated light frame, yes? Let us know how you process your darks in terms of calibration, gain, offset and exposure (are these consistent with your light exposures?). Do your uncalibrated light frames show any of these issues?
If the camera is new and this has been a problem from the start check Cloudy Nights or Stargazers Lounge as there may be other users who have encountered these problems and have solutions.

Mike

Read More...

Hi Jasem,

My CEM40 used to park OK so not sure why this is no longer the case. However, while the go to home position works just as well, it doesn't interfere with my imaging sessions. :)
Thanks for all the hard work that you do in making KStars such a great imaging platform!

Mike

Read More...

Hi Jasem,

Interestingly I was testing my CEM40 tonight (I set the flip to occur at 0.2 HA past the meridian). The counterweight settings were as default (e.g. normal). The flip occurred as expected once the current exposure was finished. The flip went well and then alignment solving occurred then guiding and restarting of the exposure sequence as expected.
The only issue I have is that the park command no longer seems to cause the mount to park so I use the go to home position which then seems to be interpreted in EKOS that the mount is parked. I thought that this was related to older firmware but the behaviour persists even after upgrading the mount firmware to the latest.
However using the "home position" works just as well for me.
Hope this helps.

Mike

Read More...

Spartacus replied to the topic 'Pedestal value for light files.' in the forum. 1 month ago

Hi Lenny,

You put the pedestal value at the calibration of lights and make sure that the box to subtract this is ticked at integration ( I think) . However I think that it is unusual to need to use pedestals.
I would check that your darks have been integrated correctly. I have found that it is better to integrate darks uncalibrated and as these contain the bias signal there is no need to use a master bias in lights calibration. So try using uncalibrated darks and no bias and see if this makes the difference. I have never found that it is necessary to use a pedestal since I have been using uncalibrated darks.
Just a suggestion.

Mike

Read More...

Hi All

I came across these excellent videos outlining in detail how to set up EKOS/indi and Web Manager under Linux, Ubuntu and Windows. The videos can be accessed on Chris Kovacs webpages. They are great for beginners to help with set up and take a very slow hands on approach.
There are 5 videos in all. I think that they are a great resource for anyone thinking about using KStars etc. They were released in June this year. I could not find any reference to them on the forum so thought I would post this to make users aware of the resource.
Here is a link to the first in the series 
www.youtube.com/watch?v=9Az3FxM8v48&t=20s

Cheers

Mike
 

Read More...

Spartacus replied to the topic 'Starters Guide to ASI294MC Pro' in the forum. 2 months ago

Hi Paul,

I think that you are viewing your flats in the fits viewer in a stretched and automatically debayered form. If you open up "configure KStars" and open the "fits viewer" tab. There are a number of options. It is likely that you have auto debayer ticked. Uncheck this and you should be able to view the flats in mono, just auto stretched. This will give a better idea of what they look like. Remember that the flats are never used in a debayered form so the red cast is irrelevant. Just stacked into a master in undebayered form. Your vignetting will be dealt with in the calibration of the lights with the flats (and darks).
The fits viewer just views the images but does not change them so you don't need to worry that there is a problem. You can still use the flats that you have taken. I have never examined any of my images using the autodebayer in fits viewer as I find that it is not as helpful as a mono image in determining contrast and exposure.
All my final calibrated and integrated lights have a prominent red cast but this can be dealt with in histogram transformation. As I said, a quick way of fixing this in the final image is doing an autostretch using unlinked RGB channels. This largely removes much of the redness.
You may be able to attract more help in relation to the use of APP with this camera if you were to start a new thread with the specific problem in the heading. Using the sticky does not really address your specific problem. It may be worth posting a final image pointing out the issues you are concerned about.
I just can't help much with APP and how it handles calibration etc. Happy to advise about KStars related issues though.

Cheers,

Mike

Read More...

Spartacus replied to the topic 'Starters Guide to ASI294MC Pro' in the forum. 2 months ago

Hi Paul,

I use a DIY electroluminescent panel and needed to use 6 sheets of white paper to reduce the levels to allow for a exposure of 3 secs approx. Any filters that you use in taking your lights should be used in the flats. As an example I tend to use a ZWO duo narrowband filter as I am in an inner city location.

All my darks and flats and flat darks are taken with 120 gain, 30 offset and 50/50 balance which are my default values for all my light frames. I seem to recall major problems when I used darks with different offset values to the lights. This did cause a red cast that I could not process out so I keep everything standard now and have not had any issues since.
I tried to use APP a year back and could not get it to work satisfactorily and if I recall I did have issues with the flats. In the end I gave trying to get it to work as I already was using Pixinsight and had spent some time getting over the steep learning curve of this software. I just did not have the time to invest in APP.

I have never needed to examine the individual colour balance of flats as all the calibration is done before debayering and it never seemed important. The resulting images after calibration and integration of light frames always have a prominent red cast but this is easily fixed in histogram transformation. You can check this by doing an auto stretch using unlinked RGB channels.
Have you tried processing your lights without using flats and do they look OK?
Hopefully someone using APP and familiar with how it works can help.

I found the tutorial by "Bulrichi" that I have referenced in the guide a great help in understanding the camera and how calibration works. However I had to read it a few times to really understand it fully.

Cheers

Mike

Read More...