×

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

Bi-monthly release with minor bug fixes and improvements

Some issues from my first test sessions

  • Posts: 26
  • Thank you received: 1
I've managed to get out to my observatory a couple of times this week to try and get everything up and running under INDI / Ekos, and I'm making some progress, such as getting the DLSR Bulb exposure to operate correctly, but I have experienced and number of other issues that I need to work through... Deep breath, here goes!

indi_gphoto_ccd appeared to download the wrong image after an exposure. It downloaded the image taken previously! I took test shots of the area around Capella first, and then Alnitak, and then of the Double Cluster. When I reviewed the images and manually uploaded them to astrometry.net I found that the image that was supposed to be the Double Cluster was matched to Alnitak, and the that was supposed to be Alnitak one was matched to Capella. I never got an image of the Double Cluster, presumably it will be sat on the camera. This is my first attempt at capturing some images, so I can't say yet whether this is a one off problem, or reproducible.

The online astrometry.net solver failed to work. It returned a couple of messages, one about JSON being missing, and another that I couldn't be authenticated and something about my API key. I have set the correct key value in the KStars settings, so presumably the authentication part of the error messages is down to the JSON issue causing the key to not be sent correctly.

I couldn't get my LX Webcam (SPC9000) to capture LX images at all. The camera works fine in normal mode, and using wxAstroCapture I can grab LX frames without issue. I've tried to apply the LX config settings from wxAstroCapture to the V4L2 CCD driver, but with no luck so far. This isn't the most important thing as the SPC900 is often sensitive enough without LX, but it'd be nice to use LX if I can.

The EQMod Mount driver has what I think is some slightly odd behaviour... Overall it works really well, but I have issues around the parking / home position. The driver allows you to specify a custom parking position, which is great for me because my roll off observatory roof wont open and close with the mount / scope at the home position. I have to rotate it around so that the counterwight bar and the scope are parallel to the ground. With a custom park position defined I can tell the driver to park and it slews to this position perfectly. The issue comes next time I try to use the mount. At initialization it assumes that the mount / scope is in the home position, and KStars shows a marker at Polaris. But of course the mount is nowhere near that location! So I have to undo the clutches on the mount and manually move the scope to the home position, and of course doing that will invalidate any saved alignment data I might have, so it's less than ideal. I think that if there's a custom park position then the driver should initialize to where it's currently parked...

Phew! So a few things are giving me trouble, but I look forward to working through them :) Overall this software looks great, and has a load of features that will be very handy during imaging runs.
10 years 2 weeks ago #778

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

  • Posts: 55
  • Thank you received: 1
Hello,
I also had problem with bulb exposure in case I want to schedule a session of n pics with delays among them. What DSLR did you used?
I would like to use KStars with eq6 motion sleew control, Canon DSLR and QHY5-II mono but, at the moment, only mount control seems to work correctly.

Giovanni
10 years 2 weeks ago #780

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

  • Posts: 26
  • Thank you received: 1
I'm using an old Canon 350D with a seaparate usb-> serial bulb cable. Exposures are taken no problem, although I've only been doing preview shots rather than sequences of images.
10 years 2 weeks ago #781

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


Most of the issues faced are with the INDI drivers, and without access to a DSLR to test, it's very hard to look at code and find out what might be causing this. It would be great if you can repeat that (or just taking images in the living room) and see if you can reproduce the results.

Yeah, it seems there was some change on the server because it used to work flawlessly, but I received the same error and just updated the header and it's working again. By tomorrow a new kstars-bleeding package should be available with the fix.

Will notify Jean-Luc to see his feedback on those issues. Thanks for the report!
10 years 2 weeks ago #783

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

  • Posts: 26
  • Thank you received: 1
Awesome! Thanks for the quick feedback / changes :)

I shall endeavour to reproduce the DSLR issue, but it's a bit tricky as the camera is astro modified and doesn't focus with regular lenses, so living room testing isn't easy! I'll have a think about how I can take some test images and be able to differentiate them from each other. My first thought is a cap of card with a pin hole in that I can rotate through 90 degrees for each exposure os some such. I'll figure something out :)

I shall keep plodding away, trying things out and tweaking... The more bugs I find and help iron out the easier it'll be for other people to make the switch to Linux for astrophotography.

Thanks again!
10 years 2 weeks ago #784

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

  • Posts: 226
  • Thank you received: 88
Hi,

Concerning Park Position, did you use the 'Write data' button of the 'Park Options' in the Site Management Panel ? When you set a new park position it is only set in the driver to avoid unwanted modifications. It should be saved using this button to be restored in the next session. The driver uses the file ~/.indi/ParkData.xml to save the position and the park status (status is automatically handled when using the Park button in 'Main Control'). You may look to this file to check if your position has been saved. This surely may be simplified, I don't remember why I worried about unwanted modifications...
Concerning LX Mod, which method are you using ? I only tested the Led method with my SPC900, the Serial port method has only been tested with a led and an optocoupler plugged onto RTS. You should also activate LX using the' enable' switch in the Long Exposure tab, it is disabled by default. Which settings do you use in wxAstrocapture, I can make some tests with it to make some comparisons.

