What’s your band? Mapping LTE

“Verizon expands its XLTE network – the combination of Verizon’s existing 700MHz LTE spectrum and its newly activated 2100 MHz AWS spectrum – to over 400 markets in the US.”

“T-Mobile’s ‘super fast wideband LTE network’ went live in New York City three days ago.”

“EE switches on ‘world’s fastest’ LTE-Advanced 4G in UK”

These stories are just a snippet of the telecommunications advancements and improvements that are happening all over the world. Conclusion? These are exciting times!

Here at OpenSignal we are using the data collected by the OpenSignal app to build models of 4G and LTE networks and the factors that affect data speeds. However, we’re missing two pieces of the puzzle: the band (which part of the spectrum is used) and bandwidth (the range of frequencies included – how many frequencies make up the band). Different bands determine how permeable the signal is through different materials (and therefore the distance covered by that band), and bandwidth determines the capacity of data that can go over that band.

The Android API does not have a published method to read the band and bandwidth information off the phone. This means we cannot map these important details together with our other signal data without your help! You can check the band your phone is on by entering ‘Service Mode’. On Samsung phones this is done by entering *#0011#, but on other phones the codes can be different – sometimes the codes will also change based on the network operator you have.

Once you’re in Service Mode, look for the Band information, and if you find it, the LTE DL BW (LTE download bandwidth) or the Earfcn_dl (which stands for E-UTRA Absolute Radio Frequency Channel Number Downlink, and refers to the download frequency). Once you have this information, if you could please enter it into the form on this page, we can track the developments in LTE services: http://opensignal.com/blog/2014/05/11/help-needed-mapping-lte-bandwidth/

Many thanks for your help and contributions! If you have any questions, just email me at teresa@opensignal.com.

Posted in Uncategorized | Leave a comment

CrisisSignal launched in Ebola afflicted regions

When disasters strike, whether conflicts, flooding, earthquakes or epidemics, the effectiveness of the emergency response can often mean the difference between life and death. Mobile phones have a crucial role to play in emergency response, and will only grow in importance as they become more ubiquitous (the ITU estimated there were 6.8 billion mobile subscriptions worldwide in 2013).  The OpenSignal team has developed an app called CrisisSignal, which is designed to collect data on cellular and Wi-Fi coverage in emergency situations. The app, available on Google Play, allows users to contribute to mapping coverage in (or very close to) real time, providing information to emergency responders, humanitarian agencies and local communities so they can make appropriate decisions as part of the relief effort.

CrisisSignal has been tested in several emergency response situations, such as after Hurricane Sandy in New York in 2012 in collaboration with the US Federal Emergency Management Agency (FEMA) and following the devastation in the Philippines from typhoon Haiyan in 2013. It is about to be rolled out to the largest cohort so far, to assist relief efforts for the Ebola outbreak in West Africa.

Nethope, a group of 43 international humanitarian NGOs, is working with a number of organizations to distribute 10,000 phones in West Africa, funded by the Paul G. Allen Family Foundation. These phones are currently en route via Ghana and have several apps pre-installed, including CrisisSignal, to map coverage in Sierra Leone, Guinea and Liberia. OpenSignal has teamed up with Esri, who supply Geographic Information System (GIS) software, and other experts to map the data that the CrisisSignal apps collect and provide it to the public as part of the World Bank Geonode system. This is the first uptake of CrisisSignal at scale, and potentially an opportunity to make a meaningful impact on the communities that have been most affected by the disease.

Initial readings from CrisisSignal in West Africa

Initial readings from CrisisSignal in West Africa

Why does mobile matter?

The humanitarian sector is evolving to harness the power of technology in emergency response situations. The Red Cross defines humanitarian technology as ‘the use and new applications of technology to support efforts at improving access to and quality of prevention, mitigation, preparedness, response, recovery and rebuilding efforts’. Communications are a necessity in the aftermath of disasters and therefore a key humanitarian technology. Article 19 of the Universal Declaration of Human Rights protects the right to ‘seek, receive and impart information and ideas’ i.e. communicate, ‘through any media and regardless of frontiers’. Humanitarian and aid organizations can work to ensure this human right through making communications a top priority.


