Ok so it is all about the priority. What are your priorities that the developers should focus on?
Personally speaking, there are some features that Iād like to have in SGP: direct support for QHYCCD cameras (or at least the possibility to set the offset for each event), the possibility to repeat times a sequence (i.e. instead of 9xR + 9xG + 9xB do 3 x (3xR +3xG + 3xB) without duplicating the target, INDI support for a client/server approach, and many more. However, all I really ask to developers is keeping the current level of reliability as they-re adding support for new hardware.
Anyway, thatās just my opinion and Iām perfectly fine with you having a completely different one.
Thats good to know. I thought the Devs policy was to not spend time on specific hardware support but to focus on supporting ascom compliant devices. In many posts they have put the onus on the hardware developers making their drivers ascom compliant. You can already do 3x 3x R etc by adding extra events. INDI support is also interesting. I wonder what percentage of users are asking for this? Perhaps a poll of users would help?
Just to be clear, with āsupport for new hardwareā I mean the capability of handling new types of devices of new functions that are NOT supported by ASCOM. Perhaps something thatās still to be invented. As a owner of a QHYCCD camera Iāll never ask for direct QHYCCD support: everything that can be done in ASCOM should be done in ASCOM, hardware abstraction is a key principle in programming. Thereās a big difference between what Iād like to a have (as a nice feature) and what Iād ask to developers (BTW, I never issued a request for a new feature since I use SGP).
Interesting. Thanks for sharing that Jared.
And thanks for all the great work on SGP. Much appreciated!
I fully agree on that Alessio, Iāve been an INDI user from 2015 onwards and I love the entire idea of it. Linux as a server so itās super stable (and never tries to force an update) and is built for remote control. Iāve had very succesful sessions with it and am still trying it out in the beginning of a new session, just cause the polar alignment is/was awesome (mainly when PHD didnāt have it yet). My main problem with it, as much as I love it, it is unreliable. In 2015 I was on board and wanted to test out everything and send back bug reports, nowadays it seems I still have to do that. And I appreciate the effort the developers put into it ofcourse (and itās free as well), but when drivers for my cameraās out of nowhere suddenly stop working or the scheduler suddenly misbehaves and this happens for 3 years already off and onā¦ Iām now simply waiting until those kind of issues don;t pop up on the forum anymore. 
As much as I want to not use ASCOM anymore and as much as the stability of a Linux based system is attractive, when I started using SGP, I simply was snapping away. Updates? No issues, just carry on. So to me it seems a bit like too many new features, but I also wonder if the underlying code is as clean as it could be. Otherwise these kind of bugs should show up more easily (just guessing as Iām not programming it).
TLDR; I rather have a feature take 3 years to develop, than to bug fix every little step on the way for a hobby like astrophotography.
1 Like
Itās interesting to watch the call for bug fixes. In my experience with SGP over many years Iām not seeing these issues. The thing I like about SGP is that it simply works. I have a reasonably standard setup including Windows, ascom, eqmod and ascom drivers. I often wonder if a lot of the issues people report as bugs are UGEs or simply compatibility issues with unsupported equipment/drivers?
I still experience a few gremlins in 3.0.1 but nothing too serious or unreliable as such. Most of my imaging is unattended and I can leave it all night without concern.
I echo the sentiments about reliability. If this hobby was a simple as buy some kit, turn it on and upload some pictures, it would be no fun at all. The middle ground is someone who has the satisfaction of overcoming obstacles and gets to where they want to be with a reliable system and finally those who are constantly battling with multiple issues which defy correction and ultimately have nothing to show for their investment.
There is a bit of device specific going onā¦ quite a bit of traffic from ZWO users, which I guess is why it is being singled out for special attention.
There has not been an update for some time and it might be useful to know what is on the planned next maintenance release.
If someone were to ask my opinion on the matter, and having developed software, I think buzzās analogy is spot on. Just because it can, does it mean it should?
Iād rather sgp be good at what it does (imaging sequences) first and foremost. Stabilize that, then add additional functionality.
I think if anything, adding application compatibility may be a better way to do this, ie. allowing sgp to communicate with other softwares that are good at what they do.
So I wouldnāt say never add it, but as mentioned by others, itās a priority thing. Especially since there are stand alone softwares out there that are dedicated to that.
Unfortunately ASCOM doesnāt expose offset and CMOS cameras seem to need that. Weāll (unfortunately) do the same for QHY after ZWO is finished. But we had to pick one to start with and ZWO seems to have more traction with CMOS cameras than QHY does at this point.
Thanks,
Jared
Unfortunately no one has asked the ASCOM developers to add offset.
If you had then if might have been added. But no one asked. I did mention it but the wisdom from experts is that there isnāt a technical reason for it, not even on a CMOS CCD. Iām not going to push for something that I donāt believe is required on behalf of people who canāt be bothered to ask for it.
I notice that some of the latest CMOS cameras change offset automatically when the user changes the gain and the offset is not exposed to the user. In many ways, that is a more robust way to go, as it allows the OEMs to have tighter control over the image quality.
I almost had written the very same. My ASI294MC (a very new CMOS camera model) has no setting for offset and I am glad that the setting of the offset happens automatically. It works very well.
Bernd
Iād prefer to use the existing capture, solve and slew capability of SGP for fast polar alignment than have to resort to using other applications which are more limited than SGP - especially in their plate solving capability.
The concept of new major releases implys new features will be added, not bug fixes. If it can and enough users think it is a useful feature to add then why not?
3 Likes
Iād like to see this as well, with the ability to polar align with a smaller FOV than that required by sharpcap.
Iād like to see this as well, with the ability to polar align with a smaller FOV than that required by sharpcap.
Fully agree!
Chris
Sorry to bump this up! There are a couple of reasons I did this as follows:
-
I and many users use polemaster which is great when its working. There is a well known bug where the polemaster stops to refresh the video frames on screens and this is well documented. QHY have indicated they will fix this down the track but until then for users facing this problem polemaster is not the solution. (Details here - https://www.qhyccd.com/bbs/index.php?topic=5787.msg39338#msg39338)
-
The Sharpcap software has come a long way āSharpCap 3.0 with better star detection and plate solving, more accurate adjustment measurements and some handy hints on how good your polar alignment needs to beā but the best feature is the live display of the polar alignment error.
-
PHD2 is not as easy and quick as either of solutions mentioned in 1 and 2. Well atleast when Iāve tried using it.
My belief is that if SGPro is aiming to be a one stop shop for imagers than it should have a good alignment tool in place (similar to sharpcap). The guiding feature is already in PHD2 and there is no need to bring that into SGPro.
Edit - One more point Iād like to make is that if this feature was added to SGPro it would be reason alone for me to update by subscription since its a fantastic value add.
Perhaps I am missing something in your post but if you are already using SharpCap and it has a great polar alignment tool, why not just keep using it?
Charlie
1 Like
I donāt have SharpCap unfortunately; I have Polemaster (the link I posted has the issue I raised in it) and Iāve used PHD2. Ideally, Iād love to see SGPro become my one-stop shop for image acquisition.
Just a thought and observation.
SGP does not guide, and relies upon a 3rd party application. Between PHD2 and Metaguide, it is hard to see why Ken and Jared would spend resources trying to recreate either in SGP to make it a one stop shop.
Having said that, PHD2 already has some polar alignment facilities, based on drift. It might be more appropriate to suggest that PHD2 has a plate-solve/rotate/platesolve/align routine, since it would be more likely to use a shorter focal length?