This project and writeup are still in progress as of February 2018. See here for most recent schematics.
The idea came out of my parking situation in Cambridge. I use my car maybe once every other week, and usually leave it parked on the street wherever I can find an open spot. Because I’m super scatterbrained sometimes and haven’t seen the car in a few weeks, I’ll tend to forget where it’s parked. The end result is me walking around Cambridge for a half hour trying to find the car, and after not being able to find it having no idea if the car’s been towed or if I just haven’t looked in the right spot. Technology to the rescue!
The specs are as follows:
-A location tracker that can remotely report it’s location, independent of wifi or bluetooth
-Small enough to be discreetly placed on the dash of my car, and really just as small as possible. The bad guys of Cambridge love breaking into cars if it looks like there’s something valuable inside. On the other hand, stealing a GPS tracker is probably not the best idea.
-Relatively low cost
There are a few such devices that I found while poking around the internet. The Retrievor had a massively successful indiegogo campaign and is very similar to the product I describe. Unfortunately they’ve been unable to deliver on the promises, having cut the self-powered solar panel feature leaving the device needing to be charged occasionally. It’s also much larger than originally intended. The Lightbug is one that I found after completing my design. Coincidentally, they use the same photovoltaics (IXYS SMD series) and GSM module as I’ve chosen. I’m not sure why the photovoltaics are on opposite sides, it’s an interesting design decision. I suppose it’s good if the device is flopping around and you can’t guarantee it’ll always be pointed into the sun. Regardless, I was disappointed to see that their kickstarter campaign was not funded.
The main idea is that I text this device, it figures out it’s location and texts me back with GPS coordinates. The architecture is what you’d expect. A GSM module for communication to the outside world, a GPS module for location tracking, and a microcontroller to tie things together and do the housekeeping. Upon receiving a text, the GSM module wakes up the microcontroller, which in turn wakes up the GPS module. The GPS module reports a fix back to the microcontroller, which commands the GSM module to send a text with location back to the requester. This is all pretty routine stuff- the most interesting part of the project by far is the power generation, conversion and storage. The requirement to be self-powered and also small puts power consumption at the top of the list of critical design parameters. I’ll discuss this topic last as it’s design is a consequence of the architectural choices for the rest of the system.
It became clear very early on that GPS would be by far the biggest power hog of anything in the system. Many GPS solutions have “warm fix” and “hot fix” modes where previous GPS ephermis can be used as a starting point to speed up location acquisition and reduce power. There are also many “periodic fix” modes which vendors use to cheat on their average power consumption spec, because the device is in hibernate most of the time. In my intended application where the device gets a location fix maybe once every few days at most, the cold acquisition power is the most critical. In a typical GPS module, cold acquisition takes ~40 seconds at ~50mA.
A big appeal of this project was to gain experience with system-level RF work (in addition to taking MIT’s 6.776 RF class this semester). I would have loved to design the RF component of the system from the ground up using something like Mediatek’s MT3339 GPS IC but of course, Mediatek and most RF vendors keep documentation close to their chest, and don’t even think about wanting to buy a handful of parts. The next best thing is a GPS module which incorporates such an IC as well as supporting circuitry. These modules are available online for sourcing and documentation. Options abound for such modules. I briefly considered going with an integrated GPS/GSM module such as this or this. However, looking at them more closely they win on neither power nor size when compared to a discrete GSM and GPS solution. I ended up going with the originGPS Nano Hornet ORG1411. This one is by far the lowest power of the lot, the smallest, and has an integrated antenna which saves both development effort and space. The ORG1411 specs a cold acquisition in >35 seconds at 43mA (1.8V). It also has rich hibernate and sleep features for the 99.9% of the time that it’ll be off. There is the option to buy the ORG1411 with a built in LDO, allowing it to be run at 2-5.5V, however I wrote this off due to the lower power constraint.
The ORG1411 has three main communication methods- UART, SPI and I2C. Knowing later that essentially all GSM modules use UART I would have loved to go with SPI or I2C, however their documentation is embarrassingly poor in the ORG1411 datasheet, and I didn’t feel comfortable risking it. There’s essentially no discussion of data formats, their implementation of I2C multimaster, etc. The UART is also not documented well, however at least UART is the standard for NEMA location communication so there is documentation available elsewhere. Choosing UART forces me to mux the microcontroller’s UART between the GPS and GSM, but I don’t see a way around this short of choosing a micro with two UARTs.
The GSM module’s main purpose is to receive text messages, wake up the rest of the system, and respond with a text containing location to the original requester. Based on some research, during a request-location acquisition-response cycle it’s total energy use is much smaller than the GPS subsystem. On the other hand, because the RF front end will need to be constantly active, waiting for a text message while the test of the system sleeps, it’s “sleep mode” power consumption is of critical importance. I narrowed down the options to two- the simcom SIM800h and the Quectel M66. They’re almost identical in terms of performance, functionality and size- I suspect the silicon inside the two modules is the same. My choice would have been the M66 due to it’s better package (pins only on the perimeter of the package make hand soldering way easier) and slightly lower power consumption. Unfortunately the M66 is nowhere to be found for purchase online (as of February 2016), including the sketchy gray market vendors. As a result I’m forced to go with the SIM800h.
The 800h has an even worse documentation than the ORG1411. It has all kinds of features I don’t need- FM radio, microphone connections, bluetooth, PCM, keypad interface, etc. It is able to communicate via I2C but only with a firmware update provided by the vendor (good luck with that). Unfortunately the only other communication method is UART, forcing me to mux it’s UART signals with the GPS into and out of the microcontroller. It uses standard AT commands.
The 800h runs off 3.4-4.4V nominally, and has a 2.8V LDO internally which supplies it’s IO pads. Kind of a weird design, not sure why they did this- it essentially forces you to use level shifters unless you can fit your application in the 50mA of 2.8V allowed on it’s LDO output. The GPS’s 100mA peak won’t fit on it, and there’s no benefit to hanging only the MCU on the rail, so it’s a bit of a waste. The SIM800h can be placed in GSM idle mode via AT commands where it consumes 1.3mA and is woken up by a call, SMS or toggling of a wakeup pin. Upon receipt of SMS it wakes up to full power mode and asserts a RI “ring indicator” pin which is used to drive an interrupt on the MCU to wake it up. In full power mode the SIM800h consumes peak 2A. It doesn’t specify current during SMS transmission but I’ll use GPRS ~300mA as an estimate. As described here, in typical GSM time slot, 114 useful data bits are sent in every frame of 577uS. A typical SMS message of ~1200 bits would take ~11 frames or 6.34mS. This will be used when estimating power later on.
The GSM module interfaces with a standard SIM card using a standard nano SIM card holder. I went with this one. AT&T sells nano sim cards for their gophone pay as you go service for 5 dollars, with texts being 20 cents each. 40 cents each time to find my car, not bad!
The power goals are the following: the device is powered by solar power, with enough storage to manage transient power loads during GSM transmission and GPS fix, plus enough power for a handful of receive-acquisition-send cycles for use in cloudy days or nighttime. The initial power plan involved the use of a supercapacitor, however I quickly found this to not be sufficient – capacitors of the desired size were found to have issues in energy storage, voltage rating or ESR. Therefore I switched to using coin-cell Lipo batteries, eventually settling on this battery.
The battery’s operating voltage range (3.45-4.17V) allows it to power the GSM module (3.4-4.4V) directly without regulation, minimizing parts count, maximizing efficiency and also minimizing noise on the supply rail. Operating voltages on the GPS module and microcontroller require a buck converter to 1.8V. I went with the TPS62240 for it’s high efficiency and small size. For battery charging and power management, I went with the BQ25504 which is intended for this purpose. It’s super efficient, highly flexible for energy harvesting needs and integrates battery charging features.
Now for some power calculations. For proper operation, the solar panels need to be sized so that even in worst case operation, their power output exceeds the standby requirements of the system. In standby, the largest power consumer is the GSM module at 1.1mA (4V). The rest of the system operated at low power state consumes negligible power: GPS (15uA, 1.8V), microcontroller (1uA, 1.8V), level shifters (20uA at 1.8V). Total standby power is therefore approximately 4.65mW, or about 5.5mW after efficiency loss in power converters. For solar panels, I went with 2x the surface mount IXYS KXOB22. The manufacturer claims 22% efficiency which is probably a bit optimistic, but I’ll go with it. Worst-case power assuming a cloudy day (100W/m^2): 100W/m^2 * 7mm * 22mm * 2 = 6.7mW. Therefore there is ~1.2mW left for charging the battery, ~0.5mA. The battery selected below will fully charge in 6.3 hours, acceptable for my needs.
The second part of the energy calculation is to be sure that the battery isn’t fully depleted after a receive-fix-transmit transaction. This calculates the energy used in such a transaction. The two main consumers are the GSM and GPS module. Per their datasheets, gps consumes 43mA at 1.8V for 35 seconds, or 2.71uJ per fix. The GSM module consumes 450mA at 4V for an assumed (likely conservative) 100ms, at 0.18J. Other energy consumers are negligible. Therefore the total energy is approximately 3J, after an efficiency hit from power converters. The selected battery has a capacity of 12mAh at ~3.5V, for a capacity of ~150J. Even accounting for internal impedance and horrible misrepresentations from the manufacturer it’s well suited for my energy needs.
It’s important to make sure that the battery can handle transient power requirements of the loads, especially for small lipo batteries with high ESR specifications. This battery specs a maximum discharge of 20mA. The GPS module consumes worst case 43mA at 1.8V, or ~18mA at 4V so we just squeak under in worst case conditions. The 450mA transient current consumed by the GSM module is a very brief transient and I assume it will be handled by decoupling and filtering circuitry.
Another consideration is noise. The noise specification on the GSM module calls for less than 15mVpp noise above 1MHz. With my power supply design output LC filter of 2.2uH inductor, 22uF capacitor (200mohm ESR) and switching frequency of 2.25MHz, the peak to peak noise is 21mVpp. This will all be at or above the fundamental switching frequency of 2.25MHz. I confirmed this with a SPICE model, see here. Therefore I added a second LC filter to the output of the 4.0V power converter to reduce ripple to below 1mVpp. I added similar filtering on the 1V8 rail just to be safe.
Not much to say here. The microcontroller is the ATMEGA328P, the same one used in the Arduino Uno. It has level shifters for the UART to communicate with the GSM module, as well as the reset lines. The micro is woken up by an interrupt on the ring indicator line, which is asserted by the GSM module upon receiving a text. It then wakes up the GPS module, which receives a fix and reports back to the Microcontroller, which commands the GSM module to send a text message with these coordinates. Because the micro only has one UART interface, the Arduino software serial library is used to emulate a software UART on two other pins for communication with both GPS and GSM. A third UART is exposed via software serial for debugging. The micro is programmed using the avrisp mkii and Atmel Studio. Code will be available soon.
The board was laid out using my favorite CAD software, Kicad. I implemented it as a four layer board of 30x50mm and manufactured by elecrow. The general strategy was to have the two RF components on one side and everything else (particularly the power components) on the other side. One crucial mistake here- I initially implemented the passive components as 0201 size, thinking I could solder them by hand. After receiving the boards I was quickly humbled and frustrated. I got busy with other projects before I could remedy and respin the board, resulting in an almost two year delay before completing the project. Lessons learned!
As of February 2018, the revised board is in manufacturing. Updates as they come!