noah4x4

Quality of 12v battery is crucial with a NUC. I had no problems with my Tracer 22aH. But my i5 NUC didn't like the 12v output of some cheap Chinese battery packs that offer circa 12v but soon deplete to 11.3v. The NUC needs an absolute minimum of 11.6v. However, I have recently tried a different solution with interesting success. Connect a 12v DC battery to a 12v DC/240v AC Bestek 300w power inverter (£26). Then use its 240v output with the manufacturers AC adapters supplied with camera, focuser etc. This is a great replacement where mains electricity is not available and often used by caravanners etc. Whilst this sounds convoluted, the supply seems to be more regular/reliable as the NUC then gets its 19v, the camera get 12v, focuser 12v, with each receiving the correctly specified voltage/amperage as it uses it own AC adapter as if connected to the mains. Just make sure you buy an inverter that has enough wattage. I put battery, inverter and plug sockets in a small plastic easy to carry tool box.

People argue cable is the only reliable solution for large sensor high resolution cameras. But USB (or HDMI) is limited. The signal dies in under 30 feet of cable. Cat6 cable or wireless is far superior. However, many slimline modern computers don't have RJ45 Ethernet connectors (e.g. for Cat6). Fortunately, you can buy cheap USB to RJ45 converters. However, you may also need a powered Network Switch.. Wireless can be much easier than cable if you know how to (say) manage Windows Remote Desktop and RemoteFX compression. See my earlier post. You might have a 433 mbps wireless network, but if RemoteFX compression is strangling it,, you might struggle to exceed 10mbps. Resolve that and you can discard cables. But best advice, keep any USB cables short.

That day has huge memories for me. Aged merely 16, I was representing Great Britain at the Idaho Farragut State Park Boy Scouts of America International jamboree. First time I had left the UK, let alone flown to another continent.. Was privileged to meet Astronaut, Frank Borman; Boxer, Archie Moore and Jessie Owens. Then watched the Moon landing on a colour TV which I had never seen before (and yes, the lunar images were grey!). The overall experience changed my life deeply as it instilled a "can do" mentality into a previously unambitous child that had up to that point largely wasted his education and opportunities. I went on to enjoy a wonderful career that brought great satisfaction and reasonable affluence. But had I not been inspired by the combination of the Moon landing and this additional event. I suspect that I might have stumbled through life. But instead I now have few "I wish I had" regrets. One of my greatest is perhaps not making time to properly enjoy astronomy until my retirement, but one cannot have everything.

You simply connect PC to the SkyPortal external WiFi accessory rather than to your regular WiFi network when in Direct mode. Alternatively, you can connect both to your regular WiFi network in Access Point mode. CPWI will auto-find it. When you select connect to WiFi.

Answering a question from an earlier post.... You do NOT need NexRemote with CPWI. So no messing about with Win8 compatibility mode required. You can now directly link your scope to a Windows PC using a SkyPortal external WiFi accessory. Previously that was only possible with Android/IOS.

CPWI is your best solution, and being realistic, all you need today. Stellarium or Cartes Du Ceil do have more sophisticated databases, but (no disrespect), you are not going to see the vast majority of the extra objects they include through your limited scope. My advice is don't waste money investing in accessories for it unless they can later be migrated to a higher quality GEM. Astrophotography on an Alt-Az is challenging; and a wedge can be frustrating; and the only other Alt-Az solution is Hyperstar. But I suspect your scope is not Fastar/Hyperstar compatible. It's a good beginners scope and will offer a lot of initial fun. But if smitten by astronomy, you will soon wish to upgrade.

Celestron has announced firmware updates for both Nexstar and Nexstar + HC's that will resolve the 'GPS Rollover Bug'. These are available within TeamCelestron, where final beta testing is being concluded before final public release.

