XML Phase Sensor Data Format

The following represents a guide to the XML format used for communication between the GPS Disciplined DAQ (Phase Sensor) and the host PC operating the phase estimation algorithms.

The needs of the format were identified as follows:
  1. Must be human and machine readable
  2. Must be open and extendable
  3. Must be bandwidth efficient (since some MCUs have limited throughput)
Requirements 1 and 2 are readily addressed by XML. In order to achieve requirement 3, the payload from the sensor will be encoded in Base64 (Wikipedia).

Data to be included in each sensor datagram:

  1. Time of Day
  2. Date
  3. Number of Channels
  4. Number of Samples per Channel
  5. Sampling Rate (Hz)
  6. Messaging Rate (Hz)
  7. Channel Payload
    1. Channel Type
    2. Channel Name
    3. Channel Scale
    4. Sensor Sample Data

Example datagram

<?xml version="1.0" encoding="UTF-8" ?>


Comments are welcome as to how to secure information transfer in the case when a sensor might be deployed on a LAN. IPsec is possibly an option.

Last edited Feb 3, 2012 at 6:02 PM by clockdoctor, version 7


clockdoctor Nov 23, 2011 at 2:40 PM 
Hi Wolfram, Arnold,

(Sorry, just getting these messages!)

This is the format from the DAQ to the PC that performs phase estimation. The payload here is not a Synchrophasor, it is waveform samples (raw ADC data). It is unreadable as it is binary data encapsulated in Base64 so that it can be transferred in ASCII characterset.

The rational for using UDP datagrams for delivery of ADC data is this:

1) Allows for a virtual ADC for rapid prototyping of phase estimation algorithms. Simple set up Virtual ADC to send data to localhost.
2) Easy migration from virtual ADC to a physical ADC
3) Device independent - can be National Instruments / cRIO, homebrew, or customised firmware in commercial PMU.
4) UDP so that there is less development hassle than if using TCP (may add TCP option later as platform matures)

All the best,


ajstadlin Aug 1, 2011 at 11:55 PM 
Suggestions: 1) Use different datagram schemas to separately transmit configuration constants or data. The config constants can either be periodically or on demand transmitted.
2) Include error detection in the schema (e.g. <CRC>##</CRC>); especially if the encapsulating protocol does not provide this or if the data must traverse a communications link prior to protocol transmission.

wopl Jul 18, 2011 at 5:32 PM 
struggling with "SAMLES", "FREQ" and "RATE"... as "FREQ" might be confused with power-net frequency. Maybe adjust the terms a bit.

"PAYLOAD" is quite unreadable. Shouldn't it be much more generic than device-specific?

How do we cope embedding this XML into GOOSE messaging protocol, which is standard to communicate with upper PDC's?