Two-way mobile phone communications can help victims of disasters by ensuring that local communities remain in contact. Authorities can send messages notifying people of danger. There are also psychological benefits associated with keeping in touch. After the 2010 earthquake in Haiti, the International Federation of Red Cross and Red Crescent Societies (IFRC) launched a campaign to send SMS alerts to warn Haitians of preventable diseases, such as cholera, weather warnings and directions for finding help. Feedback from several participants of the program said the SMS made them ‘feel cared for’.

Communities affected by disaster can also communicate useful information, and should be empowered to engage with the aid effort as a whole. For example, Al-Jazeera established a program called Somalia Speaks in 2011, using mobile phones to send and receive SMS on how people were being affected by the conflict. Mobile users also take to social media to communicate, such as in Syria where YouTube has been used to inform the international community of what is happening in conflict zones. Mobiles allow for family members to keep in touch at home and abroad, and enable practical actions such as the transfer of cash via mobile money from the diaspora.

Data and Maps

Data collected actively or passively from mobile usage can also contribute to emergency response efforts. For example, research teams predicted population displacement using call records after the 2010 Haiti earthquake. Movement of populations is common after disasters such as earthquakes, which makes it difficult for relief organizations to deliver the necessary aid. Data from mobile phones has also been combined with maps following disasters, a process known as ‘crisis mapping’, just as CrisisSignal does. For example, maps of tweets were used during Typhoon Pablo in the Philippines in 2012 to provide data to the United Nations Office for the Coordination of Humanitarian Affairs  (OCHA) so they could assess the extent of the damage and plan accordingly. Ushahidi, meaning “testimony” in Swahili, was originally established to crowdsource data and map the 2008 post-election violence in Kenya. Ushahidi partnered with Tufts University after the 2010 Haiti earthquake to crowdsource SMS and social media mentions to plot events to maps, which, according to the US Marine Corps saved hundreds of lives.

How CrisisSignal fits in

The power of mobile phones to contribute to disaster preparedness, mitigation, response and recovery is dependent upon connectivity. The data that will be collected through CrisisSignal has an impact both in terms of the immediate response as well as intermediate, and longer-term reconstruction and disaster preparedness actions.

After a disaster, communications infrastructure is often damaged and cell sites may be down. Roads might be blocked, making it impossible for vehicles carrying telecommunications reconstruction equipment to reach these damaged sites. As more and more people use their phones to check on friends and family and take to social media, networks may become overloaded and fail. By getting CrisisSignal on phones in the disaster affected area fast, the state of connectivity can be learned quickly in-real time so that decisions on appropriate relief efforts can be made and resources diverted to the most efficient use. Immediately following a disaster this could involve learning where to place limited supplies of temporary cell tower infrastructure such as Vodafone’s Instant Network of Base Transceiver Stations, Broadband Global Area Network (BGAN) portable terminals, or Very Small Aperture Terminals (VSATs).

After the initial immediate response to a disaster, humanitarian organizations may wish to gather data using mobiles to further assist in the relief effort. For example, applications and tools such as the Open Data Kit (ODK), KoBoToolbox, Commcare, Premise, Magpi, NOMAD, and FrontlineSMS, can be used to track aid efforts, population displacement, market information and survey data. The network coverage information gathered by CrisisSignal lets aid organizations know where they can roll these efforts out. In particular, some of these require a data connection while others simply require voice or SMS. Since CrisisSignal maps the connection type, organizations will know what tools can be used where.

In the longer term as efforts move to reconstruction and preparedness, CrisisSignal can play a role in understanding how to build out cell tower structures and rebuilding damaged infrastructure. Countries affected by disasters may not have national coverage even before the emergency, and it is important to prepare for the long-term reconstruction of affected regions rather than just focusing on immediate fixes of towers in neighbourhoods that previously had coverage. Mapping out the country’s coverage can allow for this considered build out to take place, so that once the aid agencies leave a more resilient infrastructure remains.

CrisisSignal data will be collected from any phone with the app, whether it is someone based locally affected by the disaster, or a visiting aid worker. Education and communication ahead of disasters, such as raising awareness of the app locally so that it is installed on people’s phones ahead of time, and partnering with organizations that can distribute phones or notify aid workers to download them, will also allow for data to be collected quickly. This will speed up the time it takes to gain knowledge of the networks to roll out immediate relief efforts.

Initial CrisisSignal readings in Freetown, Sierra Leone

Initial CrisisSignal readings in Freetown, Sierra Leone

What’s next?

