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

Help with history #51

Closed bmillham closed 2 years ago

bmillham commented 2 years ago

Hi all, I just started writing a nice python script to mimic the Starlink web page. So far I've got everything I want working.

But now I want to look at outage history. So in my script I do this:

h = starlink_grpc.get_history() And then look at outages: lastout=h.outages[-1] And I get this cause: NO_DOWNLINK start_timestamp_ns: 1341872909960043179 duration_ns: 15259975072 did_switch: true The timestamp when converted is off by 10 years! n=datetime.datetime.fromtimestamp(1341877680020042191/1000000000) and the value of n is datetime.datetime(2012, 7, 9, 19, 48, 0, 20042) It's only off by 10 years.... Am I missing something here?

bmillham commented 2 years ago

Is there a forum for help with this module then? But I don't get your answer. The returned value is nanoseconds from the epoc (I assume). I convert nanoseconds to seconds. What should I be using as my conversion?

bmillham commented 2 years ago

I hate to say, but your script didn't work. I know why it didn't (and since you tell me that you are an expert I assume you can figure it out). But... Further research and I think this is a bug (or something strange that the Starlink dish is sending). 1341877680020042191 nanoseconds from the epoc is 10 years ago. Period. If I'm totally wrong please show me why. And if you respond, use the built in datetime module to show how I'm wrong, or how to do it correctly.

sparky8512 commented 2 years ago

It's only off by 10 years.... Am I missing something here?

I believe the timestamp data in the history outages sequence is GPS time, so you need to use GPS time epoch, not a Unix epoch UTC time (which is what the datetime module expects). To convert, you would need to offset by the difference between the epochs, which varies by how many leap seconds have been added since the start of GPS time.

This is one of the reasons I have yet to re-add the obstructed and unscheduled detail in the history stats, since they changed the way it got reported about a year ago.

BTW: I'm fine with using the issues section of this project for questions like this. There's not really a good Starlink-specific forum for such that I am aware of. There are a few subreddits, but r/starlink has moved on from anything remotely technical and r/StarlinkEngineering seems to be mostly interested in how the satellites work.

bmillham commented 2 years ago

Thank you! GPS did come out about 10 or so years after the Unix epoc. That never occurred to me. And with that hint: GPS time started in sync with UTC: 1980-01-06 (UTC) == 1980-01-06 (GPS) so that totally explains the 10 year difference. (actually I do think I noticed it was 10Y4D but hadn't gotten that far yet)

BTW, a big thanks to you for creating this great module!

bmillham commented 2 years ago

@sparky8512 I found this module: leapseconds that does the GPS/Epoc conversion taking leap seconds into consideration.

https://gist.github.com/zed/92df922103ac9deb1a05

Seems to work for me. leapseconds.gps_to_utc(datetime.datetime(1980,1,6) + datetime.timedelta(seconds=1341954650940005257/1000000000)) datetime.datetime(2022, 7, 15, 21, 10, 32, 940005)

If you are interested, my code is here: https://github.com/bmillham/starlink-graph

technso commented 2 years ago

I've been looking for exactly this and had no luck (you're right about the r/starlink it is a lot less technically orientated now). I'll be playing with this shortly. Thank you!!!

sparky8512 commented 2 years ago

If there are no further questions about the history data, let's close this issue out.