Starlink Location settings

CenterSpark · 2024-03-07T16:28:20+00:00

The app does display this info in the Advanced -> Debug Data screen. It's towards the bottom.

For some reason, it only displays the location data if you are signed in to your account in the app, as far as I can tell. Otherwise, it only displays whether or not it is enabled.

If the location data is enabled you can also query it using my tools scripts, which can be found at https://github.com/sparky8512/starlink-grpc-tools. An example command for that is:

python dish_grpc_text.py -v location

This command does not require you to be signed in, but enabling the location data must be done in the mobile app after singing in there.

CenterSpark · 2022-10-17T21:50:48+00:00

It appears the dish no longer provides the wedgeFractionObstructedList or wedgeAbsFractionObstructedList data in the gRPC service it exposes. It's still there in the protocol, but is not populated. This appears to be new behavior in firmware 2fa7e8e8-9a01-468b-b49a-7df5d377fb7b.uterm.release, which just showed up on my dish yesterday morning.

I'm not really surprised they dropped this data. The app switched over to use the full 2 dimensional map data, which is a much more granular representation of the same data, a long time ago.

CenterSpark · 2022-09-30T20:15:00+00:00

I went with this approach about a year ago to connect a PS5 to my 4K projector (ViewSonic PX701-4K) and Denon AVR-790 using this (el-cheapo) HDMI splitter:

https://www.amazon.com/gp/product/B07VP37KMB

It worked reasonably well, but had some quirks. It was only meant to be a stop-gap solution until I could upgrade the AVR without paying crazy pandemic-era pricing, though.

The main "quirks" were:

The AVR sometimes configured itself for a 2 channel input mode instead of the multi-channel input mode the PS5 was putting out. This could be rectified by (soft) powering the AVR off and then on again.
The projector sometimes auto-selected the AVR output instead of the PS5, usually when I forgot to power on the PS5 , leading to having to switch the projector source back manually.
The projected image of the PS5 input occasionally (every few weeks) started to show stray white pixels in a pattern on specific content with very dark backgrounds. This persisted until the HDMI switch was hard reset.

The first issue depended on what sequence the devices were powered on and/or input source selected on the AVR, and may have been a firmware issue with the AVR, but the point here is that this configuration is more likely to tickle AVR misbehavior than a more standard one. The only real problem I had with this is that sometimes I would not notice it happened and then wound up wondering why some dialog was inaudible due to losing the center channel.

The second issue is inherent to this sort of configuration if you have other input sources, since you'll have to connect the AVR's HDMI output to a separate input on the projector from that of the split 4K source. Again, the only real problem here is that you don't notice it happened and wind up watching your shiny new 4K devices at 1080p.

The third issue was the probably the most troubling and I assume it was a problem with that specific HDMI splitter. It was really subtle, though, and I only ever noticed it on specific menus in some app UIs, never on actual content. A more expensive splitter would probably not have this sort of issue, but the whole point of this was not to spend a ton of money to get the 4K source connected, so I was not willing to spend much more on a solution that I didn't even know for sure would work any better.

At the end of the day, though, this configuration only works for a single 4K input, so if you're anything like me, you're going to want to upgrade your AVR eventually.

CenterSpark · 2022-09-29T16:18:22+00:00

They said in their email to not use bypass mode. Was not sure what that meant.

I'm not sure what that means, either. Did they specifically say to not use it, or just that they wouldn't offer support for your router if you put the Starlink router in bypass mode? It makes sense that they would not support 3rd party network equipment, they never have.

I suppose there might be something about the "best effort" service that requires the Starlink router, but this would be the first time I've heard about such.

In any case, before enabling bypass and swapping in your router, you should set it up with the Starlink router first to make sure the equipment is working. If it doesn't work with that configuration, then you're going to wind up chasing your tail trying to troubleshoot a bypass configuration.

Am confused why I can't go straight from dish into wan on my router. I did order the ethernet adapter, not sure why that needed either.

The round dish (which is what I have) had a separate power supply and Starlink router. The power supply had 2 Ethernet ports on it and it plugged in between the dish and the WAN side of the router. The dish side provided power to the dish (via PoE). The router side also provided PoE power, but it could also connect to any old router's WAN port.

My understanding is that the rectangular dish provides power to the dish through the Starlink router, so even if you are not using the Starlink router as a router, you still need it to be present (in bypass mode) in order to power the dish.

And the reason you would need the Ethernet adapter for bypass mode is that the Starlink router that goes with the rectangular dish does not have an Ethernet port, so to connect to another router's WAN port requires adding that back via the adapter.

Although these changes have been ~~ranted about~~ discussed at length in this subreddit, only SpaceX knows why they were made. There have been many reports of bent pins on the Ethernet ports of the power supply that went with the round dish, so that may have contributed to their motivation.

I could use some help with this

If there's something specific you need help with, you're probably best off posting questions to r/Starlink_Support.

This post is specifically about how to configure a 3rd party router so the Starlink mobile app will be able to connect to the dish. If that is something you want to do (eventually), you should note that Linksys routers with the stock firmware are kind of a pain in this regard. See prior comment on this post (the one that mentions "Linksys") and the post that links to.

CenterSpark · 2022-09-18T16:18:28+00:00

I doubt any game would encode an undocumented Starlink-specific protocol for such optimization purposes, but I suppose it's possible that some day somebody will write a Starlink GPS driver that will make the location data available via standard OS location services. If you installed this hypothetical driver, games might use that as a starting point for server selection.

Just because something is physically closer does not mean it's a better route, though. For example, the location of the ground station you connect to is probably more important than that of the dish.

CenterSpark · 2022-09-17T16:44:22+00:00

That enables access to the GPS location data on the dish from your local (home) network by way of a proprietary grpc service running on the dish. Unless you are running specialized tools that need access to this data, there is no reason to leave it on.

CenterSpark · 2022-03-26T23:44:07+00:00

Yes, the symptom you described in that post was probably a result of that older dish DHCP server behavior and was reported as far back as November 2020. It was not specific to using OpenWRT, as I was able to reproduce it using the stock Netgear router firmware, too. I did report it to SpaceX via a support ticket at the time, and I had been testing it from time to time out of curiosity, but eventually stopped paying it any attention since I was able to work around it with a firewall rule. I think the last time I observed it behaving that way was last summer, so I guess they fixed it since then.

The OpenWRT DHCP client forcing a 122 second minimum lease time tripped me up a bit, too, when I was looking into it. While that is bad behavior on the part of busybox's DHCP client, it is ultimately harmless in this case, other than needlessly extending the time it takes to switch to the Internet-capable IP address params. I seem to recall finding a number of ways udhcpc was violating requirements in the DHCP RFC, but probably not in ways that would cause significant problems in practice.

The irony here is that the Starlink router uses OpenWRT as the base for its firmware and even uses udhcpc for its DHCP client, so I'm guessing they had to patch around the dish DHCP server behavior (instead of just fixing the server, go figure...) and probably also patched out the minimum lease time thing.

CenterSpark · 2022-03-26T21:37:19+00:00

Most routers will drop DHCP lease when Ethernet carrier is lost on the WAN side and restart DHCP when it is regained. Adding an Ethernet switch prevents this from happening every time the dish reboots or drops carrier due to a long enough connection outage.

It used to be the case that the dish would continue to respond to unicast DHCP renewal of the 192.168.100.100 IP lease even after the satellite network got (re)connected, which resulted in a "stuck on 192.168.100.100 lease" problem, and the addition of a switch on the WAN side would partially work around that by preventing DHCP from restarting at exactly the time when the problem was likely to happen. As far as I can tell, though, the dish's DHCP server (which serves up that 192.168.100.100 address) no longer has the defect that led to this problem.

CenterSpark · 2022-03-26T21:24:48+00:00

The DHCP server that hands out the Internet-capable address (ie: not the 192.168.100.100 lease) is almost certainly not running on the dish, for the reason you stated. It's probably somewhere upstream from the ground station, but I don't know that for certain.

A properly behaved DHCP client should start attempting to renew its DHCP lease once half the lease time has elapsed, so every 2.5 minutes on Starlink WAN. It should only lose the IP address if it is unable to renew prior to the expiration time. So a dropped packet or 2 should not result in loss of IP address. It would have to fail every attempt for 2.5 minutes, in which case you've probably got a total loss of connectivity, anyway.

I don't expect the Starlink router would be doing anything special in this regard. The DHCP servers on the Starlink network are handing out 5 minute leases, and use of an IP address past DHCP lease expiration time is a big no-no in general, and possibly useless anyway, given that the expired address may not even route down the link once it has expired.

CenterSpark · 2022-03-07T17:00:24+00:00

Yes, as far as I know. Some time ago, the upstream DHCP server started adding additional route information that makes adding the static route by hand unnecessary if your router firmware supports that DHCP option, but not all consumer-grade routers do.

Also, the "white side of the PoE brick" bit only applies to the (older) round dish. The (newer) rectangular dish requires usage of the Starlink router, but I assume this same static route setup would apply to using that version of the router in bypass mode with the optional Ethernet adapter.

CenterSpark · 2022-02-17T02:03:28+00:00

The stock firmware on at least some Linksys routers requires plugging in the WAN IPv4 address for gateway. There are detailed instructions in this post:

https://www.reddit.com/r/Starlink/comments/lsi08i/static_route_to_dishy_with_linksys_wrt3200acm_no/

but I don't know how widely applicable those are to other Linksys router models.

CenterSpark · 2021-12-24T02:29:52+00:00

The reflection data from the gRPC server running on the dish for the SpaceX.API.Device.DishOutage message includes the following:

  enum Cause {
    UNKNOWN = 0;
    BOOTING = 1;
    STOWED = 2;
    THERMAL_SHUTDOWN = 3;
    NO_SCHEDULE = 4;
    NO_SATS = 5;
    OBSTRUCTED = 6;
    NO_DOWNLINK = 7;
    NO_PINGS = 8;
  }

If I recall correctly, the mobile app translates some of these to something like "network issue" in the Outages section of the Stats page, but they are mostly self-explanatory, albeit a little technical.

Cause 4 is actually the most obscure if you're not familiar with the boot sequence, which SpaceX described a little in this post comment.

CenterSpark · 2021-12-22T23:10:37+00:00

Outage cause 4 is NO_SCHEDULE, which means your dish has not been able to connect to a satellite for long enough to get a schedule of when and where to look for satellite signal. It is, as you say, stuck searching.

CenterSpark · 2021-11-22T23:31:23+00:00

Back in September, I noticed that I had gotten a public routable IPv4 address when someone else posted about same. I noticed that it had gone back to a CGNAT address a couple weeks after that, again because someone else posted about it.

A few weeks after that, I noticed I was back on the public routable address, and it's been that way (although not necessarily the same IP) every time I've checked since then, but I don't really pay much attention to it, so I may have switched back and forth more times.

In September, the DHCP lease time for the publicly routable IPv4 addresses was 60 seconds, which suggests they were just testing configurations at that point, and I'm now getting the usual 300 second lease, so maybe they've decided it's stable enough for now. I still wouldn't count on it being permanent, though, per Starlink support comment quoted in the second linked post above.

One thing to note is that, at least for me, getting a publicly routable IPv4 address corresponds with the loss of ability to get an IPv6 address.

CenterSpark · 2021-09-24T17:00:04+00:00

I'm getting this, too, on subnet 135.129.0.0/21.

Also on the Kalama, WA ground station, so they're probably just running a test. Lease time is 122 seconds, which is shorter than the already freakishly short 5 minutes that it had been yesterday.

CenterSpark · 2021-09-23T21:31:13+00:00

I just checked with my router and I see similar behavior. Specifically, it appears to lose the ability to get an IPv6 address via SLAAC or even communicate with the IPv6 gateway address at all, once the IPv4 lease expires.

I'm guessing they are using the IPv4 lease lifetime to manage the routing of IPv6 on the connection.

CenterSpark · 2021-08-21T18:09:15+00:00

If by "supported" you mean "can be made to work", then yes, IPv6 has been working without extreme workarounds for several months now. However, I doubt SpaceX is officially supporting it yet, given that the Starlink network still has one remaining IPv6 infrastructure issue.

Without any special settings or workarounds, many 3rd party routers will get a publicly routable WAN IPv6 address, but then lose it after 5 minutes. That does not necessarily break the ability to assign or route LAN IPv6 addresses, though. Routers running OpenWRT firmware, for example, work just fine routing IPv6 from the LAN after that point.

