Firstly, no one has raised a github issue for this. That would be the first step to formerly raise this as a requirement.
As far as I can see these are still pre-order only, so there are no physical units out there in the field.
Someone contacted Primaluce and their response was no helpful.
So at the moment developing any feature to use the Arco under INDI would be impossible, we don't know how it works, we don't have any working units to figure out how it works and we have no information from the manufacturer to state how it should work.
ST4 is older, and I think developed without thinking that we'd have a separate computer controlling the mount, the ST4 messages would be generated by the guide camera itself which would do the calculations and calibrations etc...
Guide Cameras these days don't have that ability, and the quickest way to ask the mount to do something is to ask it directly, not ask the camera to ask the mount to move.
I'm having a play with indi-allsky, and I have a few questions, don't know if someone can help me with these:
On the config, there is a "ADU ROI" - region of interest, I assume this is a box within the image to use to calculate the upcoming exposure length. The settings just say it is x1,y1 , x2,y2.
What are x1, y1 , x2 , y2?
I'm think it could be that x1,y1 is the top left of the box, measured in pixels from the top left of the overall image, and perhaps x2,y2 is the bottom right of the box, measured in pixels from the top left of the overall image? Would be nice to see this explained in better detail on the github page.
I don't see a way to purge the old (test) images that I've been producing, I deleted images in var/www/html/allsky/images/20220205/day/05_13/
for instance, but I still see reference to the deleted images in the web interface. I assume there is a better way to purge the images?
What is the "EndOfNight" data that is transferred to the website? Images, Keograms, StrTrails I understand, but not sure what EndOfNight data is.
Looks like a nice tool, like the ideas of the Charts and Star Detection (yet to try them out though).
fudge 127.127.28.0 refid GPS
fudge 127.127.28.0 flag1 1 refid GPS
flag1 enables signal processing of implicitly, regardless how out of date from system time it is.
Is this with Stellarmate appliance (which has a built in RTC), or with Stellarmate OS (which will only have a RTC if you have installed one on the GPIO)?
With a USB GPS you are not going to get a synchronisation that is entirely accurate (expect it to be around a second out), and if chronyd/ntpd has access to better time sources then it will label the GPS time as too out of date to sync to.
As I'm not using Stellarmate, I'm probably not going to be much help, but it is strange that you say ntp / chrony are not working, firstly, you should only run one or the other, you can't run both. I think they both try to bind to a port udp/123, so if one is running already then the other won't start properly.
You should probably try and find some relevant logs (in /var/log) which would tell you why something is not starting properly.
www.indilib.org/ccds/zwo-optics-asi-cameras.htmlThere are two ZWO camera drivers available:
I think you have a collimation task ahead of you.
If it is any consolation, the JWST team have the same task, but they're collimating 16 primary mirrors against a single primary.
Lack of collimation might throw the focusing out, maybe focus at bin x2, or collimate your scope for the future !!
OK, so there are focus issues, we can put these down to:
* We have backlash
* We have slippage
When we say backlash we generally means that there is a delay when we change direction of the focuser that there are a certain number of steps that we take that have no effect, and it is until these steps have expired that focuser actually moves.
When we say slippage we mean that during he course of the movement of the focuser, some movement is recorded where no movement happens at all.
We can measure this, move your focuser from its normal in-focus position 10,000 steps in one direction, and move 10,0000 steps back, measure the difference of your starting position to your ending position, this is (more-or-less) a combination of the two added together.
Measuring backlash would be the same process, but with smaller steps (to eliminate the effect of slippage).
Now look at the settings under "Mechanics"
Initial Step Size - this needs to be a number that, not-withstanding the above values, creates a noticeable difference to the recorded HFR in an image.
Max Travel - this needs to be a number that the difference of gets you to within the focus value that you're looking for
Max Step size - this needs to be above the number of "Initial Step Size", if unsure, make it equal to.
20 seconds is pretty high for a focusing frame, the focusing algorithms will be able to detect differences far lower than the eye can detect, you don't need high gain settings, or high exposure settings for focusing, try the similar settings that you use for guiding, only raise them if needed.
You can't focus if seeing is bad, test these under optimal conditions, if they fail due to bad seeing later on, then maybe it was just a bad night for AP.
If you deselect "Full Field" then you will work with just one star, be it automatically selected or manually selected. However, if your field is changing during focus then you're probably not tracking very well, perhaps due to poor polar alignment or due to other mount issues.
If your field is not changing all that much then you'll still get a reasonable curve, as long as enough stars are detected, changing the annulus setting allows you to select the stars in the centre of your field, or in a ring between 25% - 75% of your field of view. What you chose for these settings will depend on your target and target type.
You might want to test focus on a non-nebulous target first to get the hang of it, then move onto nebulous targets which might interfere with the algorithms.