Recently Browsing 0 members
No registered users viewing this page.
I'm new here and thus question has been on my head all day. Tell me your thoughts! The light pollution is p******* me off!
Just found this. https://www.bbc.co.uk/newsround/amp/49836623
Let's hope it is a success and the good folk of Switzerland enjoy some clear dark skies.
Today we published first release candidate to version 0.19.1 - please help us testing Stellarium!
List of changes between version 0.19.0 and master (0.19.0.16926/0.19.1RC1):
- Added allow to search an inactive meteor showers in Search Tool/Lists tool
- Added 'Azimuth vs. Time' graph into AstroCalc/Graphs tool
- Added feature to show tracks for latest several selected planets (GH: #539)
- Added calculation and showing the orbital period for artificial satellites
- Added revolutions per day info for artificial satellites
- Added tools for jumping to the next or previous time of rising, transit or setting for selected object (GH: #484)
- Added new behavoir for AstroCalc/Graphs when clicking within graph area now sets current time.
- Fixed issue in script 'Mercury Triple Sunrise and Sunset'
- Fixed crash of Stellarium for eyepieces with permanent crosshair
- Fixed Stellarium crash when Remote Control plugin is working
- Fixed computation of assume radius for minor planets.
- Fixed the issue of the scrolling not working properly on Mac (GH: #393)
- Fixed crash in Scripting Engine (Hide artificial satellites through StelProperties in core.clear() method to avoid crash if plugin was didn't loaded)
- Fixed planetarium crash in HiPS (network manager delete problem)
- Fixed position problems on the Poles (GH: #391)
- Fixed scaling Telrad sign on HighDPI monitors
- Fixed surface occlusion bug even with landscape turned off in scripting engine (GH: #680)
- Fixed building with cmake -DBUILD_SHARED_LIBS=ON (GH: #683)
- Fixed error in constellation file format (Babylonian)
- Fixed Europe/Volgograd time zone settings (GH: #686)
- Fixed HiPS handling of allsky download (GH: #671)
- Fixed progress bar rendering (GH: #671)
- Fixed positive declinations issue in AstroCalc tool when option 'Use decimal degrees' is enabled (GH: #690)
- Fixed file names inconsistency
- Fixed constellation line in "Japanese Moon Stations" skyculture
- Fixed file name for constellation boundaries in Stellarium User Guide
- Fixed the user interface problems in Oculars plug-in (GH: #580)
- Fixed getting the wrong values in objects/info method for selected object for different formats (Remote Control plugin)
- Fixed refresh plots when AstroCalc dialog becomes visible again (AstroCalc/Graphs tool)
- Fixed jquery vulnerability (GH: #694)
- Fixed date and time dialog behaviour: Hour/Minute/Second spinners now correctly trigger signals dateChanged(), dateChangedByYear and dateChangedForMonth() when days, months or years are affected by it.
- Fixed update graphs in AstroCalc/Graphs tool when days change
- Updated planetary nomenclature
- Updated common names of stars and DSO's
- Updated cmake rules for Windows deployment
- Updated DSO textures
- Updated behaviour of HiPS survey if Stellarium started without network (GH: #681)
- Updated GUI for ArchaeoLines plugin (GH: #689, #682)
- Updated default pulsars catalog (v1.60)
- Updated list of asterisms
- Excluded Armintxe skyculture and landscape from default package
Download link: https://github.com/Stellarium/stellarium-data/releases/tag/beta
By Captain Magenta
Last year I was given a Unihedron SQM-L, the narrow field of view version of their gadget for measuring night-sky brightness. Since then, I’ve nipped outside to take zenith readings whenever I’ve been able, often a few times per night. As a result I now have 85 data-points, all from my back garden in Sunbury on Thames which rates a 19.04 on www.lightpollutionmap.info . As it turns out, this agrees well with the data I’ve collected.
The darkest I’ve measured at this location has been 19.13, with 4 records better than 19.05 and 10 better than 19.00.
Plotted against Moon altitude, it looks like:
One thing I noticed very early on was that the reading generally gets darker and darker as the night goes on. The chart below suggests the data agrees, but how strongly I’m not adept enough yet with my statistics to work out. If anyone fancies doing this for me, I’d be grateful, I’ve attached the data .csv file I think to the end of this post.
The data itself: each record contains date, time[GMT], SQM value, Moon phase, Moon altitude . For the purposes of my analysis, I’ve converted the time value into hoursafter6pm, which allows the intercept of the regression solution to be loosely considered as the “6pm starting point” for the darkness estimation, which is OK for this dataset as my data is all from this latest Autumn/Winter.
I’ve done an “ordinary least-squares” regression with multiple input variables. At first glance it seems to me that the SQ vs altitude chart above should not behave well with that: there’s a clear kink, intuitively obvious I guess, at the point the Moon altitude goes negative.
To cope with that, I divided my data into two and did three separate regressions: “Moon up” data, “Moon down”, and “All data” but treating phase and altitude as zero if the Moon is below -5 degrees (I chose -5 degrees arbitrarily).
With Moon up, I decided the SQM value will depend on Time of Night, Moon Altitude and Phase. With Moon down, it only needs to depend on time of night.
Thus my regression model is:
SkyQual = a + b.timeafter6pm + c.phase + d.altitude + residual
residual = a + b.timeafter6pm + c.phase + d.altitude – SkyQual
The analysis involves minimizing the sum of (the squares of the) residuals, by hunting around for the appropriate values of a, b, c & d which yields this minimum. I used MS Excel’s built-in Solver to do the “hunting around”.
The following table summarizes the results:
In words, using “Moon Up” as my subject, my Sky Quality, in magnitudes per arc-second, can be estimated as
plus 0.0314 /hour
minus 0.864 /full-phase (or 0.216 /quarter)
minus 0.0186 /degree above horizon (or 0.186 /10 degrees).
This is a pretty simple analysis. I’m sure there’s theory and formulae available relating Moon-altitude and -phase to extra sky brightness, but I haven’t used any of that here. And the “error model” I’ve used implicitly assumes that the relationships between SQM-reading and the variables are linear.
If anyone is curious and wishes to do their own analysis, my raw-ish data is available as a .csv file attachment at the end of this post.
A note about the data collection: each reading is an average of a few readings at a given time, with outliers rejected. For instance, often the first press yields an outlier, and over the following few seconds subsequent ones tend to settle down. So the series of readings 19.05 (me getting excited), 18.85, 18.86, 18.86 , which is a quite typical pattern, would cause me to record 18.86. My highest recorded reading, 19.13, was indeed where it settled down.
Other “one-on-one” charts:
I wasn't sure where to post this tip....it is probably of most use here....
Many of us with observatories or indoor Mission Control use Windows 10 Pro Remote Desktop to control a scope side computer running camera and scope control software from a second computer indoors. This works superbly at 1080p resolution.
However, I have struggled for a year trying to perfect a wireless solution that works with 4K UHD cameras terminating in a 4K UHD display. Until now, whilst cat 6 cable does work fine, wireless even at 5Ghz 802.11ac has struggled with some lag and poor performance. I have spent a fortune upgrading wireless adapters and range extenders, but this isn't the issue!
Here is a solution;
1. Seperate your dual band network into distinct 5Ghz and 2.4 Ghz channels.
This is easy with (say) a BT Home Hub. If you don't do this, it can be a bit hit or miss whether your 5 Ghz wireless adapters connect to the right channel. You will now see TWO channels, one at 2.4 Ghz with a suffix like <hub name> and another at 5 Ghz named <hub name -5>. Connect your 5Ghz adapters to the latter. If your internal adapters are merely 2.4Ghz, you can disable them via Device Manager and plug in a USB version costing around £5. Note that at 5 Ghz wireless range might drop. If so, a Netgear EX8000 wireless extender is recommended as it employs 'mesh' technology.
2. ONLY if you have a fast network, and powerful CPUs and quality graphics card, try DISABLE 'RemoteFX compression' in RDP.
This allows uncompressed screen data to flow across RDP. I have found this improves performance whether using 802.11ac wireless or cat 6 cable. What RemoteFX compression appears to do is limit effective RDP speeds to under 10Mbps (due to translation times). That is crazy if you have 433 Mbps adapters, and an 802.11ac network (or catv6 cable). Unleash the beast! Send across uncompressed data! The issue is not with speed or bandwidth, it is an artificially imposed limit in RDP.
To do this type 'Edit Group Policy' in the Windows 10 Pro search box (doesn't work in Win 10 Home). You need to drill down through about five levels of Windows Configeration Folders, and Administration Templates and Remote Desktop Services/Host folders to find a utility named <Edit RemoteFX Compression>. In that, your options are <disable> compression or <enable> a compromise mode.
If you don't know how to do this try Googling 'Disabling RemoteFX Compression' to find a lengthy Microsoft tutorial. Or visit https://docs.microsoft.com/en-us/windows-server/administration/performance-tuning/role/remote-desktop/session-hosts .
I deliberately don't here state the quick route sequence to access this deeply embedded network utility command because you are delving deep into developer/administrator territory and do need to understand what you are doing and how to revert to your original RDP settings if your network can't handle these levels of uncompressed screen data. We don't want any novice attempting this on a cheap Compute Stick on an inadequate network!
3. When employing RDP from your computer indoors, select <WAN 10 Mbps> or <LAN 10 Mbps> as appropriate via <Options><Experience>. The default <auto-select my connectivity> often selects too low an option. The irony here is you can select this and still not enjoy faster speeds unless you have edited/disabled RemoteFX compression.
I now have Atik Infinity plus CPWI software running in an end to end 4K UHD system terminating in a 4K UHD monitor. Over 802.11ac wireless it is now rock steady. Over cat 6 cable my system is now turbo powered. If you don't need RemoteFX Compression, don't let it restrict your network performance. It is evidently set to ensure it works on lowest common denominator networks. If you have a fast network/CPU, disable RemoteFX compression and finally release the beast of 4k UHD over RDP.