Network will have a downtime during the deployment of the new version.
I’ll update this topic when, it is back online.
We are sorry for any inconvenience.
Network will have a downtime during the deployment of the new version.
I’ll update this topic when, it is back online.
We are sorry for any inconvenience.
Update:
Due to slow migration of the database, the downtime will continue a little longer.
Thanks for letting us know. I thought my PC was on the fritz.
We are closer… 1 of the 2 migrations is completed… and it was the big one.
And we are back and running again!
Thanks for your patience.
Please if you face any issue, let us know!
With the new network changes and the required changes to the satnogs-auto-scheduler
, the auto-scheduler will schedule CW at 437.125MHz for every pass, regardless if it is a UHF or VHF station.
I’m investigating; use of the auto-scheduler should be minimized until further notice!
I think the update introduced some problems regarding scheduling and UHF. I opened an issue because I couldn’t schedule any passes on my VHF stations: https://gitlab.com/librespacefoundation/satnogs/satnogs-network/issues/642
When I manually schedule an UHF observation it also results in CW at 437.125MHz regardless of the selected transmitter. The new observation page of a VHF station seems to show only UHF stations.
You are correct.
It appears the passes are properly scheduled but the transmitter defaults to 437.125MHz CW from LUSAT 20442 which is the first transmitter in the transmitter list. It seems the link between satellite and transmitter is buggy.
This also means that at present it is not possible to schedule any sensible observations.
Hi,
I’ve got some problem since this morning and don’t know if it’s linked to the update.
But yesterday everything working great on my test setup station, and this morning when I wanna schedule a new observation, the new observation page say : No station available.
We have spotted the issue… is on the db site. It has to do with the recent commit of filtering transmitter by uuid. It is fixed and it’s going to be deployed in the next minutes.
I have removed all the observations (349) in network that were affected by this issue. I’ll let you know here when db changes are deployed so you can starting scheduling again. Until then please avoid to schedule new observations.
Looks like this is already being looked into, but as one more data point - VHF observations are showing up on my UHF only station, and I can’t seem to schedule VHF observations on my VHF station at all. Strange.
–Roy
K3RLD
Checking this issue, I’ll come back with an update.
hm… it looks like that this is the issue @f4fwh faces… I think this is part of the other issue, but I’m taking a deeper look to make sure. Thanks!
Yes I confirm that the VHF only station issue is part of the other issue I described in Network downtime 2019-05-08.
So it will also be solved after the db changes are deployed.
A quick update, deployment in db is still in progress…
DB is deployed! The issues should be now solved. All the observations that were using the false transmitter are now removed from network.
Please let us know if you face any other issues!
As i can see, for now it’s working.
Thanks for the good work
Works for me! Thank you!