MUDPI Publisher

Introduction

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

Two programs are provided: rtctkMudpiPublisher and rtctkMudpiPublisherReceiver, the publisher does the sending, 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 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: rtctkMudpiPublisher -r -t -l<frameLimit> -s<sampleSize> -n<nFramesPerSample> \
    -d<loopDelayInUs> -f<datafile> -b<buffSize> <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

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). 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 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 floating point numbers, space separated. 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->applicationTag = 0x1234;
mht->componentId = 0x4321;
mht->version = 0x0101;
mht->numFrames = 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->payloadSize = BUFSIZE - sizeof(mudpi::mudpiHeader);

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

The MUDPI topicId field is filled with the topicId parameter

The MUDPI frameId starts with 1 and increments up to the nFramesPerSample

The UDP packets are sent with a destination specified as destIP and port.

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 sampleId in 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 SampleId that 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 shared memory look to 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 FITS binary table with the values to be sent, the fits2txt tool is an astropy program which is a good starting point for converting it to text.

Running with the TelRepub

The primary goal of the rtctkMudpiPublisher it 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 -t TestTopic00 -c

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

Where 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 Configuration for 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:

topics:
    topic_00:
        name:
            type: RtcString
            value: "TestTopic00"
        mudpi_topic:
            type: RtcInt32
            value: 0
        rcv:
            type: RtcInt32
            value: 0