MUDPI Publisher

Introduction

The MUDPI Publisher is a simple Linux socket-based application which allows MUDPI packets to be generated and sent in a well defined sample pattern.

Note

This tool is planned to be replaced by/collapsed with: Generic MUDPI publisher standalone tool

Two programs are provided: rtctkMudpiPublisher and rtctkMudpiPublisherReceiver. The publisher does the sending, while the receiver can be used to sanity check the publisher. An additional two Python programs are provided, which allow FITS binary tables to be created and converted to the form used by the publisher.

Example usage where output from the receiver is kept:

$ rtctkMudpiPublisherReceiver localhost 2020 & \
  rtctkMudpiPublisher -n6 -d100000 localhost 2020 1234 > /dev/null

Binding to port 2020 on host localhost
Enter receive loop
inSynch
sample 0 complete, size 47808 delta is 1 1
sample 1 complete, size 47808 delta is 1 2
sample 2 complete, size 47808 delta is 1 3
sample 3 complete, size 47808 delta is 1 4
sample 4 complete, size 47808 delta is 2 2.5
sample 5 complete, size 47808 delta is 2 3
sample 6 complete, size 47808 delta is 2 3.5
sample 7 complete, size 47808 delta is 2 4
sample 8 complete, size 47808 delta is 2 4.5
...

Usage is as follows:

usage: usage: rtctkMudpiPublisher -m -t -r -s<frameSizeInBytes> -l<limitOfFrames> -n<nFramesPerSample> \
    -d<loopDelayInUs> -f<datafile> -b<buffSize> -g<multicast_group> <destIP>  <port> <topicId>

-r: Increment the ramp each cycle
-t: Wait for trigger
-s: Send a sample of given size (in bytes), calculates the number of frames required,
    last frame may be shorter than the others
-n: Send a sample consisting of n frames of the same size
-b: BUFFSIZE, the size of UDP packet to use including MUDPI header
-f: Read sample date from file
-d: Delay in microseconds between samples
-l: produce a limited number of samples
-g: multicast group to listen to on the network adapter with IP address <destIP>

The -s and -n options cannot be used at the same time.

The rtctkMudpiPublisher runs in a loop, sending MUDPI samples with a delay of loopDelayInUs between sample transmissions. Default is 1100ms; other values can be specified with the -d option.

The sample is transmitted over nFramesPerSample frames. Default is 6.

The sample payload is filled with a floating point vector. The total sample size (unless the -s option is used) is defined by nFramesPerSample * buffSize (minus the MUDPI header size). The default buffsize is 8000. With the default buffsize, the number of floats per frame is 1992. If the -s option is used, then the number of required frames is calculated; if it is not an even multiple of the sample size, then the last frame will be shorter than the rest.

The sample data contents can be provided in a simple text file with one line per sample, the contents being space-separated floating point numbers. If the number of floats in a line is less than required, it is padded with 0’s; if there are too many they are truncated silently. An example data_file.txt is provided (see standaloneTools/mudpiPublisher/mudpiPublisher/data_file.txt).

If a data file is not provided, then a floating point ramp will be generated starting at 0.001 with an increment of 0.001. If the -r flag is used, then the ramp values are incremented each cycle and wrapped around back to 0.001 after 1000 samples to avoid rounding issues.

The MUDPI packets have some fixed fields which are populated as follows:

mht->application_tag = 0x1234;
mht->component_id = 0x4321;
mht->version = 0x0101;
mht->num_frames = nFramesPerSample;

The payload size will be as follows for most frames, with the last frame possibly containing a shorter payload if the -s flag has been used:

mht->payload_size = BUFSIZE - sizeof(mudpi::MudpiHeader);

The MUDPI sample_id field is filled with the incrementing sampleId starting with 0.

The MUDPI topic_id field is filled with the topicId parameter.

The MUDPI frame_id starts with 1 and increments up to the nFramesPerSample.

The UDP packets are sent with a destination specified as destIP and port. If multicast_group is specified, the UDP packets are multicasted to the specified group.

The rtctkMudpiPublisher publishes up to 1000000 packets or until it is interrupted with ^C or until the -l limit of samples has been generated.

Running Multiple Instances with Triggering

If you need to run multiple instances which run synchronously to simulate e.g. wavefront processing of different WFS in different parts of the RTC, you can use the -t flag to indicate that the instance should wait for a trigger. An example usage would be:

$ rtctkMudpiPublisher -t localhost 2020 1234
$ rtctkMudpiPublisher -t localhost 2020 1235
$ rtctkMudpiPublisher  localhost 2020 1236 -d 10000

This runs three instances generating three topic id’s all being sent to localhost/2020. The first two will wait (-t) until the last one is started and starts updating the sample_id in the shared memory, generating a new sample whenever it is updated. The frequency of generation can be controlled by giving the “master” instance a -d option to control the sample frequency.

Each “waiting” instance (option -t) generates a message indicating the SampleId that it is waiting for. E.g.:

[ waiting for SHM trigger for sampleId: 455 ]

Note

The synchronisation is done using a shared memory segment: /dev/shm/rtctkMudpiPublisher. If you see any error messages about not being able to open the shared memory, see if this file exists.

Making a sample text file

The data files which can be passed to the program are text files where each line contains space separated values making up a sample.

To generate a new file using octave, use the following commands:

# Make 3 samples of ramp with 10k values
data = [[0.001:0.001:10];[0.002:0.001:10.001;];[0.003:0.001:10.002;]];
save ("-ascii", "data_file.txt", "data")

Alternatively, if you have a FITS binary table with the values to be sent, you can use Python code similar to the following to convert the table to text:

import astropy.table

def dump_table_to_text(filename):
    table = astropy.table.Table.read(filename)
    for x in table:
        print(*x)

Running with the TelRepub

The primary goal of the rtctkMudpiPublisher is to inject data into the system to be picked up by the rtctkTelRepub process. To run it together with this process the following should be done:

# Start the TelRepub
rtctkExampleTelRepub.sh run
rtctkExampleTelRepub.sh send Init
rtctkExampleTelRepub.sh send Enable
rtctkExampleTelRepub.sh send Run

# Start the DDS sample receiver; use a -c flag to check the data
rtctkGenDdsSub -d -t test_topic_00 -c

# Start the MUDPI generator
rtctkMudpiPublisher localhost 60000 0
# or for a rolling ramp
rtctkMudpiPublisher localhost 60000 0 -r

The port number 60000 in the above example must be chosen to correspond to the port number on which the TelRepub is actually listening. See section Receivers with DDS topics Configuration of TelRepub for details about how these port numbers are set for TelRepub itself.

At this point the mapping from MUDPI SampleId to DDS Topic is used. This is defined in the tel_repub Runtime Configuration Repository:

mudpi_receivers:
 rcv_00:

   ...

   dds_topics:
     test_topic_00:
       mudpi_topic: !cfg.type:int32 '0'