search

sparky8512 / starlink-grpc-tools

Random scripts and other bits for interacting with the SpaceX Starlink user terminal hardware
The Unlicense
482 stars 64 forks source link

starlink_grpc documentation doesn't appear to match get_status response #56

Closed boswelja closed 2 years ago

boswelja commented 2 years ago

Below is a sample of the get_status result from my Starlink

device_info {
  id: "0000000000-00000000-00000000"
  hardware_version: "rev3_proto2"
  software_version: "2a2e1faf-c874-430c-b4a7-b7ce5990af05.uterm.release"
  country_code: "NZ"
  utc_offset_s: 39601
  bootcount: 58
}
device_state {
  uptime_s: 638533
}
obstruction_stats {
  wedge_fraction_obstructed: 0.0
  wedge_fraction_obstructed: 0.0
  wedge_fraction_obstructed: 0.0
  wedge_fraction_obstructed: 0.0
  wedge_fraction_obstructed: 0.0
  wedge_fraction_obstructed: 0.0
  wedge_fraction_obstructed: 0.0
  wedge_fraction_obstructed: 0.0
  wedge_fraction_obstructed: 0.0
  wedge_fraction_obstructed: 0.0
  wedge_fraction_obstructed: 0.0
  wedge_fraction_obstructed: 0.0
  wedge_abs_fraction_obstructed: 0.0
  wedge_abs_fraction_obstructed: 0.0
  wedge_abs_fraction_obstructed: 0.0
  wedge_abs_fraction_obstructed: 0.0
  wedge_abs_fraction_obstructed: 0.0
  wedge_abs_fraction_obstructed: 0.0
  wedge_abs_fraction_obstructed: 0.0
  wedge_abs_fraction_obstructed: 0.0
  wedge_abs_fraction_obstructed: 0.0
  wedge_abs_fraction_obstructed: 0.0
  wedge_abs_fraction_obstructed: 0.0
  wedge_abs_fraction_obstructed: 0.0
  valid_s: 638222.0
  avg_prolonged_obstruction_interval_s: nan
}
alerts {
}
downlink_throughput_bps: 25744.638671875
uplink_throughput_bps: 143302.59375
pop_ping_latency_ms: 26.399999618530273
boresight_azimuth_deg: 170.00000000000000
boresight_elevation_deg: 60.00000000000000
gps_stats {
  gps_valid: true
  gps_sats: 15
}
eth_speed_mbps: 1000
is_snr_above_noise_floor: true
ready_states {
  cady: true
  scp: true
  l1l2: true
  xphy: true
  aap: true
  rf: true
}

This does not appear to match what is documented in starlink_grpc file. (I have redacted some information, not sure if it can be used to track me lol)

I'm wondering if square dishy sends entirely different data compared to round dishy, or if a recent software update changed a lot of things

sparky8512 commented 2 years ago

The documentation strings in starlink_grpc.py don't directly document the raw grpc structure, they document the cooked values returned by the status_data function (and similar). That being said, for status data, it's mostly just passing along what is in the raw data and just formatting it a little differently.

I don't believe there is much, if any, difference between the square and round (which I have) residential service dishes with respect to data returned via grpc, but there have been some changes over the past year, or so, that I have not incorporated. As far as I know, only 2 items (snr and seconds_obstructed) have been removed from status, and those are marked obsolete in the docs. The other items that don't show up in the get_status output are probably just reporting default values. grpc allows for default values for a type (usually something like 0 or false) to be omitted from the wire protocol and grpcurl won't show them in its output. For example, fractionObstructed doesn't show up in your get_status output because you have no obstructions reported, as evident from the wedge data.

If someone requests addition of some of the newer items (gps_stats and later in the above, as well as a few others that don't show up), I will add them, but I don't even know what some of them mean. The ones where the meaning is obvious don't seem all that useful to me to track over time, but then again, I don't track status myself, so that's not saying much.

boswelja commented 2 years ago

Ah I see, seems like I was also calling get_status rather than status_data which explains a lot of my problems 😆 Thanks for your help! I'll close this for now