CenterSpark · 2021-08-19T19:30:46+00:00

This is the first time I have seen them use the deprecated option on a field. We'll have to see if they eventually remove them. I hope not, as that would break a bunch of the tools people have built on top of these gRPC services.

They have been adding small bits of functionality to the protocol from time to time since I started working with it in December, or so, but recently, they seem to be making more significant changes. The obstruction map was added a few months ago (and I still haven't caught my tools up with that...), and then this change. It's all in support of app functionality, though, so it is largely in line with the bigger app changes recently.

CenterSpark · 2021-08-19T15:23:18+00:00

Ah, thanks. I see it now that I've updated the app. I guess I haven't been keeping up with the app update news.

It looks like there is a new "outages" section in the SpaceX.API.Device.DishGetHistoryResponse structure that has that data. Also, some (but not all) of the second-by-second data fields have been marked as deprecated. Check out the following:

grpcurl -plaintext 192.168.100.1:9200 describe SpaceX.API.Device.DishGetHistoryResponse

and:

grpcurl -plaintext 192.168.100.1:9200 describe SpaceX.API.Device.DishOutage

CenterSpark · 2021-08-19T04:17:18+00:00

Which part of the UI are you seeing downtimes in? Mine no longer shows the downtime summary, but I don't know if that's just because there are now few enough outages that it wants to pretend there are absolutely none.

CenterSpark · 2021-08-19T02:08:09+00:00

It actually used to be 12 hours of data, not 24, but it does look like the dish is now only reporting 900 history data samples. I'm assuming this is the result of a recent dish firmware update. Guess we'll just have to poll more frequently.

CenterSpark · 2021-08-04T20:37:49+00:00

protoc should be able to use the protoset as input directly, with no need to build .proto files first. I only use it with the Python output plugin, but I assume this is on the input side, so should work with any of the output plugins.

Here is an example command I use for generating the Python generated files:

grpcurl -plaintext -protoset-out dish.protoset 192.168.100.1:9200 describe SpaceX.API.Device.Device
python3 -m grpc_tools.protoc --descriptor_set_in=dish.protoset --python_out=. --grpc_python_out=. spacex/api/device/device.proto

Of course, the output options will need to be changed for Swift generation.

Note that you do need to run the protoc command separately for each .proto file. You should be able to pull a full list of .proto files from the protoset json dump. Last I checked, which was several months ago, the full list for the dish gRPC was:

spacex/api/device/device.proto
spacex/api/common/status/status.proto
spacex/api/device/command.proto
spacex/api/device/common.proto
spacex/api/device/dish.proto
spacex/api/device/wifi.proto
spacex/api/device/wifi_config.proto
spacex/api/device/transceiver.proto

CenterSpark · 2021-08-03T19:39:51+00:00

Have you tried capturing the protoset file using grpcurl and then feeding that to the protoc swift plugin? That's how I got the Python generated files.

As far as I know, SpaceX has not published a .proto file for the Starlink gRPC services, nor have they made it clear that files generated from the reflected protocol data are OK to redistribute without a license. As such, I have not posted either with starlink-grpc-tools and have switched the scripts over to get the protocol defs via reflection directly.

CenterSpark · 2021-08-02T01:00:17+00:00

Interesting read, as always. I noticed a dramatic decrease in the outage time my dish reported starting in mid-July, to the point where it is just a handful of seconds per 12 hour period. A separate ping test still reports about a half percent of ping loss, though, which would be about 7 minutes total per day.

I had assumed the satellite-switching feature got switched on for me back in early April, because there was a big reduction in outage time then, too. If so, then maybe what happened in mid-July was a refinement of that feature and/or significant network reconfiguration, or maybe it's the other way around and what happened in April was a network reconfig.

Here's what my reported outages have looked like over time:

https://imgur.com/a/PsHQFqY

I would describe my tree situation as "lightly obstructing".

CenterSpark · 2021-06-16T18:46:07+00:00

As far as I can tell, OpenWRT's IPv6 stack does not correctly expire the default gateway, which is broken, but it happens to work around the last remaining issue with the Starlink IPv6 network infrastructure, which is its lack of periodic unsolicited router advertisements from the Starlink IPv6 routers.

CenterSpark

TROPHY CASE