Add support for pulling dish_get_obstruction_map data about starlink-grpc-tools HOT 16 CLOSED

I was just going to write an issue for this! FWIW the new capability seems to be in Dishy itself, not the router. I think firmware db6b5d22-a642-43d6-bbec-97a816e3dbd6.uterm.release enabled it; the feature wasn't working for me until I upgraded from the older 1752790c firmware.

I poked around with grpcurl and found what I think is a new dish_get_obstruction_map call with associated Request / Response objects. I've attached a dish.protoset file I generated against firmware db6b5d22
dish.zip

from starlink-grpc-tools.

OK, I have a prototype of this up and running. Pulling the data is easy enough and write out a PNG image file from that data is pretty simple to do. Here's a sample:

(I haven't added color-coding yet, and yes, it's much lower resolution than the Starlink app's display of it would imply)

@NelsonMinar (or anyone else): Any opinion on whether image file output is sufficient vs some form of database output? I've mostly been using CSV output for my own usage, mostly because it's easy to import into a spreadsheet and get a sense for the behavior over time just from the raw numbers, but that doesn't work so well for this type of data. The plan is to support either one-shot output or periodic loop output, same as the other scripts.

from starlink-grpc-tools.

Nice work! I think a PNG is certainly good output for a lot of use cases and matches what the existing app is doing, just displaying the image. I mostly use starlink-grpc-tools for monitoring too, with InfluxDB and Grafana. The PNG won't help much there but that's OK.

The only other thing I could think to emit is some summary number like "average value of pixels" as a different calculation of percent obstructed. Given Starlink already has that in a couple of forms I don't see any need for it. It could be calculated from the PNG, anyway.

One other interesting fact latent in this image; it tells you what angle Dishy is pointed at. Or I presume it does, the center of the white area, although maybe the projection messes things up a bit. Again that could be calculated from the PNG or raw array data.

It looks like your image is able to distinguish no-data regions (black? transparent?) from 100% unobstructed areas (white). That's important, glad that's working.

from starlink-grpc-tools.

The only other thing I could think to emit is some summary number like "average value of pixels" as a different calculation of percent obstructed. Given Starlink already has that in a couple of forms I don't see any need for it. It could be calculated from the PNG, anyway.

I may have a look at this as some point, but I suspect the values already provided in the other data are going to be more useful, given that the dish may be weighting the data points by time spent in each direction.

One other interesting fact latent in this image; it tells you what angle Dishy is pointed at. Or I presume it does, the center of the white area, although maybe the projection messes things up a bit. Again that could be calculated from the PNG or raw array data.

Ooooh... I like that. I'll have a look at it once I'm done with the image output script. While you're right that the projection probably messes with the true direction, it could still be interesting to track this over time, and that's the kind of data that would integrate more easily with recording to a database.

It looks like your image is able to distinguish no-data regions (black? transparent?) from 100% unobstructed areas (white). That's important, glad that's working.

Yes, the raw data the dish returns is an array of floats labelled "snr", where the value of -1.0 appears to correspond with "no data", and 0.0 through 1.0 correspond with the per-direction SNR data points. The image above just made the "no data" black and the other points shades of grey for simplicity. I'll probably make it transparent in the final script, with an option to disable that.

from starlink-grpc-tools.

Thanks for all informations. I don't have starlink terminal but I will be interrested to know if SNR (in dB) is timestamped with the associated satellite number. Coverage seems not to be available for the moment in south of France. So if the starlink terminal offers this opportunity, it will be great if you can display examples in text format. Thanks Laurent

from starlink-grpc-tools.

I will be interrested to know if SNR (in dB) is timestamped with the associated satellite number.

Not that I could find. In general, the Starlink gRPC APIs only expose what is necessary for the Starlink mobile app. They did have one structure with more detailed technical info, but I think they enabled that in error, then later disabled it (or made it require authorization, I forget).

from starlink-grpc-tools.

Uhg. Just realized it's been a month and I have not managed to spend any time on this. It's really not that hard, I just need to find the time.

from starlink-grpc-tools.

Take your time. It's not urgent. It's just to see the associated data and the frequency of the data acquisition in the dish. Thanks. Laurent

from starlink-grpc-tools.

from starlink-grpc-tools.

It's just to know if it's possible and if data is timestamped with indication of the signal angle (azimuth and elevation) or satellite location.

Not that I could find. There is an indication of what direction the entire dish is pointed, but that rarely changes. I was going to add support for logging that, anyway, but I have not found time to work on this project for even simple things like that recently.

Are you located in north of America ? If yes, Is there a frequent update of snr signal?

Yes. I live in the Southwest of Washington state, USA, which was included in the initial public beta rollout.

The reported SNR on my dish jumps around a lot from second to second, but doesn't cut out entirely very often, not like it did early on in the beta. If you meant the obstruction map (SNR map) data, I have not seen that change much, but I haven't been monitoring it closely. I figured that would be easier once I wrote the tool support for pulling it periodically.

from starlink-grpc-tools.

(FWIW there's been reports on Reddit that their Dishes are pointing in slightly new directions. Maybe a recent one-time change? That might be part of why folks are interested in that data.)

from starlink-grpc-tools.

I got a burst of motivation somehow and managed to get a few changes in, including the initial support for this functionality. It still needs more thorough testing and the documentation needs to be updated, but as far as I can tell, it appears to work fine. Anyway, I stuck it into a branch (cleverly named "obstruction-map") for now.

It does add one more Python package dependency, on pypng. This has been added to requirements.txt but not yet added to the README file for manual installs.

Also, I have not yet added support for running in a loop inside the script, so running it in a loop would currently require a wrapper script.

Here's an updated sample of the output, using the default colors:

This may not display well in GitHub due to the default "no data" area color now being transparent and the default "unobstructed" color being white, same as the GitHub issue background color, so here it is in negative:

from starlink-grpc-tools.

Nice, thanks!

from starlink-grpc-tools.

Dear All. Thanks a lot for all information.
it would be interesting to run the script during rain event.
SNR will change and then the dish will be similar to a precipitation radar..
if you give me satlink frequency (sat to terminal user), I will give you conversion rule to estimate the precipitation intensity.
Laurent

from starlink-grpc-tools.

I don't think the SNR map data changes quickly enough for that. I have not verified this, but I expect the data in the map is averaged over a long period of time (hours or days). You could maybe start to see small changes in the SNR data as new data gets averaged in and try to compute from that, but without knowing how old data is aged out, you wouldn't know whether the changes were due to new data or old data.

from starlink-grpc-tools.

Perhaps!! If it's easy, mask partially the dish with a metal plate and then you will see the map changing, and the upgrading frequency.

from starlink-grpc-tools.