Recently Browsing 0 members
No registered users viewing this page.
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
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.
I gave a demonstration/workshop at my local Astro Group* about a simple way of removing light pollution from an Astro Photo.
The description I gave was deliberately for beginners, using a wide angle tripod shot photo and using one of the easiest packages to get to grips with (Paint.net).
The attached pdf covers the basic technique.
I'd appreciate any feedback on it.
* The Mid Cheshire Astronomical Group - all welcome, we meet on the last Friday of the Month.
By Split Zygote2
A little long - sorry! This cord wrap issue may (or may not) happen to someone else and result in a less fortunate outcome. AND apologies if this is already a well known foible of the equipment in question - I did do a search with a negative result.
Formatting may be a little weird as I did a copy and paste from a word programme but see point 3 below!
firstly, the mount - it is BLAMELESS (a statement of faith; we have bonded!)
secondly, what happed may on the one hand be the result of a unique set of circumstances that will not occur again before the end of time, yet on the other hand.......
thirdly, I am a Board Certified Muppet (Eldest Child's Opinion and possibly not wrong) - when anything related to computers or software is involved. Computers just know when you don't like 'em!
The mount (a mid 2016 example) was very recently upgraded by obtaining the SkyWatcher SynScan WiFi module, the SynScan App (Pro 1.11.3) which I run on an iPad Air (the first one) using iOS 12.0.1. This was connected to the dongle(?) generated WiFi to control the mount. I have used this set up for a few nights without incident.
I had set up outside on the patio and the mount was slowly tracking across some trees at a sidereal rate (it was daytime) as I was occupied in balancing some new equipment. The Wi-Fi module was plugged in, the mount in Alt-Az mode was being controlled by the iPad using the SynScan App alone (i.e. no planetarium programme or any other device was involved); power as usual was supplied by a fully charged Tracer LiFePO4 12V 16 Ah battery which typically supplies according to my meter around 14 volts over a 2 metre length of cable. All was well, however at this point my brother phoned to query some points in an e-mail that I had sent him.
Leaving the mount to do its own thing I went into the lounge via the French Doors, taking the iPad with me, sat on the sofa and loaded up the mail programme to review the mail in question - this doesn't require an internet connection. It is unclear whether or not I shut down the Syn-Scan App (probably not) and I do not know at this point whether the iPad reverted to the Home Wi-Fi network (still on auto join) or stayed connected to the mount's. I suspect it stayed paired with the mount as the mount was much nearer and that is what it had always done before.
After a short while on the sofa talking to my brother I became aware of a noise that sounded like a cross between a stationary, hovering camera drone and an angry hornet. The noise was strangely persistent and unchanging in character - so I idly walked outside to investigate.
The AZ EQ6 was in distress, not moving and with the power plug bent to an unnatural angle as the motor strained against the power lead which was tightly wound several times around the mount. In addition my TeleVue 85 had seemingly been doing a fair imitation of a propeller as while it was currently motionless and horizontal it was upside down (very fortunately not hitting anything in the process). I cut the power released the clutches and manually untangled the cable. The plastic plug insert inside the metal plug housing screwing the power cable to the mount had fractured neatly into two (possibly by design) but otherwise based on subsequent testing the mount would appear as yet to be undamaged. It could have been a lot worse.
In previous instances of briefly, absentmindedly and unintentionally exiting but not shutting down the Syn-Scan App nothing dramatic has occurred. Evidently on this occasion, in these circumstances and given the short amount of time that I was away from the mount, the mount seems to have moved at full slewing speed 'til it could go no more however hard it tried - I would estimate based on the cable wrap 2 full revolutions or so - at the time I wasn't counting . As far as I am aware in a normal Go-To (and the mount was not left going to anywhere it was just left tracking) the mount obeys its software limits to prevent cable wrap (at least using the SynScan hand controller v4.something) and to intentionally recreate this situation I guess you would have to manually hold down the slew control until full cable wrap was achieved; self evidently I was not doing this. Whatever (a word I thought I would never use thus), IT DID NOT FAIL SAFE.
The lesson learned is to maybe Hibernate (the App speak for Park) the mount if multitasking with the iPad, better still not to multitask or if unavoidable to stay with the mount.
At the moment and without further experience I would be reluctant to again leave the mount to its own devices when using this set up for control. The mount is in regular use carrying a heavy scope that requires 20 kilos of counterweight - had this been the case on this occasion it might have cost very much more than a new power lead.
Any thoughts or opinions would be welcome. Our nearest neighbours are SHEEP and although noisy on occasion I feel that they are unlikely to generate much in the way of RF interference.