Once you realise the true enemy of software development is complexity, not waterfalls, you can start rethinking how we write our software. In her talk, Bodil shows why modern languages like Scala and Clojure may lead to fundamentally better software systems than any of yesterday’s tricks.
Cloud computing vastly simplifies the process of launching new servers with various configurations. This presentation tells the story of how we at Comoyo used Amazon Web Services (EC2 and S3) to create our own Frankenstein monster, an automatically scaled video processing pipeline that splits the tasks across a mix of various operating systems and components.
This lightning talk describes Bjørn’s toy project rmatch, an efficient regular expression matching library that makes it possible to look for many matching expression in the same input, each of the expressions are connected to their own callback function.
Having some many Mozillians here was great fun, and we all learned a lot! During the week, a lot of Telenor employees stopped by the work area (which was located next to a popular café on campus) to have a peek at what people were doing. So here is a video summarizing some the mood of the week:
The developers from Comoyo/Telenor Digital are working both on the OS itself, and looking at how Telenor can add value to phones with the OS on, by adding services such as direct operator billing, financial services and new communication services. We are launching the first devices in Hungary, Serbia and Montenegro hopefully before Christmas this year, and there is a lot of excitement around the future possibilities of providing affordable smartphones to the users in Telenor markets in Asia.
The Firefox OS work week in Oslo was also appropriately timed to coincide with the viral explosion of Norwegian-made international hit “The Fox” from the Ylvis brothers. If you haven’t seen it yet, here it is:
And this was obviously a hit at the closing party (although the DJ was somewhat resistant), here the app search engine of Firefox OS, everything.me, is demonstrated:
If you are located in Oslo and you’re interested in learning more about Firefox OS, sign up for the Firefox OS meetup in Oslo to get notified about future events.
This week, Telenor is hosting the Firefox OS work week, where 160 developers from Mozilla’s offices around the world are gathered in our headquarters at Fornebu to work together and fix bugs for the next release of the OS.
As we have written about before, Firefox OS is the first web-based operating system for smartphones, bringing the advances that are happening on the web to mobile. The first phones running Firefox were released by Telefonica and Deutsche Telecom this summer, and Telenor is set to release the first phones in Hungary, Serbia and Montenegro very soon.
The goal of the work week is to fix bugs and resolve issues with the next version of Firefox OS, currently work is being done on version 1.2. The focus of this work week is Quality, and the teams are working together on improving processes for automated testing.
We’ll get back with another blog post summarizing the events of the work week after it is done, but here are some snapshots from the first day:
Andreas Gal, VP of Mobile Engineering at Mozilla, gives a welcome speech:
We even took the liberty to give our visitors an introduction to Norwegian humor, playing the viral video ”What does the fox say?” by Norwegian comedians Ylvis brothers:
The work area in Telenor Expo Café:
Comoyo’s own Firefox OS developers, Jan Jongboom and Olav Nymoen:
This is a follow-up post on how to build a water temperature sensor using the Arduino GSM shield and Xively. This post should make sense on its own, but if you want to read the first part you can find it here.
The biggest problem with the sensor we made in the first post is that it cannot operate on battery power for any considerable amount of time. In our testing using 8 AA-batteries the sensor lasted for about 24hrs, which is not acceptable for most sensors. So, how can we make it run for longer periods of time?
Power down the modem and LEDs
The first thing to do is to disconnect the GPRS connection and turn off the modem when it is not in use. The modem is the biggest energy consumer, reaching 2W in some configurations. So we need a way to switch it off and on again.
We start by making a function to turn on the modem, and set up the connection. This should seem familiar if you have read the previous post, as the code is more or less identical to its setup function. Whereas in the previous version of the program you might get away with not having a delay between connecting to GSM and setting up the GPRS connection, it becomes quite important here since we are disconnecting and connecting more than once. In our testing we usually had problems connecting to the network during rush-hour when using too small of a delay, so even if your code works right now, it might not tomorrow morning. We still had problems using 1s delay so we bumped it up to 3s and have not had any problems since. You might get away with a lower delay, but it should at least be 1s.
Then lets look at how to disconnect. The heart of this function is the call to the GSM shutdown() function. We use the notConnected boolean to check that we are connected, then try to shut down the modem. If it managed to shut down, we turn off all LEDs to save power while not connected.
We now have a way of turning the modem off and on in between measurements. So in the loop function we start by calling startConnection(), measure temperature, upload the data, and end with calling closeConnection().
Set serial pins to low
Setting the serial RX pin on the GSM shield low after shutdown saved us a lot of energy. This seems to be a problem that is well known, and will be added in a future version of the library. In the meantime we need to do this ourselves.
Change GSM operating frequency
The Arduino GSM shield uses the Quectel M10 modem. This is a quad-band modem, meaning it can run on all four most common GSM frequencies. The modems specifications tells us that the modem uses 1W of power on 850/900 MHz, and 2W on 1800/1900 MHz. Our measurements showed the same results, even if the connection was considerably weaker on 1800 MHz than on 900 MHz. So changing the operating frequency of the modem will likely save us some energy. A simple way to change the modems operating frequency, is using the Arduino Band Management program. When you change the frequency it is changed internally in the modem so you don’t have to specify it every time you upload new code
When you run this program you can either choose single frequencies (top three choices) or a combination of several frequencies. If you choose one of the combinations, the Arduino is going to connect to the frequency with the strongest signal. This won’t always be the best in terms of power, so in our case we use the DCS frequency specifically. In Norway (at least) this frequency is not used as much outside of the cities, so we will lose some portability. Make sure the frequency you choose is available in the area you are going to use your Arduino.
Let the Arduino sleep
There are several pages on the internet explaining how to make your Arduino sleep, but the by far easiest way to do this is to use Rocket Scream’s LowPower library. From the code below, you can see that we use the LowPower powerDown function. This puts the Arduino to sleep and sets the watchdog timer to wake it up. The ATmega328 supports sleep up to 8 seconds, so we set the timer to that in the parameters of the function. We also turn off the Analog to Digital Converter and the Brownout Detector to save even more energy.
The biggest problem with making the Arduino sleep, is that it stops counting running milliseconds while it sleeps. Therefore the previous way of posting values every five minutes won’t work anymore. Instead we start counting sleep-cycles. Counting 25 sleep cycles plus the time it takes to get and upload data, we get data spaced somewhere between 4 and 5 minutes apart. You can choose how many sleep cycles you want to wait between each measurement, and the battery is likely to improve with a longer interval (more cycles). If you want to read more about sleep and the watchdog timer, you can take a look at the ATmega328 documentation and Rocket Scream’s description of their library.
The Arduino was made to be versatile, not to be used for low power projects. Using the voltage regulator and other standard features of the Arduino, we lose a lot more energy than what we would have if we made a specific board for this specific use case. This guide was made to be simple for others to follow so we decided to only do changes to the program, not the hardware. If you want to lower the power consumption further than we have done here, you should take a look at gammon.com.au/power which has a lot of good tips.