Visit Mobile Instrument Def for points we have decided to address.

Hardware Connections

  

Ethernet

Ethernet would be the transfer medium for data, status and configuration. It would seem that the instrument would have to do DHCP, especially if it were to be a mobile instrument moving across platforms. The IWG1 packet would then be easily available for aircraft data.  

Modern switches accept 10Mb, 100Mb and 1Gb, and do not lower other ports based on lowest common speed. Hubs will lower speed for all ports to the lowest common speed. 100Mbps seems fine for all/most instruments.  

Ethernet IP cores are widely available for FPGA applications.  

TCP vs. UDP

UDP seems to be the choice over TCP. TCP requires a server at the receiving end requiring handshaking. This ends up generating more traffic with all the acknowledge packets.  

Joe Van Andel once did some tests of transmitting radar data via UDP. My recollection was the results were impressive. I should see if he still has the results. --Chris

How do UDP loss rates compare with RS232/422 loss rates? We definitely lose SPP data on our systems, say < 1%. --Chris

The loss rate for UDP is entirely dependent on the network used to move the packets and the computers/devices which are talking: loss can be arbitrarily close to zero for a dedicated point-to-point connection between fast computers, even at high data rates, but can approach 100% on burdened or unreliable networks (e.g., satellite transfer from aircraft to ground when the plane is turning) – Burghart


1 Pulse per Second

Instrument would accept a 1 PPS input line. This would allow the instrument to then divide this down to the configured sample-rate with an internal timer chip. There would be less potential for data-system [both local or remote] timing issues. Time-stamping seems optional as the correct time can be manufactured by the data system. This issue is especially important for instruments which do pulse counting (e.g. PMS/SPP probes and CN Counters) at high-rate; the deltaT is more important than the time-stamp.

Data packets should then send the sample count in each packet. Packet for sample zero, which would occur at the 1PPS, would be zero every second and then count up. This would allow an acquisition system to know which packet(s) were lost and their position in the data stream.
----

Instrument Configuration

If the instrument requires no configuration, then it can start transmitting on power up. If the instrument requires configuration (e.g. sample rate, number of channels) then it should wait for that configuration. The existing DMT SPP probes currently do the latter.

Configuration items could include:

  • DHCP vs. static IP
  • port to broadcast data on
  • port to receive control commands on
  • sample rate

Web Services

An instrument can easily run a Web Server for configuration and control.

  • We already appreciate this functionality in router appliances, time servers, and other devices.
  • A google for embedded web server open source turned up about half a million hits.
  • Multi-threading/multi-processing would not be a requirement, as there are libraries for embedding http services right in an application.
  • The server would save configuration information in non-volatile storage.
  • wget could be used on the host side for automated interaction.
  • No follies with fixed port numbers.
  • There are web servers that run on FPGAs.

Future iterations/generations could even use Universal Plug and Play (UPnP).
----

Data Formats

Low Bandwith - CSV Packet

The CSV packet should work for many instruments which need to send scalars or histograms. The 80% solution.

Identifier

If the CSV identifier can not be configured via a setup packet, then it should be unique. I would suggest the instrument tag followed by a serial number (e.g. SPP100_109 instead of SPP100).

Time stamp

Q: Should the time-stamp in the CSV allow a sample count starting at zero every PPS? IFF 1PPS is used as input.

e.g. for a 5hz value:

ID,s0,value
ID,s1,value
ID,s2,value
ID,s3,value
ID,s4,value
ID,s0,value

perhaps using the letter 's' to denote it is not an ISO8601 time-stamp.


CSV Header

It would be desirable to query an instrument for configuration.

Still working on draft format, but seems something XML is the preference. To date we have been considering this for variable names, units and titles. But this could be extended to sample-rates, serial numbers, and other information as well. --Chris

  • No labels