In my first Research Note I introduced a new smart gas sensor module for detecting toxic gases and explained some background of the project. Now I'll start to get into the details of the design, and introduce the bigger picture of how these might be used effectively in the real world.
I've dubbed this new board the echem328. It is an iteration of previous prototype designs as I discussed in the intro, but it is also inspired by other modular smart sensor designs, for example this MIT “Stack” project for wireless sensing applications. I've also directly borrowed the concept of the Smart Transducer Interface Module (STIM) from IEEE Standard 1451 which describes "a set of open, common, network-independent communication interfaces for connecting transducers (sensors or actuators) to microprocessors, instrumentation systems, and control/field networks" and uses Transducer Electronic Data Sheet" (TEDS) format to store sensor calibration data.
Design Philosophy
The echem328 is based on Arduino open-source hardware and software environments, but takes on a new more integrated physical form factor that is also stackable and easily included in all sorts of embedded systems using a variety of standard interface protocols. Beyond it's fundamental echem sensor interface, the echem328 is also designed to perform a range of remote sensing and data logging functions and is highly modifiable and programmable. The circuit board has many options selectable by jumper installation or software modification.Reducing component and board cost per se was not a primary consideration during circuit design. Rather, I focused on overall value, reliability, and flexibility. For example, the circuit board is a four-layer high-density affair (expensive!) but the internal power and ground planes allow a smaller overall system footprint while ensuring lower noise and EMI.
On the other hand, it is anticipated that after some field experience with these circuits, a “devolved” or “evolved” or perhaps even “minimum viable” version of this circuitry will find definition, targeted towards a specific application that will make another iteration worthwhile. In the mean time, this platform should serve as a solid development platform for evaluating these various options, and for gaining valuable experience in a variety of field trials so that future circuit refinements are based on convincing, real-world performance data.
Calibration
The general idea is that the module not only is smart (has a local microcontroller) it also knows intimate detail about the particular sensor on the board as well as error sources and temperature offsets in the module's own circuitry, which is "metadata" stored in local non-volatile memory. More than that, it has the remaining pieces of the software puzzle (error correction algorithms, previous calibration history, other system and sensor diagnostics, command parser and scheduler) to receive commands, decode sensor signals, and transmit accurate sensor readings over a serial communications interface in predefined scientific units (typically parts per million or billion concentration).Alternately, in a format closer to the traditional IEEE1451 style, this all of this calibration metadata would be transmitted along with the raw data so that final computations can be performed on the system's host processor. This can be a "chatty" way of doing things, but I think there is potential to effectively store this metadata in the "cloud" and do the data processing there as well (IEEE 1451 calls this a "virtual TEDS").
Another part of my exercise has been building up various DIY calibration rigs using pre-mixed cal gases and valves and flow sensors and mass flow controllers and so on. The general idea is to have the calibration rig talk to the sensor board to perform various auto-calibration routines. Yes, the Alphasense sensors are calibrated to within 1% at the factory, but as I mentioned it's never that simple. For example the AFE chip's TIA feedback resistors have a tolerance of 5%. Ooops! So that's another thing to do, figure out how to precisely characterize the board itself and collect metadata that can (mostly) subtract these errors back out of the signal. This and many other calibration topics deserve a whole other discussion which I'll save for future Research Notes.
沒有留言:
張貼留言