Pin Sleep Xbee with Arduino Host

Making it work.

I got everything to function with a rather messy board setup as shown below.

The output from the Arduino shows the delta T between messages received from the end-devices.  It is pretty close to the calculated ones. I will change the duration to be 15 minutes later on but for debugging purposes 10s intervals for pin sleep is tolerable.

 Code

The following are the libraries were referenced.

Arduino library for communicating with XBees in API mode – I used both Java and C++ versions for this.

Standard Template library (STL) for AVR – I wanted some maps and other stuff in the dev environment.

Streaming C++ style Output – print and println gets to be a pain after a while

Ardunio Modbus Slave - I used this for my energy monitoring project as well and hacked in a modbus function 6. Since then, a new library that includes function 6 has been deployed, but I still used the older version as I wrapped the C++ class – SerialModbusSlave and did not feel like manually merging code.

 HardwareSerial

I leveraged the serial ports available in the Mega2560 and created global variables to reference instances of the serial port as follows:

Which allowed me to do things like the following:

I can change ports around in one spot in the code rather than find an replace things.

I opted to over design things a bit as I wanted to avoid changing the code later on as tacit information tends to be forgotten over time. What I wanted to do is be able to provision new end devices without changing the arduino code and follow a simple 4 step process:

  1. update to appropriate firmware in XBee, set Pan ID, and API mode 2
  2. utilize the home grown Java app to set up the details such as IO types and lines  ( I am thinking of adding a clone function to make this even simpler)
  3. wire up xbee related circuitry
  4. provision the end device in the Arduino via Mango HMI over Modbus

The following illustrates the concept in a non-formal way of describing software. When a ioresponse is received from an end device I look up the corresponding meshdevice entry in map using the string representation of the address64. I was thinking of using int64_t  type rather than a string as the string takes more space but that is not at a premium at this point.

The address64 string for managed end devices are stored in eeprom and loaded on setup(). Provisioning of end devices are sent over modbus from the HMI host and written to eeprom as well. Yes overkill, but t I want to evolve the system and focus on some abstraction to allow the evolution the meshdevice representation. All the smarts to evolve will be confined in one class. The tacit information like how to provision and communicate with the HMI, etc. will hopefilly remain static.

Map of Meshdevices

A map of using the STL for AVR to reference the MeshDevice is as follows:

And updating meshdevices is coded as follows and will change later on as the error handling is uber weak.

Modbus Register Buffer

Lastly the mapping to modbus style registers are set up as clusters for each device and terminated with a set of register to accept commands and address64 strings from the host. The code for it is rather simple and I will shoehorn this later on. Up to 13 discrete (digital) and 5 analog I/O are reserved for each device. What is used depends on how the XBee device is configured which is explained in the XBee datasheet 90000976_D Datasheet

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The prototype basically implemented the following data flow model. The issue for me is battery powered end device is not green enough of a solution for me.  I’m thinking of exploring energy harvesting to help things along. The plan was to also send battery voltage level on the end device to the SCADA host to generate low battery alarms. Still, it would be nicer to tap into ambient environment (vibration, etc) to generate energy to help power the end device. This will be explored later.

Host Software

Rather than re-invent the wheel, I thought there should be software out there that provides SCADA/HMI functionality for free. It is a commoditized activity by now.  After combing the web, I stumbled and settled on Mango, an open-source M2M solution. Mango is Java based that integrates with MySQL and runs under Apache. All good stuff so far.  The web site describes the features and how to install the software.  I liked the data historian, alarms, and the various types data points including calling external web based sources. I set one to get the external temperature at the airport and using regex to scrape of the temperature form the HTML. All within Mango.

I found it relatively easy to get going. One thing I had to do was write a Modbus function 6 (write a single register) for the Arduino in C as I want to send commands to the arduino. i.e. set the time for example.

The diagram below shows some of the points I configured to handle the home energy monitoring. I used ISA motivated nomenclature to name the tags. I may revert to a human readable tags as I won’t have hundreds of points and becomes cryptic after a while.

mango3

Data logging for each data point is configurable as shown in the screen shot below. The example is for the temperature in the basement. All of this info is in the MySQL database from which one can chose to slice and dice the data later on using external tools.

mango5

As for graphical objects, one can create custom objects e.g. dials, meters, etc. and assign tags to them. When this is all done I will add an iPhone friendly UI to this so I can interact with the home energy system on the road. One thing that Mango does is allow me to work on my solution rather than re-inventing the wheel.  I know have the facility to hook up multiple ardduinos and focus on the fun stuff which is the embedded side of things.

Prototyping – Part II

There is not much to this. A protoshield, the arduino, and a breadboard. Note the current transformer (donut). I have two of those to use in the panel.

IMG_1426

The first test was to plugging in a 60 W lamp to see what the measurement came too. I expected around 0.5 Amps and 60 watts. I was not disappointed.  I proceeded to plug in a toaster and put the ammeter in the circuit to see if my RMS current matched its RMS measurement. The photo below shows a .4% error. Not bad. Note the drop in the line voltage.

In Canada, the nominal line voltage is 120Vrms. I do measure the voltage as part of my power calculations and when I saw the 113 V I checked with the multi-meter and it read the same.  Assuming a 120 V reference would lead to errors in the power calculations. I should not be running a toaster outside my 20Amp line in the kitchen. I created a suicide cord that threads through the current transformer and is basically an extension cord. It plugs into a 15Amp line with other loads. 120 down to 113 is just over a 5% difference from the nominal line voltage. I am trying to rationalize why such a large dip. Anyway, the power measurement works.

IMG_1421

Crest Factor

The crest factor is the the ratio between peak and RMS signals. I do compute that and it gives me an idea on the shape of the waveform. A sinewave should have a crest factor of \sqrt{2} . The 60 W lightbulb had a crest factor of 1.40 for the voltage 1.40 for the current. Close enough.

I plugged in a variable speed drill and ran it a low RPM. As expected, the power factor went down to .27 with most of the power becoming reactive at 104 vars. The real power was just a mere 29.5 watts. The crest factor for the voltage was 1.39 and for the current, 3.96. That is expected as the duty cycle is changed to control the speed. For us home owners, we get charged for the real power consumed.  In industrial environments, the power company would penalize you for running with such an awful power factor.

I can’t wait to plug all this in the main panel see what the overall power consumption profile is. I expect the power factor to be closer to one.

Next Steps

Computing C02 emissions is trivial as well as projecting cost of power usage.  I would like to have that wired next to the power panel and displayed on the LCD sooner than later.  On the other hand, I need figure out the zigbee side of things as well as how to best do the data logging.  I can easily purchase another arduino later and focus on getting this prototype soldered on something more permanent.