Display Messages >-3dBFS per 10min instead of per hour. Due to the now
correct logging of those messages the red area corresponding to them can
get very big and make the rest of the graph hard to read. Displaying
them like the total messages received was also considered but that tends
to make the red area become very small and hard to see.
dump1090 produces stats.json, this is read to produce the database the
graphs are based on. strong_signals is a counter which logs every message
with an RSSI of bigger than -3dBFS.
Currently this message counter is unlike the other message counters read
from the last1min instead of the total bucket. This creates bad data as
the rrd data source type used assumes a constantly increasing counter,
which the last1min bucket is not. When the last1min strong_signals
bucket decreases the database logs unkown, when last1min strong_signals
increase it logs the increase and divides it by the elapsed time which
assuming a relatively constant number of strong_signals per minute can
greatly underestimate the actual value of strong_signals received.
Change the data collection to use the total strong_signals bucket like
the other message logs. The data collection will log the difference
between readings and create a correct rate.
- import time module for time.sleep() to work
- change all occurrences of true to True and false to False. In Python
these have to be capitalised.
- add initial state to purge_aircraft, purge_flights, purge_positions,
purge_days_old; set it to False
- cursor.fetchone() returns a single row; change the assignment to
purge_aircraft accordingly (otherwise the script fails with an "out of
range" error)
- calculate purge_date only if purge_days_old is not None (otherwise set
it to None too). This stops the script from failing when the date was
not set
- run the database purging only if both
purge_(aircraft|flights|positions) and purge_date exist