Skip to content

Latest commit

 

History

History
82 lines (64 loc) · 5.47 KB

REDIS_DOCUMENTATION.md

File metadata and controls

82 lines (64 loc) · 5.47 KB
Raw

Redis Documentation

The information made available by this interface and the format within which it is stored in redis

Key / Value Pairs

Here are the redis keys that are created by the KATCP Server and KATPortal Client modules and descriptions of their values.

current:obs:id --> (string):

The product_id sent with the most recent ?configure request. A product id is specific to a subarray and will last for some period of time (over the course of observing multiple targets). Note that product ids can be repeated at different times in the telescope's lifespan, so do not use it as a unique identifier to label the data products! The product id is used as a temporary identifier of a currently activated subarray. Accordingly, metadata for this subarray is grouped with this product id. For instance, if the product id of the currently-in-use subarray #2 is array_1_bc856M4k, then metadata will have a redis key in the form of array_1_bc856M4k:<type of data>, e.g. array_1_bc856M4k:n_channels.

[product_id]:timestamp --> (string):

The Unix time at which the ?configure request was processed. This is generated by Python's 'time' module, with a time.time() function call. It is in seconds since UTC 1970-01-01 00:00:00.

[product_id]:antennas --> (list):

A redis list of physical antenna names used in particular sub-array to which the product id is associated.

[product_id]:n_channels --> (string):

The number of frequency channels provided by the CFB.

[product_id]:proxy_name --> (string):

The CAM name for the instance of the BLUSE data proxy that is being configured. For example, “BLUSE_3”. This can be used to query sensors on the correct proxy. Note that for BLUSE there will only be a single instance of the proxy in a subarray.

[product_id]:cam:url --> (string):

The url used by the KATPortal Client module to query additional metadata for the subarray associated with the given product id.

[product_id]:streams --> (string):

A json-formatted string for a python dictionary that contains different URL's for the different types of raw data that are produced in the current observation being conducted on the given product_id's subarray. To convert this string to a python dictionary, simply call json.loads(<streams_string>), and it will return a python dictionary object. This dictionary will look something like this:

{
    "cam.http":
        {"camdata":"http://monctl.devnmk.camlab.kat.ac.za/api/client/2"},
    "stream_type1":
        {
            "stream_name1":"stream_address1",
            "stream_name2":"stream_address2"
        }
    }
    "stream_type2":
        {
            "stream_name1":"stream_address1",
            "stream_name2":"stream_address2"
        }
    }
}

It may contain:

  • One CAM stream, with type cam.http. The camdata stream provides the connection string for katportalclient (for the subarray that this BLUSE instance is being configured on). This is the same as the [product_id]:cam:url value in the redis database.
  • One F-engine stream, with type: cbf.antenna_channelised_voltage.
  • One X-engine stream, with type: cbf.baseline_correlation_products.
  • Two beam streams, with type: cbf.tied_array_channelised_voltage. The stream names ending in x are horizontally polarised, and those ending in y are vertically polarised

[product_id]:[sensor_name] --> (string):

Most of the keys published to redis will look like this, and are created from the KATPortal Client module. The [product_id] is that of the subarray that is queried by the KATPortal Client. The value of this key a repr string for a python dictionary containing sensor information. The dictionary looks like this:

{
    'status': u'nominal', 
    'timestamp': 1533319620.245345, 
    'value': u'PKS 0408-65, radec bfcal single_accumulation, 4:08:20.38, -65:45:09.1, (800.0 8400.0 -3.708 3.807 -0.7202)', 
    'value_timestamp': 1533291480.096976
}

Messages

Here are the messages published to the various channels of the redis server

Channel: alerts

  • configure:[product_id] --> sent when a configure request is sent to the KATCP Server. Gives the associated product_id.
  • capture-init:[product_id] --> sent when a capture-init request is sent to the KATCP Server. Gives the associated product_id. Signifies that a program block is starting. This is not yet the start of an observation schedule block, so no need to start data capture yet.
  • capture-start:[product_id] --> sent when a capture-start request is sent to the KATCP Server. Gives the associated product_id. Signals the start of an observation. Should be used to trigger other modules to start ingesting and processing data.
  • capture-stop:[product_id] --> sent when a capture-stop request is sent to the KATCP Server. Gives the associated product_id. Signals the end of an observation. Should be used to trigger other modules to stop ingesting data.
  • capture-done:[product_id] --> sent when a capture-done request is sent to the KATCP Server. Gives the associated product_id. Signals that the current program block is done.
  • deconfigure:[product_id] --> sent when a deconfigure request is sent to the KATCP Server. Gives the associated product_id

Channel: sensor_alerts

  • [sensor_name]:[sensor_val] --> sent when a sensor (which belongs to the list of sensors for subscription in the KATPortal Client) reports a new value.

Channel: chan[n]

  • [product_id]:configure:stream:[addr_list[n]] --> sent when a configure request is sent to the KATCP Server