Celestron is working on a firmware fix and I posted an interim workaround above. I think Derik's (firmware engineer) comment needs to be put into perspective as it doesn't reflect an uncaring attitude. It was also made in a confidential forum designed for beta-testers and with an entirely different purpose to SGL. Posting that comment in SGL is a breach of TeamCelestron terms & conditions, especially as it is quoted out of context. I don't know anybody else as passionate about customer problems or works harder to find solutions to often tricky unexpected challenges. It seems that NOBODY in the astronomy equipment world anticipated this problem until it had almost dawned on us. Twenty years ago, Telescope manufacturers bought GPS devices from third party suppliers either oblivious of their 1024 week lifetime or with the intent of finding a fix before it expired that then got forgotten. The firmware enginners that originally implemented this are probably long retired. It was cutting edge technology at a time when many of us still had mechanical watches. It's absolutely true, "everything does die eventually" and merely reflects the status of that component.. Derik is a top guy who is currently managing solution finding for a huge number of challenges. Just count the number of current threads in TeamCelestron. I am confident a firmware release will appear soon. But is it any great hardship to manually input year data for a few weeks while this is fixed? Let's give the man a break, as until late-March he didn't even know there was a problem. A part has 'died' out of warranty after a lifetime of 19.7 years from its inception (albeit that the timescale for some purchasors is less). Cars regularly get recalled for unforeseen component failure. Why should telescopes be different? Thankfully, it sounds like a no cost solution is feasible soon.

Each version from 5.0.0.1 to 5.0.0.4 (there was no 5.0.0.5) cured one bug but introduced another. ASCOM drivers are fine in theory, but once the suite needs to add a CMOS camera (like Horizon) with additional variable controls (like for filter wheel) it becomes more challenging because SharpCap, SG Pro, APT and Dusk all deal with this differently. Adding the Horizon functionality then screwed up some Atik CCD cameras and other devices and its not been easy to find solutions. However, 4.2.2.9 works fine with Infinity, Artemis Capture and third party software that worked before. The latest version is 5.0.0.6. In daylight test I have had this driver working fine with SharpCap and SG Pro (not tested Dusk), but persistent poor weather has prevented a proper darkness test.

Care with this because many of the accessory cables sold on (say) Amazon that have the 'right' plugs are incorrectly wired and will fry yoir circuitry. Three years ago I tried all the reliable UK astro-kit suppliers without success. It is not easy to ensure you get the right one unless you have it made up bespoke. So instead, I bought a SkyPortal external WiFi accessory permitting remote control from a phone/tablet (Skyportal APP) or from PC/laptop (via CPWI). But it begs the question, why do you want a longer HC cable? If your plan is to do (say) Astrophotography from (say) indoors most folk will start by solving scope control from a distance. Then, they generally find they need a different solution for camera. Then, another solution for focusser or guiding; then have power supply challenges. If attempting something like this, you are probably best served by looking at the holistic challenge, as there may be better solutions once you take a helicopter view of where you want to be. Most folk want fewer cables, not more. Lots of good ideas in the EAA Forum (EEVA)

An easy user work around for older Celestron mounts that doesn't require a firmware update has been posted in Cloudy Nights. It involves allowing GPS to insert date (which is incorrect), time, location, then using <undo> after turning off GPS then changing the year/date via the HC Menu. As year is the easiest coordinate to remember and user input accurately, you keep the benefit and convenience of time location accuracy from GPS and its just a few extra step to update date. Should work fine until a firmware release is made.

