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?

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

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

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

What version of KStars is that with?

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)

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.

That would make a perfect tool tip. I always wondered what the bit depth means in detail.

+1

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

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.