Hi All,

I had the situation where certain parts of the sky would not plate solve, saying lack of sufficient stars.
I messed around with exposure time, I unticked the scale option, which was a issue some time back.
I thought it might be a regression issue

Any way been pulling my hair out, then finally decided to re-setup alignment from scratch.
1.) Push the retore defaults button.
2.) Check that your scope focal length is correct. (including reducers.)
3.) Check that your FOV is correct.
4.) NB Step ... untick all your index files and make sure that you select that they are deleted.
Now download fresh copy and reinstall these based on your FOV.

This seems to have corrected my problem, for all the problem points in the sky, where plate solve failed.
Still testing as all seems to be working now. Just want to check the Whale Galaxy in the early hours as well.

Hope this helps those that are having issues with plate solving suddenly not working.

Read More...

Hi All,

So I was about to post a thread on this myself, as after upgrading my EKOS, I had similiar problems where plate solving went loopy.
Not sure if this is related however it may solve your problem as it solved my problem.

I had the situation where certain parts of the sky would not plate solve, saying lack of sufficient stars.
I messed around with exposure time, I unticked the scale option, which was a issue some time back. ( I thought it might be a regression issue)

Any way been pulling my hair out, then finally decided to re-setup alignment from scratch.
1.) Push the set retore defaults button.
2.) Check that your scope focal length is correct. (includes flatteners.)
3.) Check that your FOV is correct.
4.) NB Step ... untick all your index files and make sure that you select that they are deleted.
Now download fresh copy and reinstall these based on your FOV.

This seems to have corrected my problem, for all the problem points in the sky.
Still testing as all seems to be working now. Just want to check the Whale Galaxy in the early hours as well.

Hope this helps those that are having issues with plate solving suddenly not working.

Read More...

Okay, making a bit more sense to me now.

Apologies have not had a good oppertunity for last 2 weeks, so have not been able to get a decent night to do this.
The reason i needed to drop down to 1ms is because my PEC cycle was generated off guiding data, where correction where being applied to the mount.
at 20ms, there are hardly any pulses applied with my (incorrect) data. I will need to do this with a log where mount corrections are not applied.

I suspect the west positive means west pier side as well. But would need to confirm this.

I think i understand dephase now, ie. in the data it will be a series of negative, then switch to positive for a while and then back to negative.
You want to count the number of pulses 1 per second to get to the point where the switch over happens. - Got it.

I think i am all ready now to try this for real, where the rain clears later this week.

Read More...

With some testing i have some observations.

Tests Conditions:
15 iterations of the worm cycle used with PECPREP. (autofilter on the log for best ones)
This is my guiding log at the end of a evening of imaging, with dithers removed manually from the log.
Guiding was using 3 second exposures, to remove seeing.
PECPREP PEC Error correction Cycle generated and exported with "save 10PEC cycles".
However my PECPREP data is 2 weeks old, so the phase would be completely out.

First Results:
Data loads correctly and runs through the system generating pulses (Yaay - see log)
I set mine to pulse at 1, so that for every index i get a pulse.
This is because i have a completely smooth curve generated by PECPREP.
I am hoping that this will mean no conflicts with my guiding system.
(When i record this for real.)

Next if you get the file name  / location wrong the driver crashes.
I suggest if you have a blank file name / location, then just start recording.
(ie for somebody that wants to record manually from GPG guiding.)
If file name / location > blank and not found, then a write an error into the log, file not found.

I do not understand West Positive, ie. how to work out if i should change this.

Lastly, when i do this for real, i am not sure how to get the Dephase number.
For this test I just set it to 100, to see how it works. (ie. it moves the index out by 100.)

Log File attached and PECPREP data attached. 

Wow, impressive results, this is looking fantastic. My guiding graphs when i am well aligned and balanced are 2 arc seconds up and down, which is very similar to your PEC graph.
What is the correction interval (i.e when you are recording, what is the interval of the guiding corrections?)

