Sky Safari 6+ installed on Android phone and works great. Checked Forums and found an answer that Sky Safari 6+ would work on Chromebook. Installed Sky Safari 6+ on my Chromebook. Installation worked fine. Connects to Celestron Sky Portal Wi Fi. The scope, (Celestron 8 SE) won't respond to commands and gives the message, "connected to Celestron Wi Fi but scope does not respond to commands, check type scope selected." I have checked Celestron Wi Fi, same as my phone. Have any suggestions?
8 comments
-
Matt Harper Same error for me with SkySafari Pro. Using a Samsung Chromebook Pro. Latest OS updates installed. Works fine on my Huawei Mate 10 pro and Nexus 9 Tablet. The Chromebook was the preferred location for running SkySafari.
-
Bill Tschumy We don't test on Chromebook or claim to support it.
That said, try capturing a scope log file and send it to me at "bill@simcur.com". Maybe that will indicate the problem. The instructions for getting a log file are in the Help for Scope Communications. However, I don't know if those instructions work for Chromebooks.
-
Paulimirie10 I gave up. I drug out my wife's old ipad, 2nd version. I reformatted it into my own account and loaded SS6+ on it. Works great.
-
Matt Harper Hey Bill, I sent the log file. Totally understood it's not officially supported. Would be great to have that in the future though. The app seems to run fine otherwise.
-
Bill Tschumy Yes, I responded to your email but I'll add the response here as well:
The log file shows a failure on the very first command that is sent. There is no communication at all.
This is what I would expect if you hadn’t joined the Celestron Wi-Fi network or if Chromebook had blocked the communication.I don’t have a Chromebook that will run Android apps so I can’t try this myself. You could try posting on Cloudy Nights to see if anyone there has figured it out. I do see one poster there (JazzyOldMan) also reports it not working.Possibly I can dig into this in the next month or so and see what is up.Bill -
RA Not sure what the status on this problem is, thought I would add my input.
I have a DIY basic encoder system which talks to sky safari, and I had a similar problem on chromebook where skysafari would connect and then appear to timeout giving a message similar to the OP. At first I thought it was a chromebook android app related problem.
I investigated my particular case a little bit more looking at the logs from both the skysafari and encoder side (which is a python script). I noticed that sky safari 6 pro on the chromebook sends a H command after the initial QQQQQQ.... and my basic encoder system did not know what to do with H which resulted in the timeout on the sky safari side. However, this does not happen when SS6 Pro is run on just Android on a tablet. It sends QQQQQQ.... followed by Q s. Googling led me to the information that H meant querying the encoder resolutions in <num>-<num> format. So I added that to my scripts and, sky safari started working. My equipment setup on SS6 Pro does have the encoder resolutions set in Scope Setup -> Mount Type page but on the chromebook SS6 still sends the H command.
So maybe not all devices can handle the H command which is causing this problem? Might also point to some bug in SS6/Chromebook Android which causes the H to be sent in the first place.
-
John Sillasen How much native memory is in the Chromebook? Also how much available memory?. Considering most Android cell phones have 4 GB to 6 GB (the 12 GB is quite new in the cellphone world). Even with 6 GB on mine, too much in memory can be problematic. I've even seen characters thrown like H when you expected something else. Clearing memory and I do mean RAM not disk space (why do kids these days call disk size memory anyway). Old school... I've thought Chromebooks have less than most laptops.
-
RA My Chromebook has 4GB RAM. SS6 Pro does consistently send a H just after QQQQQQ..., which seems like the correct time to send a H to know the encoder resolution. I think SS6 Pro on the chromebook is using a different protocol than the one marked, causing this problem. Or it somehow does not see the encoder resolutions set on the mount page on this platform.