Plate solving has always been fine for me once i moved to pinpoin and as a backup astrometery.net (and worked two nights ago)
However with either of those its failing to solve anything, bit a fit , fjp or capture off the ccd.
Any thoghts?
humm upgrading to 2.4.1.10 seems to have fixed this.
1 Like
Often when a weird issue like this pops up, I find a reboot fixes it.
Yeah i did think that myself as it was 2am and i was nt very awake i casnt recall if i did… however its solving now so all is good.
Dont think i have renooted since the reinstall mind you,
1 Like
When this happens to me I have to stop and restart the local ANSVR server. Maybe in a future version SGPro can just shell out to solve-field directly and not use the ANSVR server at all. We could eliminate that large chunk of code and this problem which K & J can’t do anything to solve anyway.
This is the first I have heard of this. Without seeing the ansvr logs, we can’t know whether the restart actually solved anything or was merely coincidental. If you see it happen again, please post your SGP log and your ansvr logs and the image that is failing to solve (if available).
The ansvr logs are in C:\Users\YOUR_USERNAME\AppData\Local\cygwin_ansvr\var\tmp\platesolve\
You could un-check the ansvr option to cleanup the temp files after solving to preserve the image that SGP sends to ansvr. Then, when you see the failure post the .fit image in addition to the logs. (Make sure you turn the cleanup option back on once you get the files you need.)
Thanks,
Andy
I don’t actually control the mount in SGPro anymore as none of the ASCOM drivers work with my mount. For now, that means I can only image a single target at a time, but it is what it is. I use a program similar to AstroTorilla that grabs an image moves the mount in a loop until rotation and coords are within a given tolerance. SGPro is just hooked up to the simulator to keep it happy. If I should get back to using SGPro to control the mount I’ll grab a log if this happens again.
mick what mount are you using? is it a blanket case of all ascom or just some?
Meade LX850. It is an auto-guiding mount that also auto-centers similar to how SGPro does (move, sync, move). None of the ASCOM drivers support ALL the features needed for SGPro. The closest is the Meade Universal ASCOM driver but it doesn’t support syncing – SGPro can move the mount but can’t sync it. The problem is matching a previous image. The mount will go to the object but it may not place it exactly in the same place as the previous session – so an SGPro plate solve is needed to match a frame and that requires a sync. The best ASCOM driver for the mount is the LX200gps but it is out of date and can’t determine what mount it is connected too. Easy change but in VB, something I don’t know.
In fact, ASCOM doesn’t distinguish between a “goto RA,DEC” and a “center RA,DEC” which are different operations so it is ASCOM issue as well. For mounts that can auto-center we need to say “center RA,DEC” as opposed to “goto RA,DEC”. ASCOM needs a “can center” property someday to fully support this.
It’s a real shame for the Meade users that the support for their mounts is so poor. I’m not sure why. When I got my first Celestron mount I didn’t like the drivers that were available so wrote a better one. It’s really surprising that no one of the multitude of Meade owners doesn’t have the expertise and interest to produce a better driver.
The problem is, I suspect, that it’s very difficult. There seems to be a multitude of different software versions, each with different, undocumented, bugs. Different mount versions implement the same functionality differently. And Meade seem to be uncooperative.
One thing that isn’t very obvious is that SGP requires more from a mount than to have a valid ASCOM driver. SGP requires a specific set of functions to be implemented, in particular sync. It’s a shame this isn’t made more obvious.
I’m surprised that no Meade driver implements sync. I thought this was available from the LX200 classic days, which is when most drivers were written.
What is the difference between goto ra, dec and centre ra, dec?
Chris
Not it’s really not that hard to write a driver for Meade. It’s also serial communications send/receive. They’ve maintained backwards compatibility by extending the command set and the last time I wrote a driver in Linux (2011) I wasn’t aware of any bugs you had to code around. I think it’s just a small subset of Windows programmers who use Meade gear. The INDI drivers fully support all versions of the Meade line including the RS which is so expensive very few have ever bought one. The INDI drivers sync, set slew custom slew rates, OTA temp, GPS control, everything, even support the selenographic slew and sync modes – which can’t be used that much (maybe they are).
The difficulty I’ve had is the closed source drivers. For the life of me I can’t understand why you wouldn’t want to share the source so your own driver would get better, but I can’t get the resident Meade ASCOM guys to provide it (I’ve e-mailed them all). That way over time all features get supported as the driver gets more and more attention. I suspect most people are using The Sky, Maxium DL, etc. and those programs have built-in native drivers that support all functionality the program needs. I would guess that is way there is so little support for Meade gear in a generic driver system like ASCOM.
Believe me if I knew C# or VB or Windows C I’d be all over this. But I haven’t programmed in Windows in my 30 year career so I am unfit to do the job.
But, as you said, Meade could do it if they wanted and they could do it well. The problem is theirs.
Tonight I’m working in KStars, ASP, and Ekos with INDI. Ekos is not SGPro, but at least it’s something I can work on.
frustrating 
[quote=“mick, post:11, topic:1617”]
Not it’s really not that hard to write a driver for Meade. It’s also serial communications send/receive.
[/quote]Yet many people have said they will be producing one, then nothing, not even a simple driver that implements the basic functionality.
Several of the legacy drivers have sources available as part of the install. They are in VB6 but still useful as a source of ideas.
An ASCOM driver is basically a facade that converts a set of COM properties and methods to mount specific code. A series of short functions - encode and send a command, get a reply, decode it and return it. There are templates that provide much of the boiler plate code for the ASCOM side, all that’s needed is to fill in the mount specific code. There are a lot of drivers that have clearly been implemented like that, complete with the bugs in the template code (we’ve removed the ones we know about).
I would think that an experienced developer should be able to adapt to a new language such as C# pretty quickly. Visual Studio is available free of charge from Microsoft and there’s a lot of ASCOM support - pdf files, videos, templates, the ASCOM-talk forum and so on.
Chris
Agreed. It’s something I’ve already looked into. I downloaded the MS IDE, and I have the lx200gps code as a starting point. It wasn’t even intuitive to figure out how to import that code into a project. VB is nothing like C. The learning curve is super steep for me. 
I can get more done faster in the environment I have been coding in my whole life and I don’t intend to use Windows anyway so my time is better spent working on other projects.
I think what Ken and Jared have done is amazing and then fact that they are old-school small company, a small group of guys writing code, is awesome. I fully want to support their efforts because I agree with how they’ve gone about it. I bought a license to help support them and the dev team and I’ll buy an upgrade license later to continue that support as long as I can afford to do it.
If you have the tools, Chris, the lx200gps driver has 90% of what SGPro needs (everything but pier side support which we can survive without). All it is doing wrong is sending the wrong command to determine the scope name. It uses a regex to try to pull apart the returned string to verify the firmware version. If that were fixed, maybe 5 lines, it would suffice for SGPro. I’ve got everything you need. You game to try?
1 Like
Chris usually wants to be paid for his work 
. If you could work a kickstarted for a LX200 driver, I bet he’d consider it for an appropriate amount.
On the plus side, he’s good at his job 
️!!!
I’m not doing it.
I don’t have any hardware so can’t test. And no interest.
Something I’ve learnt over a working life in software development is that the less one knows about a project the more its difficulty is underestimated. Trying to do this, especially without hardware, would end up in a perpetual cycle of partially working drivers and continual reports of problems, none of which would come with enough information to be able to debug.
I know of at least two Meade driver development projects, both of which seem to be in a perpetual pre beta stage. I don’t think another one would help.
I can hardly believe that there’s nobody with Meade kit who can’t program in C#.
1 Like
Thanks mads,
Your reply crossed over with mine. Being paid would increase my interest of course.
Not having hardware really makes this a challenge. I speak from experience here, part of my day job was developing drivers for electron microscopes and when the microscope is in Japan and I’m in the UK and the testing is done by people in Japan not only does it take months but it’s hugely frustrating.
Chris
Chris,
I mean it about a kickstarter. You can’t tell me all the Meade people out there wouldn’t chip in 5 bucks to get a working driver. I think it’s add up pretty quick!!
It may be best to contact Tim Long, he’s got a Meade universal driver project going.
http://tigra-astronomy.com/ascom-unified-driver-for-meade-telescopes
Chris
1 Like
Done. Thanks, Chris.