Leaf Test Drive

I had the opportunity to test drive a Nissan Leaf EV over the recent 3-day weekend. As an energy-head, I’ve been interested in the possibility of an EV ever since they became comparable with traditional motors. However, there were a lot of things I wasn’t sure about.

Comfort-wise this car is fine. I was advised, however, that I might not want use the ACU as it does drain the battery a little faster.

Appearance is, er, typical for Nissan. Not my cup of tea but neither are most modern designs, apart from top class marques. This should not be a deciding factor.

Range is, of course, the big issue with EVs. The LEAF has a nominal range of 99 miles. Your actual achievement, of course, depends on your driving style and, presumably, the age of your battery. On our 66 mile journey I was initially careful to keep acceleration down. Towards the end of the journey I was less careful and as a result reached home with only 6 miles worth of remaining battery capacity. Recharging took 7 hours. This presents the user with a challenge to get their planning right. My dear lady wife thinks journeys of any length constitute a reckless gamble and I have to concede that.

Economy of EVs is good apart from capital costs and depreciation etc. I clocked the energy used on the supplied charger at 3.4 pence per mile (based on my normal home electricity rate). This is pretty good compared to the petrol I use in my current 2 litre car at around 18p/ mile. This would save me some £840/ year, more if I charged during the day when I have solar to spare.

Emissions are correspondingly better than a fossil-fueled car, especially if charged during the day using solar. Embedded carbon in the car itself is hard to assess. I don’t know if such data is obtainable at all. I have asked AMEE about this – they’re pretty expert in carbon calculations – but they have not done cars and do not currently plan to do so.

The crucial point about deciding weather to buy a car like this is the overall economy including depreciation and servicing costs. This is a hard calculation and I will eventually do it and report back here. I would be surprised if a conventional car can be beaten on overall economy but who knows? One thought is that leasing may be a good option, especially if this manages the risk of having to replace the battery. The other thought, as for any car, is to buy nearly-new, avoiding the worst of the depreciation curve.

To be continued …

GDG Chrome Day 25th August

I was lucky to win a Chromebook at a recent hackathon and was then invited to a day at Google to learn about Chrome.  I have long been interested in thin client and this is a great take on that concept.  Basically it’s a machine with the Chrome O/S which is little more than a browser.  However, that browser is Chrome and this has the interesting ability to load and run apps from the Chrome store.

For those who create HTML5 apps for IOS and Android, a Chrome App is much the same kind of thing but with a big screen and it’s own appstore.  I wanted to develop one of these on the Chromebook, push it to the store, pull it down and run it.  Should be straightforward, right?

However, a lot of things we do in development lend themselves to having a Mac with developer tools downloaded and running locally.  In this test we were trying to do the whole process on a machine that does not run any of the usual tools.  That said, there are tools for Chrome books including HTML editors and image manipulation programs.  In this case we had the developer of ShiftEdit on hand, giving a talk about it and answering questions all afternoon.  This is a good HTML/ css/ js editor if you are working on a Chromebook.  Could be good for hacks and small changes to existing code.

As usual, my trial app was Energy-related. It’s called “OWL Guage” and is on the app store.  It allows those of us with an OWL monitor and a local microcomputer to see our (electrical) energy consumption in real-time.

Needless to say with technology as new as this there are a few issues:

  • Documentation is confusing, especially between “Packaged apps” and browser extensions.  I found myself googling in circles looking for essential information.
  • The Content Security Policy relating to Packaged apps is quite anal.  This is actually “a good thing” but it does mean that you can’t just take a hack that worked on a normal browser and upload and run it in the app store.  Furthermore, you do not see any violations when testing normally, only when they execute from the app store.
  • The Chromebook I have is underpowered.  This made it tedious to go round the development loop.  So I did not complete the exercise and had to finish it up on a Mac the following day.
  • There seems to be no app for pushing the app to the app store.  The missing piece is a zip tool.  It could be that this will appear in ShiftEdit before long.

The bottom line is that I did get my app working.  Must now put up some documentation and open sources the other bits people will need before they can get any use out of it.

Londroid Hackathon 18-19 August (incl. yoyo)

a.k.a “Smart Interconnected Devices Hackathon”

This session over the weekend, organised by @novodakm, was a very unusual #londroid event but none the worse for it.  Kevin explained that this was going to be very unstructured and apologised for lack of sponsorship/ prizes.  No apology was needed; this was a very interesting event that identified people interested in hardware issues.

I heartily agree with the sentiment of both Kevin and Dan that there can be a lot more to mobile devices than (increasingly similar) rectangular screens.

I decided that 24 hours was not enough to hack anything useful, especially given the temperature (hottest day of 2012 so far) and the stuff I had already done @ota2011 and ota2012.  This left plenty of time to meet people and find out what their interests were.

One of the items I was able to mention was the upcoming OSHCamp in Hebden Bridge on 15-16 September when I’ll be talking about  Android Accessory Development Kit (ADK).  Here are some notes that are part of my prep for that.

I realised that I have been focused on the use of the ADK Arduino Mega board while the IOIO (pron.  yoyo) provides an interesting alternative.  I should look into that and maybe include it in my talk.  I have since investigated IOIO and it certainly does look like a great alternative for many types of project, though not all.

Summarising the differences with a little help from IOIO developer @ytai, writings:

  • ADK and its clones only work on specific Android devices, while IOIO would work on almost any Android device since Android 1.5. That said, software is available to overcome this limitation.
  • With ADK you have to write both the Android-side (Java) and the Arduino-side (C++) software, and establish a communication protocol between them. You have to know both languages and two different IDEs and unless you’re doing something very trivial, it will take a significant amount of time to do this. With IOIO, you just write the Android side. You include a library called IOIOLib in your application, which provides an API that lets you control the IOIO pins and functions as if they were physically connected to your Android. You don’t need to care about the fact that there’s a separate processor here, communication protocols, etc.
  • With ADK you can control peripheral devices with strict timing requirements. For example, if you want to generate or decode a specific waveform you would need ADK. I use this to drive BBSB/ Homeasy sockets. IOIO cannot give you fine grain control of timing.
  • ADK boards are compatible with Arduino shields. If you want to use one in your application, IOIO will not be a good choice.
  • If you plug a Bluetooth dongle into IOIO instead of a USB cable to the Android, it will communicate wirelessly with the Android. The nice thing is that your application doesn’t need to care about it, and you can even switch back and forth while your app is running. This may well be possible with ADK but I don’t know who, if anyone, has tried this. Anyone?
  • If you want more info on IOIO, see @ytai’s github or Google “IOIO over OpenAcessory” (without quotes).

I plan to get my hands on a IOIO board and have a play. A different set of libraries is required but at first glance it seems to live up to the description of being significantly easier to implement than ADK.

As Kevin pointed out it gets expensive to have all the kit you need for this king of hacking. So be it :-(

Watch this space.