×

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

Bi-monthly release with minor bug fixes and improvements

EQMOD/EQ6-R regression/fault?

  • Posts: 225
  • Thank you received: 16
Tracy,

Sorry for your issues. I also use an EQ6R Pro and am using the latest build, but not experiencing this issue.

One thing you mentioned (and may have misspoke) is that you are "in DST here". I don't know where you are located, but we are not in Daylight Savings Time here in North Carolina.

Good luck!

Ron
Last edit: 1 year 4 months ago by Ron Clanton.
1 year 4 months ago #88088

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

  • Posts: 70
  • Thank you received: 10
TZ offset is -6 now, whereas before the time change it was -5... so the TZ is set correctly, even though I may have typed DST we are in CST - the offset is correct though.
I mistyped as I was also working in PI trying to figure out how to do color on narrow band before Stellarmate OS took a mighty dump on itself after a meridian flip.
Last edit: 1 year 4 months ago by Tracy Perry.
1 year 4 months ago #88091

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

  • Posts: 12
  • Thank you received: 0

Replied by James on topic EQMOD/EQ6-R regression/fault?


So I'm one of those boring system administrator types who insists that all their servers and other headless devices run in UTC; both Pis are set to Etc/UTC as a timezone and were showing good NTP health, and manual checks showed them synchronised to what I expected. There is a GPS/gpsd on the telescope Pi for location data, which is a little redundant given it's a stationary setup, but it isn't used as a source for system time (e.g. by chrony, as PPS/GPS ref, etc). I'm also in the UK, so in GMT anyway. I also had this issue with local time as BST, a month or so ago.

I will double-check, but I am very confident it isn't this. Good thought though!
1 year 4 months ago #88096

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

An update is pushed to StellarMate & INDI PPA Stable channels. Please check.
1 year 4 months ago #88103

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

  • Posts: 349
  • Thank you received: 107

Replied by nou on topic EQMOD/EQ6-R regression/fault?

I had once similar problems like these with my EQ6-R. I solved them like this.
1. slew to some point away from pole
2. plate solve with action set to do nothing just to get align error.
3. manually adjusted scope position without moving mount to remove align error
4. repeat from step two to get until I got error to half a deg.

After this I get much better initial align and got rid instances when mount refused to move to correct position.
Last edit: 1 year 4 months ago by nou.
1 year 4 months ago #88119

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

  • Posts: 12
  • Thank you received: 0

Replied by James on topic EQMOD/EQ6-R regression/fault?

OK, so I rebuilt everything from scratch on the INDI side. Fresh Raspberry Pi OS install (Lite 64-bit) and Astroberry repositories set up.
I set up chrony for NTP sync with the UK pool and local servers, and set the gpsd plugin to use the system time so there was no confusion from the GPS. All the clocks in KStars, local system time on both machines, etc all synchronised to UTC and using the same timezones (Etc/UTC).

I used default configurations for everything otherwise in INDI etc.

I left the scope in the home position, pointed at Polaris, and powered up. I then solved a few times and got wildly differing answers. I then moved the scope (slewed from software) and tried again, and again had wildly differing answers while the image remained perfectly still (160 degrees error).

File Attachment:

File Name: alignfail_...1-15.txt
File Size:1 KB


Interestingly the KStars EQMod Mount position indicator is perfectly correct throughout all this.

I then repeated the Polar Alignment routine and got to below an arcminute, just to be sure of that, and tried using the internal solver and got similar answers.

So, no luck so far.
1 year 4 months ago #88171
Attachments:

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

  • Posts: 225
  • Thank you received: 16
That's really weird. I've never had this problem with my similar setup. However, I use StellarMate... so things may not be exactly the same.

One thought... Have you tried taking the GPS and NTP Sync out of the equation? Those are two components that I don't use. I just setup the location manually and get the time from my home network. I'm thinking that there may be some issue with their interaction???

Ron
1 year 4 months ago #88173

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

  • Posts: 12
  • Thank you received: 0

