Joe, I really like your suggestion for the API response format. As it is a breaking change, it would be most convenient to implement it as /v2/ of the API, so everybody can migrate to it in a timely manner. Let me know when you have something to test, and I will start working on a new version of my app to use it.
The QO-100 cannot be treated as a LEO satellite because it does not fit the computing model. The AOS happened just once, when it came operational and LOS will not happen until it is turned off to die! For us over here in the Americas AOS will never happen :-( But it's Azimuth and Elevation can of course be computed, but it is just a function of the location of the observer.
/Heimir W1ANT
On Thu, Jan 16, 2020 at 6:36 AM Joseph B. Fitzgerald < jfitzgerald@alum.wpi.edu> wrote:
Awesome work Joe! Glad UMass has such a lousy orientation :-)
Thanks, Heimir. K1JT did some work there a few years back that got a bit of notice, so I'm glad to get noticed also.
I am considering adjusting the response to the APIs in case something goes wrong:
{
"payload": [], "errors": [{ "code": 1, "description": "Resource is bad" }, ]} Additionally, HTTP Status Codes in the 400-599 range are sent as a secondary indication of a problem.
Speaking of things going wrong, QO-100 has no "passes" as such. Except at the very edge of the footprint it never rises and sets. I'd love to hear ideas on how to handle this case.
de KM1P Joe