OpenSignal will be monitoring the data collected by CrisisSignal in West Africa, and will share the maps with the public and aid agencies operating in the region. As this is the biggest rollout of the app so far, we’ll be on hand to make bug fixes, answer questions and support the community of users. Most of this will take place on Google Play but also on the dedicated forum page http://opensignal.com/blog/forums/forum/crisissignal/. We will continue to learn from and share our data with the many organizations working in mobile disaster response, such as the GSMA Disaster Response team, UN OCHA and their Humanitarian Data Exchange, the Communicating with Disasters and Affected Communities (CDAC) Network, the Harvard Humanitarian Initiative, and others. We have a lot to learn about how CrisisSignal can be used to facilitate emergency response, and we can use this knowledge to improve the app and data analysis in West Africa, and future disaster afflicted regions.

Posted in CrisisSignal | Tagged , , , , , , , | Leave a comment

We’re raising the bar!

Can you hear me now?

Raising the Bar - Translation Status

OpenSignal is trying to reach as many people as possible – and our ‘signal strength’ isn’t great in some countries because our app is not in the local language. We’re asking for your help to raise the bar for our Android app – help us in the campaign to reach 50% translation across all languages by January 1, 2015!

How does it work? Well, in short, we’re using a crowdsourcing platform called Pootle to manage the translation effort. When you visit the page - http://translate.opensignal.com/projects/android/ - you’ll see all the of languages we’re currently translating into (and if you don’t see your language, you can just email me at teresa@opensignal.com and I’ll add it right away!). Please contribute as much or as little as you want! Do you have to register? Registering helps us know who did what, plus, you’ll have a chance to get some goodies à la OpenSignal … see below.

If you are the top translator in a language, or have translated more than 1500 words, we’ll send you a free OpenSignal T-shirt. But that’s not all!

If you refer someone to translate, and they translate more than 1500 words, you can get a second T-shirt!

Finally, anyone who translates 1500 words or more will be entered into our New Year’s Translation Prize Draw for a free iPad! Right now, there are only 5 people who have been entered! (We can only ship Apple products to countries with an Apple Online Store. We will try to get an alternative tablet if you live in a country to which Apple cannot ship).

Ready to go? Here are some more detailed instructions - http://opnsg.nl/help-translate-android3 – but if you have any questions, once again, just feel free to email me at teresa@opensignal.com.

Thank you so much for your contributions!

Posted in Competition, Help Needed!, Translation | Leave a comment

Like what we do? Help us collect data!

I’ve been working hard to write an FAQ section, to help our users understand how our apps work, special features, and our methodology. I’m putting this information together based on the questions that we’ve received, and the first question I want to address is: ‘How do I help? I want to collect as much data as possible to contribute to your maps. What settings do I need to have on my phone?’

Manual Speedtests

Running manual speed tests with the OpenSignal app is one of the best things you can do to contribute data. A manual speed test results in a a very rich dataset as it’s an active test of the network and we measure a number of different parameters.  Please do note, though, that the more tests you do the more data the app will use.

You may be thinking, speed tests are great, but there are only so many you can do as you go about your day. What are the settings that will let the app collect data on its own? Here’s a summary of those settings, for Android and Apple phones.

On Android

How do I collect as much data as possible?
The frequency settings change the rates at which data is collected by the app. Common to all modes, when the app is open, network scans are performed continuously (similarly to the high setting for background data – see below), but you can set how quickly readings are taken when running in the background, that is when the app is closed. On Android phones, the phone only collects readings when the screen is on.

Here are the differences between the modes you can select in the settings:

  • None – Your phone does not contribute any data to the OpenSignal project
  • Low – The app only scans when the app is open, not when the app is closed.
  • Normal – In addition to the scans conducted when the app is open, in Normal mode the app will take a scan every 60 seconds when the app is closed.
  • Medium – In Medium mode, the rate of data collection in the background changes – the app scans every 30 seconds in the background.
  • High – This is where it gets really interesting. In High mode, the app does not do a periodic scan. Instead, the app listens to all the signal strength changes, such as fluctuations in signal level, handoff between towers, change between cell different technologies. How much data this produces will vary quite a bit. For example, if you’re driving round you’ll get handed-off between antennae frequently, or if you’re on 2G you’re likely to see more towers.

What’s the difference between a scan and a reading?
A network scan looks at the signal strength and the tower that the phone is connected to, and looks for other towers. The app logs a signal reading from the tower the app is currently connected to. If the app detects other nearby towers that you are not currently connected to, it will log a signal reading from these towers as well.

