MeshAir API - Version NGAM - New Generation of Air Monitors
The growing trend is to utilize data available in microprocessor and board-based (e.g., Arduino, etc) sensors by providing a digital interface to the data acquisition, instead of the traditional analog output / analog input method. However, this interface is generally limited to download to proprietary programs, cloud servers, or access to proprietary mobile apps.
If small portable sensors are to make an impact, they must easily interact with existing ambient data networks and technology. This allows not only for the data to be accessible to more users, but also allows for more easy comparison with Tier 5 monitors for comparison and generation of calibration factors to correct data from Tier 1-4 sensors and create more meaningful data.
An important thing for instrument manufacturers and end users to understand is the difference between the Transport Layer and the Protocol. The transport layer describes physically how the digital information is transferred- RS-232, USB, Ethernet TCP/IP, etc. The protocol defines the content of those messages. The best analogy is to think of the protocol as the ‘language’ (English vs. French) and the transport layer as the medium (telephone vs. email vs. Morse code). Just because two people are on a telephone doesn’t mean they can understand each other, if one is speaking English and the other is speaking French. Similarly, because a device has an Ethernet interface doesn’t mean it can talk to all instruments with Ethernet ports. Both sides have to be using a shared protocol.
Most evolving Tier 1-4 sensors have the capability to store a history of stored averages or scans on a periodic basis (generally ranging from 10 seconds to 5 minutes). This data generally consists of the value itself (either as ppm/ppb data or as a voltage or “% of scale” value). Along with (hopefully) a date/time stamp, the sensor may possibly have some quality code or flag information (good, bad, suspect) and possibly GPS location information as well. Ideally, to handle multiple servers/users accessing the data, each data query should be able to request data between two date/time periods (e.g., “give me your data between 1/1/16 14:00 and 1/2/16 03:00”). In response to this, the most useful response format is a delimited data format, and the most common of those being a comma-delimited (CSV) format. In this case, each line would have the date, time, the measurement value(s), and then the aforementioned optional information (status, GPS data, etc).
An ideal protocol would be one that is simple for the instrument provider to implement, easy for the data collector to implement, and provide sufficient flexibility. CSV files are easier to implement in small simple processors that may be found in small portable instruments, compared to XML files (which no instrument vendor has adopted or even discussed). To this end, our recommendations for a generic protocol would include:
- A command starting character: this character would allow the instrument to 'wake up' and recognize an incoming command. It should be some special character, such asoror even a special printable character (@, tt,!, etc). This was used to considerable advantage in the SDI-12 protocol.
- Command type: single or two characters. Could be used to define the desired format, data set, etc. A common standard ('D' for data, or 'PD'for 'print data') would be ideal.
- Average interval definition: could be an optional field, in the event the instrument only stores one average. Could be combined with the command (e.g., 'PDlm') or separated by a space or comma for easier coding in the instrument ('PD,lm'). This is provides easier understanding of both sides vs. a file number or buffer number.
- Starting and Ending Time- see above. Minimal year, month, day, ideally hour and minute.
- Command terminator- easier to code in the instrument to know when command is complete, handle interrupts, etc.