Replied by James on topic EQMOD/EQ6-R regression/fault?

I took GPS out of the equation, both by setting it to use system time in the gpsd INDI driver settings, and by turning the gpsd driver off entirely.

NTP sync is essential to keeping everything to UTC since nothing has real-time clocks, and is working correctly. Time really isn't an issue here! Location from GPS was correct and the site management tab of the EQMOD driver had correct information.
1 year 4 months ago #88175

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

  • Posts: 225
  • Thank you received: 16
Okay... and KStars shows the correct location and coordinates in the lower left corner of the display?

If that checks out... I give up! Someone from the support team will need to weigh in.

Good luck!

Ron
1 year 4 months ago #88176

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

  • Posts: 12
  • Thank you received: 0

Replied by James on topic EQMOD/EQ6-R regression/fault?

OK, I thought about taking the hardware and second PC entirely out of the equation and I can reproduce this in KStars using nothing but the telescope and mount simulator.



So this looks like either a bug in the astrometry.net side of things (unlikely, I'd have thought) or KStars... but it's definitely not the mount/telescope/etc!
1 year 4 months ago #88199
Attachments:

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

  • Posts: 70
  • Thank you received: 10
Don't know about anyone else... but had a chance to get out tonight as it was clear, and when trying to GoTo (via KStars to Caph to check the alignment out, the tracking in KStars simply stopped about 1/2 there and the mount quit responding. I disconnected the EQ6R-Pro and then connected it back, and ti continued slewing to the target and was able to do an alignment with it.Then, I decided to target NGC_133. Gets in the general area, and then when it is trying to complete the alignment, it can't as it does not appear to be slewing the mount to change the alignment.Power the entire system down, start it all back up, and it starts and runs OK... UNTIL I have to go out to do some weight movement for the RA. Try to do an alignment again after this and rinse and repeat the above cycle.Then to top it off, the guiding (which I have configured to use EQMod) for the DEC went from a fairly steady 0.23 to over 23.5 in a matter of seconds and then was bouncing all around... and when checking the scope, it seemed rock solid. And these are using same placement marks for the scope that I have been having excellent luck with.

I then attach my ST4 cable and change the image train for the guide scope to track using the ZWO ASI290mm and then it goes back to this (which is not the greatest it's been but MUCH better than what it was earlier tonight).



Now, tell me, how exactly do I have "insufficient stars" in the image to do alignment?
I've even got both 8.8GB data sets loaded to use for alignment.


I'm beginning to have some serious doubts about StellarMate OS on the RPi. Seems like ever since the optical trains were instituted into the mix of software, stuff has gone off the rails (and I have a strong suspicion the similar developers are involved in both). And I'd REALLY like to be able to enable the logging, but StellarMate OS then became totally unresponsive to ANY input via VNC.Then, when I go outside to check the mount and scope, the weights are pointing directly west, and the scope is pointed directly up... which is nowhere NEAR where the target it was supposed to skewing to was.

And here is an example of going back to the EQMod tracking a few hours later after using ST4 and the camera.


As you can see, it went fully back to crapping all over itself using the EQMod driver after over 5 hours of tracking successfully using ST4 interface.

And here we are back to using the ST4 interface 2 minutes later with NO changes made other than changing the optical train to the camera (ST4) and then doing a new alignment (which detected within range) and starting the guidng up again.



So, in my limited knowledge of programming and astrophotography but many decades of dealing with programs and BETA testing, I strongly suspect there are still issues with the EQMod driver that have not been resolved. To put it in a nutshell, it still seems to be farkled beyond regular use
Last edit: 1 year 4 months ago by Tracy Perry.
1 year 4 months ago #88242
Attachments:

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

  • Posts: 593
  • Thank you received: 274

Replied by John on topic EQMOD/EQ6-R regression/fault?

This may or may not help, but... whenever I have issues with the mount not doing what it should I park it, goto the mount tab and press "Clear Model". Then start again.
1 year 4 months ago #88251

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

Time to create page: 0.801 seconds