Atik has issued five versions of the 'Core Software with Dusk' in two weeks. The latest on 1st April. One problem being that the new ASCOM Driver didn't support the CMOS Atik Horizon in Sharpcap, SG Pro and others, hence limiting Horizon owners to Atik's own software, which is great software, but some of us wanted to embrace SG Pro, as well as Dusk, similar to it's range of CCD cameras. A 'Select camera' feature was added which incorporates the setting of Gain for the Horizon. But each new iteration introduced a fresh problem now affecting the wider range of Atik Cameras. As regards the Horizon, it would work in Sharpcap, but no longer work in Infinity. Then the next version added SG Pro, but it stopped connecting in Sharpcap. However, I stress version 4.2.2.9 still works fine with Artemis Capture, Infinity, and all other software supported prior to March. So it's perhaps best to consider Dusk and its new ASCOM drivers as being still in beta-testing and roll back to version 4.2.2.9 for all other use. Atik is now up to version 5.0.0.6 released on 1st April, which I have tested in daylight and it does appear to offer a solution to the Horizon's 'Camera not connecting' problems. The buttons to control the missing functionality (gain etc) also appear, at least for the Horizon. I can't comment on the CCDs. Hopefully, the unforseen bugs for the CCDs have been fixed too.. However, it has been wall to wall cloud in East Anglia hence frustrating any night time testing, and as I live close to Atik's HQ I guess they might similarly be struggling with their live testing. In summary, it is worth trying 5.0.0.6, and Dusk and the more people beta-testing this with a wider range of cameras the better, but don't be surprised if you need to roll back to 4.2.2.9 to maintain the previous functionality that you enjoyed . Frankly, I think Atik have responded well to this crisis, but clearly didn't anticipate the incompatibilities between various third party software where deploying CMOS compared to CCD, a step which has evidently proved troublesome despite ASCOM protocols. However, I am fairly confident that 5.0.0.6 should be fine......fingers crossed.......But we still have 4.2.2.9 so nothing is lost from where we previously were.

Celestron aim to have a solution available in 4 to 6 weeks. Reassuringly, the 6th April rollover date only affects GPS electronics manufactured before 2012. Later units will have future rollover dates, and will similarly be resolved. However, it appears nobody was aware of this 'Epoch' limitation until the first rollover date was imminent. I believe it results from each week being stored as 1 byte with a limit of 1 kilobyte (hence a limit of 1024 weeks). Nobody expected this crude basis to outlive the equipment it was installed in. Put another way, an assumption was made by the component suppliers that in 19.7 years nobody will still be using this, but then only the astro-community hangs onto RS232/serial/Win7.....so is this any surprise? I wonder if Meade and other mounts are affected given they must use similar technologies?

I think we have to keep this issue in perspective. I only posted this information to assist those that have not turned on their GPS since Sunday and today find it reporting "1999". Most scope owners will NOT be affected. I gather this issue was a bit like the Millenium 'bug' and nobody had much idea of what actual equipment was likely to be affected until the actual 'rollover date' of 6th April. The possibility didn't even come to light within TeamCelestron until very recently (March 2019) and my understanding is that Celestron has since been frantically trying to get information from its past suppliers of electronic components. So far, I believe it affects only CPC scopes AT LEAST five years old as the current supplier of GPS electronics to Celestron had resolved this when it took over supply in 2014. So far, I have only heard of adverse reports from users with (say) 2006 vintage scopes being affected, so it might possibly affect only scopes over ten + years old. This extent of the issue is unclear until more users come forward to report this problem which is unlikely to be unique to Celestron astronomy equipment. Celestron was also unable to properly test for this until the rollover date because they could no longer get information from some previous component suppliers (presumably no longer manufacturing) and I suspect they don't have many legacy old scopes in their workshop to test with. I should have said "...only immediate solution is use the HC...". as I believe Celestron is seeking a firmware update workaround now that older CPC mounts have been found vulnerable. The 'bug' did only strike two days ago and I guess only a handful of SGL members that visit TeamCelestron had any prior idea of its existence too. So, it would perhaps be harsh to be too critical of Celestron providing that it is fixed promptly.

I reported this possibility in an earlier post, but it deserves its own thread to properly alert people.This 'bug' has now been reported to be affecting pre 2012 manufactured Celestron CPC 9.25 models. The rollover date was April 6th 2019. The problem is that the internal GPS units have run out of dates and have reverted to 1999. The only solution is turn off internal GPS and use the hand controller for manual data input. Maybe others can add to this thread as and when problems with other makes of older mounts are identified. However, Celestron telescopes manufactured after 2014 should be fine.

