Fix build warnings and format docs

simonsobs · May 7, 2024 · fbe2ff1 · fbe2ff1
1 parent e8e94ad
commit fbe2ff1
Show file tree

Hide file tree

Showing 2 changed files with 46 additions and 30 deletions.
diff --git a/docs/agents/ld_monitor.rst b/docs/agents/ld_monitor.rst
@@ -4,10 +4,12 @@
 Lightning Detector Agent
 ========================
 
-The lightning detector agent communicates with the Lightning Detector System at the site and parses the data to obtain approximate lightning strike distances and standardized alarm levels.
+The lightning detector agent communicates with the Lightning Detector System at
+the site and parses the data to obtain approximate lightning strike distances
+and standardized alarm levels.
 
 .. argparse::
-   :module: socs.agents.ld_monitor.agent.LDMonitorAgent
+   :module: socs.agents.ld_monitor.agent
    :func: make_parser
    :prog: agent.py
 
@@ -23,16 +25,16 @@ OCS Site Config
 An example site-config-file block::
 
     {'agent-class': 'LDMonitorAgent',
-       'instance-id': 'ld_monitor',
-       'arguments': [['--mode', 'acq']},
+     'instance-id': 'ld_monitor',
+     'arguments': [['--mode', 'acq']},
 
 Docker Compose
 ``````````````
 
 An example docker-compose configuration::
 
     ocs-template:
-        image: simonsobs/ocs-lightning-detector:latest
+        image: simonsobs/socs:latest
         hostname: ocs-docker
         environment:
           - LOGLEVEL=info
@@ -42,18 +44,32 @@ An example docker-compose configuration::
 Description
 -----------
 
-The Lightning Detector System is connnected through serial communication with a dedicated PC at the site, in which a propietary application calculates approximate lightning strike distances and adjusts alarm levels accordingly. Data is parsed and the most important parameters are updated. The dedicated PC is continously running a script that streams the data via UDP to the client.
+The Lightning Detector System is connnected through serial communication with a
+dedicated PC at the site, in which a propietary application calculates
+approximate lightning strike distances and adjusts alarm levels accordingly.
+Data is parsed and the most important parameters are updated. The dedicated PC
+is continously running a script that streams the data via UDP to the client.
 
-Transmitted data
-----------------
+Transmitted Data
+````````````````
 
-The lightning detector transmits its data in "sentences". There are 5 types of expected sentences:
--electric field
--lightning strike
--high-field
--status
--alarm timers
-Electric field sentences report the electric field value measured by the Electric Field Mill in kV/m. Strike sentences include lightning strike distance and units (meters or miles) and is only transmitted if a strike is detected. High field sentences report an alarm status with respect to set thresholds of electric field. Status sentences include data such as alarms (red, orange, yellow), remaining timers, all clear status, fault codes, among others. Alarm timers sentences are disregarded, as its information is redundant. Each of the sentences' data is parsed and data updated to the feed.
+The lightning detector transmits its data in "sentences". There are 5 types of
+expected sentences:
+
+* electric field
+* lightning strike
+* high-field
+* status
+* alarm timers
+
+Electric field sentences report the electric field value measured by the
+Electric Field Mill in kV/m. Strike sentences include lightning strike distance
+and units (meters or miles) and is only transmitted if a strike is detected.
+High field sentences report an alarm status with respect to set thresholds of
+electric field. Status sentences include data such as alarms (red, orange,
+yellow), remaining timers, all clear status, fault codes, among others. Alarm
+timers sentences are disregarded, as its information is redundant. Each of the
+sentences' data are parsed and published to the feed.
 
 Agent API
 ---------

diff --git a/socs/agents/ld_monitor/agent.py b/socs/agents/ld_monitor/agent.py
@@ -292,21 +292,21 @@ def acq(self, session, params=None):
         The most recent data collected is stored in session data in the
         structure::
 
-        >>> response.session['data']
-        {'fields':{
-            'd_type': 3, 'field_value': 0.28, 'rot_fault': 0,
-            'time_last': -1.0, 'tsince_last': -1.0, 'dist': -1, 'unit_d': 0,
-            'high_field': -1, 'hifield_value': -1000.0, 'alarm_r': 0,
-            'alarm_o': 0, 'alarm_y': 0, 'delay_g': 1, 'clear': 1, 'r_timer': 0,
-            'o_timer': 0, 'y_timer': 0, 'g_timer': 0, 'allclear_timer': 0,
-            'faultcode': 0
-            },
-            ...
-            'connection': {
-                'conn_timestamp': 1711285858.1063662,
-                'connected': True}, 'data_timestamp': 1711285864.6254003
-                }
-        }
+            >>> response.session['data']
+            {'fields':{
+                'd_type': 3, 'field_value': 0.28, 'rot_fault': 0,
+                'time_last': -1.0, 'tsince_last': -1.0, 'dist': -1, 'unit_d': 0,
+                'high_field': -1, 'hifield_value': -1000.0, 'alarm_r': 0,
+                'alarm_o': 0, 'alarm_y': 0, 'delay_g': 1, 'clear': 1, 'r_timer': 0,
+                'o_timer': 0, 'y_timer': 0, 'g_timer': 0, 'allclear_timer': 0,
+                'faultcode': 0
+                },
+                ...
+                'connection': {
+                    'conn_timestamp': 1711285858.1063662,
+                    'connected': True}, 'data_timestamp': 1711285864.6254003
+                    }
+            }
 
         """
         with self.lock.acquire_timeout(0, job='acq') as acquired: