Computing stuff tied to the physical world

It’s time for real-time

In Software on May 23, 2013 at 00:01

For some time, I’ve been doodling around with various open-source Real-time operating system (RTOS) options out there. There are quite a few to get lost in…

But first, what is an RTOS, and why would you want one?

The RTOS is code which can manage multiple tasks in a computer. You can see what it does by considering what sort of code you’d write if you wanted to periodically read out some sensors, not necessarily all at the same time or equally often. Then, perhaps you want to respond to external events such as a button press of a PIR sensor firing, and let’s also try and report this on the serial port and throw in a command-line configuration interface on that same serial port…

Oh, and in between, let’s go into a low-power mode to save energy.

Such code can be written without RTOS, in fact that’s what I did with a (simpler) example for the roomNode sketch. But it gets tricky, and everything can become a huge tangle of variables, loops, conditions, and before you know it … you end up with spaghetti!

In short, the problem is blocking code – when you write something like this, for example:


void setup () {}

void loop () {
  digitalWrite(LED, HIGH);
  delay(100);
  digitalWrite(LED, LOW);
  delay(900);
}

The delay() calls will put the processor into a busy loop for as long as needed to make the requested number of milliseconds pass. And while this is the case, nothing else can be done by the processor, other than handling hardware interrupts (such as timer ticks).

What if you wanted to respond to button presses? Or make a second LED blink at a different rate at the same time? Or respond to commands on the serial port?

This is why I added a MilliTimer class to JeeLib early on. Let’s rewrite the code:


MilliTimer ledTimer;
bool ledOn;;

void setup () {
  leadTimer.set(1); // start the timer
}

void loop () {
  if (ledTimer.poll()) {
    if (ledOn) {
      digitalWrite(LED, LOW);
      ledTimer.set(900);
    } else {
      digitalWrite(LED, HIGH);
      ledTimer.set(100);
    }
    ledOn = ! ledOn;
  }
  // anything ...
}

It’s a bit more code, but the point is that this implementation is no longer blocking: instead of stopping on a delay() call, we now track the progress of time through the MilliTimer, we keep track of the LED state, and we adjust the time to wait for the next change.

As a result, the comment line at the end gets “executed” all the time, and this is where we can now perform other tasks while the LED is blinking in the background, so to speak.

You can get a lot done this way, but things do tend to become more complicated. The simple flow of each separate activity starts to become a mix of convoluted flows.

With a RTOS, you can create several tasks which appear to all run in parallel. You don’t call delay(), but you tell the RTOS to suspend your task for a certain amount of time (or until a certain event happens, which is the real magic sauce of RTOS’es, actually).

So in pseudo code, we can now write our app as:

  TASK 1:
    turn LED on
    wait 100 ms
    turn LED off
    wait 900 ms
    repeat

  MAIN:
    start task 1
    do other stuff (including starting more tasks)

All the logic related to making the LED blink has been moved “out of the way”.

Tomorrow I’ll expand on this, using an RTOS which works fine in the Arduino IDE.

What if the sun doesn’t shine?

In Musings on May 22, 2013 at 00:01

Welcome to the weekly What-If series, also available via the Café wiki.

Slightly different question this time – not so much about investigating, but about coming up with some ideas. Because, now that solar energy is being collected here at JeeLabs and winter is over, there’s a fairly obvious pattern appearing:

Screen Shot 2013-05-14 at 12.47.42

Surplus solar energy during the day, but none in the evenings and at night for cooking + lighting (it looks like the heater is still kicking in at the end of the day, BTW).

This particular example shows that the amount of surplus energy would be more or less what’s needed in the evening – if only there were a way to store this energy for 6 hours…

Looking at some counters over that same period, I can see that the amount of energy is about 2.5 kWh. The challenge is to store this amount of energy locally. Some thoughts:

  • A 12 V lead-acid battery could be used, with 2.5 kWh corresponding to some 208 Ah.
  • But that’s a lower bound: let’s assume 90% conversion efficiency in both directions, i.e. 81% for charge + discharge (i.e. 19% losses) – we’ll now need a 257 Ah battery.
  • But the lifetime of lead-acid batteries is only good if you don’t discharge them too far. So-called deep cycle batteries are designed specifically for cases like these, where the charge/discharge is going to happen day in day out. To use them optimally, you shouldn’t discharge them over 50%, so we’ll need a battery twice as large: 514 Ah.

Let’s see… three of these 12V 230 Ah units could easily do the job:

Screen Shot 2013-05-14 at 13.14.23

Note that the cost of the batteries alone will be €2,000 and their total weight 200 kg!

There’s an interesting article about the energy shortage after the Fukushima disaster, including a good diagram about a somewhat similar issue (lowering evening peak use):

2-large-fighting-blackouts-japan-residential-pv-and-energy-storage-market-flourishing

Although driven by a much harsher reality in that article, I wouldn’t be surprised to see new “one-day storage” solutions come out of all this, usable in the rest of the world as well.

For winter-time, I suppose one could heat up a large water tank, and then re-use it for heating in the evening. Except, ehm, that there’s a lot less surplus energy in winter.

Are there any other viable “semi off-grid” options out there? A flywheel in the basement?

PS. New milestone reached yesterday: total solar production so far has caught up with the consumption here at JeeLabs during that same period (since end October, that is).

MPPT hunting

In Hardware on May 21, 2013 at 00:01

Solar panels are funny power sources: for each panel, if you draw no power, the voltage will rise to 15..40 V (depending on the type of panel), and when you short them out, a current of 5..12 A will flow (again, depending on type). My panels will do 30V @ 8A.

Note that in both cases just described, the power output will be zero: power = volts x amps, so when either one is zero, there’s no energy transfer! – to get power out of a solar panel, you have to adjust those parameters somewhere in between. And what’s even worse, that optimal point depends on the amount of sunlight hitting the panels…

That’s where MPPT comes in, which stands for Maximum Power Point Tracking. Here’s a graph, copied from www.kitenergie.com, with thanks:

MPPT_knee_diagram

As you draw more current, there’s a “knee” at which the predominantly voltage-controlled output drops, until the panel is asked to supply more than it has, after which the output voltage drops very rapidly.

Power is the product of V and A, which is equivalent to the surface of the area left of and under the current output point on the curve.

But how do you adjust the power demand to match that optimal point in the first place?

The trick is to vary the demand a bit (i.e. the current drawn) and then to closely watch what the voltage is doing. What we’re after is the slope of the line – or in mathematical terms, its derivative. If it’s too flat, we should increase the load current, if it’s too steep, we should back off a bit. By oscillating, we can estimate the slope – and that’s exactly what my inverter seems to be doing here (but only on down-slopes, as far as I can tell):

Screen Shot 2013-05-14 at 15.35.03

As the PV output changes due to the sun intensity and incidence angle changing, the SMA SB5000TL inverter adjusts the load it places on the panels to get the most juice out of ‘em.

Neat, eh?

Update – I just came across a related post at Dangerous Prototypessynchronicity!