Thinking about going solar

I answered an ad by an outfit called One Block Off the Grid (1BOG) which organizes the installation of solar panels on people's roofs. When I say "organize", I mean not only that they take care of various complex logistical issues including lining up a NABCEP-certified installer, but also that they try to consolidate system purchases to bring costs down. Over the past couple of years this has become big business in the U.S. because of state and federal government incentives encouraging installation.

The 1BOG folks sent me a proposal with numbers in it, and I have 30 days to make a decision during which the proposed price is guaranteed. I also spoke briefly with SolarFlair, a similar outfit here in my town, that does the same sort of purchase consolidation and does the installation themselves. Since my 30 days is nearly expired, I'm hoping to drop into the SolarFlair office some time this week and talk numbers with them.

In my own state of Massachusetts, the situation is that people with solar panels produce SRECs (wikipedia, explanatory video) worth around $500 each time the solar panels produce a megawatt-hour.

Massachusetts' renewables portfolio standard (RPS) requires each regulated electricity supplier/provider serving retail customers in the state to include in the electricity it sells 15% qualifying renewables by December 31, 2020... Solar Renewable Energy Certificates (SRECs) represent the renewable attributes of solar generation, bundled in minimum denominations of one megawatt-hour (MWh) of production. Massachusetts' Solar Carve-Out provides a means for SRECs to be created and verified, and allows electric suppliers to buy these certificates in order to meet their solar RPS requirements. All electric suppliers must use SRECs to demonstrate compliance with the RPS. The price of SRECs is determined primarily by market availability, although the DOER has created a certain amount of market stability by establishing a state Solar Credit Clearinghouse Auction (where prices are fixed at $300/MWh), as well as the Solar Alternative Compliance Payment (SACP) for the state RPS (set at $550/MWh for 2011). The Solar Credit Clearinghouse will only be utilized if or when SREC generators cannot sell their SRECs on the open market; the fixed price of $300/MWh effectively acts as price floor. The SACP, on the other hand acts, acts as a ceiling on the value of SRECs because it is the per-MWh payment that electricity suppliers must make if they fail to obtain enough SRECs to cover their RPS obligation.

There is a federal tax credit of 30% on the cost of installation. I don't know if that's factored into the prices I've been quoted, and maybe I'd need to pay that myself upfront until I get the following year's federal tax rebate.

The 1BOG proposal offers options either to lease the system from 1BOG, or to pay for it outright at a cost of about $25K. I went to the credit union and applied for a 5-year fixed rate $25K home equity loan, with monthly payments of about $450. 1BOG proposes a system to create about 5.5 kW peak, and they are guessing that averages out to about 700 watts continuous, which is about 6 megawatts per year, for a yearly SREC income of $3200. The systems saves me about $100 per month on the electric bill, and when all the dust settles, my monthly expense is about the same as it is currently.

Five years later, the loan is paid off, the solar panels are my property free and clear, SREC income is reduced but not zero, and my electric bill is still substantially reduced or absent. And I will have set a good example for friends and neighbors that one can reduce one's carbon footprint without unreasonable financial hardship.

A somewhat half-baked embedded OS idea

I mentioned in my previous post that I had spent some time porting FreeRTOS to the SAM7 architecture before realizing my purpose was better served by looking for an existing port. But in the process I gave some thought to what kind of alternative to FreeRTOS I might cook up, if somehow the porting exercise didn't go well. I haven't thought through every detail completely, and I wouldn't trust myself to anticipate every issue until I'd actually coded the thing, which I haven't yet. My sketchy design is based on two ideas.

An aspect of JavaScript that fascinates me is that everything runs in a single thread (an idea nicely described here). Each function is the sole owner of the processor (at least as concerns the JavaScript world) until it completes, and there will be no unexpected modification of variables or data structures. No locks or mutexes or semaphores or "synchronized" keywords, no threading headaches. The price of this simplicity is that functions often are event handlers and must be written to do their work quickly and get out of the way so other events can be handled.

