Info on the display of data from bpl50s

bpl50s was connected to four H-pickups (although called H1, H2, V1 and V2).

A program (by Lars Jensen) was run on bpl50s, sending out UDP packets [1] to qlsba3, port 1234, about every 101.5 ms.

On qlsba3, a C program (by Jens Andersson) received the packets, checked the sequence number and timestamp in them, printed some statistics and sent a new UDP packet [2] to a specified computer (for example PCOPCR06), port 5001.

On PCOPCR06, a Java program (by Serguei Scherbakov) listened for UDP packets and updated a display whenever new packets were received. Screenshot.

Comments

An Excel spreadsheet with some observations on primarily the jitter (not the delay) of the packet arrival times (t_n-n*T). Conclusion: for this particular sender (the bpl50s program), the jitter of the sender (+/- 10 ms) is greater than the jitter of the network. For a more exact sender, the network jitter will however be more noticeable and something like max +/- 2-3 ms. (Possibly to come: measurements comparison with more exact sender.)

The Java program takes quite a bit of the CPU power of PCOPCR06, even with only 2*2 values.

Future enhancements: several clients, qlsba3-program that collects all of their incoming updates to one packet.

Quentin King suggested a "magic number" first in the packet to be able to recognize packets for this application, and a packet type identifier following it.

Alastair Bland recommended to minimize unnecessary network traffic. Each UDP packet which reaches the destination but is not received (nobody listening) generates an ICMP reply of "not reachable". A little investigation showed it will be detected on the sending end only if the UDP socket has been connect-ed, and will then appear as failing send calls as soon as the sender has received the ICMP reply.

[1] Packet format:

/* Data in network byte order (i.e. big endian). */
/* If signed, using two's complement. */

struct MeasurementStruct_v1 {
    unsigned short validity_code; /* 0 = invalid, 1 = valid */
    signed short h_pos; /* in a defined unit (microns, f.ex.) */
    signed short v_pos;
    signed short h_pos_sigma; /* in a defined unit (microns, f.ex.) */
    signed short v_pos_sigma;
};

struct PacketStruct_v1 {
    char version[4]; /* "v1\0\0" (to simplify change/extension) */
    char bpm_id[20]; /* "name\0" */
    struct timeval timing; /* long seconds, long useconds, <0,0> if unavailable */
    unsigned short seq_nr; /* 0, 1, 2, ..., 65535, 0, 1, ... (detect lost packets) */
    unsigned short nr_of_values; /* nr of H/V values following (6, for now) */

    struct MeasurementStruct_v1 values[6];
};

[2] Packet format:

The following values, all as integers with the format code %010d and each one followed by newline (\n).

nr-of-values
h-value-1
h-value-2
...
h-value-N
v-value-1
v-value-2
...
v-value-N
h-error-percent-1
h-error-percent-2
...
h-error-percent-N
v-error-percent-1
v-error-percent-2
...
v-error-percent-N