Previously named the drift scan mode, used on the amazing Dwingeloo telescope which is active as station 384 - PI9CAM, now has been ported to the latest version of the auto-scheduler.
This is intended for fixed directional antennas to optimize for observations passing inside the main lobe.
It could also be externally scripted to fetch the current pointing direction from rotctld or some web interface as well.
The following argument was added:
-i [POINTING ...], --pointing [POINTING ...]
Constrain passes to antenna beam radius (half beamwidth) and pointing direction.
Examples: antenna pointing straight up, 30 degree radius: '-i 30',
pointing south at horizon: '-i 30 180',
pointing west and 45 degrees up: '-i 30 270 45'.
[degrees; default: None]
By default the constraint tries to reduce the pass length to the specified area of interest, if that is too small it will increase it to be MIN_PASS_DURATION which is 3min by default.
Huge thanks to @tammojan for publishing this work in the first place.
Amazing, indeed thanks for all the great work in making this possible.
Now with a DK7ZB Yagi pointing 315 azimuth, 70 elevation and a 30 degree opening angle the auto scheduler only schedules passes that will move trough the lobe.
That sounds very useful indeed for fixed antennas. Could the idea be extended to rotating antennae that donāt have a 360Ā° view? My own site, for example, is close to my house and has no sky view from north-east to north-west (couldnāt persuade my neighbours to build it in their garden . It would be ideal if I could prevent any remote scheduling for this stretch of sky, and also prevent the rotator from going there.
Regarding using this to prevent scheduling would not be possible, as when you do this on network you can select to specify horizon manually etc, so no way to prevent this.
If you run the auto scheduler and calculate a good pointing constraint, you will still get passes that goes outside this because the only validation is that it passes inside the constraint at some part of the pass.
If you want to prevent the rotator to move to certain positions, I think that must be managed in rotctld, if even possible. like, you could probably configure it to not have full 360 span, but how to offset this and whatnot I am not sure how to manage.
You can perhaps have better control if you use the K3NG controller and code these restrictions in there somehow.
Just decided to install this amended version of Satnogs-auto-scheduler, but Iāve come across a query which is preventing me from completing the installation. In the gitlab README it mentions two APIās - the network API token and the DB (database) API token. The first Iām familiar with, but where do I find the latter? The note states (understandably) that they are both required now. Intimating that in the earlier version you did not. So, unless Iām having an āoffā day, where do I find the DB API token, please?
In the settings it needs the token to download TLEās iirc, might be more.
and that you can get after logging in to the DB and clicking on the top right icon and selecting āAPI Tokenā, paste this into SATNOGS_DB_API_TOKEN variable.
Having now been using the ānewā Satnogs-Auto-Scheduler over the past few days, I do detect an improvement with my fixed antenna (turnstile) station on 70cms. However, looking at the recent contributions on the SatNOGS database my received number of frames is way down on most observersā results; making me wonder whether my station has any useful purpose to LSF.
Furthermore, with using the improved auto-scheduler, there are many scheduled observations but only a few (~10%) showing an āautomaticā rating of having a signal in the waterfall along with some data of varying numbers of frames. Therefore, are observers expected to assess each of the numerous āblankā observations that have no data results icon in the results column (~90%)? To do so is very time consuming. Admittedly, taking a sample of those observations produces a very small number that have been missed by the auto rating as having a signal in the waterfall but not showing any data. Would those be of any use to LSF? I think not.
So what do I do with the 2,000+ observations that still need rating? Is there a way of deleting those rather than going through them individually? And also being reminded of them each time you view the dashboard!
Which leads me on to think whether auto-scheduler is vanity software, producing quantity rather than quality observations? Or should it be modified in such a way as to track certain specified satellites and/or particular modes, and possibly other parameters of particular interest?
In its present guise I see it more of a dilemma than an enjoyment.
Never-the-less, I contribute where I can with considerable interest, and dream of the day when I may afford to have an AzEl rotator and dish. Even then I donāt think SatNOGS-auto-scheduler would be so much on my shopping list.
Hi Roger,
I use the auto-scheduler to fill up the unused time between other observations, I also use a priority file to pick some satellites that has a decent chance of getting data.
With this said, having random observations running is sometimes very valuable when going back and looking at certain objects and going through the waterfalls. Some sats come back to life, some are changing their behavior, some are assigned wrong, the list can be made long.
Regarding vetting, this is a personal choice IMHO. I donāt demand that everyone vet everything on their own station, I do expect observations scheduled on others stations to be vetted by the scheduler. Automatic vetting is based on data (not CW) on the obs, this can be false positives as well. Nothing is perfect.
Deleting the observations is pretty much out of the question, as stated above, even empty waterfalls can help in identifying things.
Perhaps having 0 unvetted obs is the vanity thing here (: I did vet everything earlier (tens of thousands) but it just took too much time, now my unvetted counter is finally over 100k (of some ~200k total) and itās not getting smaller any time soon.
Have a look at the -p and -P options if you want to pursuit the 100% (auto)vetted, this can be accomplished by looking at the previous obs with data (excluding cw) and picking out the transmitters that reliably produces.
You do need to get the transmitter UUID from DB, search for the NORAD and go to transmitters and pick the appropriate one, select Copy UUID from the small dropdown.
Example line: 55098 0.5 DHeesYoebTduoSzp2P48Wr
You can also check the Recent Contributors on DB to see what transmitters are successful (perhaps too high baud).
I am planning to code some automatic prio file generation on this scheme.
Many thanks Daniel. Always a pleasure to read your comments.
Incidentally, which parameters are used to filter ground station capabilities?
And -p is showing as an unrecognised argument.
the -m and -r overrides the behavior of min horizon of the ground station default (online), theyāre not exactly the same and I recommend playing around with these to get a grasp of how they are working. some time in the future we should probably make a guide with examples how all these interactā¦
-s STATION, --station STATION
Ground station ID
-t STARTTIME, --starttime STARTTIME
Start time (YYYY-MM-DDTHH:MM:SS) [default: now + 10 minutes]
-d DURATION, --duration DURATION
Duration to schedule [hours; default: 1.0]
-o MAX_OBSERVATION_DURATION, --max-observation-duration MAX_OBSERVATION_DURATION
Max time for a single observation [minutes; default: 30]
-m MIN_CULMINATION, --min-culmination MIN_CULMINATION
Minimum culmination elevation [degrees; ground station default, minimum: 0, maximum: 90]
-r MIN_RISESET, --min-riseset MIN_RISESET
Minimum rise/set elevation [degrees; ground station default, minimum: 0, maximum: 90]
-z, --horizon Force rise/set elevation to 0 degrees (overrided -r).
-b START_AZIMUTH, --start-azimuth START_AZIMUTH
Start of the azimuth window to observe within. Window goes from startto stop azimuth in a clockwise direction. [degrees; default: 0, maximum: 360]
-e STOP_AZIMUTH, --stop-azimuth STOP_AZIMUTH
End of the azimuth window to observe within. Window goes from start to stop azimuth in a clockwise direction. [degrees; default: 360, maximum: 360]
-i [POINTING ...], --pointing [POINTING ...]
Constrain passes to antenna beam radius (half beamwidth) and pointing direction. Examples: antenna pointing straight up, 30 degree radius: '-i 30', pointing south at horizon: '-i 30 180', pointing west and 45 degrees up:
'-i 30 270 45'. [degrees; default: None]
-f, --only-priority Schedule only priority satellites (from -P file)
-w WAIT, --wait WAIT Wait time between consecutive observations (for setup and slewing) [seconds; default: 0, maximum: 3600]
-n, --dryrun Dry run (do not schedule passes)
-P PRIORITIES_FILE, --priorities PRIORITIES_FILE
File with transmitter priorities. Should have columns of the form |NORAD priority UUID| like |43017 0.9 KgazZMKEa74VnquqXLwAvD|. Priority is fractional, one transmitter per line, 1.0 gets maximum priority.
-M MIN_PRIORITY, --min-priority MIN_PRIORITY
Minimum priority. Only schedule passes with a priority higherthan this limit [default: 0.0, maximum: 1.0]
-T, --allow-testing Allow scheduling on stations which are in testing mode [default: False]
--flush-cache Clean the cache and download current transmitters, satellites and TLE.
-l [LOG_LEVEL], --log-level [LOG_LEVEL]
Set the logging output level. ['CRITICAL', 'ERROR', 'WARNING', 'INFO', 'DEBUG']
--version show program's version number and exit```
. It would be ideal if I could prevent any remote scheduling for this stretch of sky, and also prevent the rotator from going there.