4. Behind The Scenes
Just in case you are curious as to how I structured the application, I thought I would give you a high level overview.
Now, this does not cover everything that is going on in the background, as there are several more events/enums/classes that are talking or passing data, but will give you a basic overiew.
The settings manager deals will all the settings and saves/reads these from the config file. When one of the configuration forms changes a setting, the SettingsManager class raises an event, and all the subscribers of this event will then read from the SettingsManager their relevant settings.
This issues the commands to the SerialManager and the NetworkManager to connect/disconnect/start/stop etc.
The trend is a user control embedded onto the form. It responds to an event from the DataStore when new data is added and updates the trend with the latest data.
The trend consists of two behind the scenes bitmaps. One is a single pixel wide and represents the latest data. When it is drawn, all the current data points are drawn onto their relevant calculated height based on the trends range. This single pixel wide trend sliver is then joined onto another background 'main' trend, extending its width by the 1 pixel. Before adding the data, the grid lines horizontal and vertical are calculated and drawn first, so the data is always on top of these. This main trend is then displayed to the user. The position of the trend on the form is determined by its width relative to the window width, so the new data is always visible, except when the scrolling is paused, and the position will be relative to the scroll bar value.
There is a set of markers at the right of the form, the required position is calculated again based on the range, and then drawn to another bitmap using a Filled Polygon to create the triangle.
The Serial Manager sends the commands ('ix', 'rx' and 'ux') to the USB device and updates the Snapshot data with the raw responses from the USB device. The USB device is polled as per the interval settings using a timer. When new data is received an event is raised so that other parts of the application can update accordingly. Events are also raised when the manager changes state, e.g. disconnected or connected.
The Network Manager listens for request on the relevant port. When a request is received, the command request is read('ix', 'rx' and 'ux') and the raw data is pulled from the snapshot data and returned to the client. When clients connect an event is raised so that other parts of the application can update accordingly. Events are also raised when the manager changes stat. e.g. running or stopped.
The Data Store reads the latest messages from the Snapshot as per the logging interval (another timer) and updates the DataStore with a new record, which is a concatenation of the 'rx' and 'ux' commands, for the parameters we are interested in. The calculated NELM is also added to this record, along with a timestamp. If File logging is also enabled, this new constructed record is written to file. When a new point is added, an event is raised so that other parts of the application can update.
These two forms, subscribe to events from the managers and when these events occurs, updates the displayed tables with the new data.
This is published by Unihedron, and contains all the command and response information. It can be found at:
(http://unihedron.com/projects/darksky/cd/SQM-LU/SQM-LU_Users_manual.pdf)
The document also contains the formula for the calculated Naked Eye Limiting Magnitude (NELM) value from the sky brightness valve. This is:
NELM = 7.93 − 5 × log(10^(4.316−(mpsas/5)) + 1)