This page contains proposal of conventions for stations' settings and operations within Bolidozor network.
In the context of Bolidozor network an observatory represents a locality where there is a potential to realise more observations. Typical examples include private or public observatories.
From the perspective of structure at data storage, an observatory is a place that stores data from individual stations. At the present time, the data server login id is the same as the name of the observatory.
It is possible that in the future one observatory will have more user accounts.
In the context of the Bolidozor network a station is a defined measuring device. Different stations, each measuring different quantities, can therefore exist at one observation spot / Observatory.
Radio detection stations have a following name convention: Station-Observatory-RX, where the observatory corresponds to the name of observatory where the station is located. The suffix RX is an ordinal number of the station in the observatory. For example OBSUPICE-R4 means the 4th station for meteor detection at OBSUPICE observation spot.
The ordinal number increases at every change of the station configuration that may influence the recorded data - e.g. moving the antenna, changing cables, changing the configuration of detection software, changing the format of output data etc.
A special case is a station with R0 revision - it is reserved for test purposes and the data from R0 stations are not considered valid.
There are cases when there is possible to distinguish stations according to the type of measurement using a suffix in their names. However, as there are so far no other types of radio stations apart from RMDS in Bolidozor networ, such differentiation has not been implemented yet.
Example of name of data files: TIME_NAME_TYPE.EXTE
The length of the file name is limited to 50 characters.
In order to contribute to the database it is required that the file name has a form of the following regular expression:
({0-9}{4})([0-9]{2})([0-9]{2})([0-9]{2})([0-9]{2})([0-9]{2})([0-9]{3})([A-Z]{1})?_[A-Z0-9]{1,20}(_([A-Z0-9]{1,4}))?(\.[0-9a-zA-Z]{1,4})?
Examples of files:
20140815131105154_OBSUPICE-R1_snap.fits 20140815150803480_OBSUPICE-R1_raws.fits 20140815150948269_OBSUPICE-R1_met.fits 20131215115954558_SVAKOV-R2_fb.jpg 20131215115955002_SVAKOV-R2_nomet.jpg 20140808100000_OBSUPICE-R1_meta.csv
Directory structure of a correctly configured Bolidozor station looks as follows.
User_Name ├── bolidozor │ ├── radio-observer.log │ └── station │ ├── Bolidozor.json │ ├── bus_config.py │ ├── rmob.cfg │ ├── data │ ├── meteors │ └── snapshots ├── repos │ ├── pymlab │ ├── pysdr │ ├── python-mlab-utils │ ├── radio-observer │ ├── data-uploader │ ├── sdr-widget │ ├── signal-piping-tools │ └── station-supervisor ├── resize_fs.sh └── setup_reverse_tunnel.sh
All measured data, including metadata, are stored in bolidozor directory. This directory has a subdirectory called 'station' that contains recorded data in a hierarchical directory structure. The uppermost directory contains shared metadata files for nested data.
Bolidozor directory thus partially copies the data structure of the station at space.astro.cz server.
It is necessary to label the position of station by some unambiguous identification mark. There are several options: