# 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.

# Sleep Mode – Timer Setup

Upgraded to wordpress 3.2. Quite painless.

# Setting up the Timer

I received my components from digikey to finish the mesh based data collection prototyping. One of the components is the LTC6991 timer chip. I never soldered surface mount devices before so I did my share of reading up on it. Mine turned out functional but not the best looking. Hats off to those who make it look easy. The IC is TSOT-23 and I purchased a breadboard friendly board to solder it to.

Note US penny is same diameter as Canadian penny.

This chip is awesome and worked flawlessly. The datasheet has all the information and includes a sample-circuit for a self-resetting timer. The vendor also has an excel based calculator to facilitate resistor value calculations. It does not have provisions for the  resistor/capacitor portion self-resetting portion of the circuit. One can refer to the datasheet to get the formulas to compute those. For my experiment, the circuit used from the datasheet is reproduced below.

Solve the above equation for $R_{pw}$ to get

$R_{pw} = \frac{-t_{pulse}}{C_{pw}\cdot ln(1.429/3.3)}$  (1)

where
$C_{pw} = 4.3 nF$
$t_{pulse} = 55 to 56 ms$  I may have to lengthen the pulse duration later.

$R_{pw}$ came to $15.4 M\Omega$  and I had a couple of $7.68 M\Omega$ 1% resistors available. Close enough.

The rest of the components values where calculated from the the vendor tool.

$R_{set}= 118k\Omega \approx 120k\Omega$
$R1 = 392k\Omega$
$R2 = 1M\Omega$

I wanted a period of 10 seconds and active low. That is a very high duty cycle that you would not get with a 555 timer. The final solution will have around 5 minutes between pulses but for testing purposes, 10 seconds is easier.

The output from the scope below shows (click on it for zoom). The period is 10.1s.

The pulse came in at 57ms as shown below.

Now time to move on to setup the arduino and Xbee integration.

# Sleep Mode

I opted for hardware driven sleep mode (SM=1) in the XBee. I felt that that cyclic sleep mode (SM=4) to be a pain to setup. I felt that that keeping the XBee asleep for extended durations, the device would be MIA from host. With a hardware based sleep, I could use a swith to to force  it awake, configure remotely with the software tool I wrote, flick the switch back to the timer based sleep. Simple in my mind.

The tested scenario is illustrated below and it worked as planned. The XBee would be taken out of sleep for 30 ms and back to sleep for 100 seconds. As stated earlier, the power consumption does not lend itself to using batteries.

I found this link for an alternative to the 555 and will look into it.  I would also not require a level shifter and can operate from a single 3.3 battery. This would surely extend the battery life as it would remove the dependency on the 78L33 and 555.  Now I just need to deal with the LM35 and other sensors and I think I have a way to deal with that and that is to keep them “offline” when sleeping. More experimentation.

# xBee, Debugging, et al

## Relatively Easy

I’ve been busy with work and never have the time to get back to this project. Anyway, I penciled in a few hours to wire up the xBee transmitter/receiver to the arduino. The xBee explorer is a time saver. What I wanted to do is to program the arduino over wireless as well. Given that time is limited, I opted to just send data over wireless to simplify connectivity.

The xBee explorer had 4 connection points that made it easy to hookup:

• +5 to arduino +5
• gnd to arduino ground
• dout to rx (pin 1 of ardiuino)
• din to tx (pint 2 of arduino)

That is pretty all that is required to wire up the xbee. The explorer takes care of the 5v to 3.3v level shifting.  Remember I am using the Duemilanove as the reference board. Note that you can’t plug in the USB in the Duemilanove and xBee in the explorer at the same time. The two will conflict with each other. This is rather trivial to hook up so no wiring diagram other than pin connection mapping is provided.

On the host side, I used the USB explorer which is basically leads to a plug and play model which I like.  Rather than regurgitate xBee configuration, I found that it is well explained here. (Xbee Configuration tutorial)  I tweaked the PAN, Baud rate, and type. I made the host a coordinator and the slave device a routing type. Again, explained well in the tutorial.

Just like the other parts of this project, I found soldering and wiring it up the hardest. I used left over wire wrap wires (I think the stuff is 20 years old) to connect things. I don’t wire wrap them and still solder. I like it because it is not tot bulky. It does break easy though.   Anyway, I have a renewed appreciation for those who package hardware. Although mine works, only a mother could love the way it looks. Alas, it is for my own use so prototype mode is good enough.

## Current Transformer Revisited

I revisited the current transformer wiring in the context of safety. Rather than use terminal blocks, I should have used simple audio jacks to simplify the wiring. Either way, there was a safety issue that loomed in the back of my head and I wanted to address it before wiring the sensors to the power mains. The secondary in an open circuit mode of a transformer (not connected to anything) can reach a high voltage and should it come in contact to a person, guess who is going to be the resistor for that voltage to close the circuit. You.  It does not take much to kill you.

What I did was add a switch that shunts (shorts) the secondary of the transformer that I flip to “field work mode” before handling the terminals.  This is not like shorting a 120 AC line. The voltage on the secondary is the function of the reflection of the impedance on the primary. This can get mathematical so I will spare the math. Suffice it to say that shunting the secondary won’t hurt the current transformer and will add another level of safety.