Demonperformer

Thanks for the replies.

@ Budgie1 - good point, checked and it is "https"

@vlaiv - Device running Android 5.1.1 [X1 list states "Andoid>=7.1.1 (but Android >=2.3.6 will sork by default)"]. Not quite sure why it says I would need >=7.1.1 if >=2.3.6 will work??

However, the problem seems to have resolved itself now I am back within range of my router - a fact which may or may not be a coincidence (can't think why it would care whether I am accessing it that way or through normal wifi). Guess I will just have to keep an eye on it and see if I can spot anything if it happens again.

Thanks.

Anyone else having problems accessing FLO?

Thanks for all the responses.

Seems the general concensus is better to go for the fluid (+ cotton buds - "damp not dripping"), rather than the pen, together with a blower - don't think any of the visible 'splodges' would be removable with that, but I guess a tiny dust particle can still do lots of damage to the lens coatings if I drag it across the surface with a cotton bud and the extra £4 is not going to break the bank.

It is a 32mm meade 4000 and i have checked the rubber cup and the insertion tube are removable, so that should help.

Thanks.

I have decided that the time has come to do something about the state of my favourite eyepiece - see pic, and yes, those speckles are actually on the eyepiece, although I am not totally sure which end.

One option would appear to be this item, reasonably cheap, but no reviews, so has anyone used one of these and what was the verdict?

A significantly more expensive option would appear to be this, which has a series of glowing reviews, but is it worth the extra cost? Also not sure I could get a cloth into the eyepiece tube (particularly the end that is opposite the eyecup) without poking it in with a stick, which seems rather aggressive for such an operation.

So any advice on which is my best cost-effective option welcome.

Thanks.

Thank you for that response, Martin.

I think the idea of rebuilding the program from the original c is well beyond me, but at least I now understand why I couldn't get it to work.

Thanks.

That is a really nice picture. I love it when people go after the really obscure and find them.

Yes, I have python installed (not sure what anaconda is - its webpage talks about it being for development, which is waaaay outside my wheelhouse) and regularly use it to run pyephem. It seems (from the webpage) that it is montagepy that requires either unix or linux.

Thanks.

Thanks all for the replies.

Looking at it again, it looks as if (as mentioned above) it is unix/linux only.

Back to the drawing board ....

I am trying to install Montage to combine images into a mosaic.

I have downloaded the package (Montage_v6.0.tar.gz) and extracted it - it gave me another archive (Montage_06Nov 18.tar) which, upon extraction produced the array of files shown in the image in the folder: c:\admin\downloads\montage\montage.

Now, following the instructions given (Use the command: $ pip install MontagePy) I get the results show on the final image.

As you will see, I have navigated my way through the tree, trying at each stop, and always get the answer:

ERROR: Could not find a version that satisfies the requirement MontagePy (from versions: none)
ERROR: No matching distribution found for MontagePy

My searches on the internet turn up pages that I am sure would mean something to someone with an advanced degree in 'computing with python', but mean very little to someone who needs 'python for extra-dumb dummies'.

If it is relevant, I am using Python 3.10.11 (but not using that to run the pip command).

Can any of our computer experts offer suggestions as to why I am failing so miserably?

Thanks.

Thanks for your comments, Paul.

Having had a bit more time to think about this, I can see that in principle a co-ordinate system that never needs updating would be a good thing, but I see two issues with it:

(1) At the moment I can look at a star's coordinates and determine how far above the horizon it will ever get for me at this latitude, but gradually that is going to become no longer true. Ultimately, in 12 millenia, stars that have an RA of about 18h hours will have a limiting declination (at my location) of about 85°S, whilst stars with an RA of about 6h will have a limiting declination of about zero (the celestial equator). Granted, this is not going to affect me a lot, but in the long term it strikes me that that would be weird (or is it just that my imagination is limited by the current system??)

(2) New co-ordinates are still going to need to be created at intervals to account for proper motion. A quick straw-poll of the 2380 stars in BD+89 to BD+85 (excluding the four for which no PM values are provided) give an average (combined) PM of 28.867mas/yr, so in 100 years that is an average of just under 2.9 arc-seconds, which is just under 0.0008°. Although there is some variation, Simbad generally lists co-ordinates to 8 decimal places of a degree, or about 12500x this rate of change.

So I'm thinking that to meaningly accommodate PM, new co-ordinates are still going to have to be produced at regular intervals (but maybe not as frequently as under the FK5 system?) and if they are going to have to do that, they may as well have stuck with a system that relates to what we actually see.

That said, I will have "fallen off the perch" long before any of this makes any significant practical difference to me, so maybe I should just accept the fact that I don't need to find a way of generating 2050 co-ordinates, giving me one less thing to worry about.

Thanks.

I was looking for information on the internet on formulae to calculate precession values (with a view to working out some 2050 values (en masse - i have a python prog that does it for individual co-ordinates quite well), which - I thought - should start to be more accurate than the 2000 values in the next couple of years - don't ask, I just do this sort of thing!) and came across this paper: https://adsabs.harvard.edu/full/2008ASPC..394..179W

If I am reading this correctly, it says that co-ordinates are no longer precessing as long as we use the ICRS co-ordinates. In other words, Polaris - with ICRS co-ordinates of 02-31-49.09456 +89-15-50.7923 [according to SIMBAD] - will have exactly the same co-ordinates in 12000 years when it is nearly 45° away from the NCP instead of just 45'. Is that really what it is saying? Am I really understanding it correctly ['understanding' in this instance is used in the loosest possible sense ... and then some!]? It doesn't appear to have been published on April 1st! At the moment, this concept strikes me as incredibly weird and completely unworkable, but if that is what it is saying, I will try to get my brain around it.

Thanks.

Thanks, Gus. Don't know how I failed to find that page. Following one of the links, I discovered a page that states:

"As of 1 January 2000, the positions of the ecliptic poles expressed in equatorial coordinates, as a consequence of Earth's axial tilt, are the following: North: right ascension 18^h 0^m 0.0^s (exact), declination +66° 33′ 38.55″.

So I guess the the answer is not as obscure as I thought!

Thanks.

... that is of absolutely no importance, but has wormed its way into my thinking and for that reason alone I need to find a solution to it.

The North Celestial Pole is on the move. It prescribes a circle in the sky over a period of about 26,000(?) years. This circle must have a centre and I started wondering where it is. I dredged up from my memory that about 4,000 years ago it was somewhere near Thuban and that in about 12,000 years time it will be near Vega. So for my first approximation I drew a circle linking these three stars and arrived at a centre somewhere in the vicinity of 36 Draconis (give or take a degree or two!).

But that has not satiated my curiosity. I'm wondering if either there is a mathematical method of working out its co-ordinates (I'm sure there is one, but it is outside of my mathematical knowledge/ability to work out what it is) or indeed if these co-ordinates are "out there" on the internet somewhere (obviously posted by someone with as little of a life as I have), but I've not been able to find them. Clearly these co-ordinates would be dependant upon the co-ordinate system used; so I would ideally opt for "ICRS J2000", but I would be willing to work with any other system if they could provide an answer.

So, having defeated me, I turn this question over to the SGL-megamind to see if anyone has an answer.

Thanks.

Thanks, Martin. That is certainly an idea. But I am surprised at the lack of an option to just get it to output in a particular order, particularly as it is capable of sorting the results in HTML.

Having to play dodge the clouds here, but getting a few reasonable views.

Plate solving is a pretty foolproof way of making sure you have the right field, if you are using a laptop or equivalent on-site. That said, the objects you mention are all pretty bright so your high iso/short exposure system will probably show them. It's when you get onto fainter objects that plate-solving becomes absolutely invaluable - it saves you having to do the same job manually by comparing what you have with a star map. In the UK we get little enough imaging time, so anything that speeds up the preparation time is worth doing. Bottom line: practice plate solving in the field now and it will pay ongoing dividends as you progress in the hobby.

I have a search expression [otype="star" & dec <80 & dec>75 & cat='HD' & Vmag <=10.0 & Vmag>9.0] for the SIMBAD criteria query page [https://simbad.cds.unistra.fr/simbad/sim-fsam]. I want this as an ascii file and have set the output page [https://simbad.cds.unistra.fr/simbad/sim-fout] accordingly.

So far so good.

The problem is that the output is in (as far as I can make out) a TOTALLY random order, which is utterly unhelpful. Now I know that if I am displaying the result on an HTML page I can click the little arrow at the top of the column and get it sorted there, but as there are over 300 records, a text file is much more useful. I have tried sorting the HTML page and clicking the "store this result in Ascii" option and it reverts to its random order. Unless I am going completely blind, there is nothing on the "output options" page that talks about ordering the output, but my gut-feeling is that there has to be some sort of command (sort=? order=?) that I should be able to add to my original query to get it to order the output file automatically. I have tried all the options I can think of ['sort(order)='; 'sort(order) by'; etc] with no joy. I have tried various 'help' pages, but they don't. Surely, it shouldn't be this difficult.

So, does anyone understand the program sufficiently to help me get the ordered output file I require?

Thanks.

Thanks for the reply.

I'm going to have to have a think about this and then have a play with the figures I have been given. First impression is that, even though I won't have F0, as that would be a constant, if I can find the factor that equates one star's (flux-background) in your equation with it's recorded magnitude, then the others would be calculable. Even if I were to go to the trouble of photographing a zero magnitude star every time, presumably the figure would be affected by where it was in the sky and so would not be directly applicable to a photograph taken elsewhere. Any magnitudes are really an added bonus for what I am doing, so I'm not too worried, but wanted to explore my options.

Thanks.

I have run an image through astrometry.net and the attached image is part of the data provided in the axy.fits file (at least the first four columns are, the other two were calculated because they looked as if they might prove interesting).

I understand the x & y columns.

Flux is explained (https://astronomy.swin.edu.au/cosmos/F/Flux) as "the total amount of energy that crosses a unit area per unit time". This sounds like it should be directly (or at least logarithmically) equatable to what muggles like me call magnitude. But I have failed to find the formula that does this - everything that talks about flux seems to focus on the effects of distance on flux, which is all very interesting, but not what I am after. So my first question is: Does anyone have a handy formula for translating flux into magnitudes?

The fourth column (background) looks a bit more complicated. My initial thought is that this is the brightness (flux) of the bit of sky around the star ("around" being a vague way of expressing what is, no doubt, far more precise than that). Which got me thinking about subtracting one from the other. This would presumably give the brightness of the star in relation to its background, but I got quite a few with negative numbers which seemed to imply they would be fainter than the background and so you wouldn't see them! So I then thought about dividing, which at least got rid of the negative numbers, but I'm not quite sure why I did it other than that - just seemed like a good idea at the time. So my second question is: What exactly is this figure and how does it relate to/what impact should it have on the flux of the star (if any)?

Thanks.

3 minutes ago, Knighty2112 said:

No expert but first you need to change directory to the folder were the files are on your PC/laptop. For example if the files are located on your PC/laptop in a folder on the C drive named Astropy, then in a folder called Fits you navigate to the correct folder first in command prompt with the command

CD C:\Astropy\Fits

This will change the path to show you are now in the Astropy\Fits folder.

Typing in py on the command line on its own puts you into the python editor command line where you can type in ptyhon commands directly (i.e. print(“Hello”) which will print hello on the command line as >>>Hello. This is not what you need here. 

Thanks. Think I'm starting to see the light at the end of the tunnel ... or maybe it's just the train ...

Thank you for your assistance, Martin.

It took a bit of finding, but have finally obtained the answer that I was expecting. Will be busy for most of the rest of the day, but will hopefully be able to start tackling my "real" data when I am able to return to it.

Thanks.

4 minutes ago, Martin Meredith said:

The showtable instruction is used from the command line, not the Python interpreter. i.e. open a new shell and type showtable etc

cheers

Martin

Thanks, Martin.

No longer a syntax error, just not recognized ...

Thanks.

Thanks for the response.

My initial response upon reading it was "I knew I'd been incredibly stupid - exactly like that". But when I tried it, I'm still getting the syntax error.

Just taken a v quick look at fitsio - may well be easier as it seems to be specifically dedicated to what I want to achieve. Will take a more in-depth look in a while.

Thanks

As is so often the case, I am not sure this is the cprrect forum, but as it is about a computer program to access astro-info, I guess this might be the right one.

I am trying to use a program called Astropy to extract the data from a fits table.
Going through https://docs.astropy.org/en/stable/io/unified.html#table-io it appears that the showtable instruction is going to be the simplest way (at least initially).
The image shows the instructions given on the webpage for accessing their 'example' file that comes with the installation and my attempts to follow them.
A check on explorer has confirmed the presence of the file table.fits (about 8.6k in length).
After the initial "py", I typed in the instruction line given. The result is "invalid syntax".
I next tried typing in "from astropy.table import Table" first. I got this from further up the page which it required before doing other read/write operations. I then repeated the original instruction and again got an "invalid sytax" error.
So I then tried accessing the "full documentation and available options" and now I get a "'showtable' is not defined".
This last one suggests to me that if I can get the program to recognise (define?) 'showtable' I may actually get somewhere, but I cannot find an instruction for doing this. It all gives me the gut-feeling that I have committed some MSM (mega-stupid mistake) that might well be blindingly obvious to anyone who has even the most tangential knowledge of how python works (which I obviously don't).

So, what's my (latest) python screw-up?

Answers on the back of a £20 note ...

Thanks.

Having been unable to get the mount outside for imaging since the beginning of this year due to injury, I decided to end my drought a couple of nights ago by doing some test shots on a static tripod with my Canon DSLR + nifty-fifty. My garden is surrounded by (white) street lights and I decided to push matters still further by imaging an area near to the celestial equator (as that is where the stars move fastest), so headed towards Altair and imaged the area below (south) of it (Altair is the brightest star centre/top). The ISO was 800 and the lens was stopped down to f2.8.

I selected 9 exposure times (1, 2, 4, 6, 8, 10, 15, 20 & 30s) and took six images at each exposure. The results of each exposure were registered in DSS & then stacked, the final image also being registered. The aim of the exercise was to determine the "optimal" exposure time with that setup in my circumstances. The images were only recorded as JPEGs rather than RAW for reasons of size and as it was only a comparison test.

The results listed below give: sublength; #stars in the individual subs; FWHM in the individual subs; #stars in the stacked image

1s; 88-104; 3.11-3.14; 514
2s; 197-208; 3.16-3.23; 920
4s; 375-394; 3.47-3.54; 838
6s; 539-563; 3.70-3.78; 716
8s; 590-615; 4.00-4.07; 680
10s; 538-558; 4.22-4.28; 488
15s; 125-149; 3.75-3.98; 127 ... this showed major trailing in the stacked image so the longer subs are not included in the results.

Apart from the general rule-of-thumb that smaller numbers are better, I don't really understand the detail of FWHM sufficiently for those figures to mean a lot to me, but include them in case they mean something to others. Unsurprisingly, as exposure time increased, so did the FWHM figure - until the end. This coincided with the number of stars crashing, so I guess some sort of tipping-point was reached with trailing so that it rejected the worst examples as not being stars and so the remaining ones were slightly better?

What interested me was that the number of stars in the stacked images peaked at 2s and then began to decline, despite the number of stars in the individual subs continuing to rise to peak at 8s. I'm guessing this is some interaction between the increasing trailing & light-pollution kicking-in at different points of the increasing length of the subs.

I'm attaching the 6*2s image and have done a very quick magnitude check, finding quite a few stars below magnitude 10.0, the faintest so far is TYC 1062-2509-1, listed in CdC as 10.46.

Obviously, this is a tiny sample and much bigger tests would be needed to come to any definitive answers, but I share it for what it is worth. If nothing else, it demonstrates that with very basic equipment, one can experience the (all too common) scientific situation of experimentation posing more questions than it answers!

Thanks.