Patrick Chevalley replied to the topic 'INDI ASI Driver Bug causes false binned images' in the forum. 19 hours 10 minutes ago

Jasem,

This is because the driver apply a size reduction based on BinnedWidth % 8 = 0

Look at Thomas log above with the ASI1600.
It start with bin 1x1 and width=4656
when it set bin 4x4 the image width change to 1160 = (4656/4) - ((4656/4) % 8 )
As ccd_frame.width is always unbinned it is set to 4*1160 = 4640

So if MaxBinning for this camera is 4, the value for ccd_frame.width.max must be set to 4640.
This width work for bin 1x1, 2x2, 4x4 without resizing.

Patrick

Read More...

Patrick Chevalley replied to the topic 'INDI ASI Driver Bug causes false binned images' in the forum. yesterday

Hi Jasem,

Thomas ask me if I can give some idea about this issue., I think it is better to continue the discussion here if other have idea on the subject. Note that I not use a ASI camera myself.

For me the origin of the problem is the change that force the image width modulo 8 to be 0.
So my first idea is to check with ASI if this really also concern the binned size or not, I am a bit surprised of this requirement when it concern software binning as with the 183 in bin 4x4. This is probably the only way to fully fix the issue.

The temporary fix I do in CCDciel is the following.
When processing a request to change the binning, it look for the current image size (CCD_FRAME) and if the current ROI start from 0/0 and it's width and height are not the full size (CCD_FRAME.WIDTH.max) but more than 90% of the full size it send a CCD_FRAME_RESET before to set the binning.

This is not perfect, this not work if a small ROI is set, But this fix the issue with the calibration frames and for me this look more reliable than trying to remember what the size was the last time this binning was in use.

Another possible fix is the driver compute a size that work for (CCD_FRAME.WIDTH/ maxbinning) % 8 = 0 from the maximum size, this new value must be used as the default size, returned by CCD_FRAME.WIDTH.max and set by CCD_FRAME_RESET. This way it not need to change the size when the binning change.

Patrick

Read More...

Patrick Chevalley replied to the topic 'INDI distribution for macOS' in the forum. 2 weeks ago

Just an update on my progress.

I setup a new macOS 10.14 virtual machine to start clean.
Then to try the Craft build I follow manually the steps in your script github.com/rlancaste/kstars-on-osx-craft...ster/build-kstars.sh
I stop after "craft .... indiserver3rdParty"
Everything work fine and I have now a full INDI build in the craft directory.
Congratulation for your work on this Craft recipe. I like this way to build INDI and not install directly in /usr/local

Now I will skip the "Building Kstars" steps and continue at "Creating symlink", then generate-dmg with fix-libraries.
For my testing I will just try to copy everything in a dummy .app directory.

Patrick

Read More...

Patrick Chevalley replied to the topic 'how critical location coordinates are?' in the forum. 2 weeks ago

All depend what you do with your telescope.
To measure asteroid position for example the require tolerance is just a few meters.

But if it's to make nice pictures some kilometers do not make a difference.
The limit may be the hour angle computation, this can make the mount meridian flip wrong, or trying to slew to an object below the horizon.
111 km make a difference of one degree, take this as the limit.

Read More...

Patrick Chevalley replied to the topic 'INDI and PHD2 on RPi 1?' in the forum. 2 weeks ago

To not include this proprietary binary in PHD2 add this option to cmake: -DOPENSOURCE_ONLY=1

But do not expect good performance for any graphical application when running on a Rpi1 with a single core and only 512MB of RAM.
The Rpi2 is what make PHD2 to run OK, and the Rpi3 (or better a board with at least 2GB of memory) to also run the imaging application.

Read More...

Patrick Chevalley replied to the topic 'INDI distribution for macOS' in the forum. 3 weeks ago

Hi Rob,

I am currently travelling for one week more and it not easy to connect remotely to my Mac virtual machine to test this procedure.
So at the moment I only look at the script source.
For me the Homebrew script is more easy to understand, this is almost what I do manually, except I stop after everything is in /usr/local. I like how you build the 3rdparty library first, this make the process very clean.
It is more difficult to follow how the Craft build work, I really need to try after I return home.

Patrick

Read More...

Thomas,

I reply to this in another thread but it is probably best to continue the discussion here, so I copy my message:

This is probably the fix for this issue that is the cause for your problem:
www.indilib.org/forum/general/4707-asi29...sue-3x3-and-4x4.html
In the solution Jasem say:
What changed in the driver is that it now strictly obeys that width % 8 must be zero

If I take the number for your camera:
- it start with a size of 5496, corresponding to width max.
- you ask for bin 4x4 : 5496/4 = 1374
- but 1374/8 = 171.75 , to respect the condition "width % 8 must be zero" it set the width to 171*8 = 1368
- Indi frame size are always unbinned so it is set to 1368*4 = 5472
- when you return to bin 1x1 it keep this size of 5472 making your new images not compatible with the first series.

I not use an ASI camera myself so it is difficult for me to try to fix that.

Read More...

Maybe Ekos do a CCD_FRAME_RESET to return to bin 1x1.
I not do that because one may want to change from bin 4x4 to 1x1 without changing the ROI that is set. If this cause the issue I can reconsider that.

Read More...

Hi Thomas,
I look at Marco issue, but it was very different than your issue:
www.indilib.org/forum/general/4707-asi29...sue-3x3-and-4x4.html

This is probably the fix for this issue that is the cause for your problem.
In the solution Jasem say:
What changed in the driver is that it now strictly obeys that width % 8 must be zero

If I take the number for your camera:
- it start with a size of 5496, corresponding to width max.
- you ask for bin 4x4 : 5496/4 = 1374
- but 1374/8 = 171.75 , to respect the condition "width % 8 must be zero" it set the width to 171*8 = 1368
- Indi size are always unbinned so it is set to 1368*4 = 5472
- when you return to bin 1x1 it keep this size of 5472 making your new images not compatible with the first series.

Read More...

Patrick Chevalley replied to the topic 'New INDI Atik driver - Feedback requested' in the forum. 1 month ago

Thank you to find that!
I cannot test with my wheel right now but as soon I can I look for this rubber ring.

Patrick

Read More...