×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

HEQ5 Pro park position rears it ugly head again

  • Posts: 1029
  • Thank you received: 301
That might seem like a school sketch but:
((8227137-8388608)/9024000)*360=-6.44°

-Eric
5 years 4 months ago #31014

Please Log in or Create an account to join the conversation.

  • Posts: 424
  • Thank you received: 66

Well that's interesting. But it still doesn't make any sense to me. I'd still like to know the mechanism by which the mount itself has become misaligned after connecting Kstars. It works find with the hand controller and fine within Kstars but Kstars is changing something in the mount so that it becomes missaligned. What is Kstars writing to the mount? And why is it writing anything if so? Where do you get these numbers? The motors have no encoders, no gear values but you are assigning these numbers as if they do. I'm an electrical/electronics engineer with decades of experience and this doesn't add up. I'm sorry if I'm being a pest but it seems that false assumptions are made about starting encoder values. From what I've found, there's no such thing. Could you fill me in on the details because I really need to know what is happening here.

(the value 9024000 appears to be a full scale value but the DEC angle reported on mine is 10644627 which exceeds that. So where do you get this 9024000 value?)
Last edit: 5 years 4 months ago by Greg.
5 years 4 months ago #31016

Please Log in or Create an account to join the conversation.

  • Posts: 472
  • Thank you received: 165
HEQ5 motor controller doesn't retain any information after power off so the EQMod driver initializes it using ~/.indi/ParkData.xml which in my default configuration looks like:
<device name="EQMod Mount">
<parkstatus>
true
</parkstatus>
<parkposition>
<axis1position>
8388608.000000
</axis1position>
<axis2position>
10644608.000000
</axis2position>
</parkposition>
</device>

I use the default park position towards NCP with counter weights down. The values are in hex 0x800000 for RA and 0xA26C80 for DE. DE value is actually 0x800000 + 1/4 of stepcount for 360 degrees (NCP DE is 90) which for HEQ5 is 9024000 steps for both RA and DE. 9024000 / 4 is 2256000 which is 0x226c80 in hex and added to 0x800000 gives that funky DE step number. The intention is to initialize them to the middle of the numeric range of the step counters so that they don't wrap around. In any case, these values are the same for all HEQ5 mounts so if your ParkData.xml has something else, it's best to park the mount, write default values from driver, turn off the mount and possibly manually adjust the park position towards NCP if necessary. After this the parking function should bring the mount always to repeatable position as long as you park the mount before turning power off.

My observatory is remote and I can't do manual adjustments easily so after a position sync loss I manually drive the mount to park position using the mount control window via surveillance camera, turn off the mount power remotely and edit ParkData.xml to have parkStatus true so that the driver assumes the mount was parked and reinitializes it in roughly the correct position. Plate-solving and alignment takes care of the rest.
The following user(s) said Thank You: Greg
5 years 4 months ago #31018

Please Log in or Create an account to join the conversation.

  • Posts: 424
  • Thank you received: 66
Ok. So this is kind of interesting because in fact I’m starting the mount and putting it in the park/home position with the hand controller - so the motor controller is already initialized! Then I go to direct pc mode on the hand controller and connect with kstars.

So it looks like you are resetting the motor controllers values so that when the hand controller comes back online it’s -6 degrees off.

So it looks like the hand controller has somehow got a different home value than before because they used to agree - judging from the previous behaviour.

Anyway, now that I know what you are doing I can try your solution tonight and see how things work out. (I’ve had to do this correction before but for some reason I cannot get it to work now.)

Thanks!
Last edit: 5 years 4 months ago by Greg.
5 years 4 months ago #31034

Please Log in or Create an account to join the conversation.

  • Posts: 424
  • Thank you received: 66
There doesn't seem to be anything I can do about this. Fundamentally, you are re-initializing the step values after they have already been initialized by the hand controller. Here is the log output that says the motors are already initialized and then setting default init steps:

2018-10-30T22:13:03: [WARNING] Init() : Setting default Init steps -- RAInit=8388608 DEInit = 8388608
2018-10-30T22:13:03: [WARNING] Init() : Motors already initialized

To remain consistent with the HC, the re-init should not take place if an initialization is detected. (I'm guessing a step value of 0 is uninitialized so that if the values are 0, only then should they be initialized - but I suppose there's no real need to remain consistent with the HC.)

I don't know why there is this difference between the HC and Kstars initialization showing up now. The last time I was out was two months ago! I was just preparing for the next outing - who knows when that will be - the weather is so bad these days!

I see also, that I don't really have to have the HC and Kstars agree. Its just that it used to and now it doesn't. Once I've parked with Kstars, I can just turn off the mount. In the past, after parking with kstars, I would return to the HC and hit park and it gave a confirmation beep that it was already in position and then I powered off.

So I guess I'll change my operating procedure with the HC, just ignore it and power down after parking with Kstars.

Thanks for your help. I learned a lot!
5 years 4 months ago #31039

Please Log in or Create an account to join the conversation.

  • Posts: 1029
  • Thank you received: 301
There's really nothing related to electronics or anything. There are no values stored in the mount itself, only in the Controller.
Let's try this way: the origin of RA/DEC is the Home position. On HEQ5-Pro the Home position is ALWAYS 8388608/8388608, gear encoder values. Whatever goto request you will send, that value will be considered the origin by the CONTROLLER of the mount, be it the computer or the pad.
Therefore you need to make sure your parking position is always compatible with a NCP at 8388608/8388608, be it from the pad or from indi. Then you change the values used by the Controller to suit your needs.
So now, when starting your setup, either:
- the pad has proper initial gear encoder values set to 8388608/8388608 when pointing to NCP, so edit the INDI file ParkingStatus.xml, and replace the Parking values with 8388608/8388608 to sync.
- or the pad has improper gear encoder values at init (I think there is a sub-menu that shows the encoder values), and you need to factory reset, turn off and retry.

-Eric
5 years 4 months ago #31041

Please Log in or Create an account to join the conversation.

  • Posts: 424
  • Thank you received: 66

Thanks Eric.

Yes, I understand it's the controller that has the encoder values and by default, the home position should be 8388608/10644608 - thats what you meant, right? DEC offset by 90 degrees. But point taken, 8388608/8388608 is 0 deg/0 deg. And by default, the home position is pointing to NCP, weights down.

I have done a factory reset twice but the problem persists. I can't read the encoder values with the pad, it gives interpreted angles like when its parked at home, the position value is 0/90 (axis1=0, axis2=90)

Here are the discrepancies:
1. ParkData.xml says 0/90, not 8388608/10644608
2. when I connect with Kstars, encoder values reported is as I mentioned: 8227137/10644627 even though there is that message that the initial step value has been set to RAInit=8388608 DEInit = 8388608
3. If I unpark, move and park. Kstars returns to 8227137/10644627 (only thing thats as expected so far)
4. disconnect kstars, return to pad and it now reports -6/90. (it will report this whether I move the scope in Kstars or not. Simply connecting and disconnecting Kstars does this.)

So it appears to me that the pad is initializing to 8227137/10644627 - don't you agree? - and I cannot change it. And the message in Kstars about setting RAInit=8388608 DEInit = 8388608 does not make sense because kstars itself reports something different.

I'll look some more about reading and reseting the encoder values from the pad. The only other thing I can imagine is that the scope needs to go through an alignment procedure to fix the startup encoder values but thats a long shot.

Greg
Last edit: 5 years 4 months ago by Greg.
5 years 4 months ago #31051

Please Log in or Create an account to join the conversation.

  • Posts: 1957
  • Thank you received: 420
@gbeaton I am running the risk to come across as pedantic, but a few minor comments to your last comment:

"But point taken, 8388608/8388608 is 0 deg/0 deg" I think that should be 0 deg/90 deg