It is also worth viewing the Atik Horizon video available on the Atik site explaining how it cleverly applies <gain>. It has a full well of 20,000e at around 4,800 ADU, but amplification boosts that to 65,536 producing a stunningly good signal to noise ratio. Everybody tends to focus on comparing the capabilities of "sensor x versus sensor y". Frankly, I don't claim to fully understand all the technicalities, but it is clear to me that any appraisal of CMOS versus CCD needs to look beyond mere sensor performance and consider the additional capabilities of the electronics. Never mind the theory, what are the practical results? Atik claim performance of its CMOS is matching CCD at lower price and my experience of the Horizon has been awesome, albeit I won't ever win Astrophotographer of the year as no camera can ever compensate for a clunky mount and limited user skills.

Much depends on equipment and accurate user data inputs. My Celestron Evolution or Nexstar SE4 if autoaligned using Starsense with data sourced from GPS has superb GoTo accuracy. Will consistently centre my Targets in even a 12.5mm cross hair illuminated reticle EP.

The computer at the scope is running Windows 10 Professional. Hence you reduce or disable RemoteFX compression ONLY on that as it is acting as the primary 'server' device. The computer running indoors is simply replicating the screen output for the primary device with keyboard/mouse (albeit that is running 'headless'). It hence performs a the role of a dumb terminal. But even if simply receiving and re-drawing 4K UHD screen data it requires a data transfer rate exceeding the artificial restriction of 10 Mbps. However, at 1080p HD no amendment might be necessary. Frankly, I would initially try without adjusting RemoteFX compression as if your camera isn't demanding it may run fine on normal Windows Remote Desktop settings. However, if you suffer any lag or stutter, then try it before investing in greater computing or network power.

Upgrade to Win 10 Professional is easy. You pay your money to Microsoft and it auto-updates. Windows 10 professional gives you so much more control. See my tip about RemoteFX compression in previous post.

Some relevant information I learned about this month... A reason why high resolution (16 megapixel) cameras often stutter and suffer from lag over Windows Remote Desktop (or similar) is 'RemoteFX Compression'. You might have a 433Mbps wireless network or an even faster Cat 6 cable LAN and it won't let more than 10 Mbps through the system. 4K UHD screen data requires far more than this. The reason it exists is that in commerical networks or across the Internet it is designed to prevent any single user from throttling the wider network by excessive data. But if strictly confined to your home network you don't need this degree of compression and if you reduce it or disable it then your WAN/LAN network will become turbo charged. Not only can I now run my 'end to end' 4K UHD system wirelessly, I reckon that I could now achieve that using lesser computing power and certainly lesser network capacity, hence saving considerable money. Hence, lower specification compute sticks are potentially more viable, but do check their memory and storage capabilities as each individual 16 megapixel frame tends to exceed 48Mb. I still favour an Intel NUC (and you would need Iris 640 Graphics for 4K UHD). But this tip will speed up data flow on any system, including 1080p HD. To learn how to fully manage RemoteFX Compression and its enviroment visit this document; https://docs.microsoft.com/en-us/windows-server/administration/performance-tuning/role/remote-desktop/virtualization-hosts But below is the key text for the purposes of reducing or disabling RemoteFX Compression (note applies to Windows 10 Professional etc). RemoteFX data compression Microsoft RemoteFX compression can be configured by using Group Policy under Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Remote Session Environment > Configure compression for RemoteFX data. Three values are possible: Optimized to use less memory Consumes the least amount of memory per session but has the lowest compression ratio and therefore the highest bandwidth consumption. Balances memory and network bandwidth Reduced bandwidth consumption while marginally increasing memory consumption (approximately 200 KB per session). Optimized to use less network bandwidth Further reduces network bandwidth usage at a cost of approximately 2 MB per session. If you want to use this setting, you should assess the maximum number of sessions and test to that level with this setting before you place the server in production. You can also choose to not use a RemoteFX compression algorithm. Choosing to not use a RemoteFX compression algorithm will use more network bandwidth, and it is only recommended if you are using a hardware device that is designed to optimize network traffic. Even if you choose not to use a RemoteFX compression algorithm, some graphics data will be compressed. I was so frustrated by lag and stutter that I decided to completely disable the RemoteFX compression algorithm, but others tell me that the less aggressive three values (bullet points) will also work great - just don't do it over the Internet or your office network!. My system now flys irrespective of the screen data load I am transmitting using Remote Desktop. Sorry, I don't know how to do this in TeamViewer or VNC, or even if it is possible.

