Category Archives: Business issues

Turning your idea into a prototype

You have your idea…and it’s a really good one.  Now you need to build your prototype.  In this post I’ll talk about what’s involved in developing the prototype of a simple cellular M2M product.

Before you start, it is important realize that a cellular M2M product is not a product at all – it is a system.  A cellular M2M system is made up of:

  • The Hardware that gets deployed in the field.
  • Application Software running on the hardware – in the cellular M2M world we typically refer to it as just the application.
  • The Carrier, or airtime provider.  This can be a large carrier like Verizon or Sprint who own their own towers, or may be a Mobile Virtual Network Operator (MVNO) such as Telit, Jasper, Wyless, or Kore Telematics who resell airtime on other companies networks.  
  • The Server Side Application – this is where the database lives that holds all of your data and displays it on a cool webpage for your users.  The server application is broken up into several different pieces – accepting connections and data from the devices in the field, storing the data in a database, and presenting the data to your user base.

To get your prototype up and running you will need to do some work in each of these areas.  Let’s discuss them one by one.

Hardware  This is typically the first thing people think of when they have their idea.  “Dude!  Check this out!  We make a puck sized device that has GPS and a cellular modem and we sell it to parents so they can track their kids!”  So what does it take to get the hardware up and running?  First, don’t worry about the form factor.  Leave that for later and dazzle potential investors with powerpoint drawings for now.  Use development kits as much as possible – these are generic boards made by the manufacturer of your major components like the cell modem, processor, power supply IC, etc.  They are usually cheap and designed to be easy to use – some distributors even give them away for free.  Best of all they are designed to be wired into other development boards for just this purpose.  The two most important dev kits are for the modem and processor.  Make sure you choose these two parts carefully so that you do not have to change parts later on when you develop your first production hardware.  I cannot emphasize this point enough.  For the processor, make sure to think ahead and don’t change your hardware too much for your first design.  Mimic the interfaces used on the dev kits whenever possible in order to minimize the effort needed to port the application software.

Application Software  This will be running on your processor eval kit.  Don’t take short cuts – remember that the choices you make in designing the application will determine how easy it is to move from the dev kits to the production hardware when you do your first build.  Even though it doesn’t do much to dazzle potential investors, one of the first things you develop should be the boot-loader.  This is the piece of code that handles upgrading the application.  You will want to start testing this early so it is rock solid when you have to do your first Over The Air (OTA) application upgrade.  Also, count on things going wrong, not right.  Until you get some time under your belt working with the cellular network you will likely have a lot of dropped connections.  Handling this gracefully will only make your final product stronger.

Carrier  Decide on the carrier you want to use early.  Usually they will provide a couple of development lines that you can use with your modem demo boards.  Be aware that these accounts could get deactivated at any time.  It’s never too early to talk about the certification process with the carrier either.  Surprises and last minute scrambles during certification can be very expensive.

Server Side Application  Again, don’t worry about being flashy too much here, but don’t make an ugly duckling either.  This will likely be the most visible part of your product and therefor your pitch for seed money.  Many times the development team consists of a firmware engineer developing code for the device and one or more people focused on developing the server side application.  One of the best things you can do to get your device online and talking to the server quickly is to have a server side developer implement the application level protocol on both the device and the server.  Many times server application developers don’t want to work this close to the hardware, but having one person develop the protocol from both ends can save time and money.

Finally, plan on things going wrong not right.  Working with the cellular network is challenging because there is no one place to go to learn what you will be dealing with.  Be prepared to spend a lot of time working through issues with the carrier’s tech support team.  If something isn’t working right on your production hardware try to duplicate the issue on the development kit.  Many times small hardware quirks can manifest themselves in strange ways.  The dev kits can be a great tool to help isolate issues with production hardware as well.

Location, location, location

Many cellular M2M products need to know where they are.  Fortunately there are several different technologies available but they vary in terms of accuracy, cost, and implementation complexity.  Here is an overview.

The first option is to use a dedicated GPS module to get your location fix straight from the satellites.  If you want to maximize your product’s ability to get an accurate location fix this is usually the best option.  Standalone GPS modules offer the best sensitivity and, depending on the module, can be seeded with assisted GPS info to help minimize the time to first fix.  They also include advanced power management options to maximize battery life.  Like any RF device though the sensitivity is only as good as your antenna, board layout and the baseband portions of the design must not radiate into the GPS band.

Another option is using a cellular modem with an on-board GPS module.  This option is very attractive for products that have to be small and board space is at a premium.  Typically modems that include GPS capability cost more than those that do not, but the cost differential is more than the cost of a standalone GPS and antenna.  Performance is usually not as good as a standalone GPS module and power saving features are more limited.  Layout is slightly easier since all you need to worry about are noise spurs and matching the trace from the GPS antenna to the GPS antenna input on the modem.

Advanced Forward Link Trilateration, or AFLT, is being used to fill in the gaps where a GPS satellite signal just isn’t available.  AFLT location fixes are determined by the modem looking for multiple cell towers, and using a combination of timing and signal strength metrics to determine where it is in relation to those towers.  The accuracy of an AFLT fix depends on the number of towers visible to the modem, so it works well in urban areas, but accuracy can be pretty bad if you’re out in the sticks.  Keep in mind that not all cellular modems support AFLT.  The other thing to consider is that carriers limit the frequency with which a device can obtain an AFLT fix in order to control the amount of AFLT traffic on the network.

Finally, Google offers a Geolocation API that allows you to send the ID of the cell tower that the modem is connected to (along with signal strength and slot information for GSM modems) and obtain the location of the cell tower with an accuracy radius that the device should be within.  The radius is not fixed – since cellular networks are  more congested during the day, a daytime fix will have a tighter radius than a nighttime fix when individual towers are handling fewer modems.  This is a pay-per-use solution if you make more than a certain number of queries in a 24 hour period and the count goes against your API key so it applies to all devices in the field, not just one.  As of 2014 Google charges between $10K-20$K annually for the business license and still limits the number of queries to around 100k.  Usually it works pretty well, but there are circumstances where it is simply wrong.  Remember – the accuracy relies on Google having the correct latitude/longitude of every base station in the US.  This is more prone to error than you might think.  Another weakness is that geography can really fowl things up.  Let’s say your device is traveling  up a hill that overlooks a valley.  At the bottom of the hill the modem may be connected to a tower close by, but let’s say that tower is obscured by a some small hills and trees.  As you climb the hill you get line of site to a tower on the other side of the valley and the modem is handed off to that tower.  Now the modem is connected to a tower miles away from the tower that is actually closest and you get an incorrect fix without even knowing it.

Depending upon the needs of the application you may choose to implement one or several of these approaches.  AFLT is a great fall-back if GPS is not available but the carriers don’t want it to be overused.  Google’s Geolocation API is great if accuracy isn’t critical, but it can be expensive.  Both AFLT and Geolocation fixes are easier to obtain that an actual satellite fix, but are not as accurate in areas where there is adequate signal from the GPS satellites.