AndyKeogh

One of the problems I have when using PPA is translating the error reported into the mechanical movement required to correct the error. This is not helped when my AZ movements do not always translate into an actual movement. What is required is a visual feedback of how the star has moved (a bit like Polestar provides) Now the other night a very large penny dropped when I realised that a partial solution is to use live view x10 on the camera to watch how the star moves. So last night after spending an hour on drift alignment I checked how well I had done the reported error was 2.34 arc minutes. So I set about correcting it with 2 instances of PPA running. ( I still have a little flex in my system of 20 imaging pixels over 4 hours) The first instance uses a V picture taken west of Polaris whilst the second instance uses a picture east of Polaris. After 3 iterations the error was very small and the 2 results straddled the NCP. So this morning I was very pleased that PHDLAB reported my drift error was a mere 0.07 arc minutes. I do not use live view on the camera but have an image on my Ipad/laptop that I take to the scope when making adjustments. Is anyone aware of a tool similar to AstroGeeks CrossHare that could overlay the live view image with a grid in arc minutes or arc seconds? Or is there a simpler way to do this? Andy

Thanks Mike that is good to know. I have run 2 overnight tests since I upgraded to the MS updated driver and it has not crashed. Though Nebulosity has had some problems. Maybe the 12v hub that has taken the place of the mains driven netgear usb hub has changed the dynamics. I plan to run some more tests this week with different usb cables and a simplified setup to see if I can get a clean 14 hour run without incidents. Andy

I have run the chip set program and the chip in my EQDIR module is a PL-2303H. Is this the same chip version that you Tinker1947, Skipper Billy and r3i are using? Amdy

Thanks I will have a look at this and check which chipset HitecAstro have used. I note that the Prolific driver you have linked to does not support Windows 8,8.1 or 10. Begs the question as to which interface one needs for those OSs Andy

For a long time now I have been using the Prolific driver installer v10518 from the HitecAstro site on my windows 7 computer. Recently I have been getting a lot of overnight crashes and lost a lot of imaging time. An analysis of last night's crash pointed to the Prolific driver. MS today offered me a new driver V3.6.81.357 to replace v3.3.5.122. First signs are that it works... well I can move the mount. My question to the group is in 2 parts:- 1) Is this new driver reliable? 2) Is this now the time to find a new more reliable EQDIR interface and if so what recommendations can you offer. TIA Andy

An interesting approach which would get round my local byelaws. BTW suspect your start date is out by ten months.

I had a failure with a solve tonight Selecting job id 986652 Sending to URL: http://nova.astrometry.net/api/jobs/986652 Sending to URL: http://nova.astrometry.net/api/jobs/986652 HTTPError HTTP Error 500: Internal Server Error Wrote error text to err.html Exception in Tkinter callback Traceback (most recent call last): File "C:\Anaconda\lib\lib-tk\Tkinter.py", line 1486, in __call__ return self.func(*args) File "C:\Users\AKeogh\Documents\PhotoPolarAlign\PPA.py", line 1263, in <lambda > nxt = Button(self.wfrop, text='Nova', command=lambda : self.solve('i','nova' )) File "C:\Users\AKeogh\Documents\PhotoPolarAlign\PPA.py", line 887, in solve img2wcs(self, self.apikey.get(), aimg, awcs, hint) File "C:\Users\AKeogh\Documents\PhotoPolarAlign\PPA.py", line 455, in img2wcs if stat.get('status', '') in ['success']: AttributeError: 'NoneType' object has no attribute 'get' with estimated scale 4.14 Andy

Here is a screenshot of my settings for a local solve. Camera is a Canon 5D mkIII in a Megrez90. If you do not know your image scale then untick Restrict scale and set scale_low to 1 and scale_hi to 180 and see what comes back with the solve. Alternatively sole with Nova and it will provide your image scale. Themos in an earlier message gave the factor to convert the scale into a range. HTH Andy

have you been into File Settings ? There is an import button to read your Astrotortilla settings. Andy

Well I went back to my new build "shed" computer and it worked fine this morning. Last night I had lots of problems with remote logins to the existing "shed" laptop so maybe I forgot which machine I was actually on at the time. Sorry for the false alarm. Andy

Hi Themos, last night I had a problem with local solves in V1.04 all my setup data from my earlier sessions had been forgotten My expectation was that it should remember it. Have I missed something? Andy

Thanks Themos and Gonzo will have a look later.

OK I have had a play around with sigma and the downscale factor to see what sort of relationship exists. My main focus was on the first horizontal image Q07A9356. What I noticed was that as the down sampling increased the value of sigma had to be reduced otherwise no source objects were found and the solve failed. The following table shows my results. I noticed that the value of RA and Dec changed with downscaling and also with some values of sigma. So I ran two solutions :- the first with downscaling set to 1 and sigma set to 64 I then changed downscaling to 4 and sigma to 4. The results are in the notes field rows 28 and 29. No difference except downscaling to 4 saved a whole 8 seconds. Caveat this result is based on a sample size of 1. So this is my improvement using local solve. The Astrometry.net solution is earlier in this thread. So it appears that whatever downscaling factor is used, as long as the number of sources found is approximately 100 or more then a local solve produces a good result. QUESTION. Is there any guidance available on the minimum index set required for a successful solve with PPA and Astrotortilla? Andy

Thanks Themos Tried your parameters but AT gave up after 10 mins of cpu time. Simplexy had found over 4000 items! My parameters came from http://lightvortexastronomy.blogspot.co.uk/2013/08/tutorial-imaging-setting-up-and-using.html and he makes the case for defining a sigma value. I have added that back into your set of parameters. After a bit of experimentation I am getting solves with a sigma of 16. Simplexy still finds around 1000 items which I think is a bit high. Solves are taking longer so I think it is now time to read up on AT's configuration parameters. Solve for Portrait (v) image:- Solve for landscape (h) image This took 145 seconds! I compared the improved polar alignment using solutions from Astrometry.net and Astrotortilla and there was only a few arc seconds difference so that is very promising. Astrometry.net solution :- Local solve solution :- Thanks again for all your efforts. Andy

PPA imports my Astrotortilla settings. I tried turning them round in the config screen of PPA but I still had the same error. I could try to plough through 1501 lines of python code; oh and learn python at the same time ..... but I think Themos will get there quicker. Andy

I have run into a problem trying to do a local solve This was on a machine that had never had Anaconda installed before today. First installation of PPA was 1.04 today. Windows 7 64 bit First of all I solved the image in Astrotortilla to be sure it should work. Created a coarse and fine config as per instructions for V1.03 Imported that configuration into V1.04. Image had been previously solved by Astrometry.net so the green solved button came up. Ignored that and asked for a local solve and this is what I got..... C:\cygwin\bin\bash.exe --login -c "solve-field -b /etc/astrometry/backend.cfg -u degwidth -L 2.00 -H 4.50 -z 0 --sigma 70 --no-plots -N none -H 2 -L 4.5 -r --ob js 100 -O \"C:/Pictures/2015/2015_01_06/Polaralign/Q07A9354.JPG\"" Reading input file 1 of 1: "C:/Pictures/2015/2015_01_06/Polaralign/Q07A9354.JPG" ... cygwin warning: MS-DOS style path detected: C:/Pictures/2015/2015_01_06/Polaralign/Q07A9354.JP G Preferred POSIX equivalent is: /cygdrive/c/Pictures/2015/2015_01_06/Polaralign /Q07A9354.JPG CYGWIN environment variable option "nodosfilewarning" turns off this warning. Consult the user's guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames jpegtopnm: WRITING PPM FILE Read file stdin: 5760 x 3840 pixels x 1 color(s); maxval 255 Using 8-bit output Extracting sources... simplexy: found 352 sources. Solving... Reading file "C:/Pictures/2015/2015_01_06/Polaralign/Q07A9354.axy"... Scale range 2.8125 to 1.25 is invalid: min must be >= 0, max must be >= min. backend-main.c:321:main: Failed to read job file "C:/Pictures/2015/2015_01_06/Po laralign/Q07A9354.axy" solve-field.c:518:run_backend backend failed. Command that failed was: /usr/lib/astrometry/bin/backend --config /etc/astrometry/backend.cfg C:/Pictur es/2015/2015_01_06/Polaralign/Q07A9354.axy ioutils.c:605:run_command_get_outputs Command failed: return value 255 Exception in Tkinter callback Traceback (most recent call last): File "C:\Anaconda\lib\lib-tk\Tkinter.py", line 1486, in __call__ return self.func(*args) File "C:\Users\AKeogh\Documents\PhotoPolarAlign\PPA.py", line 1235, in <lambda > nxt = Button(self.wfrop, text='Local', command=lambda : self.solve('v','loca l')) File "C:\Users\AKeogh\Documents\PhotoPolarAlign\PPA.py", line 889, in solve limg2wcs(self, aimg, awcs, hint) File "C:\Users\AKeogh\Documents\PhotoPolarAlign\PPA.py", line 284, in limg2wcs self.update_scale(hint) File "C:\Users\AKeogh\Documents\PhotoPolarAlign\PPA.py", line 853, in update_s cale self.scale = scale_frm_wcs(self.vwcs_fn) File "C:\Users\AKeogh\Documents\PhotoPolarAlign\PPA.py", line 520, in scale_fr m_wcs hdu = fits.open(fn) File "C:\Anaconda\lib\site-packages\astropy\io\fits\hdu\hdulist.py", line 119, in fitsopen return HDUList.fromfile(name, mode, memmap, save_backup, **kwargs) File "C:\Anaconda\lib\site-packages\astropy\io\fits\hdu\hdulist.py", line 251, in fromfile save_backup=save_backup, **kwargs) File "C:\Anaconda\lib\site-packages\astropy\io\fits\hdu\hdulist.py", line 768, in _readfrom ffo = _File(fileobj, mode=mode, memmap=memmap) File "C:\Anaconda\lib\site-packages\astropy\io\fits\file.py", line 130, in __i nit__ raise IOError('File does not exist: {0!r}'.format(fileobj)) IOError: File does not exist: u'C:/Pictures/2015/2015_01_06/Polaralign/Q07A9354. wcs' I tried this again with downsampling set to 1 and the same error appeared. Astrotortilla still solved the image Andy

