This is software to enable a user to monitor frequency activity. The use case is where a broadcaster wants to check if a given broadcast is being received on a certain location, so that actions can be taken if the broadcast is not being received, all of this using readily available components (General purpose computers, operating systems, inexpensive radio receivers) and then use common IT monitoring software packages (such as Nagios or others) to handle the management and display of information.
This was done from a 'IT Infrastructure Admin' perspective and not from a Radio frequency engineer perspective.
Diatomite makes heavy use of GNU radio!!! https://www.gnuradio.org/
The software monitors one or more frequencies, using one or more SDR radio receivers, and reports signal statuses through a RESTfull api. The signals status is determined against a pre-determind level for each frequency set in the configuration file. There is no auto sensing.
Currently only RealTek 2832U SDR dongles are supported, but this should be easy to extend.
Also provided is a tool (tools/tap_graph.py) to monitor radio frequency analyser outputs of Diatomite on a character console. This was deliberately made as a text console utility to enable the use on remote equipment via ssh.
The software should be considered early ALPHA, and is working end-to-end, reading configurations, monitoring frequencies and reporting on the RESTfull API server. The software is being developed on a Fedora release 25 Linux on a x86_64 architecture and has not been tested in any other environment.
Signal detection is done the following way:
- a frequency is monitored
- a fast Fourrier transform is taken every 10th of a second.
- 10% of the central portion of the fast Fourrier transform is taken and averaged.
- The last average is added to a list of averages with the last 10 measurements.
- An average of these last 10 measurements is taken and check against a pre-configured level threshold. If it is above the threshold, the signal is deemed 'Present', otherwise it is deemed 'Absent'
CAVEAT EMPTOR. Use at own risk.
Major known issues.
- API server relies on Bottles' internal web server, which is not meant for production, and may not allow more than one concurrent connection.
- Message passing serialization is a bit awkward.
- Listeners may be tuned outside of a radio receiver's range.
- Api response for invalid requests is a broken connection.
Next steps:
- Create test scripts, with as close to full code coverage as possible.t
- Reporting of component status through the API
- Improve shutdown process
- Improve rf analyser tap naming
- add replay capability to tap_grap.py
- ..... many other stuff
Hope this will be of use.
Duarte Alencastre