The second idea is something I've seen when coding applications for both Android and iOS. Communication between threads is carefully controlled. Slow operations are begun by event handlers in a UI thread, and when the work is done, another handler runs in the UI thread, supplied with any relevant results from the slow operation. Within the handler thread, JavaScript's protocol of running only one handler at a time to completion is observed. Where in Android one would invoke a Runnable object using a View.post() call, I would be inclined to create a postEvent(event,arg) function since I'd plan on doing things in C, and where presumably "arg" is pointing to a struct containing whatever information needs to be retrieved from the slow operation. That way, there is never a point in time where the slow operation and the completion handler are running concurrently, and again there is no need for arbitration of data access.

Flinging structs around requires malloc and free. That worries me a little because fragmentation, memory leaks, and low memory are all likely to be more troublesome on an embedded microcontroller than a desktop computer, and I'm not a memory allocation guru. Maybe there's some way to avoid memory allocation altogether, or maybe it will be less of a problem than I fear.

The general idea would be to implement a single handler thread and a fixed pool of worker threads. Worker threads idle until assigned a task; a handler can post a task to the worker thread pool where it will be picked up as soon as a worker thread is available. There might be an event fired when the number of available worker threads went from zero to non-zero; I haven't decided yet whether that's useful.

There would be events for various hardware stimuli: pushbuttons pressed, UART character received, Ethernet byte received, timer gone off, things like that. There would also be user-definable events which would include task completions. There would be some simple way to associate handler functions with events.

That's basically as far as I've gotten with it. Obviously there's a good deal left to do, and I won't really feel good about it until I see it doing something interesting and useful on a real microcontroller.

Of microcontrollers and operating systems

In recent weeks I've put some effort into working with a Beagleboard running Angstom Linux. The Beagleboard has an OMAP3530 processor, a ridiculously over-powered thing. It's cool to be running Linux on something you can attack with a soldering iron. But as I looked at my intended application and the price of the Beagleboard, and the hoops they jump through to manufacture the Beagleboard, I started to wonder if more conventional weapons might be sufficient to win the day.

I'd blogged in the past about the AT91SAM7, another family of ARM-based chips that are a little less over-powered, so I wondered, would they work for this? My first thought was to use Angstrom Linux on the SAM7. I found that nobody had done it, and digging deeper to find out why they hadn't, I was reminded that Linux requires a MMU and the SAM7 doesn't have one. Neither of these was a surprising piece of information, and I was probably dimly aware of both, but had never consciously connected them.

The reason Linux needs an MMU is because it runs multiple processes in separate memory spaces, so that one process can't crash another by overwriting its memory. This requires remapping from virtual memory addresses to physical addresses. That's most of what an MMU does.

It's shameful to admit, but I had unthinkingly assumed that 32-bit processors would necessarily run something like Linux, merely by virtue of being 32-bit processors. This was the result of having grown up with 8-bit processors and thinking of 32-bit processors as "big" and "complicated" and a little "scary". They are in fact all those things, but we still need to keep our wits in their presence.

Casting about for an operating system that might be more SAM7-friendly, I came across FreeRTOS. I started puttering around with a FreeRTOS port for the SAM7, and after banging on that a while it crossed my mind to think that there might be some other ARM7 chip for which a FreeRTOS port already existed so I wouldn't have to do the port myself. A little investigation in this direction led me to the LPC1768 (overview, datasheet, user's manual, Digikey listing) an inexpensive ARM7 chip with lots of flash and RAM, an Ethernet controller, USB controllers for both host mode and device mode, buckets and buckets of GPIO pins, and a comfortably higher number of MIPS than the SAM7 family. The LPC1768 has an ARM Cortex M3 core (overview, user's guide).

So what are our hardware development options here? Sparkfun provides a nice little board for only $50. It has tons of pins, sanely spaced at 0.1", and a JTAG connector on one end and a mini-USB on the other. It does require a power supply but that's not unreasonable. It has two pushbuttons (one a reset) and an LED. While I heartily encourage anybody to buy this board, I ended up buying a different board (which, time will tell, I may regret) because it was available on eBay.

I'm hoping to see the board in about a week, and I'll try to get FreeRTOS running on it with reasonable haste. Hopefully it will all work out nicely and I'll get to do a lot of blogging about it. The LPC1768 is really an interesting chip with a lot of on-chip peripherals, and I'd expect that would be a good amount of fun.