Energy Harvester Telemetry

Everything becomes networked

Development focus is very important in order to prevent scope creep, however it does not hurt to look a bit further in the future to try to see how things evolve. Our development track for the energy harvester is progressing nicely, but what will be next? We think that information sharing and remote control of the ‘harvesting’ process is very important. “Everything becomes networked” is a slogan one hears quite often:

“Remote telemetry is the highly automated communications process by which measurements are made and other data collected at remote (…) points and transmitted to receiving equipment for monitoring.”

Furthermore, it would be nice to measure and track produced solar and wind energy, and get an idea about how much energy is dumped into the batteries, and how much excess energy is burned in the dump load setup. Do not forget about logging the wind speed and direction, the hours of sunshine at the site, the temperature and so on…

The “energy harvester” is about hard real-time control.

“Energy harvester telemetry” is about

• information gathering and sharing, plus
• coarse soft real-time (e.g. run, limit or shutdown) control and maintenance.

Both “harvester” and “telemetry” are complementary, but of course only “energy harvesting” can be used standalone in this context.

Before we attempt to list exhaustive requirements, again we will need to investigate the possibilities and do some prototype tryouts. We are already ‘certain’ of the following telemetry-must-haves:
It needs

• sensor input.
• control output.
• bidirectional communication with the “energy harvester(s)”.
• to be networked (wired or wireless?) in order to be remotely accessible.

And of course, it needs to be cost effective, as usual.

Prototype means

We must admit – that in this case – we are not sure whether we picked our first prototype subject to match our “Energy harvester telemetry” project extension, or that we looked for a project that could be prototyped with our prototype subject… 🙂
We always wanted to do something with the new Beaglebone Black Development Board, because it looks like it is an awesome piece of hardware for its price.

We will be doing some Linux “hacking”, iow development and prototyping on this board. Maybe, we will use Debian to run on the board, but we have not decided yet:
More boards have been ordered and we eagerly await their arrival.

First tests

We already got our hands on a single “Beaglebone black” board, and we gave it a quick spin mainly following the quick-start guide.
We made a USB connection with our Ubuntu machine and the Beaglebone, and we almost instantly (after 10 seconds) got a second network interface and an additional mass storage device. Unfortunately, it seemed impossible to read files directly from this *newly* mounted disk, but we were able to browse to the http://192.168.7.2 address. There we found more information about the board itself. Secure shell (ssh) was also working and we could login with root credentials.

We then wondered how difficult it would be to install Debian. More information about that can be found here. The network install was not a success, since we did not setup the serial connection yet and we lacked a HDMI connection – so no screen. However, other people have already prepared full demo versions . And so, the install of the Debian 7 (wheezy) demo image on a separate micro SD was fast and easy. The Debian image boot takes longer and it takes also longer before the mass storage device appears, but we could also login via emulated network on usb (ssh) with the same fixed IP (192.168.7.2). DHCP on the Beaglebone ethernet port gave us access to the Debian repos for the apt-get stuff. That at least seems like a good start.