Tag Archives: gps

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.