Mathematically speaking RA is undefined when DEC is at 90 degrees. This is so because at 90 degrees all RA lines coincide so it is impossible to derive an RA value. So when the pad reports -6/90 then that is the same as 0/90 or 6/90 etc. It depends on the internal math in the pad on how this is resolved.

Apart from that I have nothing to add to this discussion because frankly I don't now the details so please ignore all of this comment since it really isn't relevant.


Wouter
Last edit: 5 years 4 months ago by Wouter van Reeven.
5 years 4 months ago #31053

Please Log in or Create an account to join the conversation.

  • Posts: 1029
  • Thank you received: 301
Sorry for adding confusion quite stupidly!
8388608/8388608 is indeed RA=0/DEC=0. As 9024000 steps is one full rotation, 10644627 is (10644627-8883608)/9024000*360=90 degrees.
8388608/8388608 would have a properly initialized mount oriented horizontal.
From your explanation, KStars has proper gear values, and the pad has not. But you can't see a 6 degrees offset using only the pad of course.
So do the same as you described, and at step 4, request the pad to park the mount. The pad will move the mount to point to the NCP, but the orientation will be incorrect as you mentioned à 6 degrees shift. Shut down the mount, and physically move the mount to the NCP.
From there, you should have the pad in sync. Restart the mount and the pad, restart the INDI driver, and check how it considers gear values.
If you introduce an alignment in the process, you add a layer of complexity with the correlation between sky coordinates and gear values.
I for myself spent six months with the same sort of offset as you reported before noticing. That offset was caused by the scope hitting the tripod because of missed meridian flips, and caused the scope to hit the tripod even more, aggravating the problem! It was only when it attained 4 hours that I realized something was very wrong.
But something is tickling in your messages. We do agree that the shift is seen on RA, right? With all this said and done per my explanations, I currently have an offset around 6 degrees in DEC on my setup, that I did not investigate yet :)

-Eric
5 years 4 months ago #31059

Please Log in or Create an account to join the conversation.

  • Posts: 424
  • Thank you received: 66
Yes I agree. I think the pad is at fault and I asked myself what could possibly do that and I think the answer may be corruption in the firmware. Maybe the flash memory has taken a “hit”. I’m going to check everything again tonight and if I can’t change the encoder values I’ll re-install the firmware.
5 years 4 months ago #31065

Please Log in or Create an account to join the conversation.

  • Posts: 424
  • Thank you received: 66
Well I tried everything and no solution. I even updated the firmware because there was in fact a small update to V3 HC from skywatcher.

Yes, the shift is in the RA. I've tried what you said many times by now and its consistently off by -6 degrees upon.

I'm going to try EQMOD from a PC and see if it gives me any more insight.

I'm still concerned about these warnings when I connect which I've never seen before:

2018-10-31T22:25:28: [INFO] Mount is parked.
2018-10-31T22:25:28: [WARNING] Init() : Setting both ST4 guide rates to 0.5x (2)
2018-10-31T22:25:28: [WARNING] Init() : Setting default Init steps -- RAInit=8388608 DEInit = 8388608
2018-10-31T22:25:28: [WARNING] Init() : Motors already initialized
2018-10-31T22:25:28: [INFO] EQMod Mount is online.
2018-10-31T22:25:28: [INFO] Successfully connected to EQMod Mount.
5 years 4 months ago #31072

Please Log in or Create an account to join the conversation.

  • Posts: 424
  • Thank you received: 66
AH HA!!!!

I found it. Its not the pad. And its not Kstars (sort of).

Its StellarMate!

I connected my laptop directly to the mount and ran kstars and it worked fine. Returning to the pad, there was no RA error.

So something in StellarMate changed. Maybe its flash was "hit" lol

I suppose there is a clue in the previous logs I sent you.
5 years 4 months ago #31073

Please Log in or Create an account to join the conversation.

Time to create page: 1.300 seconds