Thanks for the feedback.
The following user(s) said Thank You: Jasem Mutlaq
10 years 1 week ago #796

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

  • Posts: 26
  • Thank you received: 1
Hi, thanks for getting back to me on this :) Yeah I'm pretty sure that I clicked the Write Data button, I have a ParkData.xml file with the following data in it:
<parkdata>
    <device name="EQMod Mount">
        <parkstatus>
true
        </parkstatus>
        <parkposition>
            <raencoder>
8388608
            </raencoder>
            <deencoder>
10644608
            </deencoder>
        </parkposition>
    </device>
</parkdata>

I assume that this data should be restored automatically one next driver use? I'll try and get out today to have another test with the mount, I can do that in daylight :)

As for my webcam, it's controlled via a usb->serial device, on the RTS line. It's the most basic mod, just to get LX frames, I haven't done the amp off. In wxAstroCapture I have all the tick boxes selected for RTS, except amp control, and perhaps the key thing is the Inverted Logic option for LX Frame is selected too. I guessed that the equivalent option was the HIgh->Low / Low->High setting in the LX settings. Perhaps you can give me a rough idea as to what settings I should be using for this type of device?

Thanks!
10 years 1 week ago #800

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

  • Posts: 226
  • Thank you received: 88
Ok, the position has been saved but the figures here correspond to the default position (NCP). Maybe you can have a quick test if you manually change these 2 figures directly in the file, the reticle should not be on NCP anymore. Another point is the name of the device , "EQMod Mount" here, which is checked when loading Park data (in case you have several mounts). So it should be the same when restarting the indiserver.
I had a look to wxAstroCapture, the settings panel is confusing regarding some schematic diagram I've found: if I consider the default settings (this is what you use if I understand), the transition for LX Frame is on DTR, not RTS (which is for LX amp). The schematic given with K3CCDTools however shows the contrary. Which modification diagram did you use?
By the way, you're right that the Low/high and High/Low setting is equivalent to inverted logic.
The following user(s) said Thank You: Guy
Last edit: 10 years 1 week ago by Jean-Luc. Reason: url error
10 years 1 week ago #802

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

  • Posts: 26
  • Thank you received: 1
Ok, so I've just been out in the sunshine to test the mount driver, and I take it all back, it works perfectly! :D It did take me a couple of tries to get it right... I deleted my ParkData.xml file, and manually set the mount and scope to the home position. Then I slewed the mount to a custom park position, hit the current button, and then write data. Then I hit the park button. I disconnected and powered everything off, and then fired it all up again, and the driver remembered that the mount was parked and where it was pointing :D Hitting park to unpark the mount didn't result in a slew to anywhere, previously it shot off back to the home position. So clearly that issue was entirely down to user error. Sorry for wasting your time. :blush:

And as for the LX webcam, well a picture speaks a thousand words:



To be honest I'm not sure if I need all of those options ticked or not, but that's what I currently have, and it works. I shall have to experiment further to see if any of those are unnecessary so I can get a better handle on how I need to configure the indi driver.
Last edit: 10 years 1 week ago by Guy.
10 years 1 week ago #803
Attachments:

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

  • Posts: 226
  • Thank you received: 88
I just tested with wxastrocapture: with your config it sets RTS (pin 7) from -6V to +6v when starting the LX exposure. The indi_v4l2_ccd do the same using the Low to High transition which is the default. Did you set the used port ('Lx Port' just above setting DTR/RTS/Command) to the correct value (/dev/ttyUSB0 in your config) ? It is set by default to /dev/ttyS0 (I first forgot that when I tested...).
10 years 1 week ago #804

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

  • Posts: 26
  • Thank you received: 1
Hi, sorry about the delay getting back to you, life has just been doing that annoying thing of getting in the way of my hobbies!

I've brought the LX Webcam out of my observatory so I can tinker about with it on my desk, which is much easier. Here is a screen grab of the LX settings tab:



I think those settings are what I should be using, I have tried both the Low to High and High to Low options, but with the same results... I get an image back, but it appears to be a regular frame from the camera, not an LX one. It doesn't matter how long I set the exposure for, the image remains the same. And testing indoors, during the day I would expect it to white out really quickly! For reference, this is the guide I followed to make this webcam long exposure: Philips SPC900NC uncovered
10 years 1 week ago #814
Attachments:

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

  • Posts: 226
  • Thank you received: 88
Hi,
Sorry for the delay, quite busy these times.

Did you look to the indiserver log messages ? There could be a permission issue when the driver process tries to open your serial /dev/lx_webcam port. Such an issue should be reported by the driver. Otherwise my last idea about this issue is that the driver does not capture the right frame as it does when using the LED mod. It could be a timing problem as the driver first toggles the LX signal then enables streaming in the kernel video driver to capture the first incoming frame. The LX frame may have been dropped or lost between these 2 events.
9 years 11 months ago #921

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

Time to create page: 1.292 seconds