4. Utilities

RTMS Sender (rtmssender)

rtmssender/src/main.cpp builds the rtmstoolsSender binary, a FITS replay tool that drives RtmsSender. It loads a FITS cube with LoadFitsImageCube, splits it into per-sample buffers, prepares the requested extended header and streams the images at a fixed rate.

Typical usage:

$ rtmstoolsSender \
    --sim-im ${INTROOT}/resource/image/testCube16Bit.fits \
    --src-ip 192.168.1.10 --dest-ip 239.10.0.42 --dest-port 59000 \
    --frequency 10 --iterations 100 \
    --ext-hdr BasicImageInfo --mtu-size 9000 \
    --topic-id 42 --component-id 7 \
    --log-level INFO --stats-file sender.yaml

Key options:

  • --sim-im (required) selects the FITS file that will be replayed.

  • --frequency and --iterations control the pacing (-1 means run as fast as possible / forever).

  • --src-ip / --dest-ip / --dest-port pick the transport endpoints; the source can be unicast or multicast as required.

  • --mtu-size switches between standard (1500) and jumbo (9000) frames.

  • --ext-hdr chooses how SampleExtInfo is filled: None, Timestamp or BasicImageInfo (timestamp plus datatype, width, height and offsets). The default is None.

  • --topic-id / --component-id forward the identifiers stored inside the RTMS leader.

  • --packet-send-delay-microsec injects an artificial pause between UDP packets, useful to emulate limited bandwidth links.

  • --ignore-conn-refused keeps the sender alive when no receiver is running yet (errors are logged but not fatal).

  • --stats-file writes the YAML block produced by SenderStats (total samples, failures, min/avg/max/stddev interval and effective rate). The same report is also printed to stdout on exit.

By default logging uses rtmstools’ installed CII-formatted config/ifw/rtmstools/log.properties; provide --log-property-file with an alternative log4cplus properties file, or tweak --log-level to INFO/DEBUG to see per-sample traces.

RTMS Receiver (rtmsreceiver_llnetio)

rtmsreceiver_llnetio produces rtmstoolsReceiver_llnetio, a monitoring tool built on RtmsReceiverTool. It listens on an RTMS topic, keeps per-sample statistics, and can optionally forward frames to DDT.

Example workflow:

# 1) Start DDT broker (if not already running)
$ ddtBroker --uri zpb.rr://*:12011 &> /dev/null &

# 2) Start the RTMS sender
$ rtmstoolsSender \
    -i $INTROOT/resource/image/ifw/ccf/cube_10_16_bit.fits \
    -q 1 -n 100000000 \
    -s 127.0.0.1 -d 127.0.0.1 -p 59000 \
    -m 1500 -t 10 -c 12345 \
    -l INFO --ignore-conn-refused --packet-send-delay-microsec 10

# 3) Start the RTMS receiver
$ rtmstoolsReceiver_llnetio \
    --address 127.0.0.1 --netif 127.0.0.1 --port 59000 \
    --width 512 --height 512 --data_type Int16 --topic-id 10 \
    --mtu-size 1500 --log-level INFO \
    --broker-uri zpb.rr://127.0.0.1:12011/broker/Broker1 \
    --ddt-stream rtms-test

# 4) Start a DDT viewer
$ ddtViewer -l zpb.rr://127.0.0.1:12011/broker/Broker1 -s rtms-test &> /dev/null &

Notable arguments:

  • --address / --netif / --port select the multicast/unicast source and the local interface used to subscribe.

  • --width / --height and --data_type declare the expected payload layout; --ext-hdr (none/timestamp/ basicimageinfo) controls how the leader metadata is interpreted. The default None expects no extended info; choose Timestamp or BasicImageInfo when the sender provides those fields.

  • --topic-id and --mtu-size mirror the sender configuration.

  • --samples limits the run duration (0 keeps the tool alive until Ctrl+C). When the receiver exits it prints a YAML report summarising sample counts, losses and timing data; --stats-file captures that output to disk.

  • --ignore-checksum allows the run to continue even if the MUDPI checksum detects corrupted packets.

  • --log-property-file / --log-level drive logging just like in the sender.

The short -s argument is context aware: values that parse as integers are treated as --samples while other strings are forwarded to --ddt-stream (see below). The utility registers signal handlers so Ctrl+C triggers a clean shutdown, flushes statistics and stops the DDT publisher if one is running.

DDT publishing helpers

rtmsreceiver_llnetio can forward frames to DDT by leveraging the rtms2ddtlib_llnetio gateway. Provide both --ddt-stream (or -s with a non-numeric string) and --broker-uri (-k) to turn the feature on; --ddt-interval specifies how often frames are pushed. The receiver then instantiates Rtms2DdtGateway, ensuring the incoming geometry matches what DDT expects, and DdtSender runs in a background thread fed by a lock-free queue.

The DDT components keep their own log4cplus logger and throttle common misconfiguration messages (missing geometry, missing Basic Image Information in the leader, broker disconnects). rtmstoolsReceiver_llnetio monitors the DdtSender::stopped flag when terminating so that the publisher can flush the queue gracefully.