Posts Tagged ‘build this idea’

Build This Idea: Micro-Grids for Peer-to-Peer Energy

This is an instalment of Build This Idea, where I write about stuff I want to exist. Treat it like an idea store; if you like something, take it; if you make it, let me know — I’ll be delighted to check it out. Today, a rather big ask for unifying several existing concepts and services.

London has canals. On canals there are moored houseboats. Until recently many houseboats had a diesel generator for their own electricity. Now it is common to see a photovoltaic panel or three supplementing that, and I’ve seen a few wind mini-turbines (though I’m a bit skeptical if they produced more than needed to light a lightbulb).

A thing that is not so great about this is that each boat has their generator, and they aren’t connected. There are many downsides to grids, but if you’re running a heavy load (kettle, oven) and your neighbour isn’t, a grid is a handy thing to have. A grid lets you pool resources, essentially timeshare.

But we don’t always need country-wide grids. Much of the averaging and pooling is feasible on neighbourhood or city scale. Traditional large-scale grids are most useful with centralized generation, and actually have problems with independently operated small-scale generation.

Instead, we should connect the houseboats with micro-grids. This should also be done in other cases where people use electricity in geographically close but off-grid situations, such as parked RVs, camped tents, or clusters of cabins. This would help with temporary heavy loads: your panel or battery might not be able to support a kettle or a vacuum on their own, but together with those of two of your neighbours it might. Then once your kettle is off, your panel can lend electricity to your neighbour. Try to smooth the peaks a little. Keep a running balance of how much electricity was lent and borrowed by everyone to ensure fairness.

To further motivate peak smoothing, have a surge multiplier that rewards providing energy to the grid at peak times by giving out extra credit. During a lower-demand period, the credit can be spent by receiving more energy than lent out at peak. (This is essentially demand management by economic means.)

A rough implementation idea: each houseboat or tent or RV is a system, identified by a unique key (possibly something similar to public/private key). New systems joining a grid (with a new key not previously seen by the grid) are required to lend some energy before being allowed to borrow. This privileges early movers and existing micro-grid members, but also avoids regenerating keys to repeatedly get free energy. Wireless power transfer guided by low-power beacons would make it super cool, but of course there would still be a lot of value in wired connections. Systems can connect and disconnect as they like or need, but will find it advantageous to keep connected as much as possible, to build up credit they can spend later.

Another reason this would be interesting is it sets up a new “edition” of an electrical grid where there was no grid before. If all you had before was your diesel generator, you are more likely to accept limitations on electricity use than if you’re coming from a grid-connected point of view, where this setup might be a downgrade. Further, a secondary grid where the expectations are different can be a good illustration of the concepts of demand management and peak smoothing for people who are used to current constant grids. In software terms, this is a new, rewritten “edition” that doesn’t have some features, as opposed to a new “version” removing features.

The new edition should optimally be built to be a little more resilient and better able to deal with fluctuating supply and demand. Current systems are built assuming 100% reliability, and weird things happen if grid power goes out or voltage drops. However, many of modern household uses of electricity are not particularly time-critical: increasing amounts of electronics have built-in batteries, and in many cases it doesn’t really matter if a fridge or heater turns on five minutes earlier or later. It would then be good to have smaller-scale dispersed generation as well as storage, with house, vehicle, and electronics batteries all capable of being charged or discharged as needed.

Build This Idea: Better DC Power

A significant amount of my home plug use – if not outright electricity use – is for electronics. When travelling, various electronics are the only reason I need to bring plug adapters.

(Point-and-shoot and SLR cameras are particularly bad, usually requiring proprietary chargers that don’t even charge all that fast.)

For a brief moment late last century, you could travel with no chargers, and just buy more AAs wherever you went. Or use a local charger with rechargeable AAs from anywhere. A Walkman would run on American AAs as well as on European AAs.

The Nexus 5 has a 8.7 Wh battery, a lot bigger than 0.6 to 3.9 Wh in an AA battery. But there’s problems.

Phones, tablets, laptops, various camera chargers all ultimately use low-voltage and fairly low-power DC. Using wall-warts from to 220 V AC is just asking for waste. Using incompatible power adapters for many devices is insanity.

USB sort of solves this, but comes with its own problems. Using the same plug for data and power is going to end up like CD autorun did in the 1990s: helpful but dangerous. Plugging into an unknown charger — or an unknown cable — is a risk now. You couldn’t get your Walkman rooted by a AA battery. (You could conceivably get a device fried by a rogue battery, but that’s a one-time loss, not an ongoing pwnage.)

You can now get USB cables with a switch to disconnect data pins, or with data pins unconnected, but that means you’re carrying your own cable. Android has an OS-level data switch, but I am less than confident of many manufacturers’ ability to not get low-level firmware pwned, so a phone-based low-level physical switch would be appreciated. Still, these are hacks: better make sure not to switch by accident.

USB Type C gives more power, which will come in handy for bigger devices. At some point you have to ask why put data pins on something you’d ideally plug in everywhere, why require trusting the chargers? I can only hope it is a stop-gap until better wireless power is possible. (Just make sure you can’t get rooted over the air!)

Still, the installed base means that working with various kinds of USB (type A and micro-B in particular) is probably our best bet — and maybe at some point we’ll get hardware with a physical data pins switch. So: power pins on the 5 V DC USB plug for everything!

Canon and Nikon, I’m looking at you.

Bonus: photovoltaics

Photovoltaic/solar panels generate intermittent DC electricity. That is a very interesting fit with electronics. Traditionally a big problem with using solar power is storing energy for when it’s dark. Many electronics have batteries that can store the energy for several days, and using DC eliminates AC/DC conversions.

It would be a neat project to put a PV panel on the top lid of a laptop. The top of a 15″ laptop is about 0.10 square meters and could collect about 15 to 30 watts (around 45 degrees latitude, with today’s mid-efficiency panels). That’s not as much as a AC power brick — for bigger laptops, these are usually rated 50-70 watt — but it’ll top up a laptop nicely. Plus, a deep purple/black PV panel would look very nice on a black laptop. Novena case, anyone?

One thing to note is that you’d have to make sure things don’t melt. Consumer electronics aren’t usually designed with being left in midday sun in mind.

PV panels on phones would be a tougher sell due to smaller size and therefore energy potential, and things like SLR camera battery chargers are ill-suited. Perhaps it would be better to have one PV panel with a thin battery, and running everything off a common charging standard. These exist for USB but efficiency is iffy and design is often uninspiring.

Even if these aren’t commercially viable for mainstream products, I would love to see them as aftermarket or hobby mods: a replacement lid for a Thinkpad, or a flat, e-reader-size USB power bank with a PV panel on top.

Silicon Valley transportation technology for the rest of the world

Silicon Valley is trendy, has lots of mindshare and lots more of press-share. Unfortunately, its ideas are sometimes best suited for Silicon Valley and not much else, and this is frequently the case with transportation technologies as the Valley’s built form is very different from most of the world. But some of the technology can be useful with a bit of refocusing. In particular:

Better batteries

An American on HN told me in 2013 that Silicon Valley companies are the primary force working to electrify world transport. They must not have heard of that “train” thing; but at the same time it would be nice to have easier, cheaper, more complete-lifecycle-environmentally-friendly road vehicles. Some things will continue to run on roads for a while and we might as well try to improve those.

This is primarily my carbon guilt speaking, but I’m thinking of places like Iceland in particular. It seems ideally suited: there is lots of renewable electricity to charge the cars, most of long distance trips are within a 400 km range, and most users would be able to charge overnight – whether at houses, at assigned parking lots, or in case of truckers and tourists (hence my carbon guilt) at hotels/hostels/destinations.

Apparently there’s been lots of deployment in Norway, but Norway is a rich country even by Western European standards – it would be good to have this more widely.

Beyond rides for tourists, there’s lots of room to improve electric and hybrid delivery vehicles and buses where conversion to trolleybuses or streetcars is not feasible. Central London is choking in diesel and could really use better buses and taxis. Batteries will also help off-grid applications and help smooth out grid electricity usage peaks.

A lot was made of the California-built Tesla cars initially, but it looks like in the long run their battery technology will have more impact. Still, whoever does the best batteries, many will benefit.

Last mile

It seems pretty clear that trunk services are better off operated with trunk transit, and plans to combine last-mile with trunk (such as individual pods joining up into a train) are largely in sci-fi gadgetbahn stage and might never be practical due to size/mass-per-passenger inefficiency.

Of course the correct solution for last-mile woes is walkable communities where a transit stop with good service is within an easy walk, but redeveloping areas not built like this will take a long time, and smaller improvements can be made in a shorter timeframe.

Self-driving cars don’t solve inefficiencies along trunk routes and they are poorly suited for dense downtowns/city centres. On the former, with much closer vehicle spacing we might get 16-lane freeways down to six lanes, but it will still compare poorly with passenger throughput of a two-lane transitway. In the latter, a certain level of assertiveness is needed to balance avoiding obstacles with, well, getting anywhere: imagine pedestrians if they know a car will stop.

But sprawling, low-density suburbs should be well-suited for self-driving operations. It will be particularly useful if demand road pricing is allowed. It will turn out that it is, say, 2-3 times cheaper to accept a ride to a transit terminal and transfer onto a mass transport vehicle than to stay in the self-driving car all the way to the destination. If working in a lower density area, there would be a second transfer at another terminal close to the destination. This will work regardless of how the vehicles are powered, too, due to pricing of space. (Just consider how many houses could be built on the area of a medium-size freeway junction.)

Flexible transit

Suburbs, exurbs, and smaller towns are currently served by a mix of infrequent scheduled transit and paratransit. Demand dispatch technology could help reduce waits and increase usage. Rather than concentrating on cities where you are competing with classic bus service, it would be good to look after the long tail and allow some degree of car independence in smaller towns. A Lyft Line-like service that, with a living wage and reasonable job security for the drivers, could improve upon traditional infrequent bus service in lower density areas.

As an example, Grand River Transit is starting transit service in Wilmot township outside Kitchener – having it flexibly scheduled and with shorter waits for users as a result would be nice. Knowing that you won’t have to compete with big names like Uber anytime soon can only be a bonus.

This probably won’t get billions in VC money, but will be good.

Build This Idea: Soft Meter, a smart meter for everything

This is second instalment of Build This Idea, where I write about stuff I want to exist. Treat it like an idea store; if you like something, take it; if you make it, let me know — I’ll be delighted to check it out. Today, a web service I think would be super neat but haven’t had the time to built yet.

I would like a web service where I can easily enter any kind of meter reading, transit trips, plane flights, etc, and have it collate those over time and calculate and display usage and approximate carbon footprint.

I was able to get this for electricity from a BC Hydro smart meter when I lived in Vancouver. But a lot of people, and a lot of data categories, don’t have smart meters.

Screenshot of a website showing a bar graph of energy use by day

BC Hydro’s daily energy use tracker

This would be the smart meter for everything else. Have a simple interface with one field: the current meter reading. The user walks by the physical meter with their phone and enters the current reading in the browser. Three or five days later, do the same. With two data points, the site can calculate usage. With three data points, the service can display a trend. Draw a graph.

Knowing the trend — and visualizing it — is perhaps the biggest thing. Nothing motivates quite like “you’ve used more this week than last week.” What can be measured can be improved, what can be tracked can be optimized, and what can be seen improving can motivate to improve more.

Most people get some feedback when they get their bill. But feedback every two months isn’t as effective as feedback every three days. People can link what they did in the past three days easier than what they did in the last sixty days. You can change behaviour quicker.

Frequent feedback can be done with a smart meter. Or it can be done with a service that will be a smart meter for the rest of us.

The neat thing is that the solution can scale itself to so many things. Electricity meter. Gas meter. Water meter. A car’s odometer. Also point data: a flight from Heathrow to Pearson; number of transit trips in a month.

I’ve created something like this for myself but updating it is substantially more involved than one input field. It doesn’t estimate environmental footprint (currently a 1000 km flight appears the same as a 10 km drive) and there’s quite a lot of technical debt. But it is a nice proof of concept and I did find that tracking motivates me to use less.

There will of course be privacy issues. I have been thinking of a Javascript-based site where all data is stored on user’s device unless otherwise requested, but there’s many possible solutions. Surprise me.

I often say that when you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot express it in numbers, your knowledge is of a meagre and unsatisfactory kind; it may be the beginning of knowledge, but you have scarcely, in your thoughts, advanced to the stage of science, whatever the matter may be.

— William Thomson, 1st Baron Kelvin, Lecture on “Electrical Units of Measurement” (3 May 1883), published in Popular Lectures Vol. I, p. 73

If you can not measure it, you can not improve it.

— snappier Kelvin, according to the internet, so it must be true

Extra functionality

For when you’ve nothing left to do but add exciting new features:

  • Add ability to upload data from external sources, like CSV exports of BC Hydro smart meter data, or Oyster history exports.
  • When presenting trends, add generalized data from the city/region/whole system for comparison, or add weather history to help people understand what might be driving their usage.

Build This Idea: Ultimate Transit App

Welcome to “Build This Idea”, where I write about stuff I want to exist but can’t make myself. Treat it like an idea store; if you like something, take it; if you make it, let me know — I’ll be delighted to check it out.

Vancouver: You’re on the Skytrain heading to Main and Broadway from Metrotown. Is it faster to transfer to the 99 at Broadway, or the 3 at Main St? That depends on how the buses are running right now and an app could tell you.

London: You’re at Hoxton looking to go to Hampstead Heath. Do you wait for a Highbury train or walk from Dalston Junction to Kingsland? An app could tell you.

An app that would be very, very focused. Very city specific, very local. With actual entrance locations, accessibility information, real transfers and connections, measured walking times, and real-time data.

Transit-specific apps with real-time info aren’t new, of course. Citymapper is doing this but they’re not doing it as well as it could be done. Same with Transit. They both appear to be focusing on getting as many cities as possible, which is fair enough and makes sense from a VC funding/making money point of view. But it doesn’t necessarily make sense from a user experience point of view.

To elaborate, here’s some things current solutions aren’t very good at:

Google: As far as I can tell, real-time info isn’t used in transit directions in the flagship Google Maps Android app. Where supported (and that’s very far from everywhere with data available), real-time info is on the station/stop card, but there’s no way to get to the card from the directions screen. If you’re deciding if you should take the 3, better hope it runs on published schedule! #itdoesnt (Google Maps has a number of hilarious other problems. The platforms for Toronto subway are shown as separate stations at the same location, and you can only tap into one of the “stations.” Particularly fun at transfer stations where you can only get schedules/departures for one of the four directions. This is a GTFS source problem but Google doesn’t appear to be jumping out to fix major stuff like that.)

Citymapper started out as a London app, but still has somewhat frustrating incompleteness in London information. They correctly have the Euston transfer from Northern line Bank branch southbound to Victoria line southbound as a 1 minute walk: it is as cross-platform as the Tube gets. But they list the Green Park transfer from Victoria to Piccadilly line, in practice a 4 minute walk even if you know which train carriage to be on, as 2 minutes. Time to get to platform is also estimated at best, and seems to be on the quick side. Special cases like Camden Town station being exit only on Sunday afternoons — published on the Tube maps — aren’t handled.

Citymapper piggybacks on Google Maps and individual entrances to the stations aren’t mapped; in large stations with several entrances this can be a couple minutes’ walk. Optimal routes through the stations; optimal carriages. This all saves maybe a couple of minutes, but then so do apps for ordering tacos.

It is possible to do better. I would like it if someone did better. Will there be a business of it? I don’t know. I hope so.

There is, of course, a risk of Google starting to do this in 2016. But it might be a risk worth taking. The other competitors aren’t perfect, and Google hasn’t bothered yet. Real-time transit information has been in Google Maps since mid-2011 but Google has yet to make it anywhere close to universal, let alone really use it smartly; it feels like they’re too busy with self-driving cars and internet blimps. In any case, being really good, about really specific things, that really impact people daily, is a nice niche to be in.

And, of course, ideologically it will be a good thing if more than one company has good software in this market (so long as standards eventually converge). There is a GTFS-realtime but so far it hasn’t seen pick-up at anywhere near the scale of the original GTFS. Will it eventually steamroll the market like GTFS once did? And even if it does, will building up the technology be a waste?