|Product Performed to Expectations:||8|
|Specifications were sufficient to design with:||10|
|Demo Software was of good quality:||7|
|Product was easy to use:||10|
|Support materials were available:||10|
|The price to performance ratio was good:||10|
|TotalScore:||55 / 60|
element14 Road Test of the Keysight DAQ970A data acquisition system
What does the Keysight DAQ970A Data Acquisition System (DAQ) do?
It may be helpful to build context around each of the three words in the instruments description. What is meant by "data", "acquisition" and "system" as those words relate to this instrument? Here are the contexts I have developed in my exploration of this instrument:
Digital numeric information that represents commonly measured values in electronic circuits. The most commonly measured values in electronic circuits include resistance, current, and voltage, both AC and DC. Parametric values derived from resistance, voltage, or current include: capacitance, temperature, strain, frequency, and pulse width. The Keysight DAQ970A is engineered to acquire, or more bluntly, measure, parametric data encountered in electronic systems. It is useful to think of data in the plural when thinking about this data acquisition system. Any old multimeter can measure parametric data encountered in electronic systems. Multimeters are called multimeters because they can meter multiple things, but usually only one thing can be metered at a time. A DAQ can log, or accumulate a history of, measurements over time. Of the eight multimeters I currently have in my shop, five can log single parameter measurements over time. The other three are older devices from the 20th century that measure and display a single parametric data value selected mechanically by the user, with no ability to store the value. Two of those are analog instruments from the 1970's, and yes, they both still work. A defining characteristic for a DAQ is the ability to measure and record data from multiple sources over time. Data in the plural sense. DAQs are multi-channel measurement instruments with historian capability.
To acquire in the context of this instrument is to perform accurate and precise measurement of parametric values selected by the user, at specific times, with optimized signal integrity, and to store the acquired values for later analysis. Acquisition of data happens across a span of time and involves periodic measurement of one or more channels of information that are gathered and organized into an electronic record.
A data acquisition system emerges when a high quality measurement tool (essentially a 6 1/2 digit multimeter) operating at the core of the DAQ is embedded within a flexible connection architecture that allows a variety of signals to be sequentially connected to the measurement tool in an organized fashion. Add in the ability to support a variety of common sensors for strain and temperature, support for optimizing signal integrity depending on the measurement situation at hand, and the ability to configure measurement mission parameters like trigger events for measurements, alarm events, intervals between measurements, number of measurements in a mission and you have data acquisition system. Further add in multiple options for storing data (internal, USB, over a network), multiple data presentation tools (numeric, trend, histogram) and analysis tools like descriptive statistics and computed channels and you have a really nice DAQ like the Keysight DAQ970A, shown in the photograph below.
The DAQ970A is packaged in Keysight's new matte black chassis styling in the familiar bench top form factor used in many of their mid-range instruments like the 33461A multimeter and the 33600A series waveform generators. In terms of depth the DAQ970A is deeper than a 33461A multimeter, but not as deep as a B2902A Source Measure Unit. You may be wondering why an instrument that measures a lot of things has no front panel inputs. The sheer number of input channels makes it impractical to provide front panel probe connections for all of them, or for any of them. All of the data inputs are made through a removable module system that slides into the back of the instrument. The photographs below illustrate how the system works.
The photograph above shows the back side of the DAQ970A with a DAQM901A 20 channel multiplexer installed in the first of three available slots. In the configuration shown you will see a CAT 5 data cable and three thermocouple cables exiting the multiplexer module to the left. This is how the user gets signals into the DAQ970A to be measured. The regular meter probes you are used to using are not used in this data acquisition system. This Road Test came with a DAQM901A relay based signal multiplexer and four type J thermocouples. Many other input multiplexers are available to suit a variety of signal acquisition needs.
In the image above you can see the DAQM901A multiplexer module removed from the DAQ970A and with its transparent plastic cover removed. You can see how the CAT5 cable is stripped back and each of four wire pairs have been routed to individual input channel screw terminals. Three thermocouples have been wired into screw terminals on the right side. The input wires route through a wide channel at the back end of the module via a couple of 90 degree bends. There is also provision for wrapping a zip tie around the wire bundle for extra strain relief.
Keysight includes a handy screwdriver with the module so you don't have to hunt for an appropriately sized tool to attach your input wires. Small gestures like that make a difference, I will admit. Although I found it easy to connect four wire pairs from a CAT 5 cable and three thermocouples, I can imagine that cable routing will be more challenging if all 20 channels were in use at the same time. You may have noticed that this particular input module multiplexes input signals to the core multimeter using relays. In the pictures above you can see at least 27 PC mount electromechanical relays. The picture below is a close up of one bank of input switching relays.The reason I am interested in the switching relays is because they are electromechanical. This means they wear out. Because they are mechanical devices it takes time to move the contacts, so there is a limit on the switching speed. Also, they are fairly small, which will impact the maximum voltage they can switch. Here is a link to the OMRON spec sheet for the 6GS series of relays. OMRON specs this series with a mechanical durability of 100,000,000 operations, however, the more important specification in this case may be the electrical durability which is specified as 100,000 operations at rated load. Relay life and preventative maintenance is discussed by Keysight in the DAQ970A User Manual starting on page 229. In general, if relatively low level signals are being switched, the user can expect between 1,000,000 and 10,000,000 operations of each relay. High power switching, defined by Keysight as any load >25% of rating will reduce relay life to somewhere between 100,000 and 1,000,000 operations. To help plan preventative maintenance Keysight provides an non-volatile memory odometer count for each relay. This odometer tracks operation counts for every relay and can be recalled via the View/Relay Cycles option, or remotely using the DAQ app in BenchVue. Using the BenchVue DAQ app, I recalled the odometer history for the relays in the DAQM901A. When looking at the numbers below, keep in mind I have only been using the DAQ970A for a few weeks.
These counts include some overnight temperature missions using three different sensor technologies where samples were taken once every 30 seconds or once a minute. The local instrument display of these values is a little more informative in that a relay description is included in the count table. However, I have just discovered that some of the count values reported by BenchVue are wildly different that those reported locally on the instrument. Using the LXI web interface for the instrument I captured the following screen images of the same relay odometer counts.
For relays 101 through 108 the LXI web interface (instrument front panel) and BenchVue agree on the odometer counts. This is not the case for relays 193 through 199. The screen line breaks between BenchVue and the LXi interface don't align, so I'm only including the LXi image for relays 195 to 199 below. However, I can report that relay 193 reads 5435 in BenchVue and 21 on the instrument front panel, and relay 194 reads 8362 in BenchVue and 26 on the front panel. Even more concerning are the discrepancies between counts on relays 198 (62 vs 127421) and relay 199 (35 vs. 65538). These values are so far off that there are significant impacts on preventative maintenance decisions. My assessment is that the front panel numbers on the instrument are more likely correct because they make more sense based on how I understand the relay logic in the DAQ970A works. The one piece of information I am missing however is the counts for each relay when I first received the instrument. I am assuming they were all zeroed at shipping, but I don't know that for sure. Keysight may want to look into this discrepancy.
Because of the heavy reliance on relays in this system, it is possible to wear out parts of this instrument in short order if you are not careful. For example, setting up a mission that takes samples 10 times/second you could use up 100,000 relay operations in 3 hours.
So I checked on the price of replacement relays from Newark. Approximate equivalents go for between $4 and $5 a piece in Canada, so a complete refurbishment (about $140 CAD) would cost far less than a new multiplexer module (about $777 CAD). This assumes availability of quality solder and desolder tools and the skill to use them. I assume that a customer refurbished multiplexer would have no warranty support from Keysight.
Let's acquire some data
My first test scenario involved connecting several types of signals and parametric values to the DAQ970A to learn how the connections are set up and to check accuracy against my other bench equipment. The DAQ970A as equipped with the DAQM901A module allows measurement of a fairly narrow range of voltage, resistance, currents, and frequencies. Certainly enough to handle a good selection of typical circuit measurements. However, do not expect to be measuring voltages into the kV range, nV range, or frequencies higher than 300 kHz with the DAQM901A. So, you will not be sampling 5G telecommunications signals. That requires an entirely different sort of data acquisition instrument. In terms of parametric ranges, during the following tests I exercised the DAQ970A with voltages under <30 VDC, resistances up to a few MOhms, currents under 1 amp, and capacitances under a few microfarads. The DAQ970A is capable of measuring even more types of data, but the set up I describe next covers most of the common measurements.
Equipment set up for static parametric tests
The photograph below shows how temperature, capacitance, resistance, frequency/period, and DC voltage/current were set up for measurement.
Results of static parametric tests
A 5.0000 DC voltage was set up on a Keysight B2902A precision source measure unit configured in 4-wire mode. 4-wire source mode requires the use of 4-wire Kelvin test leads. Kelvin test leads can be seen in the photograph above near the Precision DC voltage label. Each lead has two conductors. One goes to a Force terminal on the B2902A, the other to a corresponding Sense terminal. This arrangement allows the B2902A to sense the forced voltage at the ends of the leads (at the load) and adjust the Forced voltage in a way that minimizes the error between set and measured voltage.
A quick aside here. I like to label signals for documentation purposes and I appreciate it when instrument vendors provide the ability to add labels electronically. The DAQ970A has a channel labeling feature that uses a displayed keyboard and the cursor keys to allow the user to type in a label. One small improvement to the user interface would make this feature much easier to use. Instead of the displayed keyboard, or even in addition to it, why not allow a USB keyboard to be connected to the front panel USB socket? Other vendors provide this feature. For example, I enter signal labels on my Tektronix MDO4104-3 oscilloscope using a cheap USB keyboard. Tektronix also supports an internal scroll and select keyboard, but the real keyboard is SO much better.
Moving on. It is comforting to see instruments agree on measured values. Frequently two meters connected to the same point in a circuit will not agree exactly because of differences in calibration or accuracy, or because of errors introduced by the measurement method. In the image below you can see the B2902A precision source measure unit on the bottom left. It is supplying the 5.0000 VDC signal to the DAQ970A sitting above it. To the right, a Keysight 34470A 7 1/2 digit DMM is monitoring the same voltage. Now, the DMM and DAQ are not in 100% agreement, but they are within roughly 10 microvolts of each other. That is nice to see. By comparing the display on the DAQ and DMM it is clear that the core DMM in the DAQ970A is based on other Keysight bench multimeters
For a basic 2-wire resistance test I connected a twisted pair from the CAT 5 cable to channel 109 in the multiplexer module. Setting the Tenma resistance decade box to 1 M Ohm produced the following reading.
The 1856 Ohm offset from 1 MOhm is well within the 1% tolerance of the components used in the Tenma box. Nice thing about using a decade box is that custom resistance value can be created with a few switch flicks. By starting below 1 MOhm and adding resistance in steps I was able to achieve a measured 2-wire value of 1,000,000 Ohms by setting up 995199 Ohms in the Tenma box.
To examine the 4-wire capability of the DAQ I decided to measure a 0.1% 10 Ohm resistor. A precision low value resistor was selected to show the benefit that 4-wire techniques bring to low value resistance measurements where contact and lead resistances are more significant. First, I took a 2-wire measurement using about a meter (3 feet) of CAT 5 cable. The 2-wire measurement is shown below.
A ± 0.1% 10 Ohm resistor should have a value between 9.99 Ohms and 10.01 Ohms. Based on the 2-wire measurement above, this resistor is out of spec. My 7 1/2 digit 34470A multimeter in 2-wire mode gave a reading of 10.86 Ohms on the same resistor. So, is the resistor out of spec? I doubt it. Let's switch to a 4-wire measurement to eliminate the resistance of the test leads in series with the resistor being measured. Switching to 4-wire mode and connecting the sense channel (channel 119) in parallel with the source leads from channel 109 provided the following measurement.
That is much better. Now the resistor measures well within spec. The 34470A in 4-wire mode produced a measured value of 9.996 Ohms as well. It is easy to see how 4-wire resistance measurements can help improve accuracy when long lead lengths and low value resistances are being measured. This very issue will come up again when I use the DAQ970A to log temperature readings from RTD and thermistor sensors located in a garden shed adjacent to my house. There is about 80 feet (24.4 m) of underground cable between my workshop and the garden shed. The measured resistance of that much copper wire is between 4.5 and 5 Ohms. That amount of parasitic resistance can have a significant impact on temperature readings produced by a 100 Ohm RTD. Luckily, the DAQ970A has helpful tools that can compensate for long cable lengths.
Channel 107 was wired to the binding posts of a Tenma model 72-7265 Capacitance Decade Box set to a value of 1 microfarad ( ± 5% tolerance capacitors). The reading should be between 1.05 microfarads and 0.95 microfarads. The actual reading is:
Once again, we are within tolerance. To satisfy that little irrational itch for unrealistic precision, I created what measures as a 1.000 0 uF capacitor by paralleling 997.2 nF of marked capacitor values on the Capacitance Box. I experienced a little jolt of joy when I saw the following measurement on the display. The number of digits after the decimal point changed I think because the auto ranging went to 10 uF above, but dropped down to 1 uF below.
Some sensors produce time based signals rather than voltages, currents, or resistances. Optical or magnetic sensors, for example, that sense the rotational speed of motor shafts. Other examples include wind anemometers that produce pulse outputs that correspond to wind speed and flow meters that output pulses corresponding to fluid flow rates. To see how the DAQ970A measures time based signals I connected one output from a Keysight 33622A waveform generator to an input channel on the DAQ. I adjusted frequency, amplitude and pulse duration parameters to experimentally find the limits of operation. Here is what I discovered.
|Frequency/Period parameter||DAQ970A specification||Experimental limit (reading becomes unstable)|
|Frequency||Max: 300 kHz sine||≈ 830 kHz sine wave at 1.0 Vpp, 1 second gate time|
|Pulse duration||not specified||21 ns minimum pulse at 1.0 Vpp, f = 100 kHz|
|Amplitude||not specified||10 mVpp, f = 100 kHz sine wave, 1 second gate time|
I also set up a frequency sweep to see how the DAQ970A would log it. The table below shows the sweep parameters that were set up on the waveform generator.
|Sweep parameter||Keysight 33622A setting|
|Start Frequency||100 Hz|
|Stop Frequency||100 kHz|
|Sweep time||60 s|
|Hold time||0 s|
|Return time||60 s|
The DAQ970A was set up to take a frequency measurement every 5 seconds with a total count of 26 measurements. This would be sufficient to fully capture the 120 s linear frequency sweep from 100 Hz up to 100 kHz and back down to 100 Hz. A linear sweep of 99.9 kHz up in 60 seconds and back down in another 60 seconds should produce steps of about 8.325 kHz every 5 seconds. The image below shows the Scan result.
The general shape looks as would be expected, but how big are each of those steps in frequency? Lets turn on the cursor tool to find out.
The delta Y between reading 7 and 8 on the rising slope of the sweep is 8.31870 kHz with a delta X time difference of 4.996 s. That is in general agreement with the calculation above. There are nice cursor tools available in the DAQ970A, but the screen gets crowded with cursors, readouts, and menu options. Keysight might be trying too hard to squeeze this much information on this size of screen.
The DAQM901A multiplexer module is the only module available form Keysight that supports current measurement (DC and AC). Two channels on the module (channels 21 and 22) provide fused current measurement inputs. I used a Keysight B2902A as a precision DC current source to test current measurement with the DAQ970A. By connecting a pair of wires to Channel 21 in the DAQM901A and configuring the channel to measure DC current, I was able to see how the DAQ responded to various levels of injected current. I ran checks from 500 mA down to 5 pA decreasing by factors of 10 at each step. Because I intended to observe some very small currents I set up the integration time for 100 power line crossings (PLC). This would help smooth out any noise that might creep into the measurements. For each measurement I let the DAQ collect 10 samples and recorded the statistical average determined by the instrument. The results are tabulated below.
|Source current set up on B2902A||Average current measured by DAQ970A (100 NPLC) n=10|
|500 mA||500.0056 mA|
|50 mA||49.99930 mA|
|5 mA||5.000173 mA|
|500 uA||499.9910 uA|
|50 uA||49.99869 uA|
|5 uA||4.999857 uA|
|500 nA||499.9920 nA|
|50 nA||49.9956 nA|
|5 nA||4.9920 nA|
|500 pA||495.9 pA|
|50 pA||46.6 pA|
|5 pA||4.7 pA|
I work in both the electronics engineering world and the electrical engineering world. My colleagues in the electrical engineering world often talk about currents in the thousands or tens of thousands of amps. I have to pause to think about how much current that is because I spend most of my time in the electronics engineering world where currents tend to be a few amps at most and are often orders of magnitude smaller. On the other hand, my electrical engineering colleagues have a hard time fathoming the currents listed in the table above. I have to say, I am impressed first, by the ability of the Keysight B2902A precision source measure unit to accurately generate such small currents, and second, by the ability of the DAQ970A to measure those currents. Other than letting all of the instruments warm up for a few hours and using a long integration time, I didn't take any special steps to measure extremely low currents, yet the instruments performed remarkably well. I have been using test equipment since 1972. My first Micronta VOM was maybe capable of registering 1 uA of current on its most sensitive scale (30 uA full scale). Measurement technology has come a long way in 47 years. Just take a moment to consider that 5 pA is 0.000 000 000 005 A. That amounts to, what, about 31,207,545 electrons/second, assuming an Ampere is 6.2415090744×1018 electrons/second. By the way, I just read that the Ampere was redefined in May of this year. The new definition makes better sense to me than the old definition that involved forces on infinite wires.
A couple of data acquisition exercises
I have satisfied myself that the DAQ970A works really well as a 6 1/2 digit multimeter with a whole bunch of inputs that can be set up to measure a variety of static electronic parameters. The real value in a data acquisition system, however, is in its ability to log multiple measurements over time. In my Road Test application I proposed to use the DAQ970A to log data from sensors that were remotely located to see what issues might arise. I have a detached garden shed on my lot. Long ago I trenched in conduit between the shed and my workshop in the house and pulled two multiconductor cables through. One cable is a CAT 5 network cable, the other is a three pair general purpose intercom cable. There is about 80 feet of cable between my workbench and the garden shed.
Part of my motivation to apply to this Road Test was an interest in using a data acquisition system to support a planned upgrade to a solar PV system installed in my garden shed. I have a small solar PV power system in my garden shed composed of an 85 W PV panel, a PWM charge controller, a 12 V deep cycle lead acid battery, and a 1000 W modified sine inverter. The system provides light in the shed, runs a WiFi security camera, charges battery operated garden tools, and runs my computer controlled telescope on observing nights. The battery is 12 years old and is no longer maintaining sufficient charge through the night. I want to build up the system with the addition of a second 85 W PV panel, replace the PWM charge controller with a Maximum Power Point Transfer (MPPT) controller, switch to pure sine inverter from modified sine inverter, and, of course, replace the 12 year old battery with a new Absorbed Glass Mat (AGM) deep cycle battery. The upgrade project will be shared in a series of blog posts on element14 and I will use the DAQ970A to compare the old and new systems.
Exercise 1: Evaluation of three temperature sensors connected by long cables
This test evaluated remote logging of temperature using three types of temperature sensors (thermocouple, RTD, and thermistor). Because thermocouples generate very low amplitude voltages corresponding to temperature, I did not expect a thermocouple to work well with 80 feet of twisted pair cable jammed between the sensing point and the measuring point. There are noise issues, parasitic resistance issues, and multiple dissimilar metallic junction issues between the sensing and measuring point. However, I set up a test to prove my hypothesis. On a terminal block in the shed I connected a 5k thermistor, a 100 Ohm RTD, and one of the type J thermocouples provided with the Road Test. See the photograph below for the test set up. You will also notice there is a wireless temerature sensor placed adjacent to the terminal block. This sensor acted as a reference to help calibrate the outputs from the sensors under test.
To verify proper connections and to permit calibration prior to starting a log, the DAQ970A was set up initially just to monitor the three sensors. In addition to the wireless temperature sensor sitting next to the three sensors under evaluation, I set up a Fluke 287 logging multimeter with a Type K thermocouple as physically close to the three sensors as possible. My intent was to gather local ground truth data to compare with the remotely acquired data. The receiver for the wireless sensor was placed next to the DAQ. Eighty feet of copper cable running from my lab bench to the senors in the shed adds about 4.5 Ohms of resistance to each sensor circuit. This extra resistance appears in series with the resistance of the RTD and thermistor sensors. Because temperatures is calculated from measured resistance for RTD and thermistor channels in the DAQ, the cable resistance appears as a temperature offset in the DAQ measurement. The DAQ970A provides a set of features under the Math menu that can help compensate for this very condition. In the image below yow can see how a custom offset can be added to each channel using the Math/Offset function. I used this feature to trim each sensor channel to match the reading from the wireless temperature sensor. Offsets can also be set up via a computer using the BenchVue DAQ application.
As mentioned I doubted a thermocouple would work well at this distance. A thermocouple generates a DC voltage proportional to temperature, but the magnitude of the voltage at temperatures encountered in my tests is very low, somewhere in the hundreds of microvolts to a few millivolts. Would such a low voltage survive the journey through 80 feet of unshielded twisted pair that in places, runs parallel to 120 VAC electrical wiring? As a precaution, I set the integration time to 10 Power Line Crossings (PLC) to mitigate the effects of any coupled line frequency noise. Once the offsets were entered, I set up BenchVue to sample and log the sensors readings every 30 seconds, then started the log. All three sensor outputs were steady, which I took as a good sign, but the thermocouple was reading several degrees higher than the other two sensors, even though the offsets I added had nulled out any differences. I thought my concern about the low amplitude thermocouple signal surviving the long cable run was proving to be correct. To further investigate, I took a can of MG Chemical Super Cold 134 to the shed and sprayed all of the sensors until there was a visible layer of frost over the entire array. This action would also mark an obvious spot in the DAQ970A and Fluke 287 logs which would make it easy to align them for comparison. Kind of like using a clapperboard in a movie to sync the sound track. Later I exhaled some hot air onto the sensors to add some interest to an otherwise cool and uneventful afternoon temperature profile. A screen capture of the BenchVue log is on the left below along with the same data set exported to Excel for graphing on the right.
To validate the temperature profile captured by the DAQ970A, examine the profile captured by the Fluke 287 logging multimeter. The data gathered by the Fluke meter was uploaded and formatted using Fluke View forms.
Agreement between the DAQ970A and the Fluke suggests remote sensing can work for the RTDs and the thermistors, however it sure looks like the type J thermocouple did not work at all. After the log was complete I used the Fluke to check the output of the thermocouple locally in the shed. It was outputting the expected voltage and the voltage changed with changes in sensor temperature. By this time I was nearly convinced that a thermocouple can not be remotely monitored using the DAQ970A. Nearly convinced, but not fully convinced. I wondered why the temperature line for the thermocouple was so flat, even when the thermocouple was cold blasted, and why was it offset a few degrees right after I nulled out the offsets.
It took 24 hours for me to realize the error in my experiment. And it was a doozie of an error. An error that I was reluctant to report in this Road Test, but nevertheless will report because it shows the importance of checking everything twice, or more, to make sure that what you THINK you are doing is ACTUALLY what you are doing.
After a night's sleep and a day at work where my brain was kept busy with unrelated thoughts and tasks, I returned to my bench and thought about running one more experiment to verify that the thermocouple in the shed truly could not be measured over long lead lengths. It was then that I glanced down and saw the thermocouple I had set up on my work bench to do my very first operational test on the DAQ970A. That thermocouple was connected to channel 101 on the DAQ. The thermocouple in the shed was connected to channel 104. In that instant I thought, no, I didn't select the thermocouple on my bench along with the RTD and thermistor in the shed . . . or did I? A quick check of the BenchVue log confirmed that indeed, I had logged the thermocouple on my bench along with the RTD and the thermistor in the shed. The old 101, 102, 103 vs. 102, 103, 104 error. You can see the goof up on the BenchVue screen capture above. No wonder the thermocouple line was so flat. No wonder it didn't change when I cold sprayed the sensors in the shed. No wonder it had an offset after I had nulled out the offsets on the shed sensors. Argh!
So, this evening I ran another test of the three temperature sensors in the shed. Same basic experimental plan: Null out the offsets, log all three sensors (this time every 2 seconds) then cold spray the lot and see how they respond. The results are shown below.
This time I cold sprayed the sensors twice. The 2 second sample interval allowed data to be collected much more rapidly so less time would be needed to observe the effect of disturbances on the system. The rise in temperature before the first cold snap is from finger heat as I adjusted the position of the sensors. The second heat bump ahead of the second cold snap is from exhaled breath. The most remarkable outcome of this experiment is that it appears the thermocouple can indeed be read through 80 feet (24.4 m) of unshielded twisted pair. That is encouraging to see, though I am reluctant to jump to a conclusion here. I'd like to know why the three thaw to ambient curves are different. All three sensors were positioned within a few cm of each other and were all blasted with a pretty even dose of cold spray, yet the three thaw to ambient curves are noticeably different. Possible factors to consider include include differences in thermal mass for each sensor. The thermocouple (red trace) I think has the lowest thermal mass. It thawed to ambient faster than the other two sensors. However, the RTD (green trace) has the next lowest mass yet it took the longest to thaw. Humidity was high during the test resulting in a lot of frost and condensation. I speculate that the heat energy needed to evaporate condensation may explain the deviation from the theoretical exponential rise that I have observed hundreds of times during thaw to ambient experiments. I have found the following equation does a good job of generating a first approximation of a thaw to ambient curve:
The Tsensor equation produces a smooth exponential curve that can be tweaked (via the Tau variable) to fit the characteristics of a specific temperature measurement situation. The equation gives the best results I have found when compared to data gathered in a lab environment where ambient temperature, humidity, and air flow are well controlled.
To get a better sense of how the three sensors perform when remotely monitored over a longer time frame, I ran a data acquisition over a day taking samples once a minute. The results show that not everything is as copacetic as indicated by the previous short duration test. See the screen capture of the BenchVue strip chart log for the 24 hour test below.
The blue and green traces are for the 5K thermistor and the 100 Ohm RTD respectively. They track each other rather well over a 24 hour period that runs from 10:00 pm to 10:00 pm. The biggest difference (0.456 degrees C) occurred at the hottest point of the day just before 6:00 pm. The red trace is from the Type J thermocouple. It is obviously not tracking temperature in the shed. I tried various things to see if I could influence the signal. I shorted it at the the DAQ end, I shorted it at the thermocouple end. Neither had any effect. I put a 'scope across the signal at the DAQ end and got the mess shown below.
That is just a bunch of noise. The 80 feet of wire appears to be acting as a honking long noise loving antenna. Any DC voltage impressed across the twisted pair by the thermocouple is swamped by interference. So why did the thermocouple signal seem to arrive in usable shape during the previous freeze spray test? I'm not sure. There is still the possibility of a poor connection at the terminal block in the shed. I'm not going to worry about it for now. The resistance based temperature sensors seem to be far easily to use for remote monitoring. However, if I really wanted to get a remote temperature reading I would likely use a DS1624, an I2C sensor I am very familiar with. I'd connect it to an Arduino or Raspberry Pi then send the temperature back digitally using RS-422/485 protocol.
Exercise 2: Evaluation of remote logging of DC voltages
This next and last evaluation test gets to the heart of why I wanted to Road Test the DAQ970A. There are times when the ability to easily log changes in values over time in one instrument would be helpful. Case in point: I would like to better understand the relationship between the output voltage from a solar PV panel feeding a battery charge controller, and the output voltage of the battery being charged. I would like to have data to allow me to think about several aspects of this system, including the following:
In the following experimental evaluation I remotely acquired DC voltage data from an 85W solar PV panel and a lead acid battery charged by the PV panel through a low cost PWM charge controller. I expected this experiment would not be impacted by the long cable lengths to the DAQ970A because the signals being measured were strong DC voltages. I also left the 100 Ohm RTD temperature sensor installed to obtain an ambient temperature profile
This test involved connecting long lengths of wire to sources capable of delivering high currents. Accidental shorts could allow significant current to flow that could generate a lot of heat, to the point of igniting a fire. To reduce this risk I inserted an inline 2 A fuse in the connection path for the battery and the solar panel at the source end of the circuit. The photo below shows the installation of an inline fuse holder between the solar PV panel and the terminal block leading to the underground conduit..
The illustration below shows the architecture of the legacy system that has been providing service through 12 years of Canadian winters, springs, summers, and autumns without fail. However, the battery capacity is way down and it can not make it through even a short summer night without generating a low volt alarm on the inverter, so I have decided to perform a major system upgrade.
The DAQ970A was set up to log the output voltage from the PV panel, the battery terminal voltage, and the ambient shed temperature. Each channel was sampled once every 30 seconds. The weather during the test was partly sunny with some thin high cloud on the first day, then stormy, overcast and cold on the second day. The strip chart graphic below is annotated to show where AC loads were added or removed. Green is ambient temperature, red is PV panel voltage, and aqua blue is battery voltage. The annotation flag on the left marks the point where the modified sine inverter was turned on with a WiFi camera acting as a load (about 10 W worth). Note that at this point the charging activity increases. Each time the PV panel voltage spikes down represents a point where the charge controller connects the panel to the battery.The annotation flag in the middle marks the point where the modified sine inverter was shut off to prevent an under volt alarm from occurring sometime during the night The annotation flag on the right shows where the inverter and WiFi camera load were switched back on the next day.
The image below zooms in on the area just before and just after the leftmost annotation flag above. This is the point at which the inverter and connected camera load were switched on and the PWM charge controller starts to more frequently connect the PV panel to the battery to recover charge lost to the loads.
A compromise was made when setting up the parameters for the logging mission. I selected an interval of 30 seconds, mostly to conserve relay life in the DAQ970A, but also to provide enough granularity to capture trends and enough detail to reveal system behavior. While the log was being generated I was observing the solar PV panel voltage on the display of the DAQ970A. The instrument display updates quite rapidly, but the strip chart log only records the instantaneous voltage at the moment a sample is taken. The narrow dips in the red trace above could be the consequence of taking instantaneous samples on a signal that is changing frequently between sample intervals. At the instant the sample is taken, the panel voltage could be decreasing toward a lower voltage, or increasing toward a higher voltage. The connect-the-dots graphing approach doesn't allow us to tell. However, it is possible for data acquisition systems to acquire data between sample instances and record things like the maximum and minimum excursions between sample points and when they occurred, as well as the average value between sample points. If the DAQ970A or BenchVue are capable of doing this, I do not know. I could not find these capabilities during the course of this review.
For contrast, the image below is taken from Fluke View Forms from a data acquisition session gathered by a Fluke 287 logging multimeter on the same solar PV system on a June day in 2016. The log is limited to one signal, in this case the battery voltage, however, look at the richness of detail in the data chart. The sample interval on this mission was set to 1/minute and the large graph has been zoomed to a span of a little over a minute from 17:00 to 17:01 with a bit of buffer before and after. I count 16 events that were recorded between 17:00 and 17:01 including the sample at 17:00 and 17:01. Each event includes an arrow to mark when the minimum and maximum occurred, and a line to mark the average voltage within the event. Much deeper and detailed analysis of system behavior can be made with a log that contains this much detail.
If the DAQ970A and BenchVue can't do this, I think it would be great to add these capabilities in the future. If these features are already available, I'd like to have someone show me how to find and use them.
Just one more test before I submit my review, and wait, what is this?...the elapsed time counter on the DAQ970A is not even close to correct?
Here's a thing about me and Road Tests. I develop a test plan as I write my application, then, if I am selected and actually receive the product, the test plan tends to blossom as I learn new things about the product and dream up new tests. So after the battery and panel test described above, I thought I was done with my review and was preparing to do one final edit the next morning before posting. Then I thought I'd just run a simple temperature log over night using the trend chart feature. I like to see plots of ambient temperature over time. Gets me thinking about micro-climates and in the case of the plot I ran last night, gives me some schadenfreude directed at myself for the summer that never came this year.
I set up a trend chart on the RTD temperature sensor in the shed with a 10 NPLC integration time. At 60 Hz, that amounts to an integration time of 166.67 ms per measurement. The measurements would be accumulated on the trend chart as soon as they were available, so there was no specific interval set. I started the log around midnight. In the morning I checked on the trend chart. It looked to be developing as expected, reaching a low just before dawn, then curving upward with the rise of the sun. What did not look correct was the elapsed time. I checked the display around 10 am, so I expected to see about 10 hours of elapsed time. Instead I saw about 5 hours of elapsed time. Closer observation revealed that the elapsed time clock was running at what appeared to be half speed. I took a video clip of the DAQ970A display showing progress on the elapsed time clock and a separate video clip of a stopwatch on my smartphone. I then edited the two together in a side by side comparison video clip. The stopwatch shows about 8.4 seconds passing during the clip. The DAQ970A elapsed time clock shows 4 seconds passing. Something is not right here and it appears to be related to the integration time selected under the channel parameters menu. If I set the integration time to 100 NPLC the elapsed time clock slows down to a snail's crawl. If I set integration time to 0.02 NPLC, the elapsed time clock seems to keep up with real time. This looks like something that could be addressed in a future firmware release. Nudge, nudge, wink, wink.
Combining the DAQ970A with the BenchVue DAQ application did provide insights into the behavior of my current solar PV system. Most beneficial to me was the ability to see PV panel voltage and battery voltage on the same graph. These insights will help me evaluate the changes that arise from the coming upgrade. Greater detail, though of only one signal at at time, was provided by the Fluke 287. Not everyone needs a data acquisition system. If your work presents you with situations where you need to record multiple electronic parameters over a period of time, then a DAQ system makes life easier. The DAQ970A is a useful and well designed instrument that I found easy to use with little need to dig into the instruction manual (though I did have to dig on at least three occasions). I really like the built in help feature that allows the user to get more information about what a button does simply be pressing and holding until a context sensitive help screen pops up. Sometimes the help on the help screen was not very helpful, and this prompted me to dig into the user manual.
Although not part of this product review I made use of BenchVue quite a lot to control the instrument and to set up data logs and view them. BenchVue is a really slick idea, but it crashes a little too often and it can be mind numbingly slow. I mentioned this to Keysight and received back a suggestion to remove NI-VISA. I have not tried this yet, but will. If it makes a difference, I will let you know.
Overall, the Keysight DAQ970A with the DAQM901A 20 channel multiplexer work together to make a fine data acquisition system for typical electronic signals encountered in a good variety of sensor based systems. The issues I ran into are all fixable with firmware updates, I hope. There is nothing I found that points to a fundamental flaw with the system hardware.
Thank you to Keysight for again supporting the element14 Road Test program by offering a classy and valuable piece of test equipment to evaluate. And, thank you to Randall Scasny for all the effort he puts into managing the Road Test program.