New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UVSQ-SAT Error while submitting telemetry: HTTP Error 500 via SIDS #228
Comments
I've just verified that the telemetry submitter is created using the correct URL in case this was some silly error when parsing the SatYAML to get the URL. Other than this, I don't really have a clue, since the code is the same that is working well with SatNOGS DB (and also your own test server, I guess). Would this work over HTTP instead of HTTPS? If so, that would make it much easier to see what is the difference between Mike's request and gr-satellites'. If you feel like debugging further, you could even take a look at the code in submit.py. It's quite simple, and you can easily change some of the request parameters, such as the version, to match Mike's, or print the parameters ( |
Thanks for the update, I will have a look. In meantime I will also reach out to the UVSQ-Sat team, maybe they can also help. |
I'm taking a look at this right now. I have changed the URL to HTTP in the
Note the Python I wonder how this is working with SatNOGS or other servers. |
The full HTTP request is as follows:
So I guess that the UVSQ-SAT server is choking at the malformed URL, while the other servers ignore it and look it directly at the POST content. |
Great find and an example of thinking out of the box, I need to to remember this one. |
I have pushed 081e7d2, which fixes the problem with
However I'm still getting errors:
I can't really debug this using HTTP instead of HTTPS because the server returns a 301 Moved Permanently redirect to the HTTPS URL. |
I noted two differences in the request from DK3WN that you pasted here. The |
I will test this with a recording to see if that makes any difference, my system is building as we speak. |
Nope, just tested it and the same result.
|
Tweaking a bit the code I'm now able to print the body of the HTTP responses sent by the server: For a 400 Bad Request, I get
For a 500 I get
I'm inclined to think that the UVSQ-Sat server is broken. After fixing the problem with the |
I had a better look at the cap files that I created and found the following difference: When using the UVSQsatDecoder the time field is different:
This structure isn't recognised as a valid field value and therefor the test SIDS database is rejecting it. Comparing this to GetKISS+ I have the following:
It could be possible that the UVSQ-SAT sids database is using a different timestamp field check and therefor rejects the frames. I guess we need some help from the UVSQ-SAT team. |
I tried to reproduce this error with other SIDS database servers but I am unable to. I am out of options. |
I'm also out of options, other than rewriting the gr-satellites submit block using This is something to consider for further developments of the SIDS protocol. Maybe a reference implementation would help prevent these sorts of problems? I'll keep the issue open in case someone from the UVSQ-Sat team wants to weigh in. |
Good evening,
From the beginning of the UVSQ-SAT launch and activation I have tried to forward gr_satellite decoded frames to there own SIDS database, but without any luck. This evening I tried again and with the same outcome.
Every time I use gr_satellites with the
submit_tlm=yes
in${HOME}/.gr_satellites/config.ini
including the callsign, latitude and longitude I received anerror while submitting telemetry: HTTP Error 500
To make sure it isn't a database issue on the UVSQ-SAT server side, I have configured the SIDS forwarder made by DK3WN to forward the data to
https://amsat.electrolab.fr/api/V2/SIDS
and this is working as expected, no error 500.So for some reason the SIDS config in the satyaml file or the underlying code is causing an error 500.
Below, more information regarding the commands, files and output that I used or is generated.
gr_satellites UVSQ-SAT --wavfile UVSQ-Sat_9k6_satnogs_3585560_2021-02-03T09-49-28.wav --samp_rate 48e3 --f_offset 12e3 --hexdump
Below a string that is send by the DK3WN forwarder and that is excepted by the UVSQ-SAT database (I removed some private information)
Based on the earlier WSL issues I have also tested this on a Laptop running gr_satellites and there is a small difference, this is also generating
Error while submitting telemetry: HTTP Error 400: Bad Request
As far as I know, I have used all the options I could think of to debug this issue, if there are any others please let me know. I even created a cap file but forgot the transport is ssl encrypted 👎
The text was updated successfully, but these errors were encountered: