yeah it is still happening for me. I've given up and ended up creating my own Python script that I use in a preprocessing (did that a while ago when the bug appeared). I've improved the script since a few times. I will push it to my GitHub account over the weekend as I'm now happy with it. It's Pure Python and the only packages it uses is argparse and astropy. I just want to document it and put an open source license on it and the repo.  I'll post that here. Though I wish the issue didn't exist.

 

Read More...

Hey Jasem,

So I can't reproduce this on my x64 Linux server, not even on the public 3.5.4. However, it still doesn't work on the with my RPi 4 running a 64-bit Linux, it sounds like it could be potentially a race condition.

My x64 server is has a AMD Ryzen 5 3600X 6-Core Processor, so it has 12 threads, and it has 32 GB of memory.  My RPi has on 4 GB memory.

Read More...

Hey Jasem,

Definitely not working on a RPi with the build. I did a complete rebuild using your branch. I tried from both the Scheduler and Capture modules. If I've not used the FW it fails to add the filter on the first images in the capture sequence. After the FW has moved it adds the filter.

I will have to double check on my x86_64 server to see if this exists there or if it's a RPi4 thing.

If you can tell me how I can snoop on the XML requests to the INDI server I might be able to capture those and attach it to this thread.

Cheers
Will

Read More...

Sorry Jasem, maybe a false alarm. I just double checked the directory where I did the build and the git repo was pointing to master not your branch. I will do a new build and try again. Hold tight

Read More...

Jasem,

I tried a from that PR branch of yours, still not working. I can recreate the problem.

If you can tell me what I can do to capture verbose logging of what is happening between KStars and INDI that might show what is happening. I have debug logs on but to see the XML requests going through might help.

Cheers
Will

Read More...

Terry,

Best way around this is to make sure the EFW is in a different spot to what is needed before starting the run.

Read More...

Hi Jasem,

Thanks for the fix. I will try to do an engineering test later today. I will have to do my own build since I'm on ArchLinux/Manjaro at home.

Read More...

Jasem,

For me it always adds the FILTER header when I use the Capture module to do a preview.

This weekend I was able to recreate the issue 3 times in a row doing the following:
1. Take a preview image from the Capture Module with a filter (for me this is my Lum in slot 1).
2. Using the scheduler run a job that would use the same filter as just used in preview mode, submit the job.
3. Any of images that start in the sequence that have the same filter for the preview end up with NO 'FILTER' header in the FITS image. Once the filter changes all images end up with a FILTER header.

If the EFW was in a different filter slot than the first filter used in the sequence then all images get the FILTER header.

Note, this doesn't even need to used the Ekos Scheduler, it can also be just done via the Capture Sequence. The other week while I was doing my flats all the Luminance images had no FILTER header as they happened to be the first ones taken after doing a preview capture.

I hope this helps. I've also been looking into the code of both Ekos and INDI. Still can't work out where it is but hopefully the details I've provided might give you some idea where to look.

Read More...

If it is the EFW, I think the issue might be that the call to EFWGetPosition is returning -1 while it is still moving. This can then result in ASIWHEEL::QueryFilter() method to fail. I will try to get some debugging on this over the weekend and see if that is the problem

Read More...

I have the same issue.

My setup is ZWO ASI1600MM with a ZWO EFW. I find that this happens when I've used a manual capture on my Luminance filter (in the first slot). Then when I create a sequence and start capturing data I found my images with Luminance filter has the missing FILTER fits header. I feel it has something to do with when a sequence starts but the filter wheel doesn't move the state of the current filter isn't set so it's not added to the FITS image. Also, given that the original poster is using ZWO EFW it might be something to do with that (as I have the same filter wheel and it is happening to me). I might have a look at the code over the weekend and see if I can find the issue and get a bug fix for it.

As I have created my own Python script using astropy to get around it I don't find this a major issue but I can report that it does happen.

Read More...

Will Gauvin replied to the topic 'I killed gpsd somehow' in the forum. 3 years ago

I use the gpsd.socket, you can disable it but then you must enable and start the gpsd.service to be launched all the time. The use of a .socket in systemd allows for the creation of the socket so other services or processes see that it's up but the process itself isn't running.

I did have fun trying to get gpsd to work though. This page helped: gpsd.gitlab.io/gpsd/troubleshooting.html (Check the Troubleshooting Start at Boot).

Read More...

Will Gauvin replied to the topic 'Capture & Solve problems...' in the forum. 3 years ago

I've had issues before similar to this, but it's been so long ago that I can't remember how I solved it.

Given the ISO 3200 and exposure time of 60 seconds, but the image doesn't show stars it could be: a) camera is not focused, b) mirror lockup might be an issue. Are you able to see stars/sources when you take an image in the Capture module, rather than the Align module? If you're not getting stars there, then it is to do with the camera settings. 

  • If you've not focused before aligning, then just slew to a bright source and focus first.
  • Once focused you might want to check that your Ekos settings for BULB and Mirror Lockup are the same as on the camera.
For my Canon 70D when doing polar alignment I use ISO800 and exposure around 5 seconds and I don't have any issues with detecting stars.

Another thing you might want to look at, is on the Camera is your image quality setting RAW or JPEG? (It's okay to be RAW+JPEG) because JPEG is lossy compression, shoot in RAW.
 

Read More...

Will Gauvin replied to the topic 'OK, so what am I doing wrong?' in the forum. 3 years ago

Kevin you made me think of something.

Phil, you say gphoto is working for you. What is the actual commands that you're running? INDI may not be running the same command, which could lead to it not taking the image. So providing the command that is working we can check the INDI code and see if if they match.

Cheers
Will

Read More...