You’ve mentioned that the screen needs to be on. Does the app not collect data when the screen is off?
No, the app does not collect data when the screen is off on Android, except if you have experienced a dropped call. On some Android phones, there are bugs when trying to get signal data when the screen is off, so if we include this data it would skew the data.

The Android Developer settings pageHow do I keep the screen on?
When you have your frequency setting set to High, there is a wake-lock on the screen which will prevent your screen from turning off, even if the app is closed. This works on some Android phones. A more certain method is to enable Developer Options on your phone and select the ‘Stay Awake’ setting, which will ensure your screen stays on when the phone is charging. You could also use a power management application to keep the screen on. Using the Stay Awake setting or a power management app will allow you to enable frequency modes other than High in the OpenSignal app.

Here’s a quick read that tells you how to enable Android developer settings (summary – tap the Build Number in the ‘About Phone’ section 7 times).

What other settings do I need to have?
It is really important to have location settings turned on – we cannot use your data otherwise. On Android, you can select different levels of accuracy for location data – and while just using GPS does work, the best one to select is location finding via GPS together with WiFi and mobile network information.

Just out of curiosity, what exactly are you measuring?
The standard readings performed by the app are ‘network signal and type’ tests: the app measures signal strength and the type of connection (3G, 4G, LTE, etc.), but it doesn’t measure whether the data connection is actually working. To check whether data is actually getting through, you need to explicitly run a speed test, or a quick ping on the overview tab. The app does run very occasional ping tests in the background as well.

If I have the app in the High frequency mode for data collection, won’t it use up a lot of my data allowance?
You can control the upload settings as well. The app gives you the option to only allow uploads over WiFi, preserving your data allowance. The default setting is to prioritise uploads over WiFi when the phone is charging, which means that the app will try to upload over WiFi, but if the app doesn’t get a WiFi connection for a week, then it will upload over a mobile data connection. Each line of data is 250 bytes, but the data is compressed so it could be around half that size for upload. Also, the more data you are sending, the better the compression.

On iOS

There are fewer settings in the OpenSignal app in iOS phones. Here is a brief overview of the various options:

Frequency of Data Collection
You have the choice to allow data collection in the background (when the app is closed or the screen is off), or only allow scans when the app is open. If background data collection is enabled, the app will take a scan when a significant change in location is detected.

Location Settings
Yes, location settings need to be on – Apple’s method for location finding involves GPS, WiFI and network information.

What are you measuring?
On Apple, the regular scans are short latency tests. We also look at the network type, checking whether it is 2G, 3G, 4G, etc.. This data contributes to the network rankings, and may also be used in another map / data visualisation. Unfortunately, Apple does not allow apps to read the signal strength of the mobile network.


Now you are ready to go forth and collect data! Please email me at teresa@opensignal.com if you have any questions.

Thank you for your contribution and participation!

Posted in FAQ, Uncategorized | Leave a comment

Translate for a T-Shirt!

Hi everyone! Do you love languages? Do you know two or three or four? Are you learning bits and pieces of (insert language here) for fun? Join our translation effort!

OpenSignal are rolling out a big update to our Android app and there are a bunch of new bits that need translating. As a worldwide app providing worldwide signal coverage, we need to be sure our app is accessible to as many people as possible.

Interested? Here’s how to get started:

  1. Go to http://translate.opensignal.com/projects/android/
  2. Register for an account – it takes 15 seconds
  3. Click on the language you want to translate
  4. Click ‘Continue translation’ and start translating!
  5. You can do as much or as little as you like.
  6. If you are the top contributor in a language, of if you have translated 1500 words or more, we’ll send you an OpenSignal T-shirt!
  7. We’re also happy to thank you for your translation on our social media.

Do I really need to register for an account?

You can suggest translations without registering, but you can only submit translations if you register.

What am I translating?

When you click ‘Continue translation’, you will be prompted with the various phrases that need translation. However, you can also choose to translate specific parts of the app.

File choices that are available after selecting a language

How would I do that? 

After you click on a language, you’ll notice that there are 3 files (see screenshot):

  1. google_play_description-hu.po- what users see on the Google Play Store when they find the app
  2. google_play_recentchanges-hu.po – the text that comes with the latest changes to the app
  3. strings-hu.po – all of the text that appears in the app

How long does it take translations to appear?

It should generally be around a week for translations to go live. To get them slightly ahead of everyone else (and help us test the latest app version) join our Android beta community at: http://opnsg.nl/beta_community

My language isn’t listed, how do I add it?

Just email me at teresa@opensignal.com and I’ll add it straight away!

                                                          THANKS FOR YOUR HELP!

OpenSignal Team displaying our lovely T-shirts


Posted in Help Needed!, Translation, Uncategorized | Leave a comment

The OfCom Mobile Broadband Report: a response

Yesterday OfCom released a report [pdf] on the current state of UK mobile networks – a report similar to ours on the subject from last week, which found that 4G speeds had halved over the past year in the UK. OfCom focussed their report on network performance, rather than coverage, and cited our report to show that independent analysis is being carried out on the comparative coverage provided by MNO’s. Importantly, OfCom carried out their study by comparing performance in sites around the UK, both indoor and outdoor, where all four networks were present – and their findings were different to ours, with higher reported speeds on both 3G and 4G. In the OfCom report EE ranked as the fastest 4G LTE network while Vodafone were the fastest 4G network based on OpenSignal user data.

We feel very strongly that these kind of reports are exactly what OfCom should be doing, and that any and all independent data made available to consumers is a positive step leading to a more efficient market. We have made clear in the past that we want OfCom to do more independent testing, and make use of different datasets (such as OpenSignal) – so that better consumer information on network performance will force the operators to compete more in terms of the actual cellular service they provide.  We are supporters of all independent information that helps to achieve this end, and we are delighted that OfCom chose to cite our report, as it shows they are open to innovation and aware of the limitations of traditional testing methods. That being said, we retain a number of reservations about the methodology used in the OfCom study.

1) The data is up to eight months old: With the current pace of network upgrades, using data up to eight months old is not likely to reflect the current state of network performance. OfCom’s data collection ran from March to June, while our OpenSignal report covers the three months leading to October 1st. This is especially a concern when it comes to 4G measurements, as our UK report showed that average 4G LTE speeds across all networks had fallen 15% from March to October, meaning that OfCom may be overstating the speeds currently experienced by real consumers.

2) The type of device used: OfCom tested using a Galaxy Note III, a mobile phone which is available across all networks. They justify this by saying they want to test the network without it being affected by the user’s device, as different devices experience different speeds. While this is a legitimate way to judge comparative network performance, we do not feel that it is the best way to show the real user experience of the network. Testing using a consumer device in this way sits at an uncomfortable halfway point between using specialised testing equipment and data crowdsourced from real user devices, and is unable to fully capture the full spread of user experience. Many users do not have high-end devices, so testing using a device such as the Galaxy Note III is likely to overstate speeds. Our network averages represent the fact that users have many different devices, and our data is therefore naturally weighted by device market share – as every user counts the same – giving a more accurate picture of the diversity of the UK’s mobile device usage. We feel our methodology complements the OfCom data, as it would be too time consuming to road-test using a full spread of devices and OfCom do not claim to be directly measuring the user experience, despite using a consumer device for their testing.

3) The location of tests: OfCom test both indoors and outdoors (a positive development from the days when network testing included almost no indoor tests) but they test 50% on each, which is not necessarily representative of typical use. Above all, by testing in areas of good connectivity (where all four networks are present) they are potentially skewing their results to the faster end.

4) Testing on EE ‘double speed’: OfCom ran their tests using the EE 4G ‘double speed’ sim (without fully explaining why, as they stated they intended to test both the ‘single’ and ‘double’ speed tariffs, but ended up only testing the faster one). Many EE 4G users are not on the faster speed tariff and so reported speeds for EE are only representative of the experience available to users who are paying for the faster data, and therefore possibly not representative of those who are paying for 4G LTE on EE on the ‘single speed’ network.

5) What OfCom are actually measuring: OfCom are not measuring the typical speeds users actually experience (and this is by design), and therefore overstate the speeds consumers are likely to get. This explains why we report the mobile networks to be slower on both 3G  and 4G than OfCom, as our testing is directly measuring performance as experienced by users rather than modelling it based on controlled tests.

