SatNOGS client v0.9.1

Before we incorporate v1.0 in SatNOGS Client Ansible, we have added the last 0.9.* version of client which is v0.9.1.

Notable changes on satnogs-client:

  • Always check if ‘mode’ is defined when selecting script (fixes #347)
  • Fixes ‘TypeError: can’t compare offset-naive and offset-aware datetimes’
  • Fixes log statements in old format
  • Fixes variable ‘az’ to new name ‘azi’
  • Fixes ‘TypeError: readtle() argument 1 must be str, not unicode’
  • Perform update for existing jobs in scheduler
  • Adds support for flipping the antenna during high elevation passes
  • Fixes ‘Uncaught TypeError: Cannot read property ‘length’ of undefined’

For updating your station through ansible script (satnogs-setup) follow the instructions in “Updating SatNOGS Client software” wiki page section.

Note that before running satnogs-setup you will need to update the OS and reboot as is described in the instructions.


yay, just updated station#132.

Note that you have to follow the satnogs-client-ansible master branch (instead of stable, which is the default) to get the update to satnogs-client version 0.9.1 (SATNOGS_SETUP_ANSIBLE_BRANCH=master).

1 Like

Thanks for noting this… I’ll take a look, I probably need to update the stable branch too. I’ll let you know what’s going on asap. Until then I suggest you don’t change SATNOGS_SETUP_ANSIBLE_BRANCH variable.

1 Like

Master and stable branches are synced. So now update it should work by following the instructions in the first post, without any need for changing SATNOGS_SETUP_ANSIBLE_BRANCH variable.


So is updating to buster required? For everyone that is not on buster yet. (As it was suggested not to try and update to it before)

No, updating to buster is not required. By following the instructions in the wiki page you will stay on the same debian version that you are now, (stretch or buster) and you will have the new version of client.
The suggestion not to update on buster from stretch is still valid as we haven’t found yet a path for updating from stretch to buster safely.
Alternatively someone could re-flash the sd-card with the latest image, this is for now the best way to move to buster version. @Acinonyx let me know if I got something wrong with this.

1 Like

How come that every time satnogs-client is updated it wipes the configuration in /etc/default/satnogs-client? The updater just leaves an empty file there.
Luckily I have been there before so it was easily remedied, but a newcomer might tear her hair out over it.

1 Like

How are you making the update?

Here is an excerpt from .bash_history showing the commands I executed (as root):

apt update
apt upgrade
apt dist-upgrade
apt autoremove
journalctl -f
systemctl status satnogs-client
journalctl -b -u satnogs-client
vi satnogs-client 
locate satnogs | grep etc
locate satnogs | grep etc | grep -v root
v /etc/default/satnogs-client 
vi /etc/default/satnogs-client

It is unedited so it shows all my typos too :grinning:
It is not exactly the same as is written in the wiki, but hopefully is close enough. The apt dist-upgrade didn’t upgrade anything.

I hope this answers you question
73, Bent

Your not using the update stuff that exists in satnogs-setup?

As you can see from my post above I do run ‘satnogs-setup’. I downloaded the updates and applied the updates.
If that’s not what you mean by ‘update stuff that exists in satnogs-setup’ I might have misunderstood you question :confused: so perhaps you could clarify.

I saw all the extra stuff at the bottom and didn’t realize you actually updated with ansible. I though you were somehow manually updating stuff. Also I haven’t experienced my config ever resetting on either my Pi 3 system or my x86-64 system.

It has happened every time I update stanogs-client.

I just got a thought: Perhaps it is because I do not use the configuration options present in satnogs-setup but rather just copy a saved copy of the configuration from /root to /etc/default/ . Could that upset the next update?

Yes that could be the case. Another case would be to hit reset option in satnogs-setup, that resets the configuration.

It’s probably not possible any more to reconstruct the steps I took when I updated. Next time I update - which appears to be not too far away, conf. the announcement of version 1.0 - I’ll be very careful with the steps I take and report back here.

1 Like

Wich distro should I use to try this client with and old computer?

@ea5wa if you intend to use ansible script from then Debian Stretch or Buster are suggested.

1 Like

Is somehow possible with 32 bits old computer?

Hi there,
I’m new to this, and have the v0.9.1 client installed. This version doesn’t seem to heed my “False” setting for enabling rotctld, giving “Cannot connect to socket” errors. When I tried to use satnogs-client to update to version 1.0, however, I ran into problems with pip not being happy with python 2.7. My RPi with Stretch currently has both python 2.7.13 and 3.5.3 installed. Is it reasonable for me to assume that eventually v1.0 of the client will automatically and gracefully handle this and then become the default when I use satnogs-client? Also, is there an easy way to learn of updates, i.e., when they are stable and ready for general use?
Thanks for any comments,

Hi @va2wbt

About the error you get check the troubleshooting page in the wiki. You can ignore this error as you are in a non-rotator setup.

Did you follow the instructions on this thread to update to v1.0? What errors did you get for python 2.7? Was it the one about python 2.7 being deprecated at the end of the year? If this was the case don’t worry as soon all of our software will move to use python 3.
Still we need to make changes for v1.0 being the default version, there will be an announcement about it.

Currently we announce new versions here in the forum, however as v1.0 will be a major release we may send an email to all station owners for letting them know about this new release.

1 Like