Thanks, I have downloaded it. Initial view is that it needs a video camera for guiding and I do not have one. At this point in time I am trying to characterise the components on my mount and will worry about fixing issues later. Andy

What I am really trying to do is work out if a Skywatcher guide mount introduces flex or not. What I have found is that if the "guidescope" is bolted into an M3 vixen clamp and the PA is 0 in altitude then I get about 12 arc seconds drift in RA & Dec over 10 hours Due to other errors my main imaging scope camera was not running so I am still trying to characterise my mount. Andy

Looks like mental arithmetic is no longer a strong point for me An option would be nice. I have been analysing all my test runs since mid December and it looks like the altitude setting is critical to the amount of drift I am seeing over 10 hours so I am trying to nail it at 0.000 Andy

Hi Themos I wonder if you could clarify how you arrive at the move numbers? Using the examples below my CP error is 6 pixels on the x axis and 2 pixels on the y axis ( I have ignore the limits due to rounding) and with a scale of 2.57"/pixel this suggest my error is 15.42 arc seconds for the azimuth OR have I got this completely wrong ? Andy

Downloaded and installed but due to clouds and rain I have initially tested it with last night's solves and it produced the same answers although the format of the move has changed . Maybe I will grow to like it over time, In practise, I subtract the CP position from the RA axis position so use a measure of pixel change to work out how effective each move has been. Thanks for all your efforts. Andy

Sorry I must improve my proof reading. :{ that should have read:- In my case as the image below shows The SBIG ST-i normally guides so I will now have to align it to landscape mode to use it with PPA.

Very clear. The complication as Themos said arises when a CCD is introduced. In my case as the image below shows The SBIG ST-i normally guides so I will now have to align it to portrait mode to use it with PPA. http://stargazerslounge.com/topic/107109-pictures-of-your-set-up/?p=2520494 Andy

Happy new year They appear to be the same on all images a little off centre. I have sent you a Dropbox link to the files for each camera there is a screenshot of all 3 results side by side in the top directory. I have sent both .FIT and .jpg for the ST-i and the Lodestar. Note the ST-i camera is orthogonal to the other 2 cameras. When I used the ST-i data to improve polar alignment the results were disastrous ( it sent me in the wrong direction) and I had to actually look through the polar scope to get back into close alignment before finishing off the alignment with the Megrez camera. It appears to me that your routine makes assumptions about which axis is parallel to the ground. I am sure Astrometry.net reports on the camera axis. Could you not make use of that? In the meantime I will realign the SBIG ST-i orientation so its image matches the Canon 5D. I will also add another canon camera with a camera lens on it to see what results that gives. It will probably be Sunday before I have any more results weather permitting. Andy

Last night I was testing a new setup and PPA said I was aligned to less than 1 arc minute. I then ran for over 9 hours on a single subject guiding with PHD2. Analysis today showed that I had over 5 arc mins periodic error. Tonight I checked my polar alignment using my Megrez 90 as normal and the result was it was still aligned. This left me a little perplexed as my images from last night definitely had significant pixel shift over the 9 hours. So I used my 2 guide scopes with PPA. Using my Zenithstar with a Lodestar the result was in close agreement with the Megrez:- I then checked it with my SBIG ST-i guider but it gave a different result. Out of alignment by over 5 arc mins. Now the ST-i guider is bolted to the Megrez tube rings which in turn is attached pretty solidly via an M3 vixen clamp onto a substantial M3 Losmandy plate. So I am wondering what has caused the differing results? Andy