6) Lack of Coverage data: OfCom rely on coverage data self-reported by the operators themselves, looking at the proportion of premises covered in the UK. This metric is an attempt to combine raw geographic coverage with is impact on users, but we feel that, in isolation, it is some way divorced from the actual availability of networks for consumers. OfCom cite our ‘time on’ metric, which looks at the proportion of time users have a connection, as an alternative metric for coverage and we feel it is entirely complementary to the more traditional geographic metrics used by OfCom, as it helps put the ‘premises’ figure into perspective. OfCom’s testing methodology is not able to gather accurate data on coverage, and this means that their report on network performance cannot be entirely complete, as it only records data from where all networks are present. While differences in performance are right to be noted, and can be significant, what is more significant is the actual availability of the network itself.

The rise of independent reporting is vital for the on-going success of a competitive mobile market in the UK, and we feel that OfCom’s report is important for bringing questions of network performance to the forefront of consumers’ minds. We do, however, believe that additional useful and up-to-date information can be made available to consumers through additional techniques, such as crowdsourcing, and would encourage the OfCom [pdf] and OpenSignal reports to be read side-by-side to paint a more complete picture of the current state of network provision in the United Kingdom.

Posted in Mobile Trends | Tagged , , , , | Leave a comment

What’s in a CRM?

So you work in a startup. You’ve got an office, some staff and paying customers. Clients are rolling in and your sales team is furiously answering and making calls to get deals locked down. Generally things are going pretty well, but that spreadsheet you made all those months ago to record your first ever deal has metastasized into an unruly monster, sprouting extra tabs, sheets and links. It’s out of control, a mutant that has gone far beyond those first few neat and tidy tables. It’s time for a CRM system.

So what is a CRM system? CRM stands for Customer Relationship Management and a CRM system is a tool companies use to do just that, from managing their contacts and sales pipeline, to forecasting future revenue streams and tracking the performance of individual sales professionals. There are so many CRM tools available that it’s hard to know which to choose. Options range from the established and popular Salesforce, to midsized alternatives like SurgarCRM, and newer, smaller, companies such as close.io, Base and Nimble.  OpenSignal recently made the jump to a CRM tool so we thought we’d share our stories of how we navigated the sea of possibilities.

  1. Ask around

First port of call was asking our co-workers, friends and other startups for recommendations. Reviews ranged, but the general consensus was that Salesforce is clunky and complicated but hugely flexible, and everyone ‘ends up using it eventually’, whereas tools like Base and Close.io are cool with nice UIs, ‘get’ startups, and are far easier to use. That helped us narrow it down to those three to investigate.

  1. Go online and check reviews

The next step was to check out what the Wider World thought. There are plenty of websites that give you advice on how to pick CRMs or review individual systems, such as reviews.com and Forbes. Quora had some helpful hints, but also amusingly devolved into a tete-a-tete between CRM system co-founders, like this one between Base and Close.io. Generally reviews confirmed the recommendations we’d heard, that Salesforce is the bigger player by far but requires a significant time investment in terms of learning to use the software, whereas Close.io and Base are much more intuitive and simple to use.

  1. Get the whole sales team on board

Moving to a CRM requires considerable time investment up front to make sure that everyone knows how to use it properly. We involved our whole sales team from the beginning, discussing the process of making a sale and how this could be supported by, and recorded in, a system that minimized burdensome data entry while optimizing data analysis and learning. Each person reviewed the three CRM tools and everyone committed to putting in the time to learn the new system up front, whatever the decision turned out to be.

  1. Free trials

We signed up to free trials for the CRM systems and created profiles for everyone in the sales team to try them out.  We wanted to upload our contacts and current deals into each in order to test out how we could really use them. Before jumping in to test out each system we took time to figure out what we wanted the CRM for. Running quick reports for board meetings was key; being able to track our sales process quickly and efficiently was another priority.

We needed technical support from all of the CRM systems to be able to import our data, with varying levels of success. Close.io was first off the mark with uploading everything, although we had trouble with currencies since their system only understood dollars. Base was next, after I responded to a thank-you-for-signing-up-email from the CEO. However not all of the data was uploaded, such as the deal values, making it hard to test out what reports we could build. Uploading to Salesforce was the most complicated and required submitting a case number to their help desk. However, once a technical person was available, their support was stellar and they were able to upload all the data – confirming the assumption that they have great flexibility.  The whole sales team was also inundated with emails and sales calls from all three, so be warned – on sign up you’ll be hearing from a CRM rep!

The Decision

