Network release 1.10

We have deployed the new version 1.10 of Network in production. As there are many changes landing please let us know if you notice any issue.

Some of the changes that come with this version:

  • Refactoring of Scheduling
  • Scheduling API
  • Update javascript libraries
  • Update python libraries
  • Fix of station mark in station page
  • Add LatestTle proxy model
  • Improve performance of database queries
  • Remove sync-to-db from readonly in admin
  • Fix lint issues
3 Likes

Auto Schedule not working :
2019-10-07 16:19:04,958 - root - INFO - 3 passes selected out of 45, 1457 s out of 2094 s at 69.570% efficiency
2019-10-07 16:19:04,959 - root - INFO - GS | Sch | NORAD | Start time | End time | El | Priority | Transmitter UUID | Mode | Satellite name
2019-10-07 16:19:04,959 - root - INFO - 972 | | 40014 | 2019-10-07T14:20:01 | 2019-10-07T14:28:28 | 20 | 0.900000 | NSXo8tGxmxpTUMsmSH34FF | FSK9k6 | BUGSAT-1 (TITA)
2019-10-07 16:19:04,959 - root - INFO - 972 | | 40968 | 2019-10-07T14:32:54 | 2019-10-07T14:41:05 | 13 | 0.900000 | 9KeB2ZXuBaUMjcK6TtvUdh | FSK9k6 | BISONSAT
2019-10-07 16:19:04,959 - root - INFO - 972 | | 43590 | 2019-10-07T14:47:16 | 2019-10-07T14:54:55 | 32 | 0.234667 | gbcectqEdajt7qUsiThoAY | CW | MAYA-1
2019-10-07 16:19:05,560 - root - INFO - Authentication successful
2019-10-07 16:19:05,560 - root - INFO - Checking and scheduling passes as needed.
100%|██████████| 3/3 [00:01<00:00, 1.85it/s]
2019-10-07 16:19:07,186 - root - INFO - All passes are scheduled. Exiting!

But observation is not schedule.

Schedule via https://network.satnogs.org is ok.

Any error message? It should return detailed messages or 500 response.

With --log-level ‘DEBUG’ :

2019-10-07 16:44:21,786 - root - INFO - 2 passes selected out of 76, 1159 s out of 1448 s at 80.066% efficiency
2019-10-07 16:44:21,787 - root - INFO - GS | Sch | NORAD | Start time | End time | El | Priority | Transmitter UUID | Mode | Satellite name
2019-10-07 16:44:21,787 - root - INFO - 972 | | 28895 | 2019-10-07T14:49:26 | 2019-10-07T15:00:54 | 70 | 0.567778 | ShK6dsshtuNqssrY4xP7LA | CW | CUBESAT XI-V
2019-10-07 16:44:21,787 - root - INFO - 972 | | 40071 | 2019-10-07T15:05:42 | 2019-10-07T15:13:34 | 14 | 0.900000 | g2PQTyQ6gv4kudov7KoSQc | GFSK9k6 | DX1
2019-10-07 16:44:21,791 - urllib3.connectionpool - DEBUG - Starting new HTTPS connection (1): network.satnogs.org:443
2019-10-07 16:44:23,398 - urllib3.connectionpool - DEBUG - https://network.satnogs.org:443 “GET /accounts/login/ HTTP/1.1” 200 5138
2019-10-07 16:44:23,779 - urllib3.connectionpool - DEBUG - https://network.satnogs.org:443 “POST /accounts/login/ HTTP/1.1” 302 0
2019-10-07 16:44:24,083 - urllib3.connectionpool - DEBUG - https://network.satnogs.org:443 “GET /users/redirect/ HTTP/1.1” 302 0
2019-10-07 16:44:24,872 - urllib3.connectionpool - DEBUG - https://network.satnogs.org:443 “GET /users/swljn26/ HTTP/1.1” 200 24459
2019-10-07 16:44:24,886 - root - INFO - Authentication successful
2019-10-07 16:44:24,887 - root - INFO - Checking and scheduling passes as needed.
0%| | 0/2 [00:00<?, ?it/s]2019-10-07 16:44:24,888 - root - DEBUG - Scheduling 28895 2019-10-07T14:49:26 2019-10-07T15:00:54 70 0.568 ShK6dsshtuNqssrY4xP7LA CUBESAT XI-V
2019-10-07 16:44:25,361 - urllib3.connectionpool - DEBUG - https://network.satnogs.org:443 “GET /observations/new/ HTTP/1.1” 200 62698
2019-10-07 16:44:25,963 - urllib3.connectionpool - DEBUG - https://network.satnogs.org:443 “POST /observations/new/ HTTP/1.1” 302 0
2019-10-07 16:44:26,377 - urllib3.connectionpool - DEBUG - https://network.satnogs.org:443 “GET /observations/new/ HTTP/1.1” 200 62698
2019-10-07 16:44:26,464 - root - DEBUG - Scheduled!
50%|█████ | 1/2 [00:01<00:01, 1.58s/it]2019-10-07 16:44:26,467 - root - DEBUG - Scheduling 40071 2019-10-07T15:05:42 2019-10-07T15:13:34 14 0.900 g2PQTyQ6gv4kudov7KoSQc DX1
2019-10-07 16:44:26,884 - urllib3.connectionpool - DEBUG - https://network.satnogs.org:443 “GET /observations/new/ HTTP/1.1” 200 62698
2019-10-07 16:44:29,287 - urllib3.connectionpool - DEBUG - https://network.satnogs.org:443 “POST /observations/new/ HTTP/1.1” 302 0
2019-10-07 16:44:29,748 - urllib3.connectionpool - DEBUG - https://network.satnogs.org:443 “GET /observations/new/ HTTP/1.1” 200 62698
2019-10-07 16:44:30,093 - root - DEBUG - Scheduled!
100%|██████████| 2/2 [00:05<00:00, 2.62s/it]
2019-10-07 16:44:30,132 - root - INFO - All passes are scheduled. Exiting!

hm… it looks like that you can not authenticate with the old system. Did this work before the update for you?

I’ve two account michel with new account and an old account swljn26 for auto schedule.
Auto schedule run each 1/2 hour with cron, my last observation with auto schedule is 2019-10-07 13:28:45 UTC. Last auto schedule : 2019-10-07 13:00:00 UTC
I think form for submiting schedule has changed and auto schedule not send good form now.

hm… indeed it probably is the fields:

  • obs-TOTAL_FORMS
    This should be the number of observation to be scheduled
  • obs-INITIAL_FORMS
    This should be always 0

cc @cgbsat @pierros and @kerel that may know more on the auto-scheduler.

I’ll try to take a quick look and see if I can fix this issue in auto-scheduler.

Thanks for reporting this issue!

I’ve added this MR https://gitlab.com/librespacefoundation/satnogs/satnogs-auto-scheduler/merge_requests/43/diffs however I’m not currently able to test it.

2 Likes

Testing this now! Give me a couple of minutes.

2 Likes

Hi,
I have the same issue with an older version of the scheduler. It was working yesterday.
73,

1 Like

We’ve just updated satnogs-auto-scheduler, please update your local instances and try again. Let us know if the fix worked or not. Thanks!

Pinging known users @n5fxh @cgbsat @michel (please add any others here!)

4 Likes

It’s work for me, thanks

1 Like

It works after an update.

2 Likes

I’m a huge fan of the satnogs-auto-scheduler and can confirm its working after the update.
Thanks for the quick turn around on fixing it.

2 Likes

It works far better, thank you. However, I still have some problems, but I am not sure if it is due to the Network upgrade.

The following command:
./schedule_single_station.py --station=484 --starttime 2019-10-07T20:07:27 --duration 36 --wait 300 --min-culmination 84 --min-riseset 50 --priorities sp.csv

gives me the output:

2019-10-07 21:48:02,455 - root - INFO - GS | Sch | NORAD | Start time | End time | El | Priority | Transmitter UUID | Mode | Satellite name
2019-10-07 21:48:02,455 - root - INFO - 484 | 1 | 37214 | 2019-10-08T04:25:21 | 2019-10-08T04:28:24 | 86 | 1.000000 | f2iccrWcBsskw6uWeab5LA | |
2019-10-07 21:48:02,455 - root - INFO - 484 | 1 | 32958 | 2019-10-08T05:46:23 | 2019-10-08T05:49:23 | 85 | 1.000000 | SEtMDM3FujKpcBeVe6j38L | |
2019-10-07 21:48:02,456 - root - INFO - 484 | 1 | 39260 | 2019-10-08T20:27:21 | 2019-10-08T20:30:25 | 89 | 1.000000 | roUHxm5XRFAYLsdpzRBqx | |
2019-10-07 21:48:02,456 - root - INFO - 484 | | 38771 | 2019-10-08T20:39:21 | 2019-10-08T20:42:19 | 89 | 0.900000 | 3BkihmRk2jysTetJAFhTKn | FM | METOP-B
2019-10-07 21:48:03,658 - root - INFO - Authentication successful
2019-10-07 21:48:03,659 - root - INFO - Checking and scheduling passes as needed.
100%|##########| 4/4 [00:01<00:00, 3.15it/s]
2019-10-07 21:48:04,932 - root - INFO - All passes are scheduled. Exiting!

with only one line in sp.csv, for example:
38771 0.9 3BkihmRk2jysTetJAFhTKn 46 53 113 FM

However the last METOP-B pass does not want to be scheduled although it is claimed to be scheduled. I do not known why.

If you add this manual does it work?

I’m not sure what’s going wrong, dates and transmitter look fine.

Probably we need to add some more code for returning useful results. I’ll try to take a look during the week.

Thanks for digging!

Using the “+ New Observation” button as you suggest yields to the conclusion that the observation can not be scheduled if the station horizon is over 50 degrees included. The auto-scheduler also works if I ask for a min-riseset of 49 so my observation is now successfully scheduled.

I have also played with the min_pass_duration in the settings and it does not seem to be the problem. Anyhow, at 50 degrees, the pass still seems to be more than the default 2 minutes of minimum pass duration.

hm… that’s interesting… wondering if this is a bug, a corner case or another validation that doesn’t pass. I’ll try to take a look when I find some time. Let us know if you hit any similar case.

1 Like