MAS Frequently Asked Questions
Frequently Asked Questions about astronomy (see also MAS Beginners page)
This page answers many commonly asked questions about astronomy. If you have a question on a subject any not covered here, please help support this page by using our on-line enquiry form (requires Java Script to be enabled).
Much of the material here has been taken from topics presented at out monthly meetings. If any member has subject they would like to present for 15-20 miniutes as a 'second half' topic, please contact the Meetings Secretary (to contribute directly to this page, please contact the Webmaster
(+) 0001 How do I find a local Astronomical Society ?
(+) 0002 How is Star brightness measured ?
(+) 0003 What are the Constellations ?
(+) 0004 What is the shape of the Earth ?
(+) 0005 What equipment do I need to start astronomy ?
(+) 0007 What telescope should I buy ?
(+) 0008 How much Magnification can I get ?
(+) 0013 What are Equatorial and Alt Az mounts ?
(+) 0100 How do I use my first telescope ?
(+) 0109 What is a finder ?
(+) 0110 What is an eyepiece ?
(+) 0111 What is a Barlow ?
(+) 0112 What is a focal reducer ?
(+) 0114 What are Nebular filters ?
(+) 0116 How do I use Setting Circles ?
(+) 0120 What is collimation ?
(+) 0125 How can I safely observe the Sun ?
(+) 1030 How can I take photos of the stars ?
(+) 1033 How to take photos of the Aurora ? - (Northern Lights)
(+) 1035 How to calculate FOV for prime focus ?
(+) 1036 How do I calculate FOV for Eyepiece projection ?
(+) 1037 How do I use a Raspberry Pi camera for astrophotography ?
(+) 1038 What is Star trailing ?
(+) 1039 How can I take photos of Meteors ?
(+) 2100 What is Universal Time (UTC) ?
(+) 2114 What are AUs Parsecs and Light Years ?
(+) 2115 What is Bodes Law ?
(+) 3010 When was Neptune discovered ?
(+) 4000 How do I update Stellarium with new Comet data ?
(-) 5000 How To build the MAS (Raspberry Pi) photoframe ?
The Raspberry Pi Photoframe
Those attending our indoor public events will have seen the MAS Photoframe 'in action'. This consists of a old 'square' (4:3) 19" computer display monitor (with HDMI input) driven from a small plastic box containing a Raspberry Pi. Many have asked 'how does it work ?', so for Raspberry Pi enthusiasts, a summary is shown below. A 'step by step' explanation (and more details than you could ever want to know) can be found here and the Pi-Zero version here.
The first version simply invokes the fbi tool 'telling' it to display every photo found in the 'photos' folder 'for ever'. This 'works' just fine (it was left running over a weekend by mistake and was still running, showing photos, on Monday morning !).
From the local (HDMI display) command prompt :-
fbi -d /dev/fb0 -noverbose -nocomments -readahead -blend 2 -t 3 -u ../home/pi/photos/*.thumb
(Note the photos to be shown all have the extension '.thumb' so they don't get mixed up with the original, full resolution, .jpg photos)
Version 2 (now fully working !)
We then 'got clever' and added a push-button (to GPIO 17) so the display could be controlled by a 'narrator' i.e. 'paused' (when the button is pressed) and continued (when the button was released). A requirement is that the display run itself 'normally' without the need for a narrator (or even the button) to be present - so rather than 'show next photo when button pushed' we went for a 'pause on this photo when button pushed' approach.
For this, 3 .sh scripts are used :-
gophotogpio17 is run first and simply 'enables' the GPIO pin to 'read' the button state
gophotopause.sh is now launched as a 'background' task (this is key = if it's not run in the background, the Pi now 'locks up' as the script loops 'for ever' and will never exit).
The script starts by updating the 'dummy' display image (display.jpg) so it 'points' at the next photo to be shown (display.jpg is an 'alias' of (i.e. pointer to) the actual .thumb photo - if you try to copy the .thumb to display.jpg sooner or later fbi will display 'corrupted' JPEG data as it grabs the partially written file during the copy process). It then waits 5 seconds. It then checks the 'state' of the button = if 'pushed' it waits until the button is released. When the button is found in the 'released' state, the script loops back, updates the 'alias' (link to the next photo) and waits 5 seconds before checking the button again (and so on, for ever)
This allows a member of MAS to stand by the display and 'stop' the sequence so he can talk about the currently shown photo (and answer any questions) before allowing the photo show to continue, whilst at the same time allowing the display to run in 'unattended mode' (i.e. when there is no-one to push the button or when the button has been removed)
Finally, to actually start the display, gophotodisplay.sh is run. This launches the display tool 'fbi', which only runs as a 'foreground' application. Since fbi is set to 'loop forever', the Pi does nothing but display photos 'for ever' and as a foreground app. it also 'locks up' that terminal (session widow).
How to stop fbi crashing
The problem was that, with a cycle time of 1s, fbi was attempting to fetch photos 3 times a second. This hammers the 'source' SD card and whilst a class 4 card is rated at 4MB/s when fbi is grabbing 3MB/s the SD card 'bottlenecks' and fbi crashes (usually after a few 'file read failed' messages). Further, no matter how the 'copy' was setup, sooner or later fbi would always show a 'corrupted' photo for a second or so.
Reducing the 'fetch' rate (even to 1 photo every 2 seconds) didn't provide a cure - and anyway would have increased the 'latency' (delay after releasing the 'pause') far too much. The solution was to copy the 'source' photo into RAM (using a 'tmpfs' RAMdisk). The 'button' detect script (gophotopause.sh) can then copy the 'next' photo (to be the shown) into a folder in tmpfs, then change the 'master' alias so the display tool (fbi) reads from RAM (rather than from the Pi's SD card).
The final problem that had to be solved was why fbi continued to show the occasional 'corrupted' photo. Eventually it was realised that the 'fetch next' scrip was overwriting the 'old' photo before fbi had actually moved onto the 'new' one ! Adjusting the script so that after 'telling' fbi to switch to the 'new' it then delayed (for 3s) before overwriting the 'old' (with the 'next new') ensured 'fbi' had sufficient time to switch from 'old' to 'new' and avoided any corrupted display.
Finally, the gophotodisplay.sh script also needed to be adjusted slightly, as the 'alias' files where now defined in gophotopause.sh instead
This note last modified: 15th Nov 2016 17:50.