# GPS and Communication (802.11, BT, GSM/GPRS, etc.) ICs

I'm trying to do the preliminary proposals for a small, low power, low cost unit that is capable of reporting it's location to a central service. These devices will generally be in a small urban area, but locating them outside that area (i.e. for loss prevention) would be a big bonus. The run will be somewhere around 500 units, so [small] bulk pricing of components can come into play.

I'm expecting to use a standard 16 or 32 bit PIC microcontroller, along with a GPS chip. The part I'm stuck on is communication. I've come up with a few ideas:

• Wifi - Expensive, but excellent coverage in my target area and decent coverage outside it, simplest integration on the back end
• Bluetooth - Cheaper, but intermittent coverage in my target area and zero coverage outside it, more expensive to integrate on the back end
• 2 Way Pager - Cost ???, can't find any information (I don't even know the name for this kind of device), probably not too hard to integrate on the back end (especially if the carrier supports emails)
• GSM/GPRS/??? - No idea, just throwing it out there.
• Other ideas?

Does anyone have recommendations for the GPS and comm units?

Requirements:

• First and foremost, this needs to be geeky and cool. Frankly, that's the #1 criteria that will sell this
• Second I need to have a relatively accurate fix on-campus (about 20M ft^2). Let's say within 50 feet
• Power consumption and cost both need to be low. Like, able to run for 24 hours on 2 AAs, and the entire unit for under $50. I can dial down the reporting rate to once every half hour to achieve that battery life, though once every ten minutes is ideal • Lowest consideration is the potential to be able to find the device if it is stolen. This isn't a hard requirement, but if it's possible, all the better. • In the end I probably won't be building the hardware. If this is approved I'll get an EE assigned who can handle the hardware, but I need to figure out rough budget numbers to get it approved. – Hounshell Aug 3 '11 at 18:18 • Would it be possible to give some more detail about the type of range and environment this is in? There is a chance there might be a method you haven't thought of. – Kellenjb Aug 3 '11 at 18:20 • Comm speed isn't much of a factor. Data needs to be transmitted at most once every 15 minutes, and even then it'll be 30 bytes (GPS coordinates plus unique identifier). If I have to run an HTTP connection we're still only talking about a hundred bytes or so. I don't care about responses, so no RX capability is needed beyond the chip's requirements. – Hounshell Aug 3 '11 at 18:21 • I'd rather not go into a lot of details, but 99% of the time these will be in an office park. That's why the idea of Bluetooth came up, we could install base stations around the campus and accept any dead zones in the middle. But if one of these decides to "wander off", it'd be nice for our loss-prevention office to be able to go retrieve it. I'd define "wandering off" as being within 50 miles of the San Francisco Bay Area. Any other kinds of details that would help? – Hounshell Aug 3 '11 at 18:27 • Large range is a secondary consideration. If that's the sacrifice I have to make for the budget for these devices to get low enough (let's say sub-$40 apiece) then that's fine – Hounshell Aug 3 '11 at 19:43

This is a tall order. Let me recap what I understand from the original question as well as comments made:

You have about 500 devices, each costing about US$200 each. You want to protect them from being stolen from an office park, and ideally there would be a tracking system so they could be recovered. The solution shouldn't increase the per-unit cost much, either in initial cost or recurring (monthly) costs. Let me start my answer by telling you what won't work... GPS: You didn't say what these devices are, but I am going to assume that they will be indoors almost all of the time. GPS reliability indoors is almost zero. If you are careful you could get one to work, but metal and concrete effectively block GPS signals. Wood does block the signal, but not as effectively as metal and concrete. The point is, GPS is not going to be the ultimate solution for your location requirements. ZigBee, Bluetooth, Wireless: None of these are reliable enough to use for your communications. They would be OK within your office park, but not outside of it where you are essentially hoping that there is an unsecured network that you can use. Pager/Cell-phone: From a technological point of view these would probably be your best solution, but the monthly costs will be prohibitive. As @kenny said, US$15/month would be the lowest price.

Battery Life: With any of these solutions you will be very limited by battery life. You might get a couple of days, max, and that assumes that you have enough space to put a reasonable size battery in it and the stuff required for 500 people to charge it.

So, here are some "out of the box" ideas that might work for you. If it doesn't work then maybe it will spark an idea or two.

1. Use WiFi, but not for tracking. When the unit powers up it tries to establish a Wifi connection with the office park network. If it can't then the unit simply shuts down. In this way, if the unit is taken out of the office park it just doesn't work. While this doesn't do any tracking/recovery it does reduce the motivation for theft. After boot, the WiFi module can be powered down thus saving battery life.

2. Use medium or long range RFID to detect the unit leaving the park. For example, place some RFID readers at the doors to buildings and log when a unit goes through. Combine this with security camera video and you can identify who took the unit. The huge advantage with this is that it requires no batteries and the cost per unit is very low. The initial investment might be high, but after that it doesn't really matter if your tracking 500 units or 5,000 units. And since it's RFID, you can protect just about anything without a huge engineering effort.

Hope that helps!

EDIT:

New info: Units will be mostly outside. Location tracking is most important within the office park/campus. Theft prevention isn't top priority.

In that case, I'd just use WiFi for communications with or without a GPS for location. Maybe include a GPS but use WiFi triangulation for when GPS reception isn't quite working (since you already have a WiFi module). If you find out that WiFi triangulation is good enough then you can skip the GPS on later units.