Though Salesforce is great for functionality, we decided we didn’t need all the bells and whistles it offers just yet, leaving us with Base and Close.io to choose from. These options were also fairly similar in terms of tracking calls, emails and providing analytics. In the end, despite it being pricier, Close.io pipped Base to the post. We went with it because of the slick UI, the flexible reporting and the useful native desktop app (apparently a mobile app is in the pipeline, which Base and Salesforce already have). Ultimately, we’ll have to keep testing and adapting as we go to see how well this particular CRM tool works for us, but hopefully taking the time to evaluate all the options up front will pay off and we can forever bid farewell to mammoth spreadsheets!


Posted in Startups | Tagged , , , , , , , , | 1 Comment

Under Pressure: Bringing WeatherSignal to the iPhone

Alright, stop. It’s time to collaborate and listen, OpenSignal are back with a brand new invention. We’re bringing WeatherSignal to the iPhone let that news grab a hold of you tightly, we’ve been working on it hard both daily and nightly. Will we ever stop? Yes, you know it, and now we can show it to all you iPhone users who have been clamouring for a version. WeatherSignal for Android is a year old, but Apple gave us new tools so it’s time to go big and bold. The app’s a barometer that sits in your pocket, if you haven’t tried it yet then you’d better not knock it, it’s a part of our wider weather crowdsourcing project.

We worked hard to get it perfect, as anything less than the best is a felony, we want you to love it not leave it, we want you to stay, glued to our app without ever needing to stray. It will get better the more you do it, we need you to share your data so we can sift through it – making forecasts better in the long run, using WeatherSignal to make meteorology fun.

We’re the first company to build an app that makes use of the iPhone 6 and 6+ barometers for science, we were quick to this point, absolutely no faking – cooking the competition like a pound of bacon. We’re on a roll as a team, no time to go solo, rollin’ with WeatherSignal 1.0 – our iPhones out as the pressure’s getting low – the users on standby, waiting just to say hi, did we stop? Of course and listened to their feedback, making sure that we were on the right track.

So now the app is out, first of its kind, WeatherSignal’s on the scene in case you didn’t know it (you really should have done by now, come on, this is the fourth paragraph yo). It’s beautifully formed – our designer Daniil’s got a style like a chemical spill, he draws lines you can vision and feel. He conducted and formed it, it’s a hell of a concept, he’s drawn it so fast other designers say ‘damn’ – if this app was a drug we’d sell it by the gram. So yes that’s the news, we’ve launched the app – come on iPhone users, get with it, where you at?

No pressure apps for the iPhone? That’s a pretty big problem – but yo, we solved it – check out the app before Pau Perez evolves it.


Photo credit: wikimedia commons
Posted in WeatherSignal | Tagged , , , , , , , | 2 Comments

iPhone Metamorphosis

The most recent iterations of the iPhone bring with them some significant changes to the Apple ecosystem. Every year we release a report into the state of Android fragmentation, a report that heavily emphasises the difference between Android and iOS in terms of the overall homogeneity of the market. We are always interested in how devices in the same series change over time, and what trends are visible – for instance, with the Samsung Galaxy series, we’ve seen the progressive addition of sensors as a significant trend. For the iPhone series, no such clear-cut developmental trend emerges. However, it’s still interesting to compare the various iPhone versions to see how they stack-up for some of the less conventional stats they can be compared for:

Weight (grams)

Screen Shot 2014-09-25 at 17.44.53

Interestingly, despite the well-publicised skinniness of the iPhone6+, it is actually heavier than previous models. Apple have bowed to the trend of increasing screen size and this is represented by a corresponding increase in device-weight.

Total Pixels

Screen Shot 2014-09-25 at 17.43.42

While total pixels do not correspond necessarily to higher pixel density (as that obviously depends on screen area), the large jump in total pixels represents the first rise in pixel density on an iPhone since the arrival of the iPhone 4. From the iPhone 4 to the iPhone 6 dpi remained constant at 326 but jumped up to 401 with the iPhone 6+.

CPU Speed

Screen Shot 2014-09-25 at 17.30.35

This is the one area where iPhones have seen a clear and steady progression, although improvements in CPU speed have slowed somewhat since the release of the 5. During earlier iterations of the iPhone, however, it can be seen that processor improvement was an important area of focus.


Screen Shot 2014-09-25 at 17.22.40

