sparky8512
commented
3 years ago That's actually a pretty compelling argument for why such a thing may be useful. Unfortunately, it doesn't matter, because it's just not possible given the service interface the dish provides.
The interface includes a dish_stow request which takes no parameters, and none of the other available requests appear to be related to moving the dish position. In fact, the set of implemented requests is pretty much the exact set of functionality that the Starlink app supports, so if the app doesn't include some functionality, it's unlikely the tools in this repository would be able to do it, either.
So SpaceX would have to implement support for this in the dish software first, and I doubt they want people messing with the dish position. That being said, if they ever do add such a thing to the service interface, I'd be happy to add support for it in the tools. In the mean time, though, I'm going to close this out as unimplementable.
Feature Request: If you can accomplish the Stow functionality, perhaps you can also allow for manual orientation control.
Problem It Solves: In the mountainous backwoods of the inland Northwest, there are peculiar locations with very limited LOS. Trees rise over 100ft and rising elevations limit placement within range of the required power source. Range can be increased and power can be extended to a point but there are still sometimes limited placement options.
I'm speculating, but the orientation of Dishy appears to be a function of pointing the dish up and making an initial connection (after BOOTING->SEARCHING). Everybody has LOS directly up, right? Because there is incomplete coverage of Starlink currently and this kind of location has a suboptimal FOV, we have LOS but there's no satellite there so getting that connection can take hours or days even with the fancy antenna.
Only after making the initial connection does it apparently obtain the computed optimal angle for coverage and reveal the wedgeFractionObstructedList. Iteratively trying to find an optimal placement location for Dishy is complicated by this initial connection delay in the more challenging environment. It appears that after either a GPS change or missing several predicted satellites, it returns to vertical and tries to get a new orientation recommendation (which is often very similar to the last one).
With manual orientation control, we can externally compute the optimal Dishy orientation (or hazard a guess based on past success) and apply it, or even schedule changes to it at different times of the day as needed, completely overriding the Starlink recommendations if we so choose. The end user community may come up with some better algorithms for odd use cases, like the backwoods holler or the canyons on mars.
It also enables some fun synchronized Dishy dance routines that will make Elon smile.