×

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

Bi-monthly release with minor bug fixes and improvements

Failure to take exposure with Starlight SXVR-M25C

  • Posts: 33
  • Thank you received: 0
Yeah. I'm not sure what all is the difference between the two cameras but I guess they are slightly incompatible. That would be easy if it is just width and height issue. Can maybe just add a overwrite flag that one can toggle. If I can figure out how to make indi use my own build of the sx driver I could try it. It would be a lot easier if I can take the camera home. The club really didn't want anyone leaving the observatory with it, but maybe I can ask for an exception to play with it for a week during next full moon.

As for an error on my system. I'm up for trying whatever is suggested. I've tried this on two different laptops I have.
Last edit: 4 years 5 months ago by Russell Valentine.
4 years 5 months ago #44653

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

  • Posts: 1067
  • Thank you received: 140
I think the problem lies with the fact that your camera is the older SXV version, and mine is the SXVR, they have got different resolutions, not sure why yours is not being recognised correctly...
About 18 months to 2 years ago Jasem and Peter (one of the indigo developers) did a lot of work on this driver, as it did not work for me and had similar issues that you are having, but it does now work perfectly on the SXVR version, but I too at that time has issues with incorrect resolutions being displayed...amongst other issues and errors, that in time were all sorted..

You say the PID numbers are the same or different on the two cameras...as they should be different...?.
4 years 5 months ago #44659

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

  • Posts: 33
  • Thank you received: 0
I agree. If I was using a SXVR I bet there would be no problem.

Yes the PID it shows is 0x325 which I think is the same as the SXVR according to here:
www.sxccd.com/80-support

lsusb with the SXV-M25C
===============================================================
Bus 001 Device 005: ID 1278:0325 Starlight Xpress SXV-M25C
===============================================================

Interesting that in the linux usbids file PID 0325 is the SXV-M25C not SXVR-M25C. I guess because it was first.

Looks like maybe my next step will be to try to get my own build going and understand the driver more.
4 years 5 months ago #44668

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

  • Posts: 298
  • Thank you received: 46
@AstroNerd
Yes, you are correct, the driver works perfectly for sx cameras and I'm using it too, but I think it should work for his cam too.

@bluthen
I wrote a quick start manual (if it can be called like that) for you so you can do some testing yourself :)
sudo apt install git build-essential cmake libindi-dev libnova-dev libgsl-dev libusb-1.0-0-dev libcfitsio-dev
 
git clone --depth=1 https://github.com/indilib/indi-3rdparty.git  (directory indi-3rdparty will be created)
cd indi-3rdparty
cd indi-sx
mkdir build
cd build
cmake ..                  (if some libs are missing then it tells you what's missing)
make                       (if there is no errors reported go for next command)
indiserver ./indi_sx_ccd    (have your cam connected and run this for testing the new driver)

I hope I didn't miss anything..

/Markku
The following user(s) said Thank You: Russell Valentine
4 years 5 months ago #44676

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

  • Posts: 33
  • Thank you received: 0
Thank you for the help so far. I've had some success but lets see if I can explain it. In sxccd.cpp I change the resolution but that did not solve the issue. I thought maybe I get a timeout in the read because it is trying to still get too much pixels, so I wanted to see which pixel would it timeout on. So I modified the size of each fetch of data and added that info to the debug log. What I discovered is that pretty much any resolution can work. If it is bigger than the actual size, the data will just be zero for those pixels. What was causing the problem is the chunk size in the usb read.

By default it tries to get all the data in one read. I've found that I can't reliable get the image data if the read chunk size is too big. The size that works for me is pretty darn small actually and I'd assume makes transfers take longer than it normally would (A guess).

1024 I still get time outs toward the end. The value I've been able to reliably use is 512. It also seems like values that are not a power of 2 cause a LIBUSB_ERROR_OVERFLOW. In any case, I'm really happy we've gotten this to work. I'm not sure how many of these older cameras are out there, so not sure if it is worth a patch or a config parameter where you can specify smaller chunk size or something. What do you guys think? Should I also post this as a git issue?

Just in case I also tried commenting out the debug statement in case it was a timing issue, but 512 still works with the debug statement commented out. And size 512 with that debug statement is a lot of statements!

Below is my diff:
diff --git a/indi-sx/sxccdusb.cpp b/indi-sx/sxccdusb.cpp
index 8f08b78..4f89b64 100644
--- a/indi-sx/sxccdusb.cpp
+++ b/indi-sx/sxccdusb.cpp
@@ -736,11 +736,12 @@ int sxReadPixels(HANDLE sxHandle, void *pixels, unsigned long count)
     while (read < count && rc >= 0)
     {
         int size = count - read;
+        size=512;
         if (size > CHUNK_SIZE)
             size = CHUNK_SIZE;
         rc = libusb_bulk_transfer(sxHandle, BULK_IN, (unsigned char *)pixels + read, size, &transferred,
                                   BULK_DATA_TIMEOUT);
-        DEBUG(log(true, "sxReadPixels: libusb_control_transfer -> %s\n", rc < 0 ? libusb_error_name(rc) : "OK"));
+        DEBUG(log(true, "sxReadPixels: libusb_control_transfer -> %s, %lu/%lu t%lu\n", rc < 0 ? libusb_error_name(rc) : "OK", read, count, transferred));
         if (transferred >= 0)
         {
             read += transferred;
4 years 5 months ago #44826

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

  • Posts: 33
  • Thank you received: 0
On my drive home I was thinking, maybe it isn't about chunk since, maybe this older model is just slower and needs a much much longer timeout. Next time I'll try increasing BULK_DATA_TIMEOUT.
4 years 5 months ago #44838

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

  • Posts: 1067
  • Thank you received: 140
Chunk size was the issue two years ago with my SXVR M25c, so whatever it is on now in the driver, was the one that worked, so any other setting and mine won’t work, so maybe we are going to need a separate driver..... :(
4 years 5 months ago #44847

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

  • Posts: 298
  • Thank you received: 46
Nice to see success with the driver :)

I was thinking that there is a couple of options here, the easiest option would be to keep your changes to the sx driver and rename the file to something like indi-sxv and register as a new driver in the xml-file, the drawback would be you have to recompile the driver now and then and also patch the xml-file every time there is a update from ppa.
The second option is to find a way to recognize the camera and use your patched way to read the pixels, maybe Jasem would accept the way to do it.

So how to recognize the specific camera, I don't know if there is a way to get the id of the ccd, that would be the easiest way, otherwise maybe check for the exact resolution of the ccd ?? but that can create problems if there is an other cam with the same resolution so that's a bad way to do it.
I also thought about checking the cam's firmware version and resolution but that can also be a gamble.. ??
I'm a bit puzzled when checking the log you posted because it looks like it identifies it self as a "SX CCD SXVR-M25C" in "sxGetCameraModel" ??

Well done!!
4 years 5 months ago #44859

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

  • Posts: 1067
  • Thank you received: 140
I think that is the issue, the driver should recognise different cameras by there iD numbers, but for some reason these two cameras are being recognised as the same, when mine, the SXVR works fine with the current driver, but the OP’s camera is the SXV older version, with a slightly older sensor... is not...
4 years 5 months ago #44862

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

  • Posts: 33
  • Thank you received: 0
So I've been able to take home the camera to try some more things. It really just is the timeout the whole time that was the issue. Unbinned it takes 14 seconds to transfer the image with the original chunk size. The timeout was 10s. I will make a pull request to increase the BULK_DATA_TIMEOUT to 20s.

github.com/indilib/indi-3rdparty/pull/11
Last edit: 4 years 5 months ago by Russell Valentine. Reason: Added github PR link.
4 years 5 months ago #45123

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

How do the images look with the bayer? I recently submitted a fix to recognize this camera as "color" so that the bayer filter property is exposed. However, the final image looks "interlaced" and the bayer pattern does not match one captured on a PC by Maxim DL.
4 years 3 months ago #47238

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

  • Posts: 33
  • Thank you received: 0
I've had a hard time finding any good information of how the bayer matrix should be with these cameras. Some forums like on cloudy nights implied that each chip could possibly have a different one (I kind of find it hard to believe).

I did have good luck with color. I made a pinhole lens with foil and a color chart with construction paper. So if for example I force RGGB and up-bottom orientation in Siril(I believe this setting used to be called kstars-ekos/pixinsight compatibility) and some white balancing, I get the attached image.

I've also taken a test image of M33 and the colors seemed pretty good this way. I've had some set backs with my setup so that is as far as I got. I hope to get back on track after all these holidays.

I'm not an expert on maxim but maybe it has something to do with the up-bottom orientation?



P.S. Edit: I believe the person who sold it, did so because they had too much trouble getting the color right. I know this is just hearsay, and I don't know what software this person was using, but it might be possible Maxim didn't have it right either.
Last edit: 4 years 3 months ago by Russell Valentine.
4 years 3 months ago #47259
Attachments:

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

Time to create page: 0.786 seconds