The reason why i ask, is that based on some research, i have seen that if you are using PEC, it is best to guide with a much longer interval.
i.e The recommendation is around 3-4 seconds, to reduce seeing effects (which works really well for me), but the timing of corrections are based on the accuracy of the mount.
I think if the correction interval of PEC is really small 0.2 seconds say, and guiding is all the way out at 4 seconds. (guide camera timing)
This will eliminate conflicts, because the PEC corrections will be many tiny corrections, continuously.
Then guiding corrections really, fix anything in the >1 arc second range due to other factors, etc.

It would be really great if you could test this and record the outcome again.
I suspect this will get your graph down to max 1 arc second each way.

i want to test your PEC approach, once you are confident, could you let me know with some detailed notes.
Also we should contact Jaseq so that he can promote your changes into the driver for Nightly.

This way we can get a broader range of testing from CEM 60 / 70 and other mounts.

Well down again.

Read More...

Thanks, new mission is to update driver to set the flip location as i sold my handcontroller.

Read More...

My iOptron mount, failed to do a MF last night, because my mount stops dead at the meriddean. (Not sure if this is Firmware?)
My ask is that we have the capability to say Flip Early (-ve) or Flip Late (+ve).

Thus I can say 10 minutes before the meridean schedule the flip, then it will wait for the last image to come in and do the flip.
Currently what happens is that if the image is still being taken on the meridean, then the mount aborts and stops on the meridean and just hangs there till the morning and my last image has star trails.

This should be pretty easy change as all we need is to unlock the timer to allow a negitive number?
Or have i missed something here, as i am pretty new to scheduler.

Read More...

Wow, you have been busy, nice! just reviewing your code now, it is looking good.

I will do some testing in next couple of days, when the moon overwhelms my data collection efforts.
As an aside, we may need to keep PEC playback in the driver, because the firmware clashes with guiding.
Something more testing may prove to fix, but i have seen a lot of reports of this happening with all iOptron mounts on the cloudy nights forum.

i.e As an solution i was thinking something like this.
Driver does playback of PEC file in a loop, based on the wormcycle.
If guide pluses come in a negotiation happens to see if it is a double count, so ignore the PEC pulse.
This way we completely bypass the chip on the mount. (until iOptron sorts it out the firmware)
This is what EQmod does PEC on the windows driver.

For this to work we should always park the mount and never disengage the cogs.
(I know this is a real pain, unless we can work out a way of finding the start position of the worm gear.)
This must be possible, because GPG guiding works it out. So if we can somehow grab it from there?

Another Option is we as iOptron for a firmware update, which signals the worm gear start.
This should be a small change for them, but it will take some time before it is released.

Read More...

Hello,

I have looked into this for the iOptron mounts, because you cannot load a PECPREP file into chip via the firmware.
ie. you need to do a old school recording on these mounts. So i just let GPG run for 60min, then i record a smooth run.
(re-record if guiding outside 2 arc seconds, also a windless full moon night is preferable)

The issue with this is 2 fold, GPG includes other periodic errors from polar misalignment, from balance issues and from PEC.
So for a permanently mounted observatory mount, this will work quite well, but for tear down mounts this is a major issue.
If you move your mount, then this is not a good solution as each setup, the balance and the polar align will be different.

Another solution you can test, if you are technically inclined, is to take the log from your guiding session and load it into PECPREP.
Then look for the best cycle, smooth it out and load it into your mount. (if your mount supports PEC file loading.)
I have managed to load the logs and generate a smooth cycle myself, but alas, i cannot load it into my mount.

Read More...

Hi all,

Testing is complete on the new version of the code. Parking works, slewing works, PEC recording and playback works well.
I managed to get a really nice smooth curve out of GPG predictive guiding and recorded.
If you want to create a PEC recording and then, to just image without guiding, then this is a great option.

However, once PEC is recorded and playing back, it is not possible to guide well anymore.
This seems to be a conflict in the firmware. From what i can see this is what happens:
PEC issues a predictive pulse and then guider issues a reactive pulse, so they double count.
What then happens is that the corrections get bigger and bigger as it doubles up.
If the firmware, could output the PEC pulses, the driver could spot them and cancel them.
or if the firmware could look for the double counts, then it could cancel them.

Both these require, iOptron to update the firmware, so not counting on this happening soon.

I will see if any work around exsit in code for other mounts.

Read More...