Why not helpful to the OP that said he is planning to buy a mount? If his original choice can't meet his needs due to being unable to see Polaris his best option is to choose another mount that does offer a solution.

I echo this. I can't see Polaris due to obstructions but Celestron mounts have a feature called All Star Polar Align (ASPA). Works brilliantly with just HC or Starsense aided. Has also been added to Celestron's new CPWI software now in beta test.

Hi Gina, I did a lot of professional public speaking in my career and have couple of thoughts based on what you have said so far. Given this audience is not astro people - I think I would first engage their interest by first talking about something they will understand - terrestrial photography. Hence, describe how a DSLR camera works first. Hence; reverse thes two slides Explain how terrestrial images are typically done with short exposures and how that works fine. Then explain that longer exposures and adjustment to ISO are necessary to capture enough light for evening pictures. Then it is natural progression to quickly explain how more extreme long exposures (or stacked long integration time short exposures) are needed to do astrophotograpy . Then mention how daytime images can get blurred if you are trying to capture an image of a fast moving car. Then, only after people have grasped these essential camera basics, explain the rotation of the Earth and the impact that has on long term exposures and the need for tracking and or guiding. If you offer this same information the other way round, I don't think many in a broad audience will adequately make the link between exposures, earth's rotation and 'star trails'. However, if you reverse this, it becomes a far more logical progression of information. Just my two-pence worth....

The only astro equipment issue I have ever found with Win 10 is that it doesn't natively support RS232 Serial devices, but what modern computer has a serial port? The solution is simple; for older legacy RS232 devices buy a £10 serial to USB adapter cable and install the appropriate PL2303 driver. Win 7 computers tend to be slow and clunky. I can't see any justification for not upgrading other than cost. Turning off updates and other intrusions is easy. But I never connect my two astro dedicated computers to the Internet when running my scope. I just create a local WAN or LAN using Windows Remote Desktop with zero Internet connectivity. It is particularly easy using cat 6 cable. You don't need a router/hub or access point unless using TeamViewer or other options that do demand Internet access. Win 10 Pro is vastly superior to Windows 10 Home. As I mentioned earlier, you can reduce levels of RemoteFX compression and control many more facets. I too was initially uncomfortable with the progression from Win 7 to 8 and 10. But once familiar with Win 10, life isn't difficult. Indeed, it is much easier as it supports faster communications technology whether cable or wireless.

This is NOT correct. For Windows Remote Desktop to work you need Windows 10 Pro only on the scope side computer which I run 'headless. Then Windows 10 Home is fine 'indoors'. Wireless range is comfortably 30 feet, but use a Netgear EX8000 wireless extender (or cat 6 cable) if you need longer. Windows RDP is much more reliable than TeamViewer which now insists on running over the Internet to check for commercial use. To get 'peer to peer' on your WAN or LAN you need to pay a subscription. RDP is better value unless you can keep an older TV installation running (e.g. don't upgrade!). A Tip... Windows Remote Desktop artificially screws down screen data transfer below 10Mbps even if your network can handle 433Mbps (e.g. 802.11ac wireless adapters). This means software for 16 megapixel cameras may stutter/lag on the indoor display device if running a 4K UHD display. To resolve this, disable 'RemoteFX Compression' via Windows 10 Pro 'Group Profiles'. But only do this on your local WAN/LAN. This compression is to avoid a single user "throttling" commercial networks. But at home, release its full power and turbo-charge your network! I have posted fuller instructions in the Observatories Forum. The only benefit of running older Win7 laptops is access to serial ports. But put a PL2303 driver into a modern Win10 PC and enjoy fast USB, or better still 'Thunderbolt' display cable; 802.11n or 802.11ac wireless and a generally better experience. OK, the GUI is little different, but it's not difficult. I connect both of my astro computers using RDP over cat 6 cable with zero Internet connectivity. No 'updates, no 'notifications', no Google or Microsoft intrusions. Only when I need to get new astro software do they get connected to the WWW. Life is then a joy with Win 10 Professional.