开云体育

Greetings to you, I use Stellarium as a planetarium software to control my G11 via ASCOM. Yesterday I updated to version 24.4 Qt6. Bad mistake. Stellarium does not establish a connection via ASCOM with version 24.4 Qt_6_. Unfortunately this is a bug especially for Qt6. A new installation with version 24.4 Qt_5_ and everything works as usual. Just for your information /cheers Rainer

What does this command actually do? I mean, I know what Zenith is and what the mount should do, however I'm curious about how it does it. Is the mount actually slewing to alt 90 deg, az 90 deg? Or, is it slewing the telescope relative to CWD? Reason I am asking is my scope had no issue parking at CWD or at Zenith, but it was "lost" otherwise (until I plate solved to correct it). It took me a while to figure out that the mount was "lost" because I kept parking at Zenith and CWD before slewing to a target. The parking positions were fine, the target slew was terribly wrong.

Hi, Last night PHD2 suddenly stopped guiding during my imaging session. I noticed the Ethernet connection between Gemini-2 (L6) and Intel-NUC (i5), which was newly installed, was failed somehow. I remember I've been getting Communicaiton error recently, even Gemini-2 and ThinkPad X270 environment before. I looked into the log. Indeed I found "Terminating connection!" error [21:52:03.454] corresponding to the above event and also other Ethernet connection errors [18:22:13.537, 18:22:15.587]. I think Ethernet connection should be stable. What makes this kind of problems? Bad Ethernet cable? Or should I reflash Gemini-2? Any comments welcome. masami P.S. I put the log file "ASCOM.Gemini Telescope .NET.1822.083970.zip" in the files section.

Hi All, I recently hooked up a Linux PC/indi driver to my Gemini 2, and it seems that ever since then my ASCOM driver or Gemini 2 does not track in sidereal (RA). I’ve reset my USB Settings in Windows, I’ve reset my Gemini 2 controller, powered off, and then cold restarted, and I’ve also re-inputted my mount’s settings. Still, when the mount is commanded to slew to a point, such as when calibrating PHD2 guider or starting a sequence in SGP, it does perfectly but instead of the expected point stars, I observe star trails and no sidereal tracking upon reaching the target point. I’ve uploaded a set of troubleshooting logs located in files/ “promero 12-3-2024”. A look at the gemini webpage for iphone shows nominal voltage and battery voltage. I have tried going back to the .25 ASCOM driver version, but nothing changes. I have the latest firmware updates. The mount is a MI-250. In a perhaps related issue, when used, my ethernet connection disconnects after a minute or two, but my USB connection seems stable. This started occurring after I changed my router model and network physical setup. All other network devices work fine. Clear Skies, Paul [mod: fixed text color]

The following items have been added to the Files area of the [email protected] group. /Logs_and_error_files/promero 12-3-24/Gemini Telescope Driver Report.zip By: Paul Romero <romerowestridge@...> Description: troubleshooting log files

I recently updated ASCOM to platform 7. The ASCOM telescope chooser now presents the following warning when selecting Gemini Telescope.NET. “Incompatible Driver (ASCOM.GeminiTelescope.Telescope) - Unable to find a CLSID for this driver, please re-install.” I tried reinstalling the driver as the warning suggested but no change. It did not show this warning with platform 6.6. Weird thing is, some apps show it (SkyTools 3) and some don’t (Stellarium). Also, even with the warning I can successfully connect to the telescope. The ASCOM Diagnostics utility reports no problems found and the log lists the Gemini Telescope.NET driver and the CLSID associated with it. The registry also shows the same CLSID as shown in the ASCOM Diagnostics log for the Gemini driver. Anyway, not sure if this is a Gemini driver problem or an ASCOM 7 problem. I just wanted to report it and see if anyone else has seen this warning. Either way, I can still connect to the Gemini Telescope, so it’s not a showstopper. Bill Flanagan

Hi, I am not sure if this is a hardware issue or possibly related to ASCOM 7 beta work but I am getting connection errors with pulse guiding in PHD2. I am using 1.1.28 and my G11G is running L6. I tried cleaning the ethernet cables to the Gemini-2 and my PC and will replace them also but hoping someone with more experience of the Gemini driver logs could have a look at the attached ASCOM and PHD2 logs to see if they recognize the errors and can form an opinion. Any guidance appreciated. Ken

