BFree Brings Intermittent Computing To Python

Generally speaking, we like our computing devices to remain on and active the whole time we’re using them. But there are situations, such as off-grid devices that run on small solar cells, where constant power is by no means a guarantee. That’s where the concept of intermittent computing comes into play, and now thanks to the BFree project, you can develop Python software that persists even when the hardware goes black.

Implemented as a shield that attaches to a Adafruit Metro M0 Express running a modified CircuitPython interpreter, BFree automatically makes “checkpoints” as the user’s code is running so that if the power is unexpectedly cut, it can return the environment to a known-good state instantaneously. The snapshot of the system, including everything from the variables stored in memory to the state of each individual peripheral, is stored on the non-volatile FRAM of the MSP430 microcontroller on the BFree board; meaning even if the power doesn’t come back on for weeks or months, the software will be ready to leap back into action.

In addition to the storage for system checkpoints, the BFree board also includes energy harvesting circuity and connections for a solar panel and large capacitor. Notably, the system has no provision for a traditional battery. You can keep the Metro M0 Express plugged in while developing your code, but once you’re ready to test in the field, the shield is in charge of powering up the system whenever it’s built up enough of a charge.

The product of a collaboration between teams at Northwestern University and Delft University of Technology, BFree is actually an evolution of the battery-free handheld game they developed around this time last year. While that project was used to raise awareness of how intermittent computing works, BFree is clearly a more flexible platform, and is better suited for wider experimentation.

We’ve seen a fair number of devices that store up small amounts of energy over the long term for quick bouts of activity, so we’re very interested to see what the community can come up with when that sort of hardware is combined with software that can be paused until its needed.

16 thoughts on “BFree Brings Intermittent Computing To Python

    1. You may have missed the point. You should read the write up. This is part of a larger research project to develop tools for doing this sort of thing, not to make the thing itself. No doubt there are better ways of doing it if all you were doing was making a dedicated unit. This is not that. It is a proof of concept made by a research team.

  1. Very neat.

    But interesting it requires hardware and software. Can’t help but wonder if a software-only solution is possible (laptops are perfectly able to sleep and restore), or hardware-only (via JTAG?).

    1. Laptops depend on hardware to say “hey my battery level is x” so they know early enough to perform an orderly hibernate. So even laptops don’t actually do this without dedicated hardware, however your implied point is still valid: most of the heavy lifting is still software.
      Doing it mostly in hardware like this probably makes it easier to minimize power usage as well as keep it very predictable. So you could run a few tests and say “for x amount of state that we’re updating, it will always take y amount of time and z amount of power” then work that backwards to get as close as possible to saving the state at the last possible moment before shutdown. Laptops prefer not to drain it fully to zero because (besides battery chemistry) it’s harder for them to predict exactly how long a hibernate & shutdown sequence will take.

  2. I wonder, if I have a large solar cell or wind turbine that powers a large off-grid device that shuts down when power is getting low, what to do with excess power the cell or turbine generates?

    I’m currently contemplating a project with such device. I’ve solved the low energy case (shut down device until there is enough power in batteries and power source), but I do not know what to do with excess power.

    Maybe boinc server that comes online to use excess energy.

    1. Can you power a jacob’s ladder with supercapacitors? Because you could always add some sweet sci-fi atmosphere to the setup. Or maybe drive a speaker with a low frequency regular thumping to serve as a tell-tale heart reminding/annoying everyone with it’s presence ;)

    2. Both photovoltaic panels and wind-powered generators handle this automatically. When you remove all load from a photovoltaic panel, it just goes to its open-circuit voltage, delivering zero current and therefore zero power, at a voltage that depends on the intensity of the light. With generators, it’s the same – there is a voltage that the generator will output with no load, proportional to the RPM of the generator, without you having to do anything at all. In either case, you need a voltage regulator to reduce the voltage when the current drops, but you need this even without the no-load case. That is, unless your load is perfectly constant, you need voltage regulation anyway.

      There is a special case for wind turbines, where you want to prevent the turbine from overspeeding, which can happen when your load isn’t enough to limit the turbine’s speed at a given wind speed. This is generally handled by using either a mechanical brake or an electrical shunt regulator. The shunt regulator is the simpler solution, and it just involves switching on a load when the generator output voltage reaches a threshold. This is not necessary for photovoltaic panels, since there is no such thing as “surge” sunlight, unless you’re close to a nuclear detonation.

      1. An interesting case was the “Freeplay” radio, a radio powered by a wind-up spring. This used a DC motor wired as a generator, and a shunt regulator. The purpose of the shunt regulator was not just to regulate the voltage, but to slow down the generator when the radio was used at low volume. Without this, the spring would have wound down faster at lower volumes! But in the case of wind turbines, overspeed prevention is just a way of protecting the mechanical parts from reaching unsafe stresses.

  3. It’s not clear to me, how often the state would be saved. The write-up does say that the software determines where appropriate “checkpoints” are, and does the backup to nonvolatile memory. The SAMD21G18 uses flash memory for its nonvolatile RAM, with a specified endurance of 100,000 cycles. Which sounds like plenty, but if your software hits one checkpoint every second, 100,000 cycles are consumed in less than thirty running hours. Of course, you can design your application to store checkpoints much less often than this, but time between checkpoints translates into time spent redoing the same calculations. If you use a 10 second rate for checkpoints, that’s five seconds of average time spent duplicating previous calculations, each time power is restored..

    Of course, checkpoints are likely to be effectively longer than that, since the application may only store a checkpoint at each user input, which is fine for many applications. I just react whenever I see flash memory being updated automatically, since the user may not be aware of the consequence of doing many repeats of a particular operation. Just ask Tesla drivers whose computer modules have had to be replaced because of flash wear-out.

    1. This could maybe be mitigated by using a capacitor sized appropriately so that on detecting that power has dropped below a threshold, there is sufficient time to store the state of the machine. This increases the lifetime of the flash memory to a number proportional to the number of power cycles, rather than the number of discrete computational chunks performed.

  4. my fantasy for intermittent solar powered electronic devices – modular, environmentally-sealed GMRS repeaters that could be sprinkled across the mountain tops, spanning shore to shore; kind of a radio repeater Johnny Appleseed concept

  5. The best solution is using super capacitors for saving solar energy and super low power MCU. You may use any, but add the part of schematic that will notify the MCU when power goes down. MSP430 with FRAM is cool solution for unstable power , but it more useful with something like NFC ,when power can disappear immediately. In my practice we used an external FRAM as an external RAM and make there data storage and video buffet fir E-ink screen.

Leave a Reply to BrightBlueJimCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.