Another energy monitoring solution using Zeus

We just completed another installation of Zeus (our IoT monitoring/control system)  in a commercial building to collect and report electrical energy consumption.

Zeus - Wattnode

Wattnode device

In this installation, we connected Zeus to a Wattnode Pulse watt-hour transducer (shown above).  The Wattnode Pulse clamps onto the main power line and reads the killiwatts used, converting this data into a pulse output.  Using custom software on Zeus, we were able to read the output from the Wattnode device, format the data, and send it to the cloud via our builtin WiFi radio.  From there, the data can be analyzed, reported, and/or consolidated with other energy data for this particular building.

For a relatively low cost, the owners of this building are now monitoring their energy usage and can take steps to reduce their overall energy usage.

Navdive for research

I’ve been a volunteer diver for a number of years at Maritime Heritage Minnesota (MHM), a marine archeology firm here in the Twin Cities doing underwater survey work in the state,  Over the past few years, we have been working at Lake Minnetonka to search for sunken wrecks and determine what they are and how they got on the bottom.

We’ve used Navdive (our GPS-based navigation system for divers) on many of our survey dives, including yesterday when we spotted a possible wreck on our surface-based side scan sonar in the dive boat.

NavDive unit

With Navdive, we were able to:

  1. Preprogram GPS coordinates that were obtained using the side scan sonar on the boat, allowing the diver to navigate to each point while remaining underwater.

Sonar image

2.  Capture GPS coordinates of underwater features that are discovered during the dive for cataloging later.

3. During the post dive analysis, we were able to show the path our divers swam during the entire dive.

NavDIve dive trace

The results?  More efficient use of our underwater time, better data for our research, and the ability to integrate all of our data sources (i.e. surface-based side scan sonar, Navdive data, and Google Earth) to produce reports documenting our findings.

For more info on Navdive, see our web site here.

Using Zeus to monitor energy usage

We’ve just recently completed an installation of several of our Zeus Monitor / Control systems in a commercial building setting in which the owners were interested in tracking energy consumption.  Our engineering team created a custom hardware and software interface for our Zeus unit that connects to E-Mon Class 2000 Sub meters, allowing for the real time collection of electrical energy usage within the facility at the panel and transmission of this data to the cloud via WiFi.  Once in the cloud, the data can be used to track real time energy use, to provide alerts of abnormal energy consumption, and to show historical data on demand.


ScreenHunter_01 May. 13 13.20

“This is a great example that showcases the capability of our Zeus monitor”, commented Kelly Nehowig, President and CTO of Applied Logic Engineering, Inc.  “With this system, we are able to capture energy consumption data in real time and make it available to the client at a very affordable price.”

We’re happy to be partnering with Energy Resource Products and with Grovestreams on this project.

Control multiple Sony DSLR cameras

We are testing a new configuration using our ALE718 Multi Camera LANC Controller with an adapter cable that converts the standard 2.5mm LANC plug into the mini “USB” plug that is compatible with the new Sony MULTI jack connector.

This new configuration allows for the remote control of recording (stop/start) as well as the shutter for photos.  Using this with our multi-camera controller, you can now sync the shutter or video recording of multiple cameras easily.

Almost a record ice out

First dive for 2016 in Lake Minnetonka today.


The ice went out in the middle of last week — almost an all time record for the earliest ice out in this Minnesota lake.  I did have to dive in Wayzata Bay today — St. Louis Bay was still covered in ice.

Water temp was right at 32 degrees, but great visibility.

The season has started!

The Internet of Things is not a smartphone app


Recently, I’ve noticed an interesting trend in product introductions in the Internet of Things (IoT) space.   There seems to be a lot of manufacturers that want you to believe that wirelessly controlling a device by a smartphone app is “the Internet of Things”. Well of course it depends on your definition of the IoT, but simple control of a device via Bluetooth from a smartphone app doesn’t really qualify as an IoT solution to me.

In my opinion, to qualify as an IoT “product”, the product needs to:

  • Be a device that is collecting data and optionally controlling a remote device
  • Have the ability to communicate the data collected to the cloud
  • Have the ability to perform data analytics on the aggregation of the data collected to derive new value

To illustrate the difference between simple local control and a true IoT application, consider the example of a device designed to turn a light bulb on or off from your smartphone. Aside from it being pretty cumbersome to do (start the app on your phone, select the right screen, scroll to find your particular light bulb, then tap to turn it on — I think I’ll just go flip the switch on the wall), simple controllers do not make use of other devices that might work in concert with the light bulb controller — say a motion detector. A more sophisticated light bulb controller that worked in conjunction with a motion detector by passing messages over the local area network could automatically trigger the light bulb controller to turn the light on when someone entered the room. No clunky smartphone interaction is required. By having the ability to have separate devices work together, the process is simplified and much more useful.

Next — consider the integration of a cloud-based server that can communicate with the light bulb controller. By sending the device’s status to a server, I can track when the device is on or off from the cloud. Now imagine that I do this for every light bulb (or any other appliance) in my home.   I now have data available that shows the state of all of my devices in real time and data that shows how each device is utilized over any time interval that I choose. I also gain the ability to control my device from the cloud — I no longer need to be within Bluetooth proximity to control my lights — I can do it from virtually anywhere that I have an Internet connection. This gives me additional capability to create cloud-based software to set up a schedule when I want specific lights to go on or off in my home automatically. Again – no smartphone app required.

Lastly, after accumulating light bulb data over time, I can now look at it as an aggregation and derive important and valuable information from it. For example, I can track my overall energy usage over a day, month, or year. I can tell if a bulb is burned out (i.e. if it is not consuming electrical current) and needs replacement.   I can combine my lighting control data with data from other systems to provide a comprehensive picture of my home or office energy usage / savings.

If I am the light bulb controller’s manufacturer, I can use the data accumulated in the cloud to determine how my customer is using my product (how often, how many times, at what times, etc.). I can also derive quality information about all of my devices in the field — time between failures, most common failure, etc. The data allows me to understand my market and use this knowledge to create better products and more compelling solutions to stay ahead of the competition.

In our small example of the light bulb controller, you can see the value of not only controlling your devices locally, but the additional value of combining the function of the controller with other devices, the value of interacting with your device via the cloud and using data analytics on that data to derive new value. Thinking beyond simple light bulb controllers, imagine applying this same mind set to IoT solutions for factory floors, agricultural applications, transportation, oil/gas rigs, medical, home automation, and any other industry that involves process control.

Now that is the Internet of Things.

Real world wireless communication for the Internet of Things


When implementing an “Internet of Things” (IoT) solution, an important consideration is the wireless technology(ies) that will be employed to get data from your devices (sensors, gateways, etc.) to the cloud. As with most technologies, there is a confusing array of options — each with its strengths and weaknesses depending on the specific application.

Frequently the discussion around wireless technologies centers around specs, throughput, standards, etc., but what is really needed is a practical guide to implementation for specific applications.   Based on our experience in the field deployments we have made, we would like to share some of our thoughts regarding the current state of wireless technology for IoT.

Before the Tech Talk

Before getting into the bits and bytes of any particular communication standard, consider the following factors and decide on the characteristics of your device and its deployment:

  • Will my device be stationary or mobile?
  • Is there a power source that can be utilized for the device or will my device rely on its own power?
  • What is the range necessary to transmit / receive data to and from the device?
  • How often will my device need to communicate to the cloud?
  • What is the volume of data that will be sent?

These factors will be important as you decide on a communication technology for your system. As we will discuss, each form of wireless communication has specific attributes that may either make it a preferred choice or that may disqualify it from your selection process.

Some common wireless communication technologies to consider

We’ve captured a few of the most popular wireless communication technologies used in IoT deployments below along with some useful information to help during the selection process:

  • BLE — which stands for Bluetooth Low Energy. Also known as Bluetooth 4.0, BLE is useful for short haul communication (usually less than 100m) between devices. It has a moderately high data throughput rate and is deployed frequently in battery operated applications due to its low power requirements. It is really a “point to point” communication scheme between devices without networking capability.

