Jonk

I don't think SGP can connect to 2 focusers independently but if you have 2 scopes / 2 focusers, then you can run 2 instances of SPG, focuser 1 in SGP1, focuser 2 in SGP 2. I have 3 scopes and 3 focusers but in SGP only 1 can be used for a given instance of SGP. I suppose I could have >3 if I wanted, with as many SGP instances open as the system would allow. It's the same with cameras, mounts, filter wheels etc.... only 1 per SGP instance (multiple drivers and com port settings correct of course).

In EQMOD, if you have the software set to sync on solve, i.e. after a platesolve, sync the mount, then once the 1st platesolve is complete, the mount syncs to it. The 2nd platesolve is off by xx pixels, and the mount is instructed to move xx pixels as expected. However, the mount then syncs to it, so you end up with a never ending cycle. I turned mount syncing off in EQMOD, because if you're platesolving, then having the mount use multiple sync points to improve accuracy isn't actually needed and may cause the problem you describe.

For those struggling, theres is an easy way to offset init / sync. It does not matter where in the world you are, or what time of day it is, or even if you have the mount connected (faking servos mode, i.e simulation) 1. Make sure your latitude and longitude settings are correct in Sitech.exe 2. Manually move your mount so it is pointing due E or W, by turning DEC only. 3. In Sitech.exe, open skyview. 4. Click on a star on skyview nearest due E or W (depending which way you pointed your scope. This message will pop up - click Sync - the offset init screen will pop up next, and will auto close / auto sync within 15 seconds if nothing is touched. Press on the 'offset simple init automatic in x.xx' to stop the automatic countdown and syncing before you've had time to check things. 5. Check GEM scope is looking East or West and choose the correct setting (mine are greyed out as it's set to EQ, not GEM as I have a non flip pier). 6. Click 'OK'. This will sync your scope's current pointing position to this star, which may not be totally accurate, but it's a very good starting point. 7. Using the handcontroller or slew arrows in Sitech.exe, slew to your chosen park position. 9. Click 'setprk'. This will set the park position to wherever you are now pointing. 10. Click Park (you can move the mount around first if you like, but if you don't then Park after a SetPrk before you power down, it won't remember the setting. 11. After syncing, setting a park postion, parking then powering down, everything should be fine when you power up and UnPrk - this should start the mount tracking and horizon limits and meridian settings will now be correct. And you don't need stars to do this! On next power up, slew to your target, platesolve, sync the mount to the platesolve and it will be more accurate. The park position may change slightly mechanically due to the more accurate sync, but this is easy to reset. With the encoders, there are 2 types - motor encoders that the Mesu mk2 does have and mount encoders, which are an option. You must turn the encoder settings to ignore if you don't have mount encoders. I'm fairly sure this page is nothing to do with the motor encoders. Hope this helps - you can play with all this in simulation, i.e. don't connect the mount.

If you go via the hand controller, don't you need to set the hand controller to 'PC direct' mode? Just a thought for the future.

Congratulations, welcome to the Mesu MK2 owner's club - hopefully the results speak for themselves! I'd love to take mine to Arizona or somewere similar, maybe in the future.

Just seen this on various websites. A great example of forward planning to capture a rare event. Quick video here.

Last year, based on say 80% true records, I had an average of around 1 night per week across the year where conditions allowed long exposure work. It isn’t as bad as it feels but sometimes it can drag on! Like at the moment. Last night for example, lots of cloud and 25% chance of rain predicted most if not all night, what actually happened was stars were visible, no real clouds for a time and patches of very clear but rain was in the air, you could feel it and see it with a laser pointer. Horrible transparency. So, although “not cloudy”, it wasn’t “clear”. So it gets an orange on the chart.

It looks bleak and doubtful it’ll change for the good any time soon. I can remember even 20 years ago the winters were mostly drier and clearer than now.

Lots of people are having the same issue, days, weeks, maybe longer without seeing stars or even a glimpse. I'm certainly no exception, so I tried last year to keep a spreadsheet of the weather directly locally to me, not based on forecasts but on real information. I could only do this visually before bed, then again in the morning. The problem was, I missed maybe 1 in 5 days for various reasons. This year, I have a new tool - an Allsky camera that's currently poking out of a window. Eventually, it'll be installed on the roof or something, hopefully running 24/7 without any issues. The software is running on a Raspberry PI 4 and every morning it spits out a timelapse, keogram and startrails image should it be clear. Here's a keogram example from nightfall to about 1am where I took the camera indoors due to incoming rain threat: This is a great way to keep a record, and an accurate one, and so far I have managed to accurately record how it has been since January the 1st. Here's a screenshot of my astro weather so far. I base it on (any time from sunset to sunrise): green=clear for most if not all night orange=patchy cloud, limited chances of maybe lunar or planetary imaging possible, or visual red=no chance. I wonder if anyone has had it worse so far?!

You'll be alright.....you could learn to parachute!

2nd engine did not fire correctly, debris in the air, something broke.

D'oh!

Falling!

Hovering at 10km

Liftoff!

10 minutes to launch!

The LabPadre stream is about 30 seconds behind the NasaSpaceFlight stream