Topics

Stellarium Mobile Plus and simultaneous 9998 and 9999 command ports

Dave Schwartz
 

I posted a few months back about the availability of one of my favorite planetarium programs I’ve used for years on my observatory desktop, Stellarium, and its new ability to interface to OnStep from mobile devices. Stellarium Mobile is available for Android and Apple iOS. The ‘Plus’ version (direct purchase or in-app upgrade) is the one that includes basic telescope control (as well as greatly expanded object databases, full sky images and hi-res planets). I’ll refer to Stellarium Mobile Plus as SMP in the rest of this post.

Previously SMP’s OnStep interfacing only worked over Bluetooth but since the implementation of the more persistent command channel (port 9998) of the OnESP WiFi interface, which should be much more widely used than BT, I thought I’d give it another thorough testing.

I used as many simultaneous connections as I could over multiple simultaneous network types and it all worked flawlessly (with one exception I’ll describe later). For my testing, I used OnStep 3.8k on STM32, OnESP 1.11C and an SHC 1.5h on ESP32. OnESP was configured to enable both command channels (ports 9999 and 9998) as well as to enable both access-point networking (192.168.0.1) and station mode (192.168.100.124… an address in my home WiFi). My PC was running the Chrome browser connected to the web server status page over the station-mode network throughout the testing. The OnStep app was running on my phone (Samsung S5) and SMP was running on my tablet (a cheapo RCA 10”… Stellarium mobile looks much better and is easier to use on the larger screen). I also tested both SMP and the app on my phone at the same time but obviously they both have to be using the same network mode (I only tested that combination in station mode).

To get an idea of the workload, the web server status page updates itself every 5 seconds, the OnStep app seems to update at least twice a second and SMP polls the RA and Dec coordinates every half second. The SHC also polls (but only to the main controller, not over WiFi) and pauses only 150ms between refresh cycles. Throughout the testing, the web server status page showed 29% workload when tracking and 34% when slewing (the mount is an EQ5 with 400step/rev motors running at 32 microsteps, 3:1 belt reduction and 144 worm reduction).

Basically, the tests were flawless. I tested combinations with both the app and SMP on the station mode network interface, both on the access point interface and both combinations of one on one type and the other on the other type. Nothing crashed, nothing had to be restarted, there was never any perceptible lag. GoTo’s could be initiated from any location (app, SMP, SHC) and appropriately changing readouts (moving telescope marker in the case of SMP) were displayed properly as the slew was progressing. Each interface even appropriately showed the slew/GoTo in progress indication even if they weren’t the one that did it (a red pulsing telescope if you’re in SMP’s detailed object data popup).

Even when running both the app and SMP at the same time on my phone, I could initiate GoTo’s from either and switch seamlessly between them without missing a beat. However, there is one caveat when running both on the same device… if you switch away from SMP, which pauses the network activity, for more than 2 minutes OnESP’s ‘persistent’ connection still times out and SMP sees the disconnection when brought back to the foreground. It re-establishes the connection but it takes it about 15 seconds to do so (it goes through its complete probing and information collection cycle – which is why it doesn’t work over the 9999 port).

This isn’t meant to be a review of SMP – if you’ve used Stellarium, you know what it is and how it works and if you want to try the Mobile interface, there are free or low cost versions in the app store.

This post is intended to get more people testing the simultaneous WiFi interfaces so that we can find any issues (or convince Howard there are none so the persistent command port can be enabled by default).

To that end, if you are serious about using SMP for telescope control, the author has given me some free promo codes for helping him iron out a few issues. The promo code works for an SMP new purchase (not for the in-app upgrade, as Khalid found out). Only the first five requests (as captured on the groups.io thread) for a promo code can be satisfied but if you do get one I will expect you to post your results to this thread.

 

 

Khalid Baheyeldin
 

On Wed, Nov 6, 2019 at 06:16 PM, Dave Schwartz wrote:

Even when running both the app and SMP at the same time on my phone, I could initiate GoTo’s from either and switch seamlessly between them without missing a beat.

Pretty much what I observed too ...

This post is intended to get more people testing the simultaneous WiFi interfaces so that we can find any issues (or convince Howard there are none so the persistent command port can be enabled by default).

And for those who don't have Stellarium Mobile Plus on their phone, but have KStars, do test things out with KStars (port 9998), Android App (port 9999), and a web page (port 80), all at the same time.

Side point about Stellarium Mobile Plus: Dave, you may want to convey this to Fabien. Instead of SMP probing every time it connects, it could save the protocol, and use it the next time. A mechanism to reset that would be beneficial (e.g. long press or a switch), so it would probe again.

Drew 🔭📷🚴‍♂️
 

In the same vein I have run simultaneous sessions with Bluetooth and WiFi. I am using a MaxESP2 with the Wemos D1 mini WiFi. I have tested GoTo's from Android on Bluetooth and WiFi webserver on my windows laptop. I have also tested Cartes de Ceil and SkySafari Plus simultaneous operation. Howard's code processing and structure seems to support this flawlessly.