With Apple building a major marketing campaign around the ability of the user to manipulate their device to suit the curvature of their thigh, bendability is obviously an important point of comparison between various iPhone generations. As can be seen, Apple have gone for a bold 0-60 approach; going from no bendability to full bendability between the iPhone 6 and the iPhone 6+. Expect the iPhone 7 to be built entirely from silly putty.

Posted in Mobile Trends | Tagged , , , , , | Leave a comment

The Ladder of Possibilities

“Nothing is impossible” is a curious phrase. Despite its patent falsehood it is rarely challenged. A short Levenshtein distance away is “This is not impossible”, which is far more likely to hit the mark of truth and is usually what is meant in the first place. So why make such a unspecific and false assertion?

By using “nothing”, the phrase encourages us to think in general terms. It invites us to consider cases beyond the problem at hand – past occasions when we’ve considered something wouldn’t happen and then it did. This is why the phrase has currency, but it doesn’t stop it from being a tremendous cop-out, cutting short discussion of all the intricate details that determine whether things do or do not happen.

There is a second reason the phrase is tolerated: to challenge it is considered negative, even defeatist. But what can be defeatist about accepting, for instance, that you can’t have square circles, or that 2 will never be a larger number than 3?

The notion of impossibility is less appetising than possibility. Even those of use who study philosophy may only ever encounter impossibility in one of its forms: logical impossibility, the type of impossibility that forbids the existence of square circles and 4-sided triangles. Evidently this form is distant from what we normally mean when talk about possibility, it is a distillation of the everyday meaning, too potent for prolonged consumption, though an occasional sip may serve you well.

There is a richer way of thinking of possibility, introduced to me my philosophy tutor Bill Newton-Smith several years ago: why not consider possibility as having different grades? After all it’s impossible to download OpenSignal on Windows Phone at the moment, because we haven’t built it for that platform yet (sorry!) but this is not the same sort of possibility that prevents parallel lines from meeting. It’s also impossible for a person to jump from the earth to the moon (at least without the aid for some serious equipment), and this seems somewhat more impossible than downloading OpenSignal for Windows Phone (but, again, less impossible than the meeting of parallel lines).

It is helpful to think of a ladder of different grades of possibility, with each level reached new limits are encountered. Understanding this will give you a sharper sense of what can be done.

Here are a few candidate rungs for a Ladder of Possibilities:

  • Logical possibility, friend to philosophers, the top rung.
  • Physical possibility, “physical” here refers to physics, not human capabilities. This is the sort of impossibility that prevents matter or information travelling faster than the speed of light.
  • Technological possibility, allowed by current technology or technology that, to the best of our knowledge, could be produced.
  • Economic possibility, possible within the current global economic system.
  • Just-not-there impossible, “it is impossible to download WeatherSignal version 3.00”, she sobbed, “those misdirected developers at OpenSignal Inc. have spent too much time writing blog posts again”.

  • You can think of other rungs as well – for example: impossible given the time you have available, or your current skill level.

    With the exception of logical possibility, all of these type of possibility are either flexible, or have boundaries that are unknown. For instance, while we have extremely good reason to believe that nothing can travel faster than light, perhaps our current physics will be overthrown. This does not mean there do not exist things that are truly physically impossible, it just means we can’t be 100% certain what those things are. Technological possibility is even more contingent, it is not simply a case of not knowing where the borders are but of frontiers that are actively being challenged.

    Note the hierarchy of the structure, something can’t be technologically impossible and yet just-not-there possible, likewise things can’t be physically impossible but technologically possible. Impossibility trickles down, possibility does not trickle up.

    So maybe when people utter that infuriating refrain, nothing is impossible, perhaps they mean things like, “Sure, at one level this impossible – you just don’t know how to code right now, so how’re you going to build a ten million node sensor network? But, I mean, it could happen – after all there are billion Android phones out there, so get past that first rung and it can be done.”

    The OpenSignal Sensor Library
    Knowing where limits lie – and how you can move them – is much more useful than a blanket denial of their existence. This is one of the reasons why we’ve built the OpenSignal sensor library – by looking at the quantity of sensors in mobile devices right now (everything from BLE, to hygrometers, to accelerometers) it’s possible to dream realistically about the type of apps we can build.

    Maybe, just maybe, nothing is impossible is more subtle than I give it credit, maybe it taps into our innate awareness of different levels of what can be done, maybe I’m even wrong to accuse it of being a cop-out, after all … nothing is impossible.

    Posted in Philosophy, Sensors | 1 Comment