Some other key points regarding BLE:

  • Every modern smartphone has BLE compatible radios and software stacks, making communication between your device and a smartphone relatively easy to implement.
  • Bluetooth technology is evolving quickly and specifications change accordingly, making backwards compatibility a potential issue for your device.
  • BLE can be implemented in an embedded design for < $5 in quantity
  • Not really well suited for direct communication to the cloud as it does not support HTTP for REST interfaces. It typically requires a gateway that can transfer data on the BLE side to a HTTP communication path (typically Ethernet or WiFi).       We have used smartphones as gateways for this purpose.
  • Zigbee —  is a radio technology used to create personal area networks and is very useful in certain IoT deployments.   Zigbee is also a short haul communication scheme, but has the additional benefit of being able to operate in a “mesh” network in which all Zigbee nodes can pass messages between other nodes, effectively increasing the distance that can be covered. This is useful in multi-point deployments where you may have multiple sensors distributed in a concentrated area (i.e. manufacturing floors, home automation, etc.).

Some other considerations for Zigbee:

  • Typically Zigbee is very power friendly, with low stand-by current draw and relatively low power consumption during transmission.       This makes it suitable for battery powered devices.
  • Zigbee has found a following over the past few years, particularly with home automation OEMs.
  • Data throughout is modest (up to 250k bits/sec)
  • Secured via 128-bit encryption keys.
  • WiFi — started as a wireless extension of Ethernet for computer networking. It was widely adapted in the consumer and industrial spaces and has become the standard for networking PCs, tablets, notebooks, and associated peripherals. It has extremely high data throughput — however this comes at the expense of its power requirements. Range typically is up to 100m, however this can be extended with specific antenna types.

Some other key points regarding WiFi:

  • Ubiquitous
  • Universal smartphone compatibility
  • Affordable — can be implemented in an embedded design for < $5 and frequently the connection to the Internet can be obtained for free
  • Well suited to communicate through the Internet to a cloud server — universally supports TCP/IP and HTTP to provide REST interfaces to cloud services
  • Well protected and controlled from a security standpoint
  • Relatively high power usage
  • Sometimes difficult to connect IoT devices to corporate IT infrastructure because of corporate policies on security.
  • Cellular — utilizing a network established initially for voice communication, cellular offers a wide bandwidth data capability that does not depend on local access points or routers. Its range therefore is virtually limitless (as long as you are in an area covered by cellular coverage).   However, you will pay for each byte transmitted / received with this technology and of all of the technologies discussed, it has the highest requirement for power consumption during transmission.

Some additional points regarding cellular:

  • Cellular benefits from security models already established for regular voice communication
  • This is the only technology discussed that charges per byte of data transmitted or received. While these rates have come down recently (and will continue to do so), it may be a factor in your deployment
  • Network coverage can be an issue is specific deployments — especially indoors on factory floors, etc.
  • Power consumption is high, especially during data transmission.       However, if your device has a power source readily available, this may not be an issue
  • Device cost is the highest in terms of the devices discussed here — typically $20 in volume. This price will come down as higher volumes of these devices are manufactured for IoT applications.
  • Other
    • A ton of other “standards” in the Low Power Wide Area Network (LPWAN) arena are beginning to surface — including SigFox, Dash 7 Alliance Protocol, LoRaWAN, nWave, Weightless-P and Weightless-N, IEEE 802.11ah, and LTE Cat-M. These standards are emerging as a direct result of needs in machine-to-machine communication.
    • Some of these new standards have started to gain traction, particularly in specific industry segments.
    • Estimates show that today the cost of a typical module ranges from about $5 to $20, depending on the specific technology. However, the cost per module will eventually fall below one to two dollars in volume quantities.

So in summary, selecting a wireless communication technology for your IoT deployment requires careful consideration of a number of factors.   It is critical to understand where your device deployment will happen, what your data requirements are, and how the devices will operate after deployment.   Power is always a consideration, as is the overall cost of the device itself and the costs associated with on-going support.

We’ve seen IoT wireless communication projects suffer due to the mismatch of actual needs versus the technology chosen — spending the appropriate amount of time and energy on this decision will avoid expensive redesign / rework after the fact.