Visit Mobile Instrument Def for points we have decided to address.
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.
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.
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
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).
Low Bandwith - CSV Packet
The CSV packet should work for many instruments which need to send scalars or histograms. The 80% solution.
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).
It would be desirable to query an instrument for configuration.