×

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

Bi-monthly release with minor bug fixes and improvements

Two potential bugs in INDI/Ekos when using a DSLR on a new installation

  • Posts: 1957
  • Thank you received: 420
Occasionally I completely reset my RPi image and start from scratch. Too much experimenting (both with software and preferences/configurations) leads to a polluted OS so I clean up by starting from scratch. And this lead me to a very weird situation.

I have a Canon EOS 77D which in the past performed wonderfully well. I also imaged with a 700D and a 2000D and all work great! However, a few weeks ago (sorry, I really don't remember how long) suddenly (i.e. probably after resetting one of my RPis) plate solving started to show a weird behavior when using a DSLR. The target would end up in the upper corner of the image instead of the center. And this doesn't happen when using a ZWO camera on exactly the same RPi! This could easily be verified by using the ASI120MC-S guide cam but also by swapping the DSLR for our ASI2600 camera. With the ZWO cameras, the target ends up nicely in the center of the image. In both cases (with the DSLR and the ZWO cameras) plate sokving reports that the target is within 30 arcsec from the center of the field of view. However, here's an image that was solved on Deneb tonight with the 77D:



The log lines from that sessions read
[2020-09-27T21:36:38.658 CEST INFO ][     org.kde.kstars.ekos.align] - "Field 1: solved with index index-4111.fits.\nField 1 solved: writing to file /tmp/SextractorList.solved to indicate this."
[2020-09-27T21:36:38.738 CEST INFO ][     org.kde.kstars.ekos.align] - "Field: /tmp/SextractorList.xyls\nField center: (RA,Dec) = (310.355110, 45.268678) deg.\nField center: (RA H:M:S, Dec D:M:S) = (20:41:25.227, +45:16:07.240).\nField size: 77.2458 x 51.5608 arcminutes\nField rotation angle: up is 179.754 degrees E of N\nField parity: neg"
[2020-09-27T21:36:38.884 CEST INFO ][     org.kde.kstars.ekos.align] - "Solver completed in 9 seconds."
[2020-09-27T21:36:38.964 CEST INFO ][     org.kde.kstars.ekos.align] - "Solver RA (310.35511) DEC (45.26868) Orientation (180.37792) Pixel Scale (3.08026)"
[2020-09-27T21:36:39.068 CEST INFO ][     org.kde.kstars.ekos.align] - "Solution coordinates: RA (20h 42m 07s) DEC ( 45° 20' 47\") Telescope Coordinates: RA (20h 42m 08s) DEC ( 45° 21' 29\")"
[2020-09-27T21:36:39.146 CEST INFO ][     org.kde.kstars.ekos.align] - "Target is within  00° 00' 41\" degrees of solution coordinates."
[2020-09-27T21:36:39.231 CEST INFO ][     org.kde.kstars.ekos.align] - "Target is within acceptable range. Astrometric solver is successful."

"So, why is Deneb not at the center of the field of view?" you may wonder. Well, I wondered the same. So I had a look at the XML file for the camera. It contains these entries:
<newNumberVector device='Canon DSLR EOS 77D' name='CCD_INFO'>
  <oneNumber name='CCD_MAX_X'>
      6000
  </oneNumber>
  <oneNumber name='CCD_MAX_Y'>
      4000
  </oneNumber>
  <oneNumber name='CCD_PIXEL_SIZE'>
      3
  </oneNumber>
  <oneNumber name='CCD_PIXEL_SIZE_X'>
      3
  </oneNumber>
  <oneNumber name='CCD_PIXEL_SIZE_Y'>
      3
  </oneNumber>
  <oneNumber name='CCD_BITSPERPIXEL'>
      8
  </oneNumber>
</newNumberVector>
<newNumberVector device='Canon DSLR EOS 77D' name='CCD_FRAME'>
  <oneNumber name='X'>
      6000
  </oneNumber>
  <oneNumber name='Y'>
      4000
  </oneNumber>
  <oneNumber name='WIDTH'>
      3
  </oneNumber>
  <oneNumber name='HEIGHT'>
      3
  </oneNumber>
</newNumberVector>

Two things caught my eye. First of all, the pixel size is reported as "3" and not as "3.72" which I entered. As a matter of fact, the entry for the camera in the userdb.sqlite reads
3|Canon DSLR EOS 77D|6000|4000|3.0|3.0

and it now says "3.0" and again not "3.72". That in itself is an annoying but not terrible issue. Now the field size calculations will be 3.72 * 100 / 3.0 = 124 so about 25% off which the solver can compensate for.

However, the second thing is much more problematic. If I understand those numbers correctly then Ekos thinks that my camera has a sensor of 3x3 pixels located at cordinates (6000, 4000) which clearly is wrong. As a matter of fact, the same entry for the ASI2600 reads
<newNumberVector device='ZWO CCD ASI2600MC Pro' name='CCD_FRAME'>
  <oneNumber name='X'>
      0
  </oneNumber>
  <oneNumber name='Y'>
      0
  </oneNumber>
  <oneNumber name='WIDTH'>
      6248
  </oneNumber>
  <oneNumber name='HEIGHT'>
      4176
  </oneNumber>
</newNumberVector>

and that makes sense. So, whenever a new DSLR is configured in Ekos, the numbers are not stored correctly resulting in alignment issues. I will change the X, Y, WIDTH and HEIGHT in the XML file to
<newNumberVector device='Canon DSLR EOS 77D' name='CCD_FRAME'>
  <oneNumber name='X'>
      0
  </oneNumber>
  <oneNumber name='Y'>
      0
  </oneNumber>
  <oneNumber name='WIDTH'>
      6000
  </oneNumber>
  <oneNumber name='HEIGHT'>
      4000
  </oneNumber>
</newNumberVector>

and see if that fixes the alignment issue. In the mean time I'd very much appreciate it if one of the developers could confirm my analysis and, if yes, implement a fix. Many thanks in advance!


Clear skies, Wouter
The following user(s) said Thank You: Jasem Mutlaq
3 years 6 months ago #60764
Attachments:

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

Thank you for the report. When you "reset the RPI", does that mean all the config files are gone? Then you started from scratch, in Ekos, you'd get the DSLR dialog to enter width/height/pixel_size, correct? Can this be repeated?
3 years 6 months ago #60773

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

  • Posts: 1957
  • Thank you received: 420
Yes, when I say "reset" I mean a full reinstallation. I then tried to repeat this in two ways:
1) press the red trash can icon in the Camera tab in Ekos
2) Physically delete the XML file in the .indi directory AND delete all rows from the DSLR table in userdb.sqlite

In both cases I get the DSLR popup again (in the first case immediately, in the second case as soon as I start INDI from within Ekos) and both again lead to the same issue.


Wouter
3 years 6 months ago #60779

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

  • Posts: 1957
  • Thank you received: 420
FWIW what I reported was with the nighlty builds on Linux (updated last night but, like I wrote, this has been happening for several weeks now). I just tried with the stable release on Mac and the "digital numbers get truncated" issue exists there as well but not the "X, Y, WIDTH and HEIGHT are stored wrong" issue.

Perhaps the rounding off of digital numbers is a more general issue. I noticed something similar when entering a new location. For instance, when I enter my current location, I do this like this



When I then close and restart KStars, the location was updated to



On my Mac I need to use "," as a decimal separator due to the locale used. Interesting enough, the Elevation is NOT affected by this. This is reflected in the mycitydb.sqlite as well:

1|Majadahonda|Madrid|Spain| 40° 28' 46"|-03° 52' 10"|1.0|EU|735.1

The WIDTH, HEIGHT and elevation are defined as REAL in the sqlite databases so my guess is that there is a conversion issue in Ekos or INDI somewhere.


Wouter
3 years 6 months ago #60784
Attachments:

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

  • Posts: 108
  • Thank you received: 20
Hi,
i've noticed the same thing with my Nikon DSLR (D800, D5300). Pixel size decimals are not saved in Indi driver (only the int value is saved) from Ekos capture module.

Regards
The following user(s) said Thank You: Wouter van Reeven
Last edit: 3 years 6 months ago by ouioui01.
3 years 6 months ago #60790

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

  • Posts: 1957
  • Thank you received: 420
What version of KStars is that with?
3 years 5 months ago #60793

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

  • Posts: 108
  • Thank you received: 20
Hi Wouters,
I saw that since 3.4.3. I´m using now the nightly build with my rpi4 with ubuntu 20.04. i have also <n another rpi4 with Stellarmate beta (raspbian).
the bit per pixel is wrong too for me (D5300)
3 years 5 months ago #60795
Attachments:

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

Oppps I apologize that was my fault, pixel size now fixed in GIT. Regarding bitdepth, it's 8 by default and then the driver changes it depending on the capture. Please note this is NOT the camera bit depth, but the data bit-depth which can be only 8 or 16. So 10, 12, 14 camera bit-depths would be treated at 16 data bit-depths.
The following user(s) said Thank You: Alfred, Wouter van Reeven
3 years 5 months ago #60862

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

  • Posts: 984
  • Thank you received: 160

That would make a perfect tool tip. I always wondered what the bit depth means in detail.
3 years 5 months ago #60864

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

  • Posts: 108
  • Thank you received: 20
3 years 5 months ago #60888

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

  • Posts: 1957
  • Thank you received: 420
I just checked with the nighlty build of last night and, indeed, all details are stored correctly now. Hopefully tonight we can test and verify that this solves the alignment issue as well.


Wouter
3 years 5 months ago #61018

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

  • Posts: 48
  • Thank you received: 0
Thanks for the fix. I noticed it as well and came over to report it, inly to find this thread :)

I'll try the new release.


I have noticed something else as well. I do not think it has been reported.
Not sure if I should open a new thread or just say it here, but i have noticed that after running a capture session for a few hours, kstar becomes very sluggish. The exposure times updates once every 10 seconds, progressively getting worse. Clicking something takes a minute for it to respond. Htop says that kstar has 100pc utilisation over one core. Not sure why. Only way out is to kill kstar and start it again. The problem does not reappear after that, but only when running kstar for the first time after a system reboot. I had similar experience every night since updating to the aug 2020 release.

I have kstar running on my desktop with 6c12t, 16 gb ram. Indiserver is running remotely in rpi4 running astroberry.
3 years 5 months ago #61038

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

Time to create page: 0.269 seconds