I was recently forced to upgrade to Gemini 2 when my trusty old Gemini I shot craps and was unsalvageable. As you know, the Gemini I connected to a PC via a Serial/R12 cord, which is not available on the new controller. I want to connect via an Ethernet cable (cat 5) from the Ethernet port on the Gemini 2 directly to the Ethernet port on my PC. I've now gotten the cable, and have connected the two units. My guestion: What do I do now to make this connection operational, so I can connect with N.I.N.A. and The Sky to control my mount. Any help from you old pro users of Gemini 2 will be greatly appreciated! Thanks. Ron Abbott

This is probably a direct question for Paul but others can chime in if they want: I've recently started to have meridian flip issues (e.g. the mount doesn't flip and just stops at the limit). I have been running the Advanced Sequencer for >6 months with the Target Scheduler plug-in and it does everything correctly (perfectly even) except for the flip (only recently). When I look at the NINA logs it appears that NINA thinks the mount is still parked, and skips the flip command. The mount is definitely not parked as it is slewing around, platesolving, and dithering. I made sure to incorporate an "Unpark Mount" in the advanced sequencer after any "wait" command and before any slews after it has been parked as part of the sequence. I am using a G11G (Gemini II Mini/Level 6) and I recently switched the Park Mode from "Every Move" to "Explicit Wakeup" for an unrelated reason. I'm wondering if the problem is that NINA isn't interpreting the mount correctly, or if the mount is reporting incorrectly... I can't tell by looking at the log, which I've attached. In the meantime I've switched the Park Mode back to "Every Move." Battery is 2.994v and holding stable for months. Power supply is Losmandy provided and giving 15.069v. Mount connection is ethernet. Basically, I'm not too bothered if I have to keep the Park Mode at Every Move, but I just want to make sure it isn't another issue somewhere; if you can even tell. If it seems like a NINA issue, I wanted to be able to word it correctly on the Discord so that it can perhaps be fixed. I know these things can be fairly nebulous but you are a pretty sharp dude and thought you might have seen this before. Thanks in advance! Ryan

Hi Folks, An updated version of the driver, v1.1.28 is now available for download: https://gemini-2.com/ASCOM.html This version adds two fixes for reported issues: Fix for AtHome status not updating when the mount is unparked Fix for NINA time not matching with PC time warning message on NINA start-up Please report any issues here. Regards, -Paul

Greetings everyone, My mount was working a charm with 1.1.25 until very recently (I had some timeout issues similar to the description below with earlier driver versions). Now, back a few days ago and using the slew-and-center on NINA's framing wizard, the driver freezed out and had to reboot. It happened again last night. This is the only anomaly I encountered on the log file (I could share the entire log, but its just that the file is quite large): 19:50:52.269 IT:SideOfPier.Get TID:5 [Enter] pierWest, 90 20:30:45.546 IT:SideOfPier.Get TID:29 [Enter] pierUnknown, System.TimeoutException: Mechanical Declination[0D][0A] at ASCOM.GeminiTelescope.GeminiHardwareBase.get_MechanicalDeclination() in C:\Users\ypa\Documents\Ascom.Gemini.Telescope\GeminiTelescope\GeminiHardware.cs:line 5097[0D][0A] at ASCOM.GeminiTelescope.Telescope1.get_SideOfPier() in C:\Users\ypa\Documents\Ascom.Gemini.Telescope\Telescope\Driver.cs:line 1976 Two sample lines. The first one indicates that the side of pier seems to be correctly established upon connection. Everything worked fine including polar alignment using NINA, plate solving tool on NINA and calibration on PHD2. Nonetheless, later in the evening, it started reporting a timeout exception and happened precisely when using the framing wizard on NINA. I have tested different cables and I would rule out any defect on the cable as I have three new ones and same problem on each one of them. A couple of questions here. Is it just that Gemini 1 should not report the side of pier and perhaps should disable it on the settings? Is it something with NINA's framing wizard that is simply not working right? Anyone else having trouble with the framing wizard on NINA? It is the only instance that creates this issue. As usual, I thank you all and especially Paul Kanevsky in advance for your thoughts on this issue Cheers Guy

Hi Folks, A new test version of ASCOM driver is now available, 1.1.26. This version introduces a fix for the occasionally reported issue where NINA warns of a large time difference between the PC and Gemini time. If you use NINA and have seen these time warnings before, please install v1.1.26 and see if this resolves the problem: https://gemini-2.com/ASCOM.html Please post your results here, and include an ASCOM driver log for any session where you've encountered this or any other issue with the new driver. Regards, -Paul

For those who track this stuff there is a newly released ASCOM 7 RC2 available that may be of interest to some folks here. Look at the ASCOM Talk group thread for more. ASCOM Platform 7 - Release Candidate 2 Pre-release The installer is located in the "Assets" section at the end of these release notes Release Candidate 2 Changes from Release Candidate 1 Fixes a backward compatibility issue where drivers that use Platform 5 or 5.5 components fail with assembly not found exceptions. Platform 7 Highlights and Dependencies This release focuses on the asynchronous behaviour interface changes agreed in the consultation held between July and October 2023. Use of asynchronous programming techniques improves the end user experience by ensuring that user interfaces remain responsive while long-running operations are underway. Their use also speeds up tasks by enabling operations to be run concurrently rather than serially. The release implements the consultation post-feedback interface changes and is backward compatible with Platform 6 and earlier clients, drivers and Alpaca devices. The Platform requires the following Windows and .NET versions: Windows 7 SP1 or later .NET 3.5 to be installed (Windows 7 and 8 only. .NET 3.5 will be activated automatically on Windows 10 and 11.) .NET 4.8 to be installed Changes for Everyone in Platform 7 Simplified Start menu The default log file location can be customised to something other than Documents\ASCOM. Focus on technical changes to improve performance and application usability. Updated user guide that includes Alpaca. ASCOM Remote and the ASCOM Omni-simulators are now installed as part of the Platform and do not have to be downloaded and installed separately. The Omni-Simulators are now the default Platform simulators. A Camera Hub has been added to enable 32bit camera drivers to be used by 64bit applications. An alert will be generated when a new Platform version is released. The Platform installer is more resilient and reliable. Platform Issues fixed in Platform 7 The installer no longer displays a successful install message when an error occurs Changes for Developers in Platform 7 The developer components are now included with the main installer and no longer need to be installed separately. A new DeviceState property for all interfaces that returns the entire device operational state in a single call. New asynchronous Connect and Disconnect methods for all interfaces. New asynchronous methods and API clarifications. The "How to make an ASCOM driver" document has been completely re-written to document the current process. New platform-neutral online documentation: ascom-standards.org/newdocs Increased documentation clarity on where asynchronous operation is expected DriverAccess now has convenience methods to retrieve device state in a single call. The driver templates have been updated to support Platform 7 interface changes. SOFA has been updated to release 19 as issued on 11th October 2023. Please not that Platform 6 versions of Conform are incompatible with Platform 7 and a warning is issued by the Platform installer to this effect. An updated Platform 7 compatible version is available on GitHub. Interface version numbers have all increased by 1. Development Issues fixed in Platform 7 NOVASCOM – Fixed error in Sun Ephemeris calculation introduced when the Code was transcribed from C++ in 2009. Driver template – Fixed issue in Focuser Link code that resulted in an out of the box Conform fail. Fixed issue in NOVAS 3.1 component where the ephemeris file may not have been closed on DLL unload. The installer now pre-populates historic leap second data so that AstroUtils.DeltaUT1 works out of the box when there has been no earth rotation data update. Fixed a bug introduced in Platform 6.6 SP2 where a DriverException was returned instead of more specialised exceptions like InvalidValueException. Installer SHAs SHA256: 586db96645380e9a743f138a7dea31e6252091f493d29268dc9dfbf50c574694 SHA1: 67cad04a3b14b24953292c7ebb82fb419df4102c Assets 3 ASCOM Platform 7 - Release Candidate 1 last week Pe