How far is MetaGuide integrated?

@Jared, @Ken just a quick question about MetaGuide, what is exactly implemented in terms of features ?

I’m asking this because I recently started testing MetaGuide and I’m getting more inclined to start using it instead of PHD2, simply because it seems to work better with my setup. Yesterday I found some weird behavior when using it for the first time with SGP, I wanted to know what should I expect to be implemented so I can report any outstanding bugs.

I really don’t care about the guide graph, I’m thinking about dithering, auto start/stop guide while focus and this sort of stuff.


Should work fine… that said, not a lot of data has been collected here. All of the right things are implemented for it to work though.

Thanks Ken, I will run tonight a 4h sequence with MetaGuide.

The sgp developers have kindly provided most of the features needed to do sequencing and dithering with MG. The only issue I’m aware of is not being able to do meridian flips during a sequence because SGP asks MG to recalibrate. I’m not sure if this is fixed or not - but the solution is simply for sgp to omit that request for MG because it isn’t needed on meridian flip. If MG is set up correctly with an ascom mount, then you can stop guiding, go to the other side of the meridian, and then start guiding again and it will still be calibrated.

So - aside from meridian flip issue you should be able to sequence, dither, and pause guiding during autofocus with MG.


1 Like

SGPro asks the guider if it needs to flip its calibration data… in this case, for MG, the implemented function just does nothing and returns a positive result. This should work OK.

From my test session I believe MG is not reporting back to SGP total error. I have the feature active to restart the capture if error is > 1 pixel and I on purpose introduced error to the system but the frame was not restarted.

Thanks Ken. Was there a recent change to this? Previously SGPro was waiting for an acknowledgement from MG that never came - and that was causing it to hang. So if it now doesn’t ask for a response from MG that’s great. I hadn’t noticed it in the recent sgp release notes as a recent fix.


Right now I don’t think SGP captures anything back from MG and has no knowledge of the guiding status. MG does communicate this info - via UDP broadcasts every second. The info is documented and could be captured in a separate thread.

Without the info you are somewhat blind to the guiding and only have the images coming in to tell you if things are working.

The main place this impacts typical imaging is in recovery from dithering - because you have no info on how far you are from the guidestar. But the dithering in MG is fairly fast and repeatable - so you can estimate a time delay to wait after dithering. For me I think I used 10-15 seconds.

But if the SGP developers do want to support more info from MG - I’m happy to help out. It just means catching a UDP broadcast message.