Monthly Archives: January 2014

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.

Common Prototype Mistakes

As most of us know, coming up with a great idea isn’t too difficult – it’s all in the execution.  You have a great idea – you’re going to make something that you can throw in your kids backpack so you get a text message when they arrive at school, another when they leave school, and another when they get home.  If they have a field trip that day you can send your gizmo an email that tells it to send GPS breadcrumbs every 10 minutes so you know where your child is all day long.

Easy…right?  Get a cellular modem with an embedded TCP/IP stack and GPS capability.  Connect it to a cheap micro, a LiON battery with a charging IC that runs from any 5V usb charger, write some simple code and you’re off and running.  You don’t even need a server app – just have the micro put google map links using the GPS coordinates into the body of the email and you’re good to go.  You grab some dev kits for the cell modem, microcontroller, and charging IC, string them all together and in a week you have a proof of concept system working on your desk.  Nice job!

Now it’s time to design the hardware.  You carefully follow the example schematics included with your dev kits…but you need some antennas for cell and GPS.  Hmm…your cell modem dev kit came with cable antennas that used SMA connectors – not going to work.  So, you choose some off the shelf surface mount ceramic antennas and carefully follow the layout guidelines in the data sheets.  Piece of cake – it’s going to work great.  You send the boards out for fab, buy the components from Digikey, and 10 days later you pick up 5 stuffed boards from your CM.

Now for the testing.  After verifying there are no power-ground shorts you hook up the battery and smile big when you read 3.3V on the main switching power supply.  Good job.  You plug in the programmer for the micro and cross your fingers as you watch the programming status bar creep to the right towards 100%.  Voila!  Your processor is alive and saying hello to the terminal emulator running on your PC.  The battery is even charging!  This is awesome!  Okay…let’s try the modem.  You turn on the modem and send AT<CR> and give another big smile as it sends back OK.  Your modem is alive!  You query the GPS and… wait for it… wait for it… no fix.  Damn.  You check the antenna layout and it’s exactly as the data sheet said.  The ceramic antenna is installed perfectly onto the board.  You check your dev kit setup and it’s getting a GPS fix just fine.  What could be wrong?  It’s integrated into the modem!  Hmm.

On to the cell modem.  You chose a CDMA modem so you didn’t have to deal with a SIM card and coverage is better in the US.  You type in AT#CAI? and see the base station info of the closest cell tower and -95 dBm RSSI.  Cool!  It’s working!  The RSSI isn’t great but you’re not sure how close the nearest tower is.  It doesn’t matter – it’s on the cell network!  Your modem has an AT command to send an email.  You try it and get a NO CARRIER response.  Hmm.  Wait…it’s not activated yet!  You’ve chosen the carrier with “Americas largest and most reliable network”.  They love your idea and have given you 5 development accounts provisioned as data only.  You type in your activation string, hit enter, and… your board reboots.  Hmm.  Maybe the battery is low.  Nope – fully charged.  Maybe it’s drawing more current than you anticipated.  You put a scope probe on the 3.3V bus and try again.  Reboot – but no dip on the 3.3V supply.  Hmm.  You put a scope on the reset line of the processor and try again.  Reboot.  The reset pin stays at 3.3V.

Welcome to the world of cellular M2M.  These are usually the first 2 rights of passage on the road to becoming a cellular M2M veteran.  First let’s discuss the GPS issue.  Notice that our developer used a switching power supply in the design.  They probably picked one they have used on several other designs successfully and had it all dialed in.  Well, it just happens to have a switching frequency with a harmonic that falls smack in the middle of the GPS frequency.  If you run the board from a bench supply set to 3.3V the GPS works just fine.  Choose either a fixed frequency switcher that will have harmonics outside of the GPS band or use one with an adjustable frequency that you can tune.

Okay smart guy – why does the board reboot when you try to activate the modem?  At the end of the day, it’s all about the layout.  In order for the antenna to radiate the board has to resonate properly.  In smaller products the ground plane is actually what radiates.  The antenna just tunes things up.  The point is that the RF energy is everywhere.  In our example there could be several things at work.  First, the layout should be done to minimize the number and length of traces on the top layer.  Any digital traces that do end up on the top layer should be get RF bypass caps (typically 12pF for our CDMA example).  Also, any PN junction (LEDs, FETs, etc.) should get bypass caps as well.  This will shunt any RF energy that couples into those traces to ground and prevent things like…processor reboots.  If there is the slightest mismatch between the RF port on the modem and the antenna feed the modem will think it is poor coverage and raise it’s output power making the problem that much worse.  

The lesson here is that the layout of any cellular M2M product is absolutely critical.  Just because you are using a nice neat cellular module doesn’t mean that the manufacturer has isolated you from all of the RF issues as well.  Also, harmonics can bite you when you least expect it.  Anything with a clock source should be seen as a potential spur that can effect performance.  Do the math before fabbing your boards and you will save a lot of headaches.