Greg, I'm not sure where you are getting the .57 arcsec figure. If you plate solved my M83 image that image was taken with the barlow at a slightly different distance from the CCD. The photo below, taken at 2x2 binning, was taken just before the PE run I posted in my first post. When I collected data I didn't bin.
The plate solve shows 1.08 arcsec at 2x2, and it shows a position angle of 2 degrees 57 min from North. The MX manual states to have the camera within 5 degrees. Am I incorrect about this?
Hi Peter,
I just used Wodaski's CCD calc and plugged in TEC140, the size of the camera pixels, the number of camera pixels in both directions and the 2X barlow. It gave me 1.14 arc secs. But your barlow may not be exactly 2X. I wonder if that plate solve is dead accurate or if the CCDcalc is.
It doesn't sound like much of a deviance either way.
Well, I wish I had better news to report! Another frustrating night. Issues with TSX continue. It crashed running the ST-i, had trouble plate solving, and still has strange file opening issues. The St-i crash occured trying to take .1 sec exposures. It crashed after 3 min. I rebooted and was able to take 12 min of data at .5 sec exposures.
Josh, that link to Jonathan's post at SB was very good reading. Unfortunately it doesn't look like I made a mistake as best I can tell. But, tonight I decided to change camera, and use TSX rather than CCDSoft. I carefully positioned the ST-i to within 1 degrees from North, and plate solved it as .75 arcsec. I was careful to have the position angles as "zero" with the scope pointing West, the same side I collected data.
Anyway, my measure PE is 2.2 arcsec peak to peak. I saved the curve to the mount, enabled PEC and collected PE again. PE increased. Just to waste some more time I redid the curve with West checked, replaced the correction curve, re-measured PE and it was even worse (as expected!).
What I notice is that the rapid oscillation (pinion gear?) was smoothed out a lot, but that the gradual error remains and is increased. I don't get that. It seems to me that if one is fixed the other ought to be as well.
I'm not sure at all what to do next. If it's something obvious that I am doing wrong I just can't see it. Reaching for anything, could it be latency in my USB cables? I'm running active cables just a bit longer than the recommended length. Or maybe TSX is messed up?
Peter
PS Yes, I see that the plate solve I've posted says .74 arcsec. 5 previous solves rotating the camera all said .75 so maybe the focus shifted a tad? I can't see that as the issue.
If you havent already, i would also put this issue to the SB support group.
edit, i see you have.
Josh
Thanks Josh...Yes I am running the build released just yesterday. I had high hopes for that build given that the past few builds have been "difficult" but alas it seems to have the same issues.
You should be using your imaging camera or if you are using STi your image scale would be way off. Its a function of focal length, pixel size,
aperture and sensor size. That image scale was for your 8300 chipped camera not an STi.
You should be using your imaging camera or if you are using STi your image scale would be way off. Its a function of focal length, pixel size,
aperture and sensor size. That image scale was for your 8300 chipped camera not an STi.
Greg.
Well, why not? I plate solved the ST-i and got .75 arcsec which is what I used to compute the new curve posted above. My G2-8300 won't run reliably in TSX through ASCOM, but the ST-i does without issue (except for a possible problem with the current TSX build). In fact, I feel it is rather independant verification that I got an almost identitcal result to a curve I posted at SB (not the one here) that I did with my G2-8300. Both show error of 2.2 arcsec. One curve is inverted because that time the camera was at 180 instead of 0 degrees PA, but he cycle looks pretty much the same. Anyway, I wanted to collect guiding data in TSX to rule out any possibility that CCDSoft might be at fault.
Fair enough. My comment was directed at the original post that showed a different image scale. I thought you've been using the STi for all these PEC runs in which case the obvious thing would be the image scale was incorrect.
Fair enough. My comment was directed at the original post that showed a different image scale. I thought you've been using the STi for all these PEC runs in which case the obvious thing would be the image scale was incorrect.
Greg.
No worries!! Certainly with all these posts it is hard to keep in mind all that is going on or changing. I always value your comments! So, many thanks!
Peter
More info gathered last night. Possibly something is emerging here, but not sure. I received some feedback from another MX user in the USA that advised me to not shoot such short exposures. In fact he said that such short exposures may introduce some issues of latency in evaluating just when the picture was taken vs the actual worm position. I know this goes against some advice and actual result also presented in this thread, but I though there would be no harm lost in trying out more delay between exposures.
Last night I collected data with .5 sec exposures and a 2 second delay. The curves are compared in the attached photo. Whilst there are certainly similarities between the two curves, there are also obvious differences. The differences that concern me are the differences in the start and end points of the "cycle." Is this significant? A cycle is a cycle but not if it is misidentifying the position of the worm vs corrections. To me that might explain why the error corrections are not working. Also, comparing the actual PEC curves from the 2 nights is really odd. The camera orientation was unchanged between the two nights and in both cases the west option was not selected. It's really clear the the start point of a "cycle" has shifted dramatically.
What do you think? I've posted the same query at SB but no reply yet.
I can see if you were too fast you may be exceeding the speed of the system to save the results perhaps. I never have used such short exposures. You must have been using a bright star. I think I used something like 2 or 3 second exposures.
I reread the PMX manual on PEC. It does state for PMX to record at least 4 worm turns which is 15 minutes and 30 seconds (Page 98 of the manual).
The manual tends to contradict itself a bit saying that PE errors below the local seeing are lost in the noise and PEC makes no difference below that seeing level. Later it says a powerful algorithim can work out PE through the noise. I take it then that longer the better for this algorithim to see through the seeing noise and that would be a minimum of 15 minutes 30 seconds. Last I did mine I did 20 minutes and around 1-2 second guide exposures (I may've used 2x2 binning as well).
Autoguider log has to be deleted before you start a fresh PEC curve.
All guide cables removed and no autoguiding is done during the PEC run. I take it this all being done.
It sounds like your best bet is to do a 20 minute run or longer with longer exposures, no delay and wait for a night of good seeing to do it.
The two cycles in the photos look like they have the same sine wave curve but out of phase with each other. Personally i don't think this is an issue, its just a result of where the worm was at when the PEC log was started.
Josh
Quote:
Originally Posted by PRejto
Whilst there are certainly similarities between the two curves, there are also obvious differences. The differences that concern me are the differences in the start and end points of the "cycle." Is this significant?
I can see if you were too fast you may be exceeding the speed of the system to save the results perhaps. I never have used such short exposures. You must have been using a bright star. I think I used something like 2 or 3 second exposures.
I reread the PMX manual on PEC. It does state for PMX to record at least 4 worm turns which is 15 minutes and 30 seconds (Page 98 of the manual).
The manual tends to contradict itself a bit saying that PE errors below the local seeing are lost in the noise and PEC makes no difference below that seeing level. Later it says a powerful algorithim can work out PE through the noise. I take it then that longer the better for this algorithim to see through the seeing noise and that would be a minimum of 15 minutes 30 seconds. Last I did mine I did 20 minutes and around 1-2 second guide exposures (I may've used 2x2 binning as well).
Autoguider log has to be deleted before you start a fresh PEC curve.
All guide cables removed and no autoguiding is done during the PEC run. I take it this all being done.
It sounds like your best bet is to do a 20 minute run or longer with longer exposures, no delay and wait for a night of good seeing to do it.
The alternative is to use PemPro.
Greg.
Hi Greg,
May I ask why you say "no delay?" Are you saying that a short exposure plus delay on a brighter star is somehow different than a longer exposure on a dimmer star? I supose the longer actual exposure might average out the seeing some compared to the short exposure plus delay.
In any case what I find confusing is that I have generated two curves that are certainly similar. One from the short exposures and one from the short exposure + delay...so it seems they roughly agree. Except, when I generate the PEC curve and especially when I save the two curves to the mount they look remarkably different! I took these pictures by connecting to the mount but the mount was not homed or tracking. The vertical line seems to indicate where the curve is being read and determined by the RA. I would have expected to see similar parts of the curve being read, but they are not. So, naturally I wonder iof something is going wrong (assuming I have not made some glaring error!)
Peter
PS Using CCDSoft it is necessary to delete the autoguider log, but it seems in TSX that a new log is started every time guiding is started so there seems no reason to delete or rename. I'm using direct guide so there is no cable to remove, and naturally I have deselected actual guiding!
The reason I would say no delay as you are weakening the sampling of the PE data by introducing a delay. Look on the taking of the PEC data as a sampling of a system so if you put a delay between samplings then it becomes lower resolution right? Likewise, you wouldn't want a 5 second exposure to record the PE as the data would be 5 seconds apart at a minimum (plus download time, plus the time to save it so more like 6 seconds plus). That's a pretty big gap in the data. Perhaps this is a jig or a jag in that time that gets missed in the recording process and so never gets corrected in the PEC file. If exposures are too short perhaps the software has difficulty in spotting the centre of the guide star if it is too dim. Too long and there would be holes in your data. I know its smoothed later so perhaps not such a big deal but looking at it from basics it seems there would be an optimum exposure and sampling rate for the data to be collected. What that rate is would be the exposure time where the data is clear, matches the download/save/computing rate of the system. So 1 second you would think should be close to that. Perhaps 2.
Pempro goes into PEC curves a bit more indepth tha SB so I suggest you look at their site and do a trial on their PEMPRO. It is quite specific in its requirements.
Greg.
Quote:
Originally Posted by PRejto
Hi Greg,
May I ask why you say "no delay?" Are you saying that a short exposure plus delay on a brighter star is somehow different than a longer exposure on a dimmer star? I supose the longer actual exposure might average out the seeing some compared to the short exposure plus delay.
In any case what I find confusing is that I have generated two curves that are certainly similar. One from the short exposures and one from the short exposure + delay...so it seems they roughly agree. Except, when I generate the PEC curve and especially when I save the two curves to the mount they look remarkably different! I took these pictures by connecting to the mount but the mount was not homed or tracking. The vertical line seems to indicate where the curve is being read and determined by the RA. I would have expected to see similar parts of the curve being read, but they are not. So, naturally I wonder iof something is going wrong (assuming I have not made some glaring error!)
Peter
PS Using CCDSoft it is necessary to delete the autoguider log, but it seems in TSX that a new log is started every time guiding is started so there seems no reason to delete or rename. I'm using direct guide so there is no cable to remove, and naturally I have deselected actual guiding!
The reason I would say no delay as you are weakening the sampling of the PE data by introducing a delay. Look on the taking of the PEC data as a sampling of a system so if you put a delay between samplings then it becomes lower resolution right? Likewise, you wouldn't want a 5 second exposure to record the PE as the data would be 5 seconds apart at a minimum (plus download time, plus the time to save it so more like 6 seconds plus). That's a pretty big gap in the data. Perhaps this is a jig or a jag in that time that gets missed in the recording process and so never gets corrected in the PEC file. If exposures are too short perhaps the software has difficulty in spotting the centre of the guide star if it is too dim. Too long and there would be holes in your data. I know its smoothed later so perhaps not such a big deal but looking at it from basics it seems there would be an optimum exposure and sampling rate for the data to be collected. What that rate is would be the exposure time where the data is clear, matches the download/save/computing rate of the system. So 1 second you would think should be close to that. Perhaps 2.
Pempro goes into PEC curves a bit more indepth tha SB so I suggest you look at their site and do a trial on their PEMPRO. It is quite specific in its requirements.
Greg.
Hi Greg,
I kind of get what you are saying, but still I can't see how an image every 2.5 sec is different from an image lasting 2.5 sec given that both only produce 1 sample in a given amount of time. But, I agree that a 2.5 sec exposure would sort of average the star location over the 2.5 sec interval....but still only give a single averaged point in time.
Anyway, enough. I am currently going to do this yet again on a dimmer star with 1 sec exposures!
Last night I collected data with .5 sec exposures and a 2 second delay. The curves are compared in the attached photo. Whilst there are certainly similarities between the two curves, there are also obvious differences. The differences that concern me are the differences in the start and end points of the "cycle." Is this significant? A cycle is a cycle but not if it is misidentifying the position of the worm vs corrections. To me that might explain why the error corrections are not working. Also, comparing the actual PEC curves from the 2 nights is really odd. The camera orientation was unchanged between the two nights and in both cases the west option was not selected. It's really clear the the start point of a "cycle" has shifted dramatically.
Peter
Hi Peter,
The worm has an index scale 0 to 999. If you open a guiding log with a text program you will see the RA index. This will have a number from 0 - 999 depending on where the reading was taken in the worm cycle. See screen shot 1.
This information when loaded back into Sky X generates a PEC Table which is then loaded into the mount. The PEC table is a list of numbers from 0 to 999 with a + or - number next to it. The +- numbers are the amount of correction that is applied. Screen shot 2.
What concerns me is that you PEC tables are different. It should not matter where in the cycle the readings begin because they have to correspond with an index number. So if you have an error of -2 arc seconds at index point 50, next time you take a reading index point 50 will still have the same error.
If you look at the two pictures that you posted of the PEC Tables, the index reading is 101. The values at index 101 are different in each table. They should not be different. Seeing conditions will alter this a small amount but your PEC tables should be similar.
Did you by any chance get a copy of each of the PEC tables?
You can easily compare them side by side in a text edit program.
To me the problem looks like the software is not recognising the index points and is loading a PEC table that does not correspond with the index error in the worm.
Hope this makes sense, I am out in my dome and it is just on zero my fingers and brain are not working to well.
Thank you for that explanation. You have confirmed my suspicions exactly! I just didn't know how to describe what I was seeing in comparing the various curves I posted, and - if something is wrong with the way the worm position is reported vis a vis correction curve - it explains why I cannot ever succeed in getting a PEC that actually works.
I must confess one other thing I "discovered" last night that is a bit embarrassing. I suddenly realised that I had been turning off Protrack, but not disabling T-Point corrections. (However, Jonathan posted at SB that this was possible "overkill" and unnecessary.) In any case, as my last (and also failed) run last night I did turn it off and got a very different curve with only 1.6 arcsec peak to peak that looks to be nearly all pinion error. This curve also fails to give any correction....in both ways to save the curve the PE increases about double. So, perhaps it wasn't my problem, but I'm quite surprised to see such a large change in the curve. I was under the impression that T-Point improved pointing ability, but I didn't know it also (seems to) influence tracking. I though just ProTrack did that. Perhaps you can enlighten me about this???
Anyway, this curve was generated with my ST-i at .75 arcsec for 21 minutes.
PEC tables posted for May 16 & 17. They are totally different!
Thanks for your help. And, yes it sure was cold last night!!
I had the same issue and have placed a suggestion on the SB forum today.
I think as we are trying to correct an error that is almost certainly smaller than the seeing the computation of the PEC is struggling. I believe although the magnitude may be about correct the phase is out which is why you get the varied residual PE.
In my reply I attached a test I ran that shows how far the computed phase can be out even if the raw data is in sync.
What I have found is you can dramatically improve the result by running the PE measurement for considerably longer. I suggest for at least 30 minutes. This seems to enable the software to better tie down the phase of the correction.
Thanks so much for your report. I tried to attach it here but unfortunately IIS has restricted the size of attachments...
Your experiment and results do seem to be very similar to what I am experiencing.
I'm curious as to the length of guiding runs you would do to verify if PEC is working? I've felt it might not be necessary to go as long as when measuring PE. Do you think that is a correct assumption since one would only be looking at peak to peak and the phase wouldn't matter?
I just tried this again. I did a PE measurement of 30 min and another of 44 min. I couldn't keep the star in the guide box past 44 minutes. Unfortunately neither curve works. But the phase difference between the two curves is remarkable! I wouldn't have expected such a big change from two rather long PE runs.
What was your end result chasing this down? Did you finally succeed in reducing your PE and by how much? Did you do something special or just get lucky one night and it worked?
One would think that some clever software could solve the phase problem following the 2nd measurement to see if the correction worked. It would just be a question of seeing where the correction had been applied vs where it should have been applied.
I'm really starting to wonder if I should just try Pempro. Maybe it doesn't have this phase issue to the degree I'm seeing.