The main issue I see with this is the expense of the WiFi & GPS stuff. I'm estimating that it would cost about US$75-100 for such a circuit, which is not an insignificant fraction of the unit cost. I don't really see an alternative that would be as practical. I still don't think ZigBee or Bluetooth is reasonable. It would work, but would require extra infrastructure. With WiFi, you can at least share the costs with the I.T. department. • Excellent points. Let me see if I can touch on them all: 1.) The primary goal isn't actually theft prevention. The primary goal is actually the "coolness" factor. The secondary goal is locating these on-campus. Locating them off-campus is a distant third (I don't want to completely remove the need for our security personnel: they're nice guys). GPS: Actually the primary use will be outdoors, which is why I thought of GPS. Given the location I could possibly do WiFi triangulation (or even ZigBee if I can get signal data), but I felt like that was best left to GPS professionals. – Hounshell Aug 3 '11 at 19:50 • Reliability: You're right. But if off-campus reliability isn't such a concern (i.e. "maybe it'll grab a signal" is ok), wifi becomes more attractive. With bluetooth the chance for a usable signal is basically zero, so there's no chance of using that as a selling point. Pager/Cell: I'm not sure what pager rates are, since I haven't had one since I was like 16... a long time ago, but you're right, cell rates are right out. Battery life: I actually don't need continuous data. I don't see any need to transmit unless motion is detected, and even then only once every 15-30 minutes. – Hounshell Aug 3 '11 at 19:56 • RFID/Cameras: Ultimately I'd like for people to be able to say "where the hell are all of the foobars" and pull up a site on their phone that says they're all on the other side of campus. Hopefully that explains the goal better, and sorry if lack of that info led you on a chase in the wrong direction. – Hounshell Aug 3 '11 at 19:59 • @Hounshell I added more stuff in my answer. – user3624 Aug 3 '11 at 20:37 • That's pretty much what I expected. Do you have any suggestions as to particular hardware to work with for each? I'm a little out of my element here, not even sure where to begin looking. I'm just looking for a starting point, so when I break down the expected costs I'm not completely spitballing (though I'd prefer the estimates to be on the low side ;-) – Hounshell Aug 3 '11 at 21:01 If you use anything based on Telit GM862-QUAD Python GPRS module then you don't even need a PIC. • Looks like this module might be over budget, but quantity should bring down the unit costs significantly. Also, with the GPRS option you could do without the GPS, just have a whitelist of allowable cells and send out an automated text if the unit locks onto any other cell. Incidentally,$15 a month? Is PAYG (Pay as you Go) or the US equivalent not an option in the SF bay area? – Mark Booth Aug 4 '11 at 18:02
• Even if PAYG drops to $2/mo/device, over the lifetime that's still$50. If WiFi costs less than that incrementally, it's a more attractive option. – Hounshell Aug 4 '11 at 21:01

Another method is a TEXT-message only over Cellular. It's almost free for the carrier, but negotiating anything lower the $15/month is tough. I have a customer who are used pager networks and it isn't described well or easy to find, but the info is out there. They are looking to move that to Cell, because I think pagers are on the way out. Wifi given the free mostly cost is probably best if you can handle the limitations of having to be near a signal since it doesn't transmit through much. • The expected lifetime of these would be about 2 years. At 500 devices * 24 months *$15/mo/device we're talking about a pretty significant chunk of cash ($360/device). The devices will be attached to something that costs about$200; it'd be hard to swing a proposal where the security plan costs more than the object being secured ;-) I agree with you on the "freeness" of wifi, but I'm worried my gut goes there because I'm a CS person. – Hounshell Aug 3 '11 at 18:49

Assuming you don't mind low throughput and some latency, I'd recommend ZigBee for something like that. Configuring the devices to create a mesh network means they could relay messages back to a single base station without needing access points spread across the whole area.

• ZigBee isn't going to work if the unit could be "within 50 miles of the San Francisco Bay Area"-- i.e. more than 50 miles away from any equipment under the owners control. – user3624 Aug 3 '11 at 19:12
• Whoops, didn't read the comment below explaining 50 miles. It would be possible to monitor the nodes for one to go missing. You might know where it was, but at least you know it left your network. – pfyon Aug 3 '11 at 19:51
• Even without long range tracking (which is optional, but nice), I'm worried about the infrastructure costs. Campus is about 20 million ft^2. Even given a generous 200 feet of range it'd take about 150 of them to blanket the canvas. Unfortunately I need for their up-time to be intermittent, which means the really cool factor, the mesh, would not help much. – Hounshell Aug 3 '11 at 20:03

There are chips from TI, BRCM, CSR etc. that combine all of the above. THese are designed for mobile phones and they include everything.

At 200$, I would go and buy an eval kit from one of these suppliers and retrofit for your app. Don't even bother developing your board (well other than perhaps a power add-on) Your volume is sufficiently small that you can do this. Since the volume is small, forget about PIC dreams, go Linux, you will have out of the box driver support and you can get it working in a matter of days. Alternative is countless days of debugging and developing, not recommended. One down side, you will not get any support from big guys, you need to find a module maker who can support you with these volumes. If you pick the right dev. kit this can be done in a matter of weeks. • I've got super-low power requirements. Like easily able to run for a day on a pair of AA batteries. I figured waking up once every 15 minutes for a quick transmit then hibernate would make me able to hit that mark, but how small/cheap/power-light can I get and still have Linux at my fingertips. The budget in these is$50/device, they'll be attached to objects worth about \$200. – Hounshell Aug 4 '11 at 20:47
• @Hounshell I see.. You are in for a lot of work. These wireless stuff, unless you use expensive modules with built in processors or linux machines are nightmare in terms of software. Good luck and let us know your approach so that we can benefit from your research – Frank Aug 5 '11 at 6:12