Wireless sensor network for the monitoring of Natural Gas, Carbon Monoxide, Temperature, Humidity, Vibration, and even Seismic Activity
<iframe src="//www.youtube.com/embed/MYk3JprRa4g" height="360" width="640" allowfullscreen="" frameborder="0"></iframe>
Previously I wrote about the bring-up of the MRF49XA Shield. Recall that instead of the standard FSK spectrum I was met with an asymmetric comb about the carrier.
Decreasing the span we see are able to measure the comb spacing, about 80kHz.
When viewed in this way, we see more of a traditional harmonic series from the carrier. I'll assume for now that the series is not an odd function; the waveform is not square or compressed. Typically symmetric sidebands that reside xdBc from the carrier are indicative of A.M. distortion. I'll also chalk up the asymmetry seen in at wider bandwidths is due to heterodyning.
The first place I like to look when experiencing undesired A.M. spurs is the power supply.
Setting the DMM to AC mode and turning on the frequency counter, I find a dominant 78kHz AC component on my 3V3 supply.
That's close enough for me to be a smoking gun. A bypass capacitor is placed near the MRF49XA supply...
And the major sidebands are gone. We can still see spurs about 35dBc at 200kHz; for now I'll assume they are Frac-N PLL spurs and move forward.
In parallel with the SafeSense sensor node, I also spun a MRF49XA transceiver shield to aid in development. It is also intended to mate with an Arduino Yun for basestation development.
Detailed Video at the end of the post.
Assembly was simple enough, no issues found upon bringup. The one issue is that the board can only mate with 3V3 devices, like the ChipKit Uno32.
The first task was to test SPI communications between the Arduino variant and the MRF49XA. I developed an offshoot of the command line interpreter Fruitshell named Ubashell that allows for individual SPI transactions. This allows the register space for the target to be accessed and configured without having to go through multiple software development and compile cycles. It also enables the use of scripts once a configuration is decided upon. These scripts then are ported to the final application.
After reviewing the data sheet and experimentation in Ubashell, I was able to enable the transmitter and observe a CW tone at the expected frequency on SDR#.
Further experimentation allowed be to vary the TX power, frequency, modulation rate, etc.
Unfortunately I noticed a large comb when observe the waveform from a wider span. As this is not a proper FSK response, troubleshooting will be needed.
Bringup on the SafeSense Environmental Monitor kicked off this weekend with the installation of the power supply and AVR sections of the board. While the power supplies came up, programming the Arduino bootloader on the ATMEGA328P-AU (surface mount) could not have gone worse.
Arduino Uno as AVR Programmer, SafeSense ATMEGA328P-AU as target, powered by Arduino Uno ISP.
Immediately I was met with the following response: “Expected signature for ATMEGA328P is 1E 95 0F”
Apparently I should check the chip of use the -F option to override. I don’t believe I have access to the AVRDUDE backbone thus the -F option is not available to me.
I’m not completely convinced that the AVR chip is communicating back to the programmer. I need a method of verification and I don’t have a high speed oscilloscope in my lab.
In the capture pictured above, we see the following (top down):
PB0: “Error – Lights up if something goes wrong”
PB1: “Heartbeat – shows the programmer is running”
PB2: Slave Reset
PB5: SCK (Not pictured, used to clock analyzer)
1. The good news is PB4 (MISO) is in motion, thus the SafeSense AVR is talking back.
2. PB0 is flat, thus no error.
3. Slave resets twice
That’s pretty much where I have left off. I’ll do more research on the subject, in the interim I have purchased an AVR ISP from Atmel. Also, to move the project forward, I have purchased ATMEGA328P-AU’s from The Custom Geek with the bootloader pre-loaded. This is to help meet development milestones in a timely fashion while continuing to look into the bootloader issue in parallel.
It’s amazing how something so simple can consume so much of a weekend. Sometimes spending a little more for professional tools will payoff in the time they save.
I thought I smelled gas coming from my fireplace one evening. After inspection I was assured there was not an issue and the smell was aging pipes. The experience led me to the realization however that there was no natural gas monitoring in my home. A few block diagram iterations later and I had designed a wireless sensor node with the following requirements:
1. Monitor natural gas *
2. Monitor carbon monoxide **
3. Temperature and humidity monitoring for sensor calibration and temp gradient measurements
4. Report measurements wirelessly, 915MHz ISM band (chosen for range, low data bandwidth, and antenna requirements)
5. Optional vibration sensor (for significant earthquake event reporting)
6. Optional geophone sensor (for minor earthquake event reporting)
MRF49XA-I/ST: 415/915MHz XCVR chip from Microchip. Selected for cost, range, modulation diversity, spectral occupancy. Although wireless standards already exist (X-Bee) I will be developing a protocol for multiple node integration with low interference.
CC2D33S: For temperature and humidity monitoring at each node; calibration of gas sensors.
The prototype PCB arrived last weekend, bring-up to occur in the following sequence:
1. Power supplies (passed)
2. AVR (wip)
3. Natural gas sensor (already prototyped)
4. Wireless XCVR
5. Base Station XCVR (Prototype = Arduino Yun with MRF49XA Shield I also fabbed)
5. Temperature/Humidty Sensor
6. Calibration Curves
7. Remainder of sensors as deemed necessary
In all the project is more to satisfy curiosity and creative urges. Moreover it is an exercise in sensor integration, coordination of wireless nodes on one frequency, and handling of data/metrics from multiple nodes and creating trends, warnings, etc. The central hub of the network is TBD, however it will feature a 915MHz ISM XCVR as well and an Ethernet interface.
* Not intended to replace regular servicing and maintenance of gas-based appliances; simply an additional safety monitor
** Does not replace CO monitor required by CA-law for each level of the home