EQ6R Pro Motor Board Firmware v3.45 - be wary

I consider myself pretty fluent with these mounts. I cannot fathom any reason why recording a PEC curve would de-sync the mount and force it to return to home position, much less the wrong hemisphere. Also, both EQMOD and GSS will certainly reject any sync command that is not within a couple degrees of where it thinks it is.

The only reason I could think of why the mount would ‘lose position’ and try to park would be if you were using EQMOD or GSS and the limits settings option forced it to the park position instead of simply stopping it. This is an option in both software. BUT, that would still require the mount to get out of sync first.

I almost wonder if you have some other underlying issue. A slew to the opposite hemisphere can be caused by lack of location awareness, or it could have simply been a time thing. Again, the mount reject any sync beyond a reasonable error, so I can only assume you might have lost power, or browned out. Also, when the connection is not stable, you will often see the mount simply stop tracking, which MAY explain why you saw it not being able to calibrate, or guide, because sidereal may have been off.

Also, look for flashing queues from the red light on the mount. There is a slow flash (2x for PEC training and 3x for PEC active), as well as faster flashing that indicates low voltage conditions or brownouts.

I’m always trying to figure out all the little bugs and quirks for these mounts, so if you have any logs from NINA, or PHD, I’d gladly love to disect them.

Chris Jensen · Jul 30, 2026, 11:03 PM

Hi Brian,

I’ll get the log files tonight and post them as well as dig into them to see what I can find. Last night I was so focused on working out what was happening with PHD2 that I didn’t even think to look back at the log files.

Thinking back on what I observed with the mount crashing. I have Point 3D running whenever imaging so I can see the position of the mount from in my house. I was imaging RCW103 while recording the PEC. I uploaded the curve to the motor board, confirmed it was uploaded (I think I did this right but I might have misunderstood the steps) by pressing the refresh button in EDMOD. The message changed from PEC is training to PEC is off once the loading was complete. I enabled PEC in EQMOD. The mount was tracking well and I did see an immediate improvement in guiding accuracy. After about 10 minutes, I saw the mount position on Point3D flip 180 degrees briefly and then immediately saw on PHD2 that the mount was slewing.

You are correct that I have slew limits set in EQMOD to prevent possible clashed between the imaging train and the tripod. I am assuming that these were triggered and the mount was attempting to return to the home position. A quick look into the yard confirmed the mount was moving and was well past the horizontal and was inverted heading for the tripod leg. I hit the stop button on EQMOD to prevent that.

I released the clutches, restored the mount to the park position, powered down and restarted everything. I did not enable PEC on the motor board again, but I did get the scope back on target, recorded a new curve and ran it in software on EQMOD. The mount ran without issue for the rest of the night. The next morning, I looked into what the current firmware version was for the EQ6R motor controller. I was on V3.14. Looking at the release notes (see below), they seemed to indicate that there was some issues with PPEC training in the Southern Hemisphere, where I am imaging from, so I considered an upgrade to the current firmware release as a reasonable action to take.

I did see your note about southern hemisphere and PEC. I’m curious about that issue and I’ll probably see if I can find the root of it today. Still, I can’t fathom how this situation would occur unless it was a serious flaw in the firmware.

Also, use caution when imaging while recording your PEC. Dithers will will be recorded as well. I presume you recorded the PEC curve for a couple rounds in EQMOD, THEN hit the record button on the right? I only ask because you said you noticed an immediate difference, however I do not believe you should notice it immediately. This is because the PEC playback will not occur until it rolls over the sensor.

Lookin forward to your logs. PHD probably wont give me as much as the NINA log can, but both will tell alot.

I’m gonna look a bit deeper at this tomorrow, it’s a bit late right now but I’m seeing a couple things right off the bat that concern me.

Your focuser is having issues intermittently throughout the night. It’s failing to move, constantly throwing temperature errors. It’s reporting a driver error as well. Coincidentally, these errors also occurred at the same time your say your scope decided to slew towards the ground. There is a whole slew of ASCOM errors throughout this log. Mount as focuser both are having issues. Do these two devices have any connection in common? A hub?

I don’t see a single significant issue in PHD other than it lost the star.

You dithered throughout the night, which tells me you dithered during PEC training. I wouldn’t do this, but… that shouldn’t cause the issue.

There are a whole slew of things we could do here to troubleshoot, but I would do them systematically. I would look to reinstall that focuser driver, maybe even update ASCOM if you haven’t already. Run a test and investigate to see if this focuser error goes away. If it does not, then I would start investigating connection issues or power. I know you want to believe that your mount has an issue, but I’m not so inclined seeing as theres a whole lot of exceptions and errors in that log. I will investigate more tomorrow once I get a chance. A developed, systematic approach to troubleshooting this can hopefully not only fix it, but tell us why it happened.

I glanced through again. I can’t pin my finger on it really but whatever happened was not initiated by NINA. I was hoping someone else might chime in with some input. I’m leaning towards a combination of two issues. You definitely have some connectivity issues going on first of all. Second, your mount was ‘offline’ for around 10 seconds before your unusual movement happened. It was right in the middle of the exposure run. This could be related to your firmware issues, or a connection issues, maybe even both. NINA made no record of the movement either. Right around the same time your focuser was not responding either.

Here are the important lines:

2026-07-29T20:41:41.3363|INFO|SequenceItem.cs|Run|254|Finishing Category: Guider, Item: StartGuiding

2026-07-29T20:41:41.3364|INFO|SequenceItem.cs|Run|254|Finishing Category: Instruction Set , Container: NINA.Sequencer.Container.SequentialContainer, Strategy: SequentialStrategy, Items[FINISHED]: 1

2026-07-29T20:41:41.3364|INFO|MeridianFlipTrigger.cs|ShouldTrigger|211|Meridian Flip - Flip for the current target already happened at 07/29/2026 19:33:56. Skip flip evaluation

2026-07-29T20:41:41.3365|INFO|SequenceItem.cs|Run|208|Starting Category: Camera, Item: TakeExposure, ExposureTime 600, Gain 139, Offset 42, ImageType LIGHT, Binning 1x1

2026-07-29T20:41:41.3389|INFO|CameraVM.cs|Capture|742|Starting Exposure - Exposure Time: 600s; Filter: ; Gain: 139; Offset 42; Binning: 1x1;

2026-07-29T20:44:36.8874|WARNING|DeviceUpdateTimer.cs|Run|115|Mount value update cycle took longer than the device poll interval (Total: 9.76s > 2s; Poll: 00:00:09.7557804; Update: 00:00:00.0001429)

2026-07-29T20:45:17.2799|INFO|Sequencer.cs|Start|85|Sequence run was cancelled

2026-07-29T20:45:17.2830|INFO|Sequence2VM.cs|StartSequence|548|Advanced Sequence finished

2026-07-29T20:46:06.2763|ERROR|AscomDevice.cs|GetProperty|546|An unexpected exception occurred during GET of Focuser.Position:

ASCOM.DriverAccessCOMException (0x80131505): The operation has timed out.

---> System.Runtime.InteropServices.COMException (0x80131505): The operation has timed out.

I also noticed at the beginning when you first started NINA you had issues connecting to the mount as well. Overall, I’m a bit at a loss, but if it were me troubleshooting, I’d still look for any connection issues. The park/slew command that you experienced seems to have been internal, as far as I can tell. You don’t have a hand controller connected do you?

Chris Jensen · Aug 5, 2026, 10:57 AM

Hey Brian,

You have ended up pretty much where I did with my look into it. No I dont have the hand controller connected. I use the direct connection to the USB port on the mount.

I definitely have a USB connection issue that I am hunting down. It’s related to the Esatto’s power needs, so I am getting a 12v cable to give it power from my Eagle 5S and the cable to my ECCO dew heater controller is flaky, so I am replacing that. I don’t think either are the cause of the crash.

As best I can tell, the mount position moved only in software, and it triggered the limits I had in EQMOD. How that happened and why, don’t know and none of the logs from the rig captured what happened.

Upgrading the firmware as a possible fix for the crash produced its own separate issue. From a mount firmware point of view, EQMOD did not appear to like v3.45 of the mount firmware. Guiding pulses from PHD2 for the RA axis were only being applied at about 25% by EQMOD from what I could see when attempting to calibrate. No setting changes in EQMOD or PHD2 made any difference to the issue. I wasn’t able to find a copy of v3.14 online, which is what I was previously running, but I did find v3.39. As soon as I rolled back to that version, the issue vanished.

Where am I at now with the rig?

1. Fixes pending for the USB issues.

2. Upgraded to ASCOM Platform v7.1.3

3. I lost faith in EQMOD, want better logging capability and software that is actively being supported so I am trying Green Swamp Server. So far so good with it and I am finding the mount is guiding a lot better when PHD2 is interfacing through GSS compared to EQMOD.

4. I’m building a separate mount limit solution for my RA axis. Still playing at this stage but it may end up being a simple hall effect sensor on the stationary part of the mount and two magnets on the RA axis that trigger a relay to cut power to the mount at points where the RA goes 5 degrees past the horizonal on either side of the pier. Simple, no software and it cuts mount power in the event of an issue.

5. At some stage in the future, I may upgrade the mount firmware to v3.45 just to see if GSS plays nicely with it to confirm my theory on EQMOD, but right now, I am happy to have the mount working and performing well.

I have alot of faith in EQMOD. I’ve never had any issues like that, and GSS’s limit options seem rather elementary in my experience. But, EQMOD could very well have been an issue. While I love it personally, I know others who have had issues.

Very interested in your mag switch idea though. Curious how it works once you get it in play. It would probably have to be on a time delay IMO, or you’ll be forced to go out and move the mount back into position.

I will say the mount clutches do slip under load, so in the event if you actually going around and crashing, you’re not likely to really do any damage.

Be sure to post